I came across this article through TheBlueHairedgen. The article's title is: Give up Sooner. To summarize, the article talks about how, sometimes, when solving a coding problem, people get stuck at a local maximum. They find a solution that they think is correct or is the only path forward. Often, these solutions don't feel right or come with substantial tradeoffs.
In my junior days, I found myself doing this a lot; I wasted so much time going down the wrong path. The first time I realized this was when a senior engineer helped me with a problem I spent about two days on and deemed unsolvable. He, without really knowing why, had the feeling that what I was saying didn't make sense and started on his own search. He went about it the same way the article described; in other words, he had built a strong intuition about good solutions over the years.
Being on the receiving end of this was inspiring; I remember thinking to myself, I want to develop what he has. The article above goes over what it is and how to mechanically go about it. I want to talk more about how to get this intuition to begin with.
I believe the first step to this was to demystify the perceived complexity of software. I needed to internalize that all software we see today is a collection of simple principles. To fully get there, I needed to know what these principles are. Any seemingly complex software, assuming it's written well, is just a collection of simple isolated abstractions. By following this line of thinking, my solution needs to be as simple as the system's parts. This drive to minimize complexity is one of the heuristics of this search.
Now, I can't blindly hold the belief that something is simple without being able to understand it. Outside of some overarching concepts, each language, framework, and domain has its own patterns. Within each vertical, I need to give myself enough time to understand the most common patterns. This becomes easier over time, but it's this knowledge that gives me the confidence to dive into the source code when I need to. It enables me to RTFM much faster. It allows me to phrase my search queries better. Lastly, it gives me the ability to evaluate the tradeoffs of each solution.
Of course, this approach is not a silver bullet; I find it breaks down when the source code's abstraction is too obfuscated. I taught Python in a boot camp for a while and in it, I would try to show my students source code every once in a while in an effort to demystify what they're learning. I found doing this on Flask's app.route method, for example, not helpful. If I'm right, and Flask's routing is done as a Chain of Responsibility, I wasn't going to be able to explain that to a beginner nor will it be friendly to debug or trace.
It's also sometimes not worth it to dive into the source code like that. I worked with a JS image compression library and faced a bug where Xiaomi and Huawei devices shrunk and flipped images; I know, only the sky wizard knows why. I really tried to look at the source code and ended up learning a bit about images and compression, but it wasn't worth it for me to learn more. So I just messed with the function args for a bit and found out that I needed to hardcode the exifOrientation; it only had 8 possible values anyway. Till today, I don't know if it's a good solution, but we haven't gotten any complaints since, so go figure.
Overall, in my opinion, this is what builds that intuition I saw in my coworker. As a side note, the article above doesn't include GitHub issues; I find them very useful and searchable. For me, the sources go as follows: Google, StackOverflow, Github issues, the docs, and then the source code.
