Going through life we learn there is always a correct way of doing things, despite if other ways produce the same result, and even they are faster.
The same is for belonging to a certain group – there are rules to follow, even if not following them would benefit the group (and other groups) greatly.
In this article we will focus on what it takes to be a True Programmer (Real Programmer), the one and only ideal, to be accepted in the glorious programmers’ community.
Characteristics
Let’s start with the common characteristics of the Real Programmer.
It is best described by an article Real Programmers Don’t Write Specs which still holds true, just with new technologies.
More extended variation of the article is a Real Programmers
Nowadays the Real Programmer
- creates very complex code
- does not document or comment it because it is obvious what the program does
- knows low level programming very well
- is an electrician – can reprogram any electronic machinery present in his house
- uses command line whenever possible and hates every UI
- makes simple applications always with short parameters like “a” for “append”, “aa” for “add”, “au” for authorize etc.
- knows a language like BrainFuck
- has written a compiler
- has written an interpreter
- can write them again today if asked
- uses alpha version of every tool
- can write code in Notepad (original one, not “++” version) without any syntax errors
- still remembers all univeristy stuff like alghoritms even if not using them in his job
- can create a lot of code very quickly
- was interested in computers literally since being born
- never use mouse
- do not use Google; on StackOverflow posts only answers
- do not watch movies, play games, read non-programming books, meet with non-programming friends
- do not have any other hobbies besides programming
It all may sound silly but if a programmer has at least one third of those characteristics, we have found a Real Programmer.
Using Backbone
Couple of my previous articles touched this topic briefly. So called “code developers” share major part of the “real programmer” characteristics.
Below quotes are from those articles or articles I have cited.
Why real programmers write complex code?
Complex code is satisfying. That conclusion comes from the lecture given by Dror Helper on the .NET Developer Days 2019 conference that I have attended.
Do real programmers are all-in code only?
The “code developers” understand every line of their code and used frameworks, they do not cooperate with business – they expect perfect design and focus on coding it.
“Technical developer” follows all patterns and practices possible, budget or deadline being less important
Ben Collins-Sussman: There are two “classes” of programmers in the world of software development: I’m going to call them the 20% and the 80%.
The 20% folks are what many would call “alpha” programmers (…) These folks were the first ones to install Linux at home in the 90’s; the people who write lisp compilers and learn Haskell on weekends “just for fun”; they actively participate in open source projects; they’re always aware of the latest, coolest new trends in programming and tools.
What lies behind an atrocity towards not real enough programmers?
Scott Mitchell: To me, saying that titles like ‘Teach Yourself X in 24 Hours’ cheapen the craft is tantamount to saying, “Our club is full. Go away.” (..) “Newbies are ok, but they must first realize how hard this is, how hard we’ve worked, and how much more we know than them.”
Do real programmers accept gaps in one’s technical knowledge?
If you had put a technology in your resume, it means you are an expert with it.
Quoted articles:
“Are developers paid only to write the code?”
What every developer should know – ultimate edition
The Two Types of Programmers
The True Pole
Those unwritten rules exist not only for programmers.
In a What every developer should know I have stated that
It is the same with “books true fantasy fan should read”, “metal albums true fan has to know and will be examined before every concert”, “board games you need to learn before even thinking you like board games” and so on.
For example, to be a true male citizen of Poland you must be good at drinking vodka as well as follow current football and ski jump championships.
Flawless ideal
Let’s touch few characteristics that are common briefly.
Complex code
We know why writing complex code is satisfying (feeling like a wizard).
The developer being asked to do something, then in front of colleagues and his boss, opens his tool and writes “tool.exe -p -a -au 2 2 -g /4 -f out.txt /c”.
Would the tool having a UI and/or being documented be better for other developers in the future, even usable by non-coder? Probably yes, but won’t have that much “magic”.
Infinite knowledge
The “universal knowledge” comes from “It is so obvious to me, how can anyone not know that?”.
A conscious effort is needed to go to the point in the past where that knowledge was not present and imagine things going differently at that moment.
No developer has been born knowing certain concepts.
Being independent
Another trait of a real programmer is complete independence. Of books, help from others, tools, and frameworks making the job easier.
The job needs to be hard so everyone will see how much the hero the real developer is.
Would having it the other way be faster for the project or improve its quality by following some common patterns?
Of course, but “my grandparents did not have Google”. It is also an easy way to call everyone else a cheater if they code their tasks faster using frameworks.
Producing tons of code
A real programmer, given a task, starts coding immediately and produces a lot of code quickly. Does not question requirements, does not document assumptions, just produce code.
Everyone looking at that developer should be impressed. Like when seeing someone playing blitz chess (the game with a time limit of a few minutes).
However solving every problem that way is again a temporary solution, putting more weight on the maintenance teams, and making a risk of not understanding the requirements correctly. And being good at blitz chess would not guarantee victories in the longer games.
Summary
Is there anything wrong with being a Real Programmer? If there would be no social interactions or needs to maintain produced software, real programmers would be ideal.
Mentioned negative effects however exist. Anyone not real enough is looked down upon, and the more difficult code to maintain, the better.
Most importantly, let’s not make a Real Programmer characteristics a Minimum Programmer or Industry Standard Programmer characteristics. Some of them may be useful, others are just tribe identification mechanisms.
For example, a Real Programmer may be useful for a quick client demo on-site to show off the company as rockstars. On the other hand, the solution presented as a piece of cake will be a cholesterol bomb for regular developers that would need to ship before the unrealistic deadline.
The best summary is most of the article “The Real Dark Web” by Charlie Owen quoted below:
(…) developers are quietly building their sites and apps, day in, day out. But they are rendered invisible as they are not making use of the cuttingedge technologies that the 1% of the bleeding edge love to talk about.
They are the 99% of the web universe that is quietly getting on, not blogging about their technology stack, not publishing amazing new tooling. Simply building things.
(…) To be on a cutting edge team is a privilege. It means having resources and money and a lack of accountability that most web developers simply don’t have. It means being able to try out and develop new and amazing technologies. It means being able to do that and knowing that you’ll have the support from your org to do that. It means working at a user count where you are able to dismiss users who are inconvenient (“what, they’re on an old phone? Phhh, sorry, we don’t support them”), because you know a great crowd of others will be there to take their place and finance your JUST SHIP IT innovation spree.These teams are typically producing apps that are engineering-heavy. Engineering is a word that features often with the 1%. It means thinking logically, it means Serious Stuff. As a title it sounds extremely impressive. It evokes images of white-shirted men hunched over computer consoles, guiding the first humans to the Moon. It makes one think of giant engineering projects that will change the world, of Victorian builders of world-changing technology.
The reality for most, well, web developers is very different from this. Most web developers are working on very “boring” teams. They’re producing workhorse products that serve the organisation needs. They aren’t trying to innovate. They aren’t trying to impress the next recruiter with their CV. They simply want to get paid, produce a solution that works, and go home.Yet they are told, mostly implicitly, sometimes directly, that if they’re not innovating and using the latest tools that they are somehow a failure. This feeling of failure for not implementing the latest tech permeates our industry. This feeling needs to end.
You’ll notice that I didn’t say “the 1% need to stop innovating”. (…) No, they don’t need to stop innovating. I want them to innovate. It’s innovators in the web world that laid the cowpaths that we now all follow. (…)
For most teams are not able to just do what they want. They are constrained by the organisation that they exist within. They must produce code that will reliably work and be easily maintained over the next several years. They can’t afford to retain someone who will innovate a new codebase and then move on, leaving others to puzzle over it. They can’t hire a 10x Engineer Ninja who will reimplement a brochure-ware website in a client-side framework and then ignore those users who are excluded by it. (…)As I read that tweet and thought about dark matter, a darker analogy occurred to me. Because the 1% of developers who dominate our conversations and newsfeeds.
(…) People speak about “the old guard” and “stupid backwards techniques”, forgetting that it’s real humans, with real constraints who are working on these solutions. Most of us are working in a “stupid backwards way” because that “backwardsness” WORKS. It is something that is proven and is clearly documented. We can implement it confident that it will not disappear from fashion within a couple of years.
Perhaps more of us would use the latest and greatest code if it was well documented, and proven to be sustainable. If we thought that the people behind it thought about the coming 5 years, rather than the coming 5 job interviews.
I want to innovate. I love learning new things. It’s what attracted so many of us to this industry. But let’s take time to think about what we build, and how appropriate it is for any given situation.Perhaps the client-side framework developed by a multi-billion dollar company isn’t the one that you should be pushing into the browser of your local grocery website? Perhaps the buildchains that require ancient dark magick to invocate are not appropriate on a team that simply compiles some Sass to CSS?
Let’s appreciate what the 1% does. But let’s not allow the 1% to dominate the conversations and our collective headspace.
Leave a comment