I Am Not a Programmer: The New Era of Software Development

The best thing about this picture? You think it’s irrelevant, but you’d be surprised

Disclaimer

Treat the following blog as you would a fiction novel. How? Don’t take it for face value and just imagine a world where all this is possible. Enjoy the blog.

!isAProgrammer()

Yes. You read that right. I am, indeed, not a programmer. I know, I know… My CV says that I am a programmer. It also mentions all the programming languages I know. I even consistently write blogs in which I address programming or programming related concepts. I have the degree, I code every day, and even my personal projects are almost always code-related.

“Enough with the needless filler introduction and get to the point already”, you are right, I tend to add some needless ramble at the beginning of my blogs to make it a bit dramatic, but let me get right to it.

For decades(?) now, whenever someone thinks about programmers, they think about fast-moving compilation lines. Terminals. If statements. For loops. Dark Themed IDE’s. “It’s not a bug it’s a feature”. Or maybe even this

I have always disliked that narrative. The narrative of a programmer being just a coder. So, I am writing this blog to clear up, what I think, is an outdated notion about how we define software developers in the modern industry.

The Problem Process

I like mental images, so let’s do a little exercise. Picture this. Someone applies for a new job. The first step is to have a simple interview, get to know the person better, see what they want from their potential new job. Easy. Straight forward. The second step (usually) is the personality test. Ooooo, that personality test. The candidate is given one of many generic tests found online to allow an algorithm to determine what kind of person he is, instead of having an actual human being to determine that. I mean, it is common knowledge that machines have a better way of sensing what a human being is like, better than a human themself. The person gets one of many predetermined results back and relates themselves to whatever result they got. Basic psychology. We tend to see ourselves in things. If the algorithm then decides that the person fits the company culture, the candidate moves to the coding test, which is a vital part of the process. Then the candidate either gets a short follow-up session to talk about the code, or they just get a direct yay or nay

Now, let’s take that same developer and put them in a real-life work scenario. From the process mentioned above, do you know how that developer would act under pressure? Do you know how that developer would react if there is something they are stuck on and can’t solve? Do you know anything about their thought process? Do you know how…

they solve all these problems?

Binary Music

Here are my qualms. My problem does not lie in the process itself, my problem lies in the traits that the process tries to highlight. During almost all of the steps that evaluate the candidate, the most important trait a developer should have, in my opinion, is not being tested. What’s that you ask? The candidates’ problem-solving thought process. I mean, think about it. Anything and everything we do in software development is basically “We have a problem, how do we solve it with code?”. Whether we are talking about a simple calculator app or a full-fledged API, it all comes down to how we decide to solve the issue at hand.

Having established that concept, the concept that problem-solving is the core of what we do in programming, why are we not evaluating how a person problem solves? The thought process? This is sometimes addressed in the follow-up interviews after a code test is reviewed, but it always feels like a diluted step compared to all the previous ones. But I have noticed that it is more likely in this interview that people give the how they implemented, and not the why. The “I did this because…”, the why, ends up giving us the initial point I made of how a person solves a problem.

But the worst, and by far the worst thing I have seen in these evaluations, are people who get outright rejected. I will try to keep this as non-rambly as possible because I can write an entirely new blog just about this topic, so here is my point.

A well-coded application does not mean you are a good programmer and a badly-coded application does not mean you are a bad programmer.

Go ahead, boo me all you want. I can already picture your face going “WHAT?!”, but let me explain. We live in an era where knowledge is very easily accessible. Someone can find exactly what they are looking for through one simple search. Don’t get me wrong, their code could be flawless, but do they know why it is flawless? Did that person know why this approach is being used by a big number of people? Did they consider another approach? Why did they not go with that other approach? I will tell you this now, and I will even quote it so you can use it to make an argument against conflicting opinions I might give later:

