Hacker News Reader

Comment by seanmcdirmid | Hacker News Reader

Writing dumb code is a lot more expensive up-front than writing smart code. It is like writing something in simple-to-understand prose; that costs more on write than hard-to-understand prose, but pays off when read.

So I feel like the author of this essay is talking about some costs (the reader's) without considering the cost of the writer. If the code is never read because other solutions are considered more viable, then all that cost in making it simple for not. As always:

1. make it work.

2. make it nice (if it works and is going to survive to code review).

3. make it fast (if it has performance problems).

Unless you are completely on waterfall, you aren't going to be able to do 1. and 2. concurrently.

View on HN

I'm not sure if it's more expensive either. The first correct algorithm I can think of, expressed in the programming equivalent of pre-K level English, usually is less buggy and 10X easier to maintain than the advanced-language-feature-filled code that certain engineers love writing. And it takes a fraction of the time to write because it doesn't require much refinement. Is it slower than finely tuned C++? Yes. Does that matter? michael-scott-NO-GOD-NO.gif

It boggles my mind when people who are just building an everyday website decide that querying models from the DB means we need a multi-level class hierarchy that requires a 5 page paper to explain. Or that anything remotely related to math means we need to start overloading operators. Congratulations! Your brain recognizes patterns! Wow, someone should make you the President of all Engineers Everywhere.

The code you're writing now will likely not survive another 2 years, especially if every time there's a bug or even a question like "how does feature X work under condition ABC?", everyone shrugs their shoulders and has to read 1000 lines of horribly nested abstractions.

> The first correct algorithm I can think of, expressed in the programming equivalent of pre-K level English

If I can think of it, then I hope it already exists and I can just reuse it. The tricky stuff that needs a lot of thought is the same stuff that you can't just reuse off the shelf.

> It boggles my mind when people who are just building an everyday website

If it is something so routine that it doesn't need to really be designed, then I guess you can do it right the first time from memory (shame you just can't reuse some functionality if it is so routine though).

> The code you're writing now will likely not survive another 2 years

I work in research where your code is lucky to survive 2 months. I don't disagree with you, but you can't crank out perfectly simple code on the first go if the design space is clear. Those abstractions usually don't exist because the programmer was trying to be clever, they often exist because the programmer was trying to solve the problem. Its only with hindsight that we can often see a better more simple way (and hopefully have time to go back and do the simpler way).

> If I can think of it, then I hope it already exists and I can just reuse it.

There is also a cognitive load of 'using it' for simple algos and packages, like left-pad. Some end up the de facto standard of a community (Python's `requests` package), but other communities fracture (Node's SuperAgent, Axios, got, Request, reqwest, ...).

I like to think of code I write today as automatically being 'obsolete' 12 months from now. I might not replace it +12 mo, but if I _were_ to replace it, what comments, patterns, and hints might I leave my future-self to make that easier? Simpler code is easier to test and replace. Less magic code is easier to swap out with other languages. Verbose code is easier for my new team of +N engineers to digest, even if it takes twice as long to read.

Reply on news.ycombinator.com