81–90 of 93 posts
It sounds like the author is conflating sophistication with complexity. In my experience, "simplistic" programming leads to greater complexity. It is the very sophistication and use of more advanced programming and structural patterns he rails against that in fact enables concise, maintainable code.
There is a major problem with how programmers are judged. Say you are given a seriously challenging and apparently problem; that is to say the naive approaches are all hideous train wrecks. You work on it long and hard, until you have a key insight that allows you to implement the simplest most elegant solution. Now a naive observer will look at it, say well that's obvious, and then ask why you wasted a week to write…
Anyone who thinks more lines of code equals better software should not be working in this industry. Hopefully the naive observer you're referring to would be someone with no background in software development
These people are often management, unfortunately.
Your apparent mental prowesses will fail to impress those who find it easy to do the same. I have met my share of college students and professors who excel at dropping the name of a few philosophers, at using words only 1% of the population knows about… but, at a certain level, it does nothing for them. People simply roll their eyes and move on… Solid life advice.
My pet peeve on HN is people writing comments like they're gonna be peer reviewed. Either the less common words that they use are obviously out of place like someone just discovered a thesaurus ( conflated is my favourite example), or it's consistently formal and quasi-academic so I have to put extra effort into reading it. Either way it just makes the authour sound like a pretentions wanker.
I consider myself guilty of doing this, but that's because (most of the time) I actually proof-read my comments before posting them, and consider whether they provide a useful addition to the discussion. If one of my comments look like they're going to be peer-reviewed, it's because they're self-reviewed, and you don't get to see the long tail of comments that I typed out and then deleted because a) they didn't add anything useful to the discussion or b) I could not express my thoughts clearly enough.
There is a major problem with how programmers are judged. Say you are given a seriously challenging and apparently problem; that is to say the naive approaches are all hideous train wrecks. You work on it long and hard, until you have a key insight that allows you to implement the simplest most elegant solution. Now a naive observer will look at it, say well that's obvious, and then ask why you wasted a week to write…
Earlier quoted context omitted.
Yep. "Orthogonal" is one of my favorites. Along with "order of magnitude".
“order of magnitude” is a pretty useful concept, to be fair.
"The server is an order of magnitude faster than our old one."
"The server is 10 times faster than our old one."
--
More often heard: "The server is an order of magnitude more performant than our legacy server."
I've been thinking about this lately, too. I strongly believe this, to the extent that I have a preference for code which is simple but incorrect over complicated but correct. Obviously simple and correct is best, but if I can't get that (at least in the short-term) I would sacrifice correctness for simplicity. You can often incrementally improve a simple solution, but it is very difficult to simplify a complicated s…
I think the sentiment is also true for devops/infrastructure. I like to use the term "minimalistic" instead of simple, because I think some people associate simple with naive and slapshod.