TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Reading code is a skill (2020)

155 pointsby historynopsover 3 years ago

24 comments

bit_logicover 3 years ago
Reading code should completely replace all the coding portions of current technical interviews. There&#x27;s a lot of issues with writing code under interview conditions, many tech interview threads here and other places have covered this. Reading code avoids all those problems. And if someone can explain well what a piece of code is doing, then of course that person can also write code. How can you read without knowing how to write? And reading code also allows showing the depth of experience much easier in an interview setting. For writing code, the leetcode answer from a junior or senior is going to look exactly the same. But while a junior and senior may both adequately explain what a piece of code is doing, a senior can show more of their experience by discussing how it could be improved for readability, maintenance, and other engineering factors.<p>Reading and writing are two sides of the same coin. So why not test for the side that works much better for interview conditions and also allows more signal between a junior vs senior levels of experience?
评论 #28600513 未加载
评论 #28600135 未加载
评论 #28602831 未加载
评论 #28616417 未加载
评论 #28600667 未加载
评论 #28605003 未加载
评论 #28601814 未加载
theshrike79over 3 years ago
The ability (and willingness) to dive into legacy codebases and make sense of them paid my bills for a good 15 years after graduating with a CS degree.<p>It was fixing bugs and adding new features to existing code, usually stuff that was 5-10 years old at the least. If I didn&#x27;t understand something I needed to wait for That Guy to show up. The one who did the first version some time in the last millennium.<p>Latest versions of anything was a pipe dream. Java version was at least 1-2 major versions behind the time. Business logic was PL&#x2F;SQL and Perl scripts old enough to have a driver&#x27;s license.<p>Also: print-debugging all the way. There were exactly zero ways to attach any kind of modern debugger to a 20 year old pile of code that had organically grown to what it was at the time.<p>I think I was 16-17 years into my career before I started a greenfield project from scratch, one I could decide the full tech stack from top to bottom.
评论 #28599360 未加载
评论 #28599100 未加载
评论 #28601240 未加载
评论 #28600481 未加载
评论 #28599196 未加载
hoshover 3 years ago
I remember reading a much older article posted here. The author recounted his time working with two different coders, and how he admired and respected each of them.<p>One was very skilled at reading code. That skill didn&#x27;t just help him with being able to understand easy to read code, but also to understand difficult to read code. This allowed him to go through the tech stack to find out what is wrong.<p>The other was very skilled at writing readable code, and more importantly, structuring its abstractions and interfaces just right. The primitives provided were exactly what he needed. Sometimes, when he wanted to expand the functionality, he finds out there were already primitives he can use for that expanded functionality.<p>It&#x27;s not like you can&#x27;t do both, but they are distinct skills and useful in different ways.
antirezover 3 years ago
I think that you can&#x27;t get as good as you would like to be at reading code: if you are a good code <i>writer</i>, then there aren&#x27;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 &quot;locally&quot;, and you can get better at &quot;navigating&quot;. But the complexity is in the global architecture and its errors, so you will have to dig, understand what&#x27;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.
评论 #28599041 未加载
评论 #28599202 未加载
评论 #28598994 未加载
评论 #28599575 未加载
评论 #28600039 未加载
JohnBootyover 3 years ago
The only thing harder than &quot;understanding bad code&quot; is &quot;explaining to your manager why you&#x27;re going to need oodles of time to accomplish simple things because the code is bad.&quot;<p>I&#x27;ve been in this industry for a couple of decades and I&#x27;d consider sacrificing a limb if the latter could somehow become easy.
评论 #28599441 未加载
评论 #28600298 未加载
gHostsover 3 years ago
Read actively.<p>* If you have a working hypothesis as to what the code is doing, state that hypothesis as a comment.<p>* If you think you know what it is doing, making that comment executable. ie. put in an assert. Better an assert punches you in the face than you rely on an incorrect analysis.<p>* If you don&#x27;t know WTF happening, or not sure, turn that comment into observability, add logging or something.<p>* Make microcommits using rebase or the like, add observability, add asserts, add unit tests, add refactorings, make behavioural changes.<p>* Do only one thing per commit, makes review and test much easier.
guiraldelliover 3 years ago
I just skimmed the article, but a more comprehensive text on acquiring the skill to read code is the book Code Reading, from Diomedis Spinelli [1].<p>[1]: <a href="https:&#x2F;&#x2F;www.amazon.com&#x2F;Code-Reading-Open-Source-Perspective&#x2F;dp&#x2F;0201799405" rel="nofollow">https:&#x2F;&#x2F;www.amazon.com&#x2F;Code-Reading-Open-Source-Perspective&#x2F;...</a>
shadowgovtover 3 years ago
This is a great take on the topic, but it doesn&#x27;t dive into the topic itself.<p>What are some techniques you&#x27;ve found help with reading code?<p>I&#x27;ll start: breaking out trickier bits into isolated units and testing them to confirm my hypothesis. This gives me two pieces of information: it tells me what I do and don&#x27;t understand about the unit I&#x27;m looking at, and it tells me what I don&#x27;t yet know about the unit&#x27;s dependencies (because to do a mechanical unit test, I need to mock &#x2F; fake those deps, so now I know what assumptions I&#x27;ve made about those deps). This is useful for code with some very esoteric pieces in it (I spend a lot of time in graphics-land, where people do bad things to bit fields with equivalent meanings with the goal of saving a CPU cycle or two).
a_cover 3 years ago
Good code all looks the same. Modular, name what you meant, clear boundary, relevant stuff got grouped nearer.<p>Bad code is each bad in its own way. There are just infinite combination of bad. Good luck on that. It is like telling kids what <i>not</i> to do. They still won&#x27;t behave. It is like bring people with an &quot;unfit culture&quot; to your team. You might be able to work with them, you might be able to change them. But you also only got so much time
评论 #28599573 未加载
评论 #28599623 未加载
tacker2000over 3 years ago
In my opinion, modern IDEs, where you can navigate around by clicking on functions and objects and also have the API docs integrated have greatly improved the time of understanding a codebase.
评论 #28599469 未加载
评论 #28599448 未加载
908B64B197over 3 years ago
The question nobody asks is if some code is even worth reading.<p>I recall a project that was offshored where a local team was later asked to add functionality to it.<p>The code was so bad, it was useless to read it. The execs who decided to outsource in the first place did everything they could to get the local team to build on top of what they purchased. Finally, they brought in a very expensive consultant who told them flat out the only way he was going to touch it was a total rewrite. People were furious. In the end, he won and it ended up being a complete rewrite completed faster than the initial offshored project. For half the price.
olah_1over 3 years ago
Hardest part of reading code is knowing where to start. I wasn&#x27;t around at this point, but I can only imagine the horror of a C programmer seeing their beautiful art broken apart into a bunch of nonsensical files in C++.<p>I like that Golang started to undo some of this issue of hundreds of little files that jump all over.
评论 #28599036 未加载
评论 #28602858 未加载
评论 #28599395 未加载
zwiebackover 3 years ago
There&#x27;s the basic hygiene of writing code: naming things, adding the right amount of comments, letting the compiler do the optimizing whenever possible.<p>However, I find that writing reusable, highly modularized code sometimes comes at the expense of readability. In the olden days I wrote what I would call horizontally layered code with relatively clear path of execution but that leads to highly interdependent modules. Object oriented code or code that uses lots of dynamic resolution of call sites makes code reading much harder. Multi-threading, at least the traditional kind, adds more trouble to figure out what happens when just by looking at the code.<p>I think that&#x27;s why patterns are important: if we give things names people broadly agree on it&#x27;s much easier to piece together how different parts of the code should interact.
passivateover 3 years ago
Is there any agreement on the meaning of &#x27;readable&#x27;, besides the obvious of write it like I would?
评论 #28599527 未加载
AshamedCaptainover 3 years ago
I have found that learning a bit how to read assembly code (for reverse engineering) actually helps your &quot;reading code skill&quot;. It&#x27;s practically the same thing except 1000 times worse: the dissassembled&#x2F;decompiled code has absolutely no syntax sugaring of any kind, so you have to rely on strictly your experience and pattern matching to be able to efficiently guess what this snippet is trying to do. If you can do that, you can probably read the most awful of (regular) codebases.
throwaway84786over 3 years ago
Can someone please explain to me what it means to &quot;read code&quot;? I feel like the article said I should do it yet didn&#x27;t explain what it is and how to do it.<p>To me, it appears a meaningless phase, like saying &quot;think harder&quot;. It&#x27;s something said in a good faith effort to be helpful, but unfortunately isn&#x27;t. I wonder if the &quot;meaning&quot; is intended to be something like, &quot;learn to <i>understand</i> code&quot;? Yet that replacement isn&#x27;t any more helpful. Can code be understood broadly? I don&#x27;t think to can be.<p>I had a boss once who tried to emphasize, &quot;you have to learn to read code&quot;. Some of the things he wrote were comprehensible to me, some not. He was a senior and I was a junior. He also once said to me, &quot;I don&#x27;t get what&#x27;s special about Lisp&quot;. When I tried to explain about macros and metaprogramming, he said &quot;but Python has decorators&quot;. I assume my boss could &quot;read code&quot;. He could certainly write it, he demonstrated an ability to explain the workings of a new codebase, and claimed he could &quot;read code&quot;. Yet he appeared to be lost about how Lisp macro programming differed from Python decorators. I could have explained it better. Regardless, this tells me that &quot;reading code&quot; is non-transferrable. So, maybe &quot;read code&quot; is meant as a shorthand for &quot;develop mastery within the language at hand so that you can quickly understand new code presented to you&quot;. Again, I&#x27;m failing to see how this is helpful, actionable advice. No matter which way I try to understand it, &quot;leatn to read code&quot; feels like it amounts to being told &quot;be more experienced&quot;.
评论 #28605027 未加载
didibusover 3 years ago
Thanks for articulating something I&#x27;ve always tried to tell others.<p>Yes, writing readable code is preferred, but as an individual developer, you can&#x27;t just wait for others to make their code readable before you&#x27;re able to understand and contribute to it, you need to work on your skill of reading code, even badly written code that is unreadable.<p>There&#x27;s also another dimension I think people often overlook, don&#x27;t just write readable code, write easily extendable, modifiable and testable code.<p>Having code that very clearly explains that it has a shared global that is manipulated and touched by each component doesn&#x27;t really help with the task of adding or changing a feature without breaking anything else or taking forever to do so, because of having to touch too many things in the process.<p>And what&#x27;s counter intuitive is that writing simple well designed code may actually make it harder to read, if you&#x27;re not aware of the patterns or constructs that are leveraged to allow the code to be designed so it can be easily extended, modified or tested.<p>For example, you might find using Java streams to be harder to read than a for-loop. You might find dependency injection harder to follow than just creating new resources wherever they are needed. You might find using some DSL for templating harder to read than just doing your own string concatenation, etc. That is, until you learn about the patterns and constructs and become familiar with them, and good at reading and understanding them as well.<p>That&#x27;s why I would say the most important things are in that order:<p>1. Get good at writing extendable, modifiable and testable code. That means, code that can be extended, modified and tested quickly with low risk of breaking other things and requiring minimal code changes in the smallest number of places.<p>2. Get good at reading code, both bad messy code with poor names, no consistency, and complicated designs and abstractions (this includes learning tricks to explore such code with logs, prints, debuggers, leveraging IDE features, etc); as well as good code that uses more advanced patterns and language features you don&#x27;t yet understand very well.<p>3. Get good at making the code you write readable, that means clear intuitive names, useful comments, proper formatting, consistent patterns, not abstracting beyond what is relevant, stay close to the problem, etc.
kragenover 3 years ago
Gee has excellent points.<p>I think that in order to get good at writing readable code, you need to spend a lot of time both reading code and watching other people read code you wrote. That&#x27;s the way you learn which things make code hard to read or easy to read.<p>In fact, I&#x27;d go further and say you need to watch <i>people in your target audience</i> read code you wrote. Different subcultures find different styles easier or harder to read. When you&#x27;re writing prose, you always have a target audience, and readability is relative to that audience. The same is true of code.
darkersideover 3 years ago
There&#x27;s a concept in soccer of &quot;aggressive receiving&quot;. When someone passes you the ball, you don&#x27;t wait for it to hit your feet. You read the &quot;line&quot; of where the ball is going, and you GET THERE, FAST. Players who don&#x27;t do this are consistently beat to the ball, or watch passes get by them and land with the other team. There are no &quot;bad passes&quot; in a soccer game, or more accurately, the duty is on a receiver to chase what some might consider bad passes.<p>Just sharing because it felt relevant.
lancemurdockover 3 years ago
I am in my 2nd year as a FE so still learning a lot. I&#x27;ve found that I am very good at reading other peoples code. I think being self taught and initially starting as a solo founder before entering the professional world helped me greatly in this department.<p>However, I am not as strong at getting a project going. I&#x27;ve underestimated how long it will take me to do something or missed key parts that should have been thought through. Hoping this chalks up to still being new-ish at my craft and in time I get better at this.
Hermelover 3 years ago
That&#x27;s why I prefer testing code comprehension skills over testing code writing skills in interviews. In my experience, the former is much more indicative of job performance than the latter. I don&#x27;t understand why code comprehension tests aren&#x27;t more widespread.
snarkypixelover 3 years ago
&gt; favorite movie quotes or song lyrics for average threats<p>Is it me or is this some terrible advice? Most popular song lyrics could easily fit in a password word list.
jodrellblankover 3 years ago
One use for <a href="https:&#x2F;&#x2F;rosettacode.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;rosettacode.org&#x2F;</a> is to, uh, &quot;consider the readability&quot; of other people&#x27;s solutions or languages.
softwarebewareover 3 years ago
I think the people who were posting &quot;learn to write good readable code&quot; weren&#x27;t disagreeing with the idea that reading code is a skill so much as they were calling out a comparison between:<p>a) coders who can read bad code and who also write bad code<p>b) coders who can&#x27;t read bad code but who write good code<p>In that case I would always choose to work with person b.<p>tl;dr I don&#x27;t think that they were disagreeing but adding on another important point