The Coding Mindset: What makes a better coder?

Public Mindset Coders();

Two developers walk into a shop to buy a very fancy lamp each. This lamp has multiple brightness and color settings and has a Bluetooth connection, speaker system, and so on.

The first developer is a meticulous person, so the moment he gets home, he picks up the manual and starts reading the booklet, but finds out that it's in German, so he decides to enroll in German classes.

He searches around and finds out that the only German class in his area is 30 minutes away by car. So, he decides to buy a car and start taking driving lessons. He joins the nearest driving school and starts to learn how to drive. On the first day of driving school, he accidentally drives over a nail and is forced to do a wheel change.

But being the kind of person he is, he decides that before he does a wheel change, he must learn the basics of physics involved in the process. So, he leaves his car and starts to look for the nearest university.

A month goes by and the two developers meet up for drinks.

The first developer asks the second developer,

“So, how far have you reached in figuring out that lamp? I am still trying to finish my Automobile Engineering so that I can learn how to drive to my German classes, and finally be able to read the manual.”

The second developer looks at the first one and says,

“What are you talking about?! I got the lamp working 5 minutes after I got home”

The first developer exclaims with 2 months of lamp stress on his shoulders,

“How did you manage to do that? As far as I know, you don’t know German, and even if you are the fastest learner, it would have still taken you a month at least. Not to mention, I checked and there are no German classes near you, nor do you have a car. Taking all this into account, how are you already done?

The second developer pauses looks at the lunatic and says,

“I just pressed all the buttons one by one until it turned on.”

The life of a developer

This may be an extreme example, but development in the professional setting is similar to this story.

When you are given a task, it's rarely something straightforward. Most of the time, you will have to jump down a rabbit hole and hop from one fire to another. 90% of being a developer, is about understanding existing flows, rather than implementing new ones. And, depending on where you end up working, existing flows are usually so interconnected, that it takes months to get a grasp on them.

This is a problem, both for you and the person who would hire you. Because they are expecting results, preferably from the day you join. And you are someone who wants a job and hates being fired.

I'll give you an example from my personal experience.

I was asked to port a couple of java applications to Springboot. You may or may not have heard of it, it doesn’t matter.

Even though I was completely new to Spring boot, I managed to port almost all the applications without a hitch. When I hit the last and the biggest of the applications, suddenly, nothing seemed to work.

No matter what I did, the application would always give some error message and crash.

Thus started my week-long crusade into the world of Springboot. I went through Stackoverflow, Github issues, Google articles, and even Korean and Chinese error report that chrome translated to English, and found out that one dependency was causing the error, which unfortunately was used by a second dependency, which couldn’t be changed since it would conflict with a third dependency, and so on and on and on.

I felt like I would have gone crazy with these dependency issues until one day, I started the application, and it finally worked.

To this day, I have no idea what I did, or why it worked. All I know is that it worked.

The two kinds of Developers

I believe, that there are two kinds of developers, the Theoretical one and the Practical one.

In easy-to-understand terms, most developers will someday ask a technical question on StackOverflow, and the ones who answer will almost always be the theoretical developer.

The Practical Developer is always concerned with the answer and cares little for whys and hows, but a theoretical developer would take care to properly understand the technology, the algorithms, and every minutia of the code before trying to do anything.

Does that mean one is in any way better than the other?

Let’s consider a simple example, a developer has to implement the security protocols of a nuclear power plant. In such a system-critical state, who would you rather have? A practical developer, or a theoretical one?

Alternatively, a developer has to add a button in your UI, but they have never used the language before. Which one would you rather have now?

Real-life situations aren’t this black and white, and as anyone will tell you if you aren’t a bit of both, you are neither.

Let’s go through a more practical example, and find the hackiest solutions. Given the following lines of code: Create a function that checks if the sum of 2 numbers is the same as the third number.

For those of you who don’t know about this confusing and infuriating language, it’s a relatively new language called, “I made it up”. Trademark pending! But seriously, in a situation, where you are asked to do something like this with a language you have never used, or a technology you have no idea about, how would you try to answer this question?

You don’t need to learn what any of this means, instead you need to look for patterns.

• 1) Parse func in func(update{$UPDATED$}Given{UPDATED_NAME, ID}): Boolean: String, Long ::
  This is how the function is created with the name of the function also holding the return value and the parameters. “: Boolean: String, Long” looks like the return and parameter types with “::” indicating the start of the function
  
  
• 2) [String updatedName] read UPDATED_NAME;
  This is how the Parameters are being transferred to a variable with the Type and Variable Name inside [] and the value is set using “read”
  
  
• 3) Given savedName !== updatedName ::
  This looks like an If condition that is checking if the existing name is the same as the updated name.
  
  
• 4) save$nameUpdated$Given{updatedName, id}
  This looks like a function call where the value between $...$ is the variable being set in the return.

Given these patterns, and no other prior information, do you think you will be able to solve the question?

I won’t give you the answer, and instead, let it be the homework for the highly motivated.

So, what is the crux of the matter here? Coders aren’t meant to be scientists, but neither are they meant to be, for the lack of a better comparison, monkeys. A coder’s mindset needs to focus on the solution to a given problem while having enough knowledge about the different avenues to get there.

Being in any engineering-centric field means that you are constantly learning new technologies and concepts since the world is constantly evolving.

Knowing plain HTML was considered the peak of technology when I was growing up, but now it’s the most basic thing you need to know as a front-end developer.

Similarly, the concepts of micro-services, containerization, AWS, etc. are all new concepts that have become mainstream in recent years.

Does that mean you need to always be reading up on every new tool, new language, and new technology to stay relevant? Is your life as a coder completely cursed to be a life of research? Do you wish to get out now and become a world-renowned artist or a swimmer?

Well, that’s the point I am trying to make here, you will never be able to keep up with the growth in technology. The advantage of being a practical coder comes with the capability to be highly adaptable. You don’t need to know every language out there, if you know one; you know them all. You don’t need to know how to use Docker, Kubernetes, AWS, Springboot, etc., you just need to know how to read and spot patterns. You don’t need to know everything, just have strong theoretical basics, and everything else will come naturally.

Author: Akash Mehta
Drawings Credit: Piyusha Gupta