Hacker News Reader

Comment by antirez | Hacker News Reader

I think that you can't get as good as you would like to be at reading code: if you are a good code writer, then there aren't so much improvements you can get to your reading skills. Bad code will resist to such skills anyway, because bad code is full of that-bad-code-specific lack of modularity, interfaces, unexpected side effects and dependencies and so forth. You can only get good at reading better "locally", and you can get better at "navigating". But the complexity is in the global architecture and its errors, so you will have to dig, understand what's going on, what code matters, what is dead, how apparently unrelated things actually affect each other. So what I believe is the key, is exactly what somebody replied to the tweet mentioned in this post, that is: learn to write simple code, it is the real point because most of the time you read your own code, fortunately.

View on HN

> because most of the time you read your own code

This is just not the case in most software engineering jobs outside things like startups where you're on the original team, or your pet project.

In a team amongst other teams, you'll be reading code that you need to integrate with, reading colleagues' code when reviewing, and generally be producing much less than the sum of the code produced by everyone else on your team and your dependencies.

If you're the single owner of a component or subsystem, then it can be true, but that's not normally healthy for a software company - it implies a low bus factor.

You can read "your own" also as "you own team/group/...", and you as a group can have standards and quality checks on how to write good code. Especially the initial architecture of every new big system should be scrutinized with care to avoid starting with a spaghetti-system from the scratch that will hardly get better. And of course: coding standards for all.

Bus factor meaning the number of engineers who would have to die in a bus crash for the company to stop working?

That works too, but the saying is "hit by a bus".

Companies never stop working like that, they just stop being able to make changes. So many companies has huge amounts of legacy code nobody understands and they still work, that is what bus factor 0 looks like. It isn't the end of the company but it is the end of any significant innovations the company can do with that product.

> If you're the single owner of a component or subsystem, then it can be true, but that's not normally healthy for a software company - it implies a low bus factor.

Your typical company has a bus factor of 0, having one programmer who knows the code seems like a huge improvement over that.

I tend to agree with the original author more than the 'git gud' remarks for the reasons generally stated. It is important to learn to write better code, but the world will always be full of bad and learning to cope will always be valuable.

I did find that I was able to use my code writing skills to bootstrap the code reading skills. If there was code that struck me as obtuse, I would try to refactor it. Sometimes I found that the code really could be written more simply. Othertimes I found that I had missed something important about what was going on. As I did this, I learned to better intuit what the original authors probably meant and where to look for confirmation/rebuttal.

Yep. There is a limit to what bad code, just like bad prose, can tell you without having to restructure it yourself or risk losing your sanity to discover in the existing presentation. I've had colleagues whose code was totally functional and worked to achieve the desired result, and totally incomprehensible without a great deal of effort. Rewriting and reorganizing into a more sensible flow (aka, refactoring) was the only way to discern the real meaning behind the code. Code reviews are helpful here, to keep code like that out of production and give feedback so less code like that gets written in the first place.

Today's code-reviewed perfection is tomorrow's mess, unless you refactor as the domain drifts away from the original model.

Code reviews can only enforce existing practices and style, rethinking architecture is a different matter.

The author seems to be say in the article that writing readable code, at least for yourself, is still an important goal. I think they are arguing against why a writer shouldn't be expected to take it further.

For example, should a new grad be able to read your code without help? Should a 5 year old? At some point, you are spending more time writing design docs, refactoring the code, simplifying the tests, and gathering learning resources than you are just writing code that works.

Newer engineers rarely hear about how much they need to learn to read good code, and how much disagreement there is about what good code looks like. As a result it is easy to get into the mindset that "surprising" or "complex" code is bad. Instead, it would be a lot better if engineers are encouraged from the start to see reading code as a challenge. Nobody starts off knowing grep, folder organization conventions, go-to-definition shortcuts, and architectural design patterns needed to understand certain pieces of code.

To improve yourself, you are better off focusing on writing code, but at the organizational level, it's better for the team if people are willing to assume that reading code and writing readable code aren't an easy tasks.

> because most of the time you read your own code

I think this is probably more true for you than it is for us corporate schlubs :)

For those of us with less talent at writing a unique piece of code, the process of diving in and figuring out a mess is actually a learned skill that we get better at over time, possibly the most important one.

Reply on news.ycombinator.com