Hacker News new | ask | show | jobs
by mcapodici 348 days ago
I agree with the ideas at a high level, but not sure if we can tag people as “Junior” and “Senior” and make these broad strokes about how they think.

We should think of it in terms of “Theory Builders” and “Just get it done-ers”, and think of them as states of mind, rather than a character trait, or something linked to years of experience.

You may have a theory builder straight out of university (after all many go on to do a PhD straight away!), or a theory builder who has the mindset and just came in from a different profession. Or an 8 year old theory builder! You may have someone with 10 years experience writing code who still slings code.

You may also have one person who was a Theory Builder on Monday, and became a "Get it done-er" by Friday due to a deadline.

3 comments

Or the person that starts off in "get it done" mode because it looks trivial, notices that it's not and then takes a few steps back to think it through first.

Honestly, these opinions are almost always grounded in people not being honest with themselves, feeling superior to their colleagues and coming up with a character trait and argument why they're just fundamentally better

Sometimes they even are, at least to a degree. No idea wherever it's true in this case, as I know nothing about Christian Ekrem beyond this article.

The article is about Senior Engineers where time spent is a huge factor in the distinction. It would be more that theory building becomes a tuned skill for an engineer over time as a fundamental result of their job than whether they use it every day, started with it as their primary method, etc.
I personally think one does a lot of the theory building while you're getting it done because you're building something new and can't predict the kinds of issues that youll encounter.

Any sort of software that's architected only in flowcharts and uml by 'pure architects' are absolutely worthless to anyone but business people.

I agree that there needs to be a feedback loop including the system and decision makers (I also have a distrust of non-contributing 'architects').

However, just because you can 'get things done' in the current system doesn't imply you have a good enough theory for maintaining it sustainably. I've often seen self proclaimed 10x coders who trade healthy shared theory for mean time to deployment too aggressively.

They are fast, get praise and pay, then move on before the negative effects of their short term strategy becomes clear.

Another job of 'senior' devs is to point out to the business when this is happening.

Among magazine staff there’s a saying about “senior editors”: senior to whom, editor of what?