Comment by dataflow | Hacker News Reader

Comment by dataflow | Hacker News Reader

Parent Full thread

I disagree strongly with it on multiple fronts. That concern should be secondary to your program actually doing its job well. Your customer will literally not care how elegant or ugly your code is; they just see the end result. And when the program fails them, it really doesn't matter to them whether your juniors understand the code or the error. Moreover, not every abstraction is (or can be expected to be) accessible to an entry level engineer. Some technologies just take a long time to master, and doing that can also require higher-level abstractions.

So I would say great code is code that:

1. Does its job well (robustly, performantly, etc. in whatever proportion is applicable)

2. Is maintainable by engineers with reasonable expertise in the tooling

in that order. If you can manage all that and make it accessible to your junior devs, that will of course make your code greater. But don't lose sight of what your customers care about. Your business isn't there to make you feel good about maintaining code, it's to provide customers with value.

It really does matter to the customer if the junior understands it when the code fails though.

Easy to understand code can be more quickly patched and repaired by anyone on the team. If you don't need to call in the senior who built it two years ago to repair it, and you can have someone do it right away, it is better for the customer.

Assuming that senior is still working there.

I never said it doesn't matter. I said it matters. What I'm saying is the scenario you're portraying literally cannot play out pretty much by definition (and also empirically, from what I've seen) unless you accept that code readability for juniors is secondary to program quality. When you make readability your primary concern, it comes at the cost of fixing certain bugs and design issues... precisely because the best solutions may not t be trivial or easy to understand by the junior folks 100% of the time. So you never get into your purported state where everything was well designed and implemented in the first place and now you have to worry about getting a junior to fix a bug. Everything ends up clunky from the get-go and you never get a high-quality, robust program at all. Just something of mediocre quality with a ton of patches from devs of all level to get something like 85% working, shipping with know issues you could've avoided if you hadn't artificially restricted yourself and tied your hands behind your back for the sake of the juniors.

It depends on what you're optimizing for. I like to think of it this way. A good "programmer" can take ideas and turn them into working software that is performant enough, meets all of the requirements, etc. This is a mostly static operation. A good "engineer" can take ideas and turn them into working software that can be changed, updated, and maintained for years to decades by multiple programmers.

There are code bases at my current employer that are entirely "ok" and still being worked on from before I was able to spell my name. Projects that have had continued development for >20 years by armies of engineers and the code is still readable and simple to understand.

As with all software engineering, it’s all about trade offs and context.

That performant code that you wrote maybe at the expense of readability? It could very well become bad code when you leave the company and it falls to a junior engineer to modify it to fit some changing business requirement. Or, there’s a bug in the code and the amount of time it takes to fix it is a direct function of how quickly and completely that junior engineer can understand the code.

For me, the hard part is knowing when and how to make that trade off. I’ve definitely erred on both sides often enough.

I strongly disagree. You're packing a bunch of different metrics of quality into a single bullet and somehow suggesting those are separate than the second bullet point. Readability is just as dependent a metric as the others. If you make things that are hard to read, I can guarantee they are not going to be robust, as well as likely not performant.

In my experience, the easiest to maintain code is very often the most efficient and robust as well, because people haven't felt the need to hack around it at every corner.

This assumes you are absolutely certain you know what the code should do. And that it does what you think it does. Hence while you might think “performs its task” is an easily defined I’d disagree. I’d take clear code that wasn’t working over code that was hard to reason about and somehow worked every day.

> I’d take clear code that wasn’t working over code that was hard to reason about and somehow worked every day.

Then you'd be out of business.

No because I’d fix the easy to fix code, and make it work correctly. The other code is useful for sure. I mean people have built billion dollar businesses on crap software that barely works. And very rarely do they manage to fix them... I’m just suggesting I have a preference for what I’d rather work on. You might like code that works and is impossible to understand and sits there surrounded by an even more obtuse test suite (if at all), but it’s not something I enjoy is what I was saying. To some degree this is inevitable but I think it’s always worth trying to fight the good fight.

I look at it this way:

Most likely the code I write has a bug in it. Or, at the time of writing, the customer requirement is fuzzy. Or, I have a limited grasp of the problem domain. Even if it is not any of the above, most likely there will be a change in a business requirement that impacts the code.

So whenever possible, I opt to write code that is either stupidly obvious, trivially testable, or easily replaceable.

You have explained it much more clearly than me! Thanks.

This is my extreme counter example:

What is better (A) a compiled bug free binary, or (B) well written source code that has a few bugs?

If you want to keep developing the software, the answer will always be (B).

This is not generally true, but strongly depends on the domain.

I which domains is it practical to add features to software you don't have source code for?

Exactly.

How many entry level engineers come onto a project per year? 5? Is onboarding them onto the project is a deliberate and streamlined way such an undue burden that you must change your programming style to avoid it?

It's not only about new hires. You will have to figure out things about code that you wrote 3/6/12 months ago.

But you can write code you can understand 12mo from now but have that same code be inscrutable to a new hire. Definitely different litmus tests.

Reply on news.ycombinator.com