I would rather work with someone who wrote a mediocre code assignment but can back up his thought process and is willing to learn to code better, over someone who wrote a “phenomenal” code assignment but cannot explain why the problem was tackled the way it was tackled.

Unless you…

git push --force origin master

Then we need to have a serious conversation

Joking aside, this faulty evaluation of how developers' skills are measured becomes a rabbit hole with a ridiculous domino effect within a company. To give an example, here is a little skit, enjoy:

A: “Hey! I am reviewing your PR right now and I found something I wanted to ask you about”

B: “*oh, here we go again* Of courseeee! What’s up?”

A: “I noticed that you used <insert_inefficient_data_structure> instead of <insert_efficient_data_structure> that’s a very interesting take on it”

B: Yea, pretty different, right?

A: Oh yea, different is the word I’d use too for sure! *It’s got a horrible time complexity*. I was wondering why we didn’t go with <insert_efficient_data_structure> tho?

B: Well, you know, <insert_inefficient_data_structure> gets the job done, I have done it several times before, and so many others use it as well!

A: I mean, yea, the code works so I am assuming it gets the job done, but like, why, tho? Maybe others have done it, but do we want to do it?

B: It’s… suitable for our needs!

A: Actually, our application’s main selling point is how fast it is. I mean our entire ad campaign slogan is “Do you know that one app you use? Ours is definitely faster! We will dedicate all our engineering knowledge solely to achieve that goal. That’s a promise!” This… This has a time complexity of O(n²). While the other one has O(logn). Given the problem that we are trying to tackle (see what I did there?) I think it’s better to use the other, lesser-treaded-path, yet faster, more fitting approach in our application

B: Umm…

A: *PR Closed*

This shows that the thought process that went into this implementation was, well, none, which is blasphemous because a programmers thought process is sacred. It can almost be compared to making music. They both take components that mean nothing when they are standalone, but when they are all put together they melt into this one, exquisite, unique outcome that aims to serve a purpose. Whether it’s with music where you aim to convey a certain feeling, or with programming where you aim to… solve a problem, the purpose that they aim to serve needs to be carefully planned, well-thought-out, intentional, and, only in the case of programming, logical.

To lighten the mood, and to transition into wrapping this up, here is a snippet of how I, somtimes, code from scratch.

Yes, yes. I use VS Code for Java sometimes and I have come to accept my flaws, and that’s alright

Peanut Butter Jelly

It all comes down to looking a bit into the future and imagining what colleagues you would want to work with. Me, personally, when it comes to colleagues, I prefer working with problem gurus. A problem guru for me is someone that can spot a problem, analyze it, critically think of a solution, and then comes the coding part. I want to work with someone who doesn’t just code.

But then comes the part of “Okay, how can we solve this to highlight a programmers' ability to problem solve while not solely focusing on lines of code?”. First off, I want to clarify that the industry is slowly changing into doing that. Between all the satire and arguments I present, there is a sense of acknowledgment of how the industry is evolving. But, here is my suggestion, and it's one word:

Let’s be honest, did you click on that speaker icon to see if it works?

I love pseudocode. Man oh, man! I think pseudocode is the perfect harmony to showcase how well a developer thinks, but also how well they would potentially write it in code. This combination is the peanut butter jelly sandwich of the programmer assessment world, and that’s a sentence I never thought I’d write down!

In essence, we need to change the meta. The meta of assessing a programmer on how well they code, and only how well they code. There is so much more to developers more than just putting incohrenet english sentences in a machine-friendly manner. Let’s explore that potential together, as an industry. Other than what I have suggested, I don’t know how this could be done, which is ironic since I just said we should all aim towards being problem solvers. But this is something we can tackle together. Developers, recruiters, managers, product owners, scrum masters, everyone. Because like it or not, the type of developer you have on your team, will play a big factor in determining the success of that project.

That’s all I got for you! If you have any thoughts on this, let’s have a discussion! Other than that, happy coding! (or is it happy problem solving, hmm?)