In recent times we usually take these two terms (coder & programmer) as synonyms, but I believe there is a difference. So much so, that I feel it determines the quality and success of a project.
I think the two words have become interchangeable because of mass media and seeing people control their computational resources with ease. This has left an attitude of coding is so easy a 5 year old can do it. As a result, coding has become the informal term for programming. And I believe why some have moved away from the term and focus on developer or engineer.
Coding is important, yes. It’s why schools have made it mandatory learning. It will help graduates understand how to give instructions to machines so they have more control over their computing environments.
However, you can basically ‘code’ anything. For instance, you can colour code a dictionary. Words starting with ‘A’ are blue, ‘B’ are green … ‘Z’ are orange. Coding is the act of classifying or assigning something through a code. So, when we code in programming we are simply structuring codes according to a syntax to assign logic and instruction. For instance, an ‘if’ statement. It is code for a conditional statement to change the flow of control of our execution (algorithm).
Of course there is nothing wrong with being a ‘coder’, and it is vital for the current and future workforce. However, let’s clear things up with the terms, especially if you want to become a programmer.
What many think programming is
When building something in computing many jump straight into code. Working backwards until they have their solution. Trying this and that, copying this and that, feeling it as they go. They try and find the solution or the code to their problems as they go.
This is misleading in terms of progress, because of the immediate feedback (reward) execution can give. Fooling many into the belief they’ve built something solid, complete and worthy of admiration. However, 9 out of 10 times when it comes to building a sophisticated, clean, maintainable solution… this approach is risky and leads to unforeseen assumptions being made which could be detrimental to them or their client.
You might be saying, “pfft, Rhys, there are countless tutorials on how to code, this is how you do it”. Yeah, to code (recite). Not to be a programmer!
I’ve lost track of the number of times where I’ve seen a solution and asked what made them approach it like that, then get the response, “because that’s how it’s done”. Once we sit there and engineer it with a programmers mindset, their 500 lines could be done in just 150. It didn’t need this module, that template, a framework, it has too much repetition, or whatever. Those things exist in the solution because the tutorial had it. If they only took the time to understand the problem from a programmers mindset there wouldn’t be all this redundancy.
Using an analogy to define the difference between a coder and a programmer: a programmer is an artist, a coder uses trace paper — some people won’t like bluntness of that comment :-).
An artist knows what materials go best with what, how to correct mistakes that others would see as permanent, how to outline before reaching for the paint… they’re an artist. It’s why many are in awe when they see the artist’s work!
Programming is a creative process of engineering (designing, constructing and testing) logic that then is coded. It is why we have positions with the title of software engineer, and these titles are held in higher esteem over coder.
Coding in programming is simply the process of outlining logic with a formal language (a programming language). It is the same with mathematics.
Maths has a formal language, a language you construct your solution with. You might know the rules and language of maths, but if you don’t know how or why you’re applying it, you’ll always be a one trick pony. Meaning, when presented with another problem it’s back to tutorials! This eventually leads to it all becoming too hard — interesting how we tend to see the same thing with programming…
The language and rules of coding makes up one aspect of programming. It allows us to translate our engineering effort into a material form. This is why watching a tutorial only on a language/framework/etc to learn coding will leave you with just tools and a possible application of those tools.
Of course we need to learn about our tools, their quirks, their brilliance. Yet, you can have the best tools, but in the wrong hands they’re just tools. To reach our full potential we need to break away from the mindset of code, code, code… Once we do, the complexity of our solutions drop exponentially and programming becomes so addictive we end up falling in love with it.
“So you’re saying all those tutorials are a waste of time?”
No, not at all. However, when someone is learning how to program, so they don’t fall into the coder’s trap, my advice would be step back and ask yourself, do you understand the engineering, do you understand the logic being coded? If not, don’t jump into watching the tutorial: The ‘How to Code’ or ‘Learn C++’ or ‘Build your first app’. Instead, go and learn the processes, the flow of control, the patterns of design — the fundamentals of painting before you reach for a paint brush.
I believe this is critical and the differentiator between the two terms. A coder develops backwards where they code without the understanding of the engineering or logic. I also believe this is why we always see these arguments of which language is best, where people go into rage fits batting for ‘their’ language — they’re coders arguing. True programmers think about the tools after they have the engineering. They’re not locked into a coding environment.
What is the programmer’s mindset though?
I’ve danced around it a few times already, to put it simply, it is the understanding of the importance to engineer and understand your approach.
Unfortunately, this importance or even the understanding to engineer is often not in a coders mindset, so their quality plummets and their effort increases. This leads to a pretty poor outcome and more importantly… tears. Why? Because the ‘define as you go’ brute force technique becomes so hard and drudge like you won’t anticipate or be aware of what’s next — I think this is another article in the making.
You can think of engineering as the programmer’s super ‘power’ (exponent). For instance, say we use a grading system on the solutions we create. Where the bigger the number the better the outcome. Something like:
(Tools + effort)^engineering = solution
You can see with this simple formula no matter how much effort you give, or how great your tools are, engineering will always exponentially increase the quality of your solution.
Put simply, no amount of effort exerted with tools will beat a solution with a bit of engineering.
What is the engineering part of programming?
It is the science and creative expression of programming. It is knowing how computers work, strategies to encapsulate logic, the assumptions you will choose to make and test, the flow of information through algorithms, the power of 1, and more. Coding isn’t part of this stage — if anything pseudo code (idiomatic). You’re creating the logic that will be taken to a material form (coded).
I know many will argue it is not feasible to do this with every project or that it’s not necessary to learn to code. However, I’m not arguing that you create verbose documentation or designs. I’m arguing that engineering and creative thought is needed before you code. Being led by code won’t give you the thought process. It comes from actively seeking out and going through that engineering aspect of programming.
Still, many will argue. “Yeah, in a perfect world…”, but after teaching many thousands of students in programming at a university level I’ve seen it and heard it all. The fact is those who hold a programmers mindset quickly separate themselves from the average. They are simply thinking before the code.
So, the two words are not synonyms, and a coders mindset is different to a programmers, so next time you undertake a computing problem look beyond a coding tutorial or code snippets. Seek out the engineering. When looking for tutorials find the ones with this engineering process presented before they give the code. That way you will know why along with the how.
Unfortunately, not everyone who makes tutorials are programmers, just coders…