The Myth of the Coder and Programmer
The article discusses the myth of the distinction between coders and programmers, highlighting that both roles were often performed by the same individuals, influenced by historical narratives and contemporary AI discussions.
Read original articleThe article "The Myth of the Coder" by Maarten Bullynck and Liesbeth De Mol explores the historical distinction between coders and programmers in computing. It argues that while the terms suggest a division of labor, in practice, the roles were often performed by the same individuals. The distinction emerged in the 1950s, particularly influenced by the work of Herman H. Goldstine and John von Neumann, who outlined a hierarchical approach to programming and coding. However, evidence shows that this separation was more mythological than practical, as many early computing professionals engaged in both planning and coding tasks. The authors highlight that the idea of a coder as a separate entity gained traction through the advocacy of Grace Hopper, who promoted the automation of coding processes. This narrative has persisted, leading to misconceptions about the roles within computing. The article concludes by reflecting on how historical narratives can shape perceptions of technology and labor, drawing parallels to contemporary discussions about AI and automation in programming.
- The distinction between coders and programmers is largely a myth, with both roles often performed by the same individuals.
- The separation of coding and programming tasks was popularized in the 1950s but did not reflect actual job practices.
- Grace Hopper's advocacy for automatic coding contributed to the myth of the coder as a distinct role.
- Historical narratives in computing can influence current perceptions of technology and labor.
- The article draws parallels between past misconceptions and modern discussions about AI's impact on programming jobs.
Related
Programmers Should Never Trust Anyone, Not Even Themselves
Programmers are warned to stay cautious and skeptical in software development. Abstractions simplify but can fail, requiring verification and testing to mitigate risks and improve coding reliability and skills.
DHH – Programmers should stop celebrating incompetence (2021)
David Heinemeier Hansson criticizes celebrating incompetence in programming to combat imposter syndrome. He emphasizes deep understanding over surface-level knowledge, urging programmers to strive for mastery and competence through dedication and continuous learning.
Code as Art
The article explores computer programming as an art form, emphasizing its aesthetic potential alongside functionality, highlighting examples like generative AI, esoteric languages, and contests celebrating unreadable code.
A Definition of Magic in Programming Languages
The article defines "magic" in programming as a continuum of complexity in understanding code, influenced by constructs like inheritance and monkeypatching, emphasizing rational discussions on its costs and benefits.
The art of programming and why I won't use LLM
The author argues that the effectiveness of large language models in programming is overstated, emphasizing coding as a creative expression and expressing concern over the diminishing joy in programming due to automation.
1. Software architect
2. Software engineer
3. Programmer
4. Coder
The lowest level is the coder who only knows how to code.When you go higher, you have the more elite "programmer" who does the exact same thing as the coder but is more elite because he calls what he does "programming" instead of "coding"
The next level is the Software Engineer who is even more skilled then the programmer because although he does the exact same thing as both the coder and the programmer he calls what he does "engineering" which he deems equivalent to what rocket engineers do when they "engineer" a rocket that flies into space, but instead of a rocket it's some website. Keep in mind that as amazing as rockets that carry humans into space are, it is not as amazing as some plain website because these "software engineers" likely get paid waay more then rocket engineers.
The final, highest level is the software architect who's power is so high he doesn't even "code", "program" or "engineer" stuff anymore. Instead the software architect has the skill of "big picture reasoning" which is the skill of being able to draw boxes and circles on a white board and also drawing lines between those shapes. This is what we term "software architecture" and this is the epitome of software skill. The software architect is basically a god among software engineers.
My goal in life is to become a master at drawing circles and boxes and lines. I admire these people so much.
I like programming because it’s easy to ignore labels and just look at output to see if they are terrible or decent. Takes some time to distinguish decent or great, but it’s easy to see if someone is just horrible.
I’ve never cared if I’m programmer or coder or developer or engineer. It’s not like there’s legal differences like medicine or law (some places do have engineer labels, but no states where I’ve worked). I really care about ability to make an impact and compensation. Some of the stupidest titles I’ve had were most interesting work.
It seems odd to try to pick the right term as even for recruiting it’s probably better just to state the label, duties, and skills required in order to attract people.
Actually I think the article is using modern terms, but seems right.
From what I remember from the early days, you had "System Analysts", "Programmers" and "Key Punch Operators". Key Punch and Programmers were considered Low-Level and was not paid much more the the US average salary, Programmers a bit more than Key Punch people. System Analysts was where the money was. But seems during the 80s, the 3 jobs merged into one.
By then, I use to program and work directly with the Business in the 80s and 90s. Sometimes the Business person would be sitting next to me while I showed then the changes and how it worked. Changing the program based upon their comments while they were there. Fun times, and yes even did this directly in production :)
Then it seems in the late 2000s, they started to split again giving us Business Analysts (BA) and Programmers (Coders).
https://brajeshwar.com/2007/are-you-a-programmer-or-a-coder/
You see similar with cook versus chef. I'm sure the same distinction exists in near any work where a surprising amount of what needs to get done is far more mechanical than people admit.
It doesn't help that it is often loaded with loaded nonsense about worth.
In present times, the complete road map is something like this:
coder -> Programmer -> Developer -> Engineer (Analyst) -> Architect
Understanding why there even were two terms is actually quite interesting, and of value for all those pontificating on what they think current use of these terms ought to be.
Whatever you decide to call these two things anyone who has onboarded a new grad/intern has observed this distinction because its a different skill set.
The people who write code in the demo scene traditionally call themselves 'coders', and those are pretty much the best of the best (and quite a few 'proper' software engineers among them).
Related
Programmers Should Never Trust Anyone, Not Even Themselves
Programmers are warned to stay cautious and skeptical in software development. Abstractions simplify but can fail, requiring verification and testing to mitigate risks and improve coding reliability and skills.
DHH – Programmers should stop celebrating incompetence (2021)
David Heinemeier Hansson criticizes celebrating incompetence in programming to combat imposter syndrome. He emphasizes deep understanding over surface-level knowledge, urging programmers to strive for mastery and competence through dedication and continuous learning.
Code as Art
The article explores computer programming as an art form, emphasizing its aesthetic potential alongside functionality, highlighting examples like generative AI, esoteric languages, and contests celebrating unreadable code.
A Definition of Magic in Programming Languages
The article defines "magic" in programming as a continuum of complexity in understanding code, influenced by constructs like inheritance and monkeypatching, emphasizing rational discussions on its costs and benefits.
The art of programming and why I won't use LLM
The author argues that the effectiveness of large language models in programming is overstated, emphasizing coding as a creative expression and expressing concern over the diminishing joy in programming due to automation.