The Differences Between Programmers and Coders
on March 11, 2013
…one thing does irritate me: the persistent misuse of the word “programming” when the author means coding. Programming is creating the logic, coding is translating that logic into code. Many students come into class able to code, but almost none come in able to program–that is, create the logic. They think sitting down & making spaghetti code is programming.
In one of my past articles, How to Become a Better Programmer, I made a conscious attempt to differentiate between coding and programming. You might ask, “Why? Aren’t they one and the same?” And to answer the question, no. The quote above from Tom Fordham says it all so well. If you’ve been a Programmer for many years, you can’t help but have been the victim of the false perception of what a Programmer is. It’s often misused, mislabelled and misrepresented. More often than not, when you tell someone that you are a Programmer they conjure up false ideas of robotic production machines that pump out lines of code without thought or feeling and are typically referred to as, a “Coder”. Being a Programmer couldn’t be anything further from that truth. A simple analogy for this is: A Programmer is to a Coder, to what a Designer is to a Production Artist or what a Key Animator is to a Tweener.
What Are the Differences Between Coding and Programming?
A Programmer is to a Coder, to what a Designer is to a Production Artist…
When I think of a Coder, I think of someone capable of writing code at a production level. Meaning, they have a solid understanding of the language they are writing in, but are potentially instructed on what to do or what needs to be accomplished and then implement, debug, test and QA. They are typically charged with compartmentalized tasks of a much larger scale project with most of their responsibilities lying solely within execution, based on the decisions of another person.
As a Programmer, you deal with so much more. Writing code is only a portion of what makes up the duties of a Programmer. Let’s dive further into why:
This takes years of training and putting into practice, to become effective.
Being a Programmer means actively thinking about abstract solutions to a problem before you are even touching code or opening up your favorite code editor. You’re taking to the white board or literally sketching thoughts out into your sketchbook. This takes years of training and putting into practice, to become effective.
And the point of doing this isn’t to think of every little thing that can possibly happen to prevent or make it happen. It’s to see the project as a whole from a bird-eye’s perspective and lay out a plan that best navigates it’s successful implementation. Having the ability to break ideas down to more manageable abstract forms to see how something can be built to be more efficient in a tight timeline or in the case of scalability or future-proofing. This will usually help you see potential pitfalls or places to do something specifically to shave-off production time in one area and place it onto another that would require more work and effort. It’s also the skill that will allow you to give suggestions, thoughts and answers when someone comes to you with a question or to give feedback on designs or for writing official documentation.
No one should just dive into code…
If you’re even part of a somewhat professional project, you’re going to have these. No one should just dive into code, unless it’s a personal project or quick prototyping for proof-of-concept, etc. Technical Specifications are not determining functionality, but what is required to effectively accomplish the goal of the project. So once again, no coding. Taking the time up front will save a lot of time for you and your team in the end. Specs typically aren’t very large documents, more bullet points of what is required to effectively complete the development cycle. It’s something that is always helpful and will not take long, but something that coders rarely even think about.
Nothing stays the same and that’s the only thing you can count on.
Sometimes you’ll be fortunate enough to have a Technical Lead taking care of this aspect along with things like requirements, timelines, etc, but most of the time you don’t. In my experience, most businesses I’ve worked with typically aren’t setup properly to handle large-scale development cycles with the proper management in place, having the responsibility lie on the person coding.
There is usually a Project Manager, who oversees every moving part of the project, but there is rarely a Technical Lead or Lead Developer; someone in more of a position of overseeing than doing. Most of the time the Programmer is responsible for approximating the timeline either with the PM or by themselves and then handing it over to the PM. So if you’re inexperienced in managing your time and others on a schedule, there will be problems. It’s up to you, the lead or sole programmer, to make sure you’re on schedule or that your team is knocking out their to-do lists. It takes strategy, high-level thinking and being able to work with lots of moving parts and people. Someone thinking solely about execution will not have the experience and insight to manage a project, people, timeline and deadlines. The one saying that can be said about this is: Nothing stays the same and that’s the only thing you can count on.
Fastest isn’t always the best route when it comes to programming.
As a Programmer, you always take into consideration that the project you are working on might need to scale, have others work on or just be updated with new components. It’s your duty to prevent “code smells” (Jeff Atwood describes a thorough list of code smells to watch out for in your applications) or minimize shortcomings in the code itself. Sometimes, this can’t be helped, but in most cases they can.
Fastest isn’t always the best route when it comes to programming. Sometimes you need to take extra time to setup semantics or create a set way of executing similar functionality that in the end, will save time. People tend to do this by setting up or developing a framework over time. Or using Object-Oriented principles such as inheritance, polymorphism and encapsulation. Also taking advantage of Design Patterns like Singletons, Decorators and Observer patterns. Whatever method you use as a programmer, it should always be consciously chosen for the individual solution. There are no boxed formulas, patterns, ideologies, etc. that will be the be all, end all of programming.
So to sum up, it takes someone with the ability to examine abstract issues and problems from a high-level, break them down to their components and manage them in a way that will be most effective, all while remaining in the timeline. That is the major and clear difference of Programmers and Coders.