Learn to Read Code

It's clearly a trade-off. I have found that as I gain experience, reading code becomes faster, even for domains that I'm not familiar with, and it's nearly always worthwhile to understand the problem.

Moving fast and breaking things adds to the technical debt. The word debt implies that you will have to repay it (or at least, someone will have to repay it). So moving fast now means slowing down later. Sometimes this is desirable, sometimes not.

IMHO, the answer to this question is to frequently ask yourself this question as you're working on things. There's no perfect balance, you'll have to make a decision depending on the context and priorities of the moment. It might be ok to gloss over a concept you're unfamiliar with if debugging a production issue and having evidence that the root cause of the bug is in another area of the code altogether. But then make some time during feature development (or when writing a COE about the production issue) to go back to that piece of code and dig deeper into why it's written that way.

To expand on the analogy of the OP with regards to unfamiliar words in a novel, I personally don't look up every single word that I come across when I can get an idea of what it means from the context, but only after I encounter it a few times.

I just accept I'm a sprinter when it comes to coding, not a marathon runner. I spend 2 or 3 hours poking the code with a stick, proverbially speaking, reading it, maybe pruning crappy code, maybe faffing around, then bash out the actual code in an hour or two.

I believe what happens is that I form a mental map of the business process and a mental map of the code and then when I eventually come to write something, it just pours out.

Psychologically, it took me a long time to accept that only actually coding 2 or 3 hours a day is fine. For years I beat myself up for being 'lazy'.

EDIT: I mean, it's obviously different if you're just adding an extra column to an existing table or something (usually) trivial like that.

Using async/await with desktop GUI apps is basically a no-brainer. Nobody likes applications to randomly lock up and this is a way easier way to solve the problem than the old ones.

I do work on web based systems and I can tell you, without a doubt, that the performance gain is bugger all.

I flatly disagree with you, this is exactly the cargo-cult programming I'm talking about.

You're thinking about it totally wrong. Async/await is useful if you have a million pipes, but need 2,000,000. Thats millions of requests per second. Virtually no ASP.Net programmer has that need. They usually need 10 or 20 pipes per second, but they need really, really fat ones. Async/await does not make fatter pipes, it lets you use a single pipe as multiple pipes. But for decades IIS already, by default, supplies loads of pipes.

To make it clear, practically speaking, for virtually every asp.net programmer in the world, async/await is utterly pointless.

It's ok for external website calls. Or something you really need to multi-thread. Like the once in a blue moon tasks.

I work in ASP.Net, I rewrite bad async await code, get rid of it AND improve the performance by orders of magnitude.

Performance problems are almost always, in my experience, SQL bottle necks, bad EF queries or stupid loops. And I have fixed serious performance problems for various businesses. Once in 12 years have I seen IIS running out of threads and that was in 2006 when CPUs sucked. And that was fixed by, amazingly, fixing a bad SQL query.

Littering several hundred 40ms controller calls with asynchronous EF calls that run in 3ms won't make your site faster. Fixing that shitty report that locks 20 tables and takes 2000ms to run causing multiple deadlocks and gets called 5 times everytime someone opens your dashboard because you suck at JavaScript will. Put all the async awaits you want into that bugger, it's still going to screw your site over.

Async/await is a load of utter nonsense for the vast majority of MS customers. And yet now I see people using it for the most asinine calls that clearly do not need it.

It's a total nightmare to introduce async into an existing, non-async codebase, so I'm not sure it's a good case for incremental refactoring based on benchmarks.

You use async/await when you are doing any sort of IO in an application that needs to be responsive. Example: your ASP.NET thread pool is starved because all your request threads are waiting on IO. It's useless to have those threads waiting there for IO when they could be processing other requests to your server.

You're obviously going to see some overhead from the state machines generated, but that's negligible compared to the gains you'll see in throughput and code readability(compared to the older ways of doing async code).

The same reasoning extends to UWP, don't block your main thread with IO so it can still process input. Obviously there's other ways to handle async in a desktop app, but async/await just make it so much easier to reason about your async code. It looks exactly like you're writing synchronous code.

Certainly depends on the language and where in the standard library you are, though you're completely right to always be cognizant that it's all been taken through battles in production at scale and has been optimized accordingly. One could also argue that that kind of code might be idiomatic for that kind of problem (an example of general, portable, and efficient), and a good guideline on how that might be done, though it might not be a super satisfying argument depending on how conservative your definition of "idiomatic" is.

why do you say that?

There was an article last week-ish about reading OpenBSD source daily.

https://news.ycombinator.com/item?id=14521386

You're correct in your assessment, but the parent is correct in their criticism. I'll try to rephrase, though the particular example is not of particular importance.

Ok, so remove IDisposable from class declaration and fix compilation issues. My2Cents.

Some ideas: Spend time learning how to do thenusers jobs, understanding how thenusers use the system. Go into the code, pick one spot, and understand what it does very well. For that one spot, make a list of all the external things it uses that you don't know about. Go to each spot in that list and make notes about how that thing works, indented under the list item. Repeat that process recursively for a level or two, or as many as you have patience for.

Pair program with someone else who knows the system. Write unit tests.

The way I make myself familiar with new code is to find some process of interest and write out a psuedo code stack trace from the trigger through execution. So, function names, relevant params, leave out error handling and irrelevant branches. If a step is async, reset indentation and annotate the "stack" with "and later..."

This process can collapse large amounts of code into a hopefully a single page of text that can be well understood. Without it, I find it very difficult to keep all of the relevant code in my head when it's spread across the code base.

Reading automated tests and doing extensive searches in the codebase (with recursive `grep`s) is often helpful. If you use an IDE with a go-to-definition function, it can replace grep.

More than that, reading framework source often reveals that the code is very, very bad.

>This means that visual studio's 'find references' functionality doesn't work, and the project I'm working on has dozens of unused controllers

I know it's an annoying extra step to learn and do, but when doing anything with refactoring controller actions (e.g. changing action names or required parameters), Ctrl+Shift+F is really your friend. I have noticed references not getting picked up by the refactoring quick actions too, but it was sporadic.

I use such a FireFox extension for reading Japanese: Rikaichan. Written by the same dude who put together the Tomato firmware for routers.