5 ms·

I don’t like the snarky attitude in the post. I don’t work on backend systems but the problem described is similar elsewhere: less knowledgeable or naive progra

I don’t like the snarky attitude in the post. I don’t work on backend systems but the problem described is similar elsewhere: less knowledgeable or naive programmer writes a feature which looks simple but would create more work to maintain in the long run, a more expert programmer trying to sway said programmer to change the design without forcing a total change. What irritated me was the underlying sound that programmers of category 1 are always building bad solutions and programmer 2 has to fight to save the day. It feels like this person has worked to long in a bad position and started to see the world in this simple black and white form. To be fair I’ve been there before myself. I maintain a ton of build pipelines and build tools. And for a while I had the world view of them against me. Them, who by design create bad build scripts which never scale and never survive a second use-case change and me, the unsung hero who fights the verbal battle why one should not write build output into the build source directory etc. For me it boiled down to understand that these other people where not standing in line to make my life harder. They simply didn’t know or had no capacity to learn this because they also had their fair share of problems in their respective domains etc. I think there is some good information in this post. But I would have liked if it had been wrapped differently.

parentheses 3y ago
Agreed. The us/them-ness of this article immediately turned me off.
hbarka 3y ago
Agreed. If there was a thesis in there, I wouldn't have mind reading through but it became tldr and I wanted so hard to find the life lesson. I also don't understand what's hip with ignoring the uppercasing of the initial letter in sentences. In code or short tweets, fine, but in composition of an essay it looks unscholarly and pretentious.
- placesalt 3y ago
  > In code or short tweets, fine, but in composition of an essay it looks unscholarly and pretentious. I think a good general rule is: for a single sentence, not capitalizing the first letter (and not using a period) is fine. Longer than that and it both makes parsing more difficult and looks strongly like an affectation. There is a practical purpose for sentence start/end punctuation.
mspcommentary 3y ago
About 10 years ago I joined a new company, and I looked at their code and thought "what idiots wrote this?", which was strange, because everyone there was very bright. A little while later, some more new devs joined, looked at the code, and thought "what idiots wrote this?", and I was a bit annoyed, because some of that code was mine. They did a big rewrite. A little while after that, some more devs joined, looked at the rewrite and thought "what idiots wrote this?". Fundamentally, no-one likes working with other people's code or solutions. They always think that they'd have done it better if they'd had the chance.
- KnobbleMcKnees 3y ago
  It gets worse as time goes on to. Old code and teenage fashion choices have a lot in common.
- camgunz 3y ago
  I see this attitude a lot and I now kind of categorize it within "contempt culture", which I think mostly just falls out of insecurity. I've been guilty of this myself and I try pretty hard to not do it now, but life is a journey and all that. I do two things to dig out of this particular hole: - Have some (relatively) objective standards by which I judge code/a project - Have some empathy for people who were probably just doing their best, in the most multivariate sense ("I wrote this in Clojure so I didn't burn out", "I had to ship this in three days and I was just back from paternity leave", "I was onboarding a junior engineer and dumped this spaghetti in a spare 3 hours to mollify an important client" #2 is very useful because it snaps me out of contempt and helps prevent me from spreading that culture to the engineers around me. But #1 is actionable in that when I do get time to "do things right" I have some values to aim at. Mostly they're: - Does this code build/respect a coherent mental model of the problem space - Is it possible to represent invalid state - Are surprises/pitfalls noted (I'm not a big commenter in general, but this is a case where I find them useful) - Does this code consider likely engineer workflows (e.g. is it easy to add another case to handle, is it easy to enable debugging, etc.) Notably none of these are like, "methods are too long" or "variable names are too short" or whatever. I find orthodoxies like these just serve to create in/out groups and have no impact on code quality. Or, another way to say this is that if you're building a coherent mental model, your methods are probably the right size.
a-dub 3y ago
snarky gen-x attitudes can be fun, but i think these days there's a high of a risk that they'll be taken the wrong way. but yes, this is the lament of the senior developer or manager. the ideal is that people have the freedom to explore, and that they feel good for figuring things out, but that ultimately they're subtley shepharded such that they don't fall into infinite gravity wells or crash the ship along the way.

parentheses 3y ago

Agreed. The us/them-ness of this article immediately turned me off.

hbarka 3y ago

Agreed. If there was a thesis in there, I wouldn't have mind reading through but it became tldr and I wanted so hard to find the life lesson. I also don't understand what's hip with ignoring the uppercasing of the initial letter in sentences. In code or short tweets, fine, but in composition of an essay it looks unscholarly and pretentious.

placesalt 3y ago
> In code or short tweets, fine, but in composition of an essay it looks unscholarly and pretentious. I think a good general rule is: for a single sentence, not capitalizing the first letter (and not using a period) is fine. Longer than that and it both makes parsing more difficult and looks strongly like an affectation. There is a practical purpose for sentence start/end punctuation.

mspcommentary 3y ago

About 10 years ago I joined a new company, and I looked at their code and thought "what idiots wrote this?", which was strange, because everyone there was very bright. A little while later, some more new devs joined, looked at the code, and thought "what idiots wrote this?", and I was a bit annoyed, because some of that code was mine. They did a big rewrite. A little while after that, some more devs joined, looked at the rewrite and thought "what idiots wrote this?". Fundamentally, no-one likes working with other people's code or solutions. They always think that they'd have done it better if they'd had the chance.

KnobbleMcKnees 3y ago
It gets worse as time goes on to. Old code and teenage fashion choices have a lot in common.
camgunz 3y ago
I see this attitude a lot and I now kind of categorize it within "contempt culture", which I think mostly just falls out of insecurity. I've been guilty of this myself and I try pretty hard to not do it now, but life is a journey and all that. I do two things to dig out of this particular hole: - Have some (relatively) objective standards by which I judge code/a project - Have some empathy for people who were probably just doing their best, in the most multivariate sense ("I wrote this in Clojure so I didn't burn out", "I had to ship this in three days and I was just back from paternity leave", "I was onboarding a junior engineer and dumped this spaghetti in a spare 3 hours to mollify an important client" #2 is very useful because it snaps me out of contempt and helps prevent me from spreading that culture to the engineers around me. But #1 is actionable in that when I do get time to "do things right" I have some values to aim at. Mostly they're: - Does this code build/respect a coherent mental model of the problem space - Is it possible to represent invalid state - Are surprises/pitfalls noted (I'm not a big commenter in general, but this is a case where I find them useful) - Does this code consider likely engineer workflows (e.g. is it easy to add another case to handle, is it easy to enable debugging, etc.) Notably none of these are like, "methods are too long" or "variable names are too short" or whatever. I find orthodoxies like these just serve to create in/out groups and have no impact on code quality. Or, another way to say this is that if you're building a coherent mental model, your methods are probably the right size.

a-dub 3y ago

snarky gen-x attitudes can be fun, but i think these days there's a high of a risk that they'll be taken the wrong way. but yes, this is the lament of the senior developer or manager. the ideal is that people have the freedom to explore, and that they feel good for figuring things out, but that ultimately they're subtley shepharded such that they don't fall into infinite gravity wells or crash the ship along the way.