For a while, I worked for a manager that wore a lot of different hats on our team, including that of “product manager.” Sadly, that meant he was often really busy and thus hard to pin down to get a product answer from. He knew that this was an issue, and wanted to get a full-time product manager for our team. At the time, I was thrilled about the idea. Fast forward a few months, and a little reorganization later, and our team now has a dedicated product manager, and I’m regretting my earlier enthusiasm. There seems to be a disconnect between product people and developers, so for any product managers reading this, here’s a few tips to help improve your interactions with developers.
By now, a lot of us have read Susan Fowler’s tale of her year at Uber. It’s certainly not the first time Uber’s been accused of misconduct, and to be honest, the only thing that was surprising in Fowler’s post was just how institutionalized this behavior was, and just how hard so many different people at the company work to defend it. Fowler’s post describes a company that is being run wrong in just about every way imaginable, and it seems Uber’s most noteworthy success is not having been sued out of existence already.
The team I’m on at work currently has a remote developer. He’s very good, but he lives in another country, and is technically a contractor and not a full employee. That means there are restrictions on what he can and can’t have access to or do for us. These limits have started me wondering, at what point is a remote developer’s ability to contribute so limited that it limits their value to the organization as a whole?
Software development is all about making tradeoffs. Sometimes, we do stuff because it’s quicker and get things out of the door faster, not because it’s the best option long-term. Do software development long enough, and you’ll learn the term “technical debt” – which is formally defined on Wikipedia as “a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution”. A more informal, but probably just as accurate definition could also be “the price(s) you’re paying now to have shipped things earlier.” Here’s the thing, most of the time we do something that incurs technical debt, we know it then. It’d be nice if there’s a way for us to log the decisions we made, and the debt we incurred so we can factor it into planning and regular development work, instead of trying to pay it off when there’s no other alternative.
We all work with somebody who’s day job appears to be best described with phrase “has and attends meetings.” Think of any product or project managers (there’s a difference between the 2 I’m told, but I couldn’t tell you what that was) at your office. They’re always in meetings, and it’s not at all uncommon for them to insist that you join them. In fact, it seems like the more you work directly with these managers, the more time you spend in meetings. The thing I have a hard time understanding is, if all you’re doing is sitting around in meetings, then at what point are you doing anything valuable for your employer or their software? Continue reading »
Recently, my friend Steven Hicks published blog post on complex software. Despite his claims early on in the post, what he’s describing is exactly a documentation problem. Nobody actually takes time to document how to install and configure these services and as a result you never really know how to get these things to ever work together. While it’s comforting to know that he believes complex products are perfectly viable, the issue isn’t that people aren’t making complex products, it’s that the usage guides for the products out there suck.
APIs are tricky things to maintain. Because they’re designed to be open by nature, it’s hard to test every possible way someone could use it. That makes incredibly easy to break if you don’t think through any changes you’re making carefully, with an emphasis on what a developer is expecting. Luckily, there are a few things you can do to limit the amount of times you inadvertently break a bunch of applications with a well-meaning API update.
I transferred teams at work recently, and spent about a week trying to get their code running on my laptop so I can do useful development work. This is in addition to trying to wrap my head around the existing codebase and figuring out how to test my changes. It’s not that the code is bad, it’s just getting all the ****ing components hooked up, communicating with each other, and playing nicely together an exercise in impossibility. Coming from a group that ran everything in AWS, going back to managing all the third-party services in a development environment makes me want to flip my desk over and start screaming about what the **** is wrong with everyone.
1 of the most common themes around any startup these days is how they intend to “disrupt” something. Founders aren’t saying they plan to “disrupt” something as a consequence of what they’re doing, but rather using the term like it’s an actual objective – “disrupt the {industry name here} industry.” Here’s the problem, I don’t go into a store, online, or pay people to disrupt something, I pay people to either give me a thing that I find useful or at the very least want, or to do something that makes my life better in some way. “Disruption” isn’t either of those things. Continue reading »
You’re sitting there at work and word reaches you that your application is misbehaving. What’s the first thing you do? Pull up the logs and see what they say. And this is where you may wish that you had an entire class in school dedicated to the art of writing useful log messages. Good logging is an art, and it’s 1 that most of us don’t learn until we’re stuck trying to diagnose something in the wild with subpar messages to guide us.