Hacker News Reader

Comment by benrutter | Hacker News Reader

There was a blog post from Peter Seibel recently called [Code Is Not Literature)](https://gigamonkeys.com/code-reading/) which pointed out that although everyone seems to agree reading code is great, very few tend to do it regularly.

I feel like I get a lot more out of messing with / hacking on code than I do from reading it. I'm sure people vary, but I've got loads more out of open source contributions to sometimes small projects, and not very much out of trying to do something like read the code for the Glasgow Haskel Compiler or something.

So for code to read, I think having an in is crucial, at least for me. So I'd say, find a cool, maybe small open source project, look at the issue tracker if it has one, and try to implement something. You'll only really know if it's good code (or why) after you start trying to change it.

View on HN

> You'll only really know if it's good code (or why) after you start trying to change it.

I like this and it is true. In addition, I have found that good code also tends to survive refractors despite having the quality of being easy to change.

The Ask HN post specifically mentioned good code but what follows are some (of my subjective) thoughts about the benefits of reading bad code. Bad code is haphazard and varied and good code is “samey”. You are a pattern matcher and this is part of your training. Good code will make more of an impact on your understanding if you have read a lot of bad code beforehand. Being able to read and understand bad code is a far more lucrative skill to have in the workplace than being able to quickly understand good code. In a big team you will spend a lot (most if you’re senior) of time reading other people’s code. Best to get good at it.

I have yet to be presented with a steaming mess of code to read and explain to an interviewer; yet it is the very first thing most new joiners face at any seniority level.

Good point on the benefits of reading bad code. One of the best developers I've worked with said he'd become a good developer by refactoring a lot of bad code.

I think the difficulty with this advice is that it's hard to know where the venn diagram overlaps between "having an in" and "good code". A lot of the code I read because I "have an in" is, I think, not very "good" in the sense of being enlightening in furtherance of my craft. It usually just looks like code I'd already write.

I typically find the recommendations people make like "here's an example of particularly good code for this particular language / style / architecture" to be more enlightening.

I think it depends a lot on the person. I will regularly read source code for projects I find interesting to figure out how they work.

It really depends on the level that you're at in your coding ability. When I was a younger programmer I had the fortune to have a CS professor who believed in reading good code and encouraged us to do so.

Nowadays if I want to learn some new thing I'll find the 'right' code to read. Someone who has done somthing similar to what I am trying to do. But when I was younger and still trying to understand more basic concepts I just wanted to read 'good' code. I wanted to know how to structure programming logic.

Now I don't want to know how to structure logic unless I'm really interested in learning some new fangled concept. Typically something having to do with concurrency since there always seem to be new ways to express concurrency in programming.

Most of the code I look to read these days is because I want to start using a new library and I want to see how someone else has done it.

Big agree. Tinkering with code to some specific end is gonna teach you a lot more than just scrolling through files, unless you're just curious about the basic architecture or how they implemented some specific thing.

Either way, have a goal in mind when reading code. If nothing else, take notes on what you learn.

Reply on news.ycombinator.com