Hacker News Reader

Comment by QuercusMax | Hacker News Reader

I think part of it is that reading code isn't a skill that most people are taught.

When I was in grad school ages ago, my advisor told me to spend a week reading the source code of the system we were working with (TinyOS), and come back to him when I thought I understood enough to make changes and improvements. I also had a copy of the Linux Core Kernel with Commentary that I perused from time to time.

Being able to dive into an unknown codebase and make sense of where the pieces are put together is a very useful skill that too many people just don't have.

View on HN

Being good at reading code isn't a skill that helps large software projects stay on rails.

It's more about being good at juggling 1000 balls at the same time. It's 99.9% of the time a management problem, not a software problem.

The successful projects I've worked on, the technical staff have been given autonomy, responsibility and full insight into the problem space. This requires managers putting a lot of trust in the engineers, but it works.

Large projects I've worked on failed simply because nobody wanted the solution in the first place.

In government I've seen many millions spent on projects that were either forgotten about or the politician that requested it lost office.

Reading (someone else's) code is a whole lot harder than writing it. Which is unfortunate because I do an awful lot of it at work.

I'm curious, what does "read code" mean to you? What does that skill look like and how is it taught?

You’ll notice that more senior engineers are often much better at giving useful review comments, and they will do it faster than you, thats just a skill that seems to come with experience reading other peoples code(or your own code you wrote two years prior). It can’t be taught, only practiced, same goes for reading other types of technical/academic works.

Not GP, but the general idea is the skill to take a piece of code and understand what it does by reading the code itself (probably in an IDE that can help navigate it meaningfully), not relying on docs or explanations or anything else. Surprisingly few people are comfortable in doing this, and yet it's very common in any large software project that lots of parts of the code are undocumented and no one remembers the details of how they were written.

Precisely. I don't assume any documentation is accurate unless I've verified it matches the behavior of the code - and I've run into some doozies in my day.

The worst was a custom-built copy protection scheme that was built by a former (?) software cracker who designed it to be difficult for someone of his skills to reverse engineer. It took me a week tracing through the code to understand what it was actually doing so I could extend it to add more options.

Oh TinyOS! Did my thsis on that!

Reply on news.ycombinator.com