Hacker News Reader

Comment by rapfaria | Hacker News Reader

You can send this list to everyone, and people will still struggle. Sometimes I'm just amazed at some folks that join the org and are able to finish tickets in no time. Other times, it doesn't matter how much help you provide: they start to get productive in one part of the system, but moving to another component is a challenge. Without help, they are incapable of advancing.

> Let your instincts guide you if you think something feels much more difficult than you’d expect, drawing from prior experience as necessary.

I wonder if this is the knack that so few software engineers possess, and I'm not talking about the the 10x bunch.

View on HN

I think I have the knack. I don’t think it’s anything special.

Read the code. Believe the code. Not what you think it’s doing, not what the comments imply, not even what variable/function/class names imply. What is the code actually doing?

Great, now you can fix it.

And remember: when you’ve eliminated the impossible, whatever is left, no matter how weird, is what the code is doing. Don’t be afraid to console log.

I see all the time engineers wasting minutes and hours trying to reason about code when a good print statement could answer their question in seconds.

I don't think many can read code efficiently, so people who can do that are special. People who can't have to rely on documentation or slowly trudging through.

You are right. I think that part comes with experience.

I’ve been coding my whole life (since 9 yo, am 35 now) so a lot of this stuff is very deeply ingrained.

There is a mix. Some things you can learn from the code other things you need documentation.

Often it's the domain knowledge that is hard to glean from the code. Especially when bug fixing. For example:

   The domain expert told me this output was wrong but the code appears to be doing exactly what it claims to.

Trying to get a domain expert to set down and explain why the output is wrong is a skill that took me way to long to develop. Now sitting down with a pen and paper running through the logic with an expert is one of my most treasured information gathering techniques.

One way to be sure what the code is doing is writing unit tests.

Just dumb black boxing is fine: `assert f(0) == 0`. When it returns "Pancake", change to `assert f(0) == "Pancake"`

...repeat until you understand :)

> Read the code. Believe the code. Not what you think it’s doing, not what the comments imply, not even what variable/function/class names imply. What is the code actually doing?

100% agree, but in my experience there's one more step after this. What should the code be doing? If you're lucky, you have tests or human-readable documentation that explains business rules, but in legacy applications, odds are the only way to know is find an enduser that possesses the knowledge. These are the worst time sinks.

There seems to be a large contingent of people who learn almost exclusively by rote (this is not just in software engineering). A major problem they have is generalizing that knowledge to other systems or other parts of the same system. See the many people who struggle to learn a new programming language. I have worked with people who were baffled by *nix systems (especially the terminal interfaces) because their comprehension of "folders" or "directories" was a strictly graphical one (usually based on Windows' model, but they could usually adapt to another file browser at least). They even struggled to interact with filesystems programmatically as a consequence.

I've had some success helping people break out of this, but it usually boils down to individual motivation. These are the people I struggle to work with (in a mentoring/teaching capacity) the most because they get extremely frustrated by variations and novelty. Give them a well-written procedure, though, and they're usually good. Just hope there aren't any knowledge assumptions you made in writing it that don't hold.

Reply on news.ycombinator.com