Public Mindset Coders();
Two developers walk into a shop to buy the same fancy lamp. It has multiple brightness settings, colour modes, a Bluetooth speaker, the works. Basically a smart home crammed into a single bulb, for reasons nobody asked for.
The first developer is a meticulous person. The moment he gets home, he picks up the manual, only to find it's in German. So, naturally, he decides to enrol in German classes.
He searches around and finds the only German class in his area is thirty minutes away by car. So he decides to buy a car and take driving lessons. On the first day of driving school, he runs over a nail and needs to change a tyre.
But being who he is, he decides he must first understand the physics of how a wheel change actually works. So he leaves the car right there on the side of the road and goes looking for a university. The lamp, meanwhile, remains off, smugly unplugged, somewhere very far away from any of this.
A month later, the two developers meet up for drinks.
The first developer asks the second,
"So, how far have you gotten with that lamp? I'm still finishing my Automobile Engineering degree so I can drive to my German classes, so I can finally read the manual."
The second developer looks at him and says,
"What are you talking about? I got the lamp working five minutes after I got home."
The first developer, two months of lamp-stress on his shoulders and at least one unfinished engineering degree deep, exclaims,
"How? You don't know German. Even as the fastest learner alive, that would've taken a month. There are no German classes near you. You don't even have a car. How are you already done?"
The second developer pauses, looks at him the way you look at someone who's just told you they built a wind turbine to power a single nightlight, and says,
"I just pressed all the buttons one by one until it turned on."
The Life of a Developer
This is an extreme example, but professional development isn't far off, minus the German classes, hopefully. When you're given a task, it's rarely straightforward. Most of the time you'll jump down a rabbit hole and hop from one fire to the next, occasionally setting a new one on the way past. 90% of being a developer is understanding existing flows rather than writing new ones, and depending on where you work, those flows are often so interconnected that it takes months just to get your bearings, by which point someone has usually asked "so is it done yet?" at least four times.
That's a problem for you and for whoever hired you. They want results, ideally from day one. You want to keep your job. Neither of you has the patience for a German class, a car, or a degree in tyre physics.
Here's an example from my own experience.
I was asked to port a handful of Java applications to Spring Boot. I'd never touched Spring Boot before, a small detail I did not lead with in the planning meeting. Still, I got through almost all of them without a hitch, which felt suspiciously easy, right up until I hit the last and biggest application, and suddenly nothing worked. No matter what I tried, it threw an error and crashed, with the quiet confidence of something that intended to ruin my week specifically.
That kicked off a week-long crusade through Stack Overflow, old GitHub issues, and a truly heroic amount of Chrome auto-translating Korean and Chinese forum posts into something only 60% comprehensible, which, by day four, was still more coherent than my own notes on the problem. Eventually I traced it to one dependency causing the error, which was required by a second dependency, which couldn't be changed because it would break a third, a chain that, I'm fairly sure, eventually loops back and blames itself.
I never fully figured out why it broke. One day I ran it, and it worked. To this day, I couldn't tell you what fixed it, and I have made peace with that, the way you make peace with anything you survived but can't explain.
The Two Kinds of Developers
I'd split developers into two rough types: the Theoretical and the Practical.
Most developers will, at some point, ask a question on Stack Overflow, usually at 2 a.m., usually with a title like "URGENT: nothing works." The person who answers it is almost always the theoretical type, the one who wants to understand the algorithm, the mechanism, the why, before touching the how, and who will reply with a three-paragraph explanation of variable scoping when you just wanted to know which semicolon was missing. The practical type wants the answer, gets the thing working, and moves on, blissfully uninterested in why it worked, much like our lamp guy from earlier.
Neither is automatically better. It depends entirely on what's at stake, and whether anyone's life, savings, or production database is involved.
If a developer is implementing the security protocols of a nuclear power plant, you want the theoretical one, someone who understands every assumption baked into the system before changing a line of it, and who will not, under any circumstances, attempt to fix the reactor by pressing all the buttons one by one. If a developer just needs to add a button to a UI in a language they've never touched before, the practical one will have it done before the theoretical one finishes reading the framework's "Getting Started" page, table of contents included.
Most working engineers aren't purely one or the other. They shift modes depending on the stakes of the task in front of them, the way a sensible person becomes very theoretical indeed the moment the words "production" and "delete" appear in the same sentence. The skill isn't picking a side. It's knowing which mode the situation actually calls for, and switching fast enough that it doesn't cost you a week (or, in the nuclear plant's case, a small geographic region).
Pattern Recognition Beats Memorisation
Here's a practical example of what the "practical" mindset actually looks like in action. Below is a made-up pseudo-language, call it "I Made It Up", that you've never seen before. The task: write a function that checks if two numbers sum to a third.
Parse func in func(update{$UPDATED$}Given{UPDATED_NAME, ID}): Boolean: String, Long ::
[String updatedName] read UPDATED_NAME;
Given savedName !== updatedName ::
save${nameUpdated}$Given{updatedName, id}
You don't need to know what this language is called to solve the problem. You just need to spot the patterns:
func(...)::defines a function. The name, return type, and parameters are packed into the header, with::marking the start of the body.[Type varName] read SOURCE;is how a parameter gets assigned to a local variable.Given X !== Y ::behaves like anifcondition, checking whether two values differ.save$value$Given{args}looks like a function call, where the value inside$...$is what gets returned or set.
Once you notice the pattern, the actual solution for "do A and B sum to C" follows the same shape:
Parse func in func(sumCheck{$RESULT$}Given{A, B, C}): Boolean: Long, Long, Long ::
[Long a] read A;
[Long b] read B;
[Long c] read C;
Given (a + b) !== c ::
save$false$Given{result}
save$true$Given{result}
You never learned the syntax. You learned the shape of the syntax, and that was enough to get the job done.
That's the whole point. A coder's mindset isn't about knowing every tool. It's about having enough working knowledge of patterns that an unfamiliar tool stops being intimidating and starts being a slightly annoying puzzle instead. Knowing plain HTML used to be the peak of technical sophistication. Now it's the bare minimum, taught somewhere between "how to use a mouse" and "actual programming." Microservices, containerisation, and cloud infrastructure were niche concepts a decade ago; now they're assumed knowledge, casually dropped into job descriptions next to "fast learner" and "team player."
Does that mean you need to be perpetually reading docs just to stay relevant? Not really. You'll never fully keep pace with how fast the field moves. Trying to is a losing game, and also a great way to never ship anything while feeling extremely informed about things you haven't shipped.
What does scale is being a strong pattern-matcher with solid fundamentals, because once you have that, a new framework isn't a wall, it's just a slightly different lamp with the same kind of buttons, and you, unlike our first developer, are not going back to university for it.
Author: Akash Mehta
Drawings Credit: Piyusha Gupta