I really do think curiosity is the most important bit out of all this.<p>If I see some bit of our code doing something a bit odd, I'm nosy, I'll go and look why. Why does one of our classes use an IDisposable? Why is that property using a custom class? Why is that code using async/await when it looks like it should take nano-seconds?<p>If it's for a good reason, you'll have invariably found a gotcha, or gained a little more knowledge about the domain you code works in.<p>But surprisingly often you'll find that it's for a bad reason, or an outdated reason, or someone not really understanding how the functionality they're using works.<p>In the early days of a language/framework especially, when people really don't understand how it really works, what you see is a lot of cargo-cult code. Doing without understanding. .Net, Jquery, Ruby, Javascript, Typescript, Node, I've seen it happen many times (and of course done it myself too! I remember making loads of pointless singletons in one project a decade ago).<p>People do something because they don't have the full picture. They make up totally wrong rules like "If I add IDisposable the GC must work better as I believe IDisposable has something to do with the GC so it can't hurt".<p>A great example right now, in the .Net world, is people are littering their code with async/await. They can't understand it's making their code worse, not better. They don't understand that the performance gain is almost always negligible, but the code complexity increase is expensive.
Related: Dig into your language's source code and code of major libraries! Your standard lib is probably the best examples of idiomatic code and efficient code that you're going to have access to, written by the authors of the language itself. You'll notice bugs, inconsistencies and poor docs which gives you opportunities to contribute upstream, at the same time making you read more and learn how particular features work under the hood, which might give you new perspectives in your own code.<p>In Java, this might be java.util.Collections package, or java.util.Concurrent. or in C++ that might be Boost. In Elixir, I start with Kernel.ex[0]<p><a href="https://github.com/elixir-lang/elixir/blob/master/lib/elixir/lib/kernel.ex" rel="nofollow">https://github.com/elixir-lang/elixir/blob/master/lib/elixir...</a>
Of course being able to read and analyze code is important, but I think the author picked a bad example to make his point. Removing all the using statements would be a bad idea! They don't hurt anything, the verbosity is minimal, and someone could add code to the Dispose() method later. If you are dead-set on changing something, you should make the XReader no longer implement IDisposable. And if the XReader is not under your control, then you should absolutely respect the author of the class by following the correct disposal semantics.
For me, the best articulation of why coding is so hard comes from a 2000 Joel Spolsky article [1]:<p><i>It’s harder to read code than to write it.</i><p>I continue to use that line to explain coding to non-coder friends. This article's author seems to understand that as well, but it's worth making explicit.<p>[1] <a href="https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/" rel="nofollow">https://www.joelonsoftware.com/2000/04/06/things-you-should-...</a>
"dispose" sample in the blog is a wrong sample.
IDisposable is a contract, and if someone define this contract, is because this contract should be used.
the fact that the actual implementation is "empty" doesn't mean that this remains true in the future, or in another implementation of the same interface.
so, based on the sample, I can say: don't read the source!
This whole "read code" thing ("write code that's easy to read", "learn to read code") is imprecise at best. Whats important is to <i>learn</i> code. You want to learn to write code that's easy to learn (not easy to read). And you want to learn to learn code.<p>If you write code that's easy to learn, and if you learn to learn code, you'll simply remember more code. The more code you know, the more productive you gonna be. That's because at one end of the spectrum, you know nothing about the code and you simply cant do nor solve anything. And at the other end of the spectrum, you know all the code, in which case you gonna be able to do whatever you want by definition: analyse it, expand it, rewrite it, refactor it, talk about it, fix it, etc.<p>This also explains why you want to write code with fewer lines of code (or fewer AST nodes): the more lines (or AST nodes), the more you have to learn. The more you have to learn, the less you know, the less you know, the closer you are from the bad end of the spectrum.
The most damaging thing about modern web frameworks is that they make it difficult, sometimes prohibitively difficult, to read code. You can sometimes step into framework code if it's well-written (i.e. Django REST is pretty easy to read) but if the framework does anything "magical" you're basically stuck.<p>Complex frameworks are good for getting a project started quickly, but become more and more problematic as a project ages and needs to be debugged.
The how-to-read-books advice from grandpa that is buried in this article is where the majority of its value lies.<p>If you skip over unknown words, or just acquire their apparent meaning by guessing from context, you don't really know those words and won't be able to use them effectively, or at all.<p>It's perfectly fine to gloss over code. You don't have time to understand at a maintainer level every nook and cranny of everything you have to work with.
It's easy to imagine changes being made by folks who don't truly understand what's going on, being made on top of changes that were made by folks who didn't truly understand what's going on.
I don't get this. When I use a Using to wrap EF DB calls that output to a DataGridView in C# I often get errors that mean the connection was closed before the data was grabbed.<p>The solution is easy, using a ToList in the DB call to force it to dl everything first, however to me it shows that the Using is working. Now we find that the black box of Using is empty?
This sounds like active listening. A person can be a good listener in the sense of paying attention and being present, but it gets even better when the listener helps guide the speaker by asking for clarification of ambiguity or for greater detail on specific topics.<p>Surrounding yourself with the tools and materials the article suggests makes it more likely you'll turn code-reading into a conversation.
<i>Every once and a while I would come upon a word in the book that was highlighted or underlined.</i><p>I realize this is a tiny nitpick, but it is "once in a while" not "once and a while"; the latter isn't even grammatical.<p>The article is otherwise very good.
This is funny, just wrote post on a same topic: <a href="https://zarkzork.com/code-reading.html" rel="nofollow">https://zarkzork.com/code-reading.html</a>
This post (and the one by Jessica Kerr) has inspired a new witticism for my LinkedIn profile: "A 10X engineer after my destructive behavior has caused most of your team to quit."
> This was timely for me because I've recently become <i>(by atrophy)</i> one of the most productive developers on my small team.<p>Does the author ironically mean... by attrition?