Comment by tristanstcyr
6 years ago
Rather facile advice.
As a software engineer, it's your responsibility to build the product according to the requirements. Sometimes that means it needs to be built it quick because it's likely to have a short life, or it needs to land quickly to market. Sometimes, you need to get things right, otherwise you end with an insurmountable amount of technical debt and a business that grinds to a halt.
Given this, you should make the analysis to understand the tools that you need. If that means learning, then so be it. Maybe you can keep going with superficial knowledge. Or, perhaps you need to find an expert, that's fine too.
As for growing in your technical knowledge, that should be agreed upon with your employer or whoever is paying for the work. If you find that you work somewhere that doesn't allow you to learn then perhaps it's not the right place to be.
Think like a professional.
The problem is it’s extremely hard or often impossible to know what are good choices before you’ve started building the product. This, combined with the fact that software is highly malleable, should lead one to highly prefer a bias towards action vs analysis. It’s not a hard rule, but it’s much more common for people to fail due to analysis paralysis than due to poor technology choices. If you are able to get any form of traction, opportunities open up to expand resources and time that will be needed to adjust technologies. It won’t necessarily be fun, but when going through such an experience I believe more often than not engineers have hindsight bias, not a true recognition that early choices were made objectively incorrect given the knowledge at the time.
I’ve seen plenty of project grind to a halt from bad decisions and high pain thresholds. I think you’ll find and even mix in the overanalysis crowd of white tower thinkers and people exhibiting allergic reactions. If you are seeing more of the latter I have two theories. One, those people gatekeepe projects, so once bitten twice shy (ie they accumulate and add friction) or two, you are looking at more early phase startups than me. A seed phase startup locked in analysis never sees my resume, so I don’t see how often that happens.
But the trick is to start with the new Reversible decisions.
We don’t always know which are the reversible decisions, but many of the irreversible ones are obvious. For some reason developers always focus on the irreversible one. We reason that we have to get this right, because it’s very important. And if it’s important, we should do it first.
No. No. No.
If instead you start tackling all the reversible decisions first, you can make those choices quickly (because changing them is cheap, spending a lot of energy on making them is a waste of time and capital). Start building something. Get momentum. Get the team and ideas to gel.
When you start to know what you’re doing, then tackle the irreversible decisions one at a time.
But typically, everyone wants to Decide. And they want you to decide on short notice, right now, like some sort of used car salesman. If we don’t tolerate this from others, why do we tolerate it from our teammates?
Deciding for the sake of deciding is not productivity. It’s painting a floor when you haven’t identified a workable plan yet. There are always at least four corners, and rarely more than two doors. The odds are not in your favor.
I'm having a hard time following what you mean. Could you give some examples of an irreversible decision that can be deferred in favor of some other specific reversible one(s)?
2 replies →
Exactly. You should aim to build fast, at least at first, but it needs to be understood by all that this is part of “build fast and iterate”. It’s not just “build fast and stop”.
As a software engineer, it's your responsibility to build the product according to the requirements.
Ah, the solid, dependable base that is the requirements!
I'd question the reason to wait. Shove it out the door so you can learn. I say that because I'm a professional and I've seen many projects fail before seeing a single user. I've never seen insurmountable technical debt grind a business to a halt. Not once.
> I’ve never seen insurmountable technical debt grind business to a halt. Not once.
I’ve seen this happen more then once. The best and brightest tire of the crap and leave to go do other things; and those who stay erode the culture into a cesspool of negativity. Sure the business trods along for a while but often the products just enter a phase of slow death and irrelevancy. At some point there’s some kind of private equity acquisition or transaction which just temporarily delays the inevitable.
To be clear, I’m not arguing for “strict requirements”. Just that the professional engineer is who needs to distill the chaos into clear and ready action. And, that “just ship it” can sometimes come with cost.
These articles usually come across as flippant. They are written from a small business or early phase/unproven startup point of view. Sure, don’t waste all your time tweaking tools, but at the same time, make sure you’re not shooting yourself in the foot because of the 50 kludges put in place that overlooked security or performance considerations.
I guess this is just a way of saying “there is no silver bullet”. “Just ship it” doesn’t always work.
This article was shared by a product person in my team who was genuinely motivated by it to "ship more, ship often" as he described it. People are gullible af.