Bro, do you even program? The case of non-programming programmers
It was late at night, when I stumbled on yet another Quora question concerning the topic of “Programmers not programming”. The topic itself always seemed ridiculous to me. What is a programmer if they can’t program?
It seems to me that there is an arbitrary line that one has to cross to know that they are programming. The line, to me, always seemed simple: if you know a programming language and you can use it to solve a problem, you’re a programmer. But is that all it is?
I’ve worked and interviewed at many jobs where the definition of a programmer ranged wildly. One Director of Development touted the ability to use Design Patterns in order to accomplish his task.
I still remember the guy, sitting behind his desk, a smug look on his face, “You ever heard of the singleton pattern?”. No, I shook my head, thinking that I am yet another of those programmers that do not program.
How can that be? I’ve built platforms, crunched data, solved problems, both back-end and UX. I’ve built things I was proud of and in an object oriented fashion which enabled reusing of code. Yet, I had no idea what a “Singleton” was.
I was given an offer but never started (that’s another story). “Design patterns”, I thought, “and algorithms. That must be it!”.
Several years ago, I remember hearing about how programmers are problem solvers and that the modern developer was an engineer of the world. Startups were started by these “engineers” which solved the world’s problems. To be a programmer, then, meant solving problems of the world. But, obviously, not the other way around.
As I progressed through my career, I sought some type of acknowledgement that what I was doing was “programming” and that I was doing a good job. Having another co-worker marvel at your CSS is one thing, but having the acceptance of a greybeard, programming neckbeard, or a ninja, rockstar, or whomever is another. I rarely worked with other developers and when I did get the opportunity to work alongside others, it was on a foreign platform with quickly-hashed-together code and a system that I had some trouble getting into.
Not being able to program simple functions without help made me feel helpless, and put me back in the category of “non-programmer”. Though, it was years later when I realized that my naive interpretation of the situation was utterly wrong. Every platform has a learning curve.
So am I programmer? According to Jeff Atwood, it’s as simple as being able to solve FizzBuzz, or code a loop that counts 1-10, or write any code, whatsoever. To me, that’s a strange way of evaluating a programmer. I see these jokes on one side, if this really is a serious situation and the article is truthful, I find it ridiculous that someone would even apply while lacking 99% of the skillsets necessary to perform the task.
What’s even worse on the other hand, is the other extreme of the spectrum ie. hiring managers (or rather, programmers who hire other programmers) expecting programmers to figure and know algorithm implementations right off the bat. Or expecting an applicant to rebuild a tree data structure within 5 minutes.
Once you know the solution, of course, it all seems so “simple”. But if you don’t know the solution, reaching it will take some time. If my ability to regurgitate a coding algorithm within 5 minutes determines my being a programmer, then I’m screwed.
So what is MY definition then? I’ve been clawing at my brain for a while now, trying to get away from the stereotypes and the over-simplified answers.
A programmer to me IS a problem solver. But a specific one. Obviously, coding is a part of the problem solving. The real core of a programmer is having the ability to solve a unique problem they’re presented with, that does not fit into a neat template.
In other words, give me a problem that I don’t know a solution to (a BuzzFizzBoom) and allow me to solve it with code. That’s it. That’s all there is to it.
If you’re a manager, or an interviewer, and want to make sure the person in front of you is a “real programmer”, present them with a challenge that your business faced, dumbed down to be solved in a few minutes. Allow them to use whatever language they want, and see them at work. Even if they can’t get it just right, even if they can’t actually solve it, you’ll see them work through the problem, come up with potential solutions, and try to implement them.
And if they take 15 minutes to do it? Fine. Coming from one job, being used to solving a set of particular problems, and interviewing for another one that faces other, new problems, can be jarring.
That’s as good as it’s gonna get.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)