Hacker News Reader

Comment by nailer | Hacker News Reader

> Focus instead on writing code you can throw away easily, code that you are wholly unattached to and is isolated enough that rewriting it won’t cost absurd hours.

> Good code is highly maintainable so that you can continue to meet business objectives in a timely manner without regressions.

I think you essentially agree on what people should do, regardless of whether you call this 'good code' or just maintainable code.

Write tests. Give things good names. Use comments to explain why you're doing something, not how to program. Don't copy and paste the same implementation x times because that way there's only one place to fix it.

View on HN

> Don't copy and paste the same implementation x times because that way there's only one place to fix it.

But also sometimes it makes more sense to copy and paste over trying to fit an abstraction where it shouldn't be. :)

I think the purpose of questions like the ones by OP is not to figure out "rules" (which are useful only for beginners) but to figure out where and why rules were broken. Sometimes (often) the answer is time, but that in and of itself is a useful example.

Good intermediate (I suppose Sr. in our industry) level code is notoriously difficult to find examples of and mentor toward.

>But also sometimes it makes more sense to copy and paste over trying to fit an abstraction where it shouldn't be. :)

depends on goals. diverging modules should be copy-pasted, two modules that rely on the same functionality should be consolidated (not necessarily abstracted, but synchronized somehow). Those are both two common cases, so there's no general advice on which is better.

>Good intermediate (I suppose Sr. in our industry) level code is notoriously difficult to find examples of and mentor toward.

so much industry code and knowledge is proprietary, so I imagine that is by design. even intermediate code has a bunch of value to a company, even if the company lets go of that engineer to make their earnings report 0.1% higher.

> But also sometimes it makes more sense to copy and paste over trying to fit an abstraction where it shouldn't be. :)

I find that's a smell of limited languages: Maybe a language has poor error handling semantics, maybe it's not expressive enough to make a parameter generic.

It can also be a smell of not understanding the language well enough, too. Maybe there is no need to copy and paste, but the programmer didn't understand the language well enough to make a generic abstraction.

I agree. I've had the unfortunate experience of moving from more expressive languages and interesting problems to less expressive languages and boring problems as the size of my TC and company go up. :')

But you can only do what your tools allow you to do.

Reply on news.ycombinator.com