[tristanstcyr]

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.

[gfodor]

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.

[hinkley]

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.

[shantly]

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)?

[hinkley]

Interesting. You know, I would’ve sworn I had a pat answer to this question, but it turned out I had to think about a little bit.

They say that some of the most rewarding interactions for teachers are the ones where they learn something, not jus the student. Every once in a while I get an example of that in real life.

So what are some examples? Programming language is often difficult to change. This is sometimes listed as a pro for microservices. Because I get to change my mind for every new area of the app, which makes it cheaper to reverse directions.

The most obvious answers that I have are load balancers and external caches. I shouldn’t have a big knockdown drag out argument over haproxy vs nginx. Now, a load balancer is almost a given. It’s possible that someday in the future, someone will invent an SMP machine with 256 cores that gets some economy of scale by running a whole website on two machines. It’s easier to reduce the number of machines behind a load balancer than it is to add a load balancer to a mature product. So put one in, but don’t fight about which one. We don’t know if we need haproxy features, or if we want paid support from nginx now. Just flip a coin and move on.

Similarly, external caches are usually easier to turn off than internal ones. With internal caches, people start to pass around IDs instead of objects, assuming object lookup is “free”. It becomes integral to the information architecture. A rat’s nest of lazy and duplicate lookups. External caches are cheap but never free. Access tends to leave bigger footprints in the code. And there’s some small hope that you can get a direct lookup down to a small multiple of the cache lookup time if it really becomes necessary.

Database architecture is another big one, for certain dimensions. Going with Oracle is hard to take back. MySQL vs Postgres is smaller. KV store versus MVCC SQL database is also harder. For a prototype it might make sense to pick one that is obviously a placeholder, like SQLite, until you know what your customer’s needs really are. Do they need audit trails? Are they addicted to graphs? Multitenant security? On and on. You can stave off fights with SQLite because it’s effectively a promise to revisit this later.

[gfodor]

If you thread this up to the product-level, opportunities abound. For example, instead of storing data for a feature, see if you can get half the feature without the data storage. Or, if a certain feature is going to require a major shift in the way the UI looks or works, perhaps there's a way to blend in a v1 to the existing metaphors that can be replaced later. Etc

[taneq]

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”.

[cs02rm0]

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.

[mr_tristan]

> 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.

[pm90]

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.