Agile Zone is brought to you in partnership with:

Antonin Januska is a web developer, designer, writer, life enthusiast, and more. Shedding the third person for a moment, I would like to tell you about who I am. I am a freelancer with extensive background in business, marketing, advertising, and developing products. I have worked with many different media and advertising agencies as well as ambitious individuals hoping to elevate their small businesses above their competitors. From furniture companies, to software development companies, I’ve made websites for businesses in just about every field. Antonin has posted 16 posts at DZone. You can read more from them at their website. View Full User Profile

Bro, do you even program? The case of non-programming programmers

  • submit to reddit



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.

road to success

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 isn’t someone who can do FizzBuzz, or memorize quicksort, or do a simple while loop. Nor is it someone who’s able to code C, Javascript, and other X language that an interviewer values. Nor is it design patterns, algorithms, or the number of repos in your Github account.

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.

Published at DZone with permission of its author, Antonin Januska. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Lund Wolfe replied on Sat, 2014/05/31 - 2:36am

Computer programming is problem solving.  That's what makes it fun.  That's what makes it hard.  Many people problem solve all the time.  Programmers just use a programming language as building blocks to build a solution.

It's not really any different from solving math word problems or physics problems.  The equations are the easy part.  Applying them correctly to the problem at hand is difficult.

We are very attached to our techniques and tools, but they really just make the problem solving process simpler and more efficient.  The ability to reduce the problem to an abstraction and find its abstract solution will always be the challenging part.  Just as in the real world, though, the challenge in programming is to also be able to find a solution given a gazillion very real (and often ridiculous) constraints.

Joe Fisher replied on Sun, 2014/06/01 - 1:18pm

 If I'm a manager and I want to know if I have to train you in basic programing idoms, such as Singletons and Builders, I will pick the next candidate. Just because you can solve a problem does not make you a programmer. Lots of carpenters and airline pilots can solve problems, and do every day. But those carpenters and pilots will have to "discover" or "re-discover" a tool like singleton if they were to program. Why would I pay you do fumble around in your "problem solving skills" just to discover a builder. And worse yet, you may not even know that what you discovered has already been invented. Would you be happy that your carpenter had to constantly re-discover the hammer, or craft it, just to build your house?
No wonder software costs so much.

Martyr Two replied on Mon, 2014/06/02 - 3:51pm

I have always thought people are a programmer if they can do the following things...

1) Diagnose a problem (the real problem) and come up with a solution

2) Write that solution using a programming language (ideally from the ground up or somewhere near the ground)

3) Walk someone through the code and thus tell them the solution and demonstrate that they actually know what they are talking about.

So people who are not programmers in my book are people who can't come up with solutions on their own or try to treat symptoms rather than problems. Then try to create solutions by ripping off other people's code and ask others how to fix any problems that actually arise from it. 

That is why I say people who jump on codecademy, work through a few of their topics and call themselves a programmer is a problem. They are imitating what they see without really knowing why and often times when you give them the same problem in perhaps a different format, they still don't see the problem or able to even come up with a solution remotely clear.

Programmers know when they see other true programmers. It is how they write, how they talk and more importantly how they think about problems. The very same reason I can't walk into a lawyer convention and start spouting off without being found out.

Diego Almeida replied on Sat, 2014/06/07 - 11:32pm in response to: Joe Fisher

I totally agree, Fisher. I think the author tried to explain an interesting idea. "A programmer don't have to be a senior expert in all languages and patterns expected by managers", but he used the wrong examples. Memorize all data structures and design patterns, ok, but knowing or at least have a good understanding of the main structures and design patterns works, and of course dominate one or two languages, is in my opinion, a basic skill for who want be a "programmer".

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.