They will never try to reinvent the wheel, they will google up the best practices, write in small understandable chunks, thoroughly follow naming conventions in order to not confuse themselves in the future, document everything in comments etc.
Their bad part is mostly the speed. Lacking experience, they have to consult with stackoverflow, refactor every now and then and eventually burn out.
While the good and fast coder will deliver the working code in hours and days to the manager's satisfaction, though not as universal and forward looking (in terms of configuration and integration hooks).
And the coder that I classify as mediocre knows and employs all the programming patterns which makes their quickly written code standard and understandable, but not always working as expected until several testing iterations pass.
So what do you think, does this classification make sense, who would you hire and what does the first category need to do?
Fast programmers that write something dirty first, and iterate it until it's working well. John Carmack is like that.
Slow programmers that think about a problem and then write code that covers all scenarios they want to cover.
There are advantages to both styles. Both styles have disadvantages as well. Fast programmers sometimes have the tendency to not deal with details, so their code works but it's not bug free. On the other hand slow programmers might spend a long amount of time thinking about a solution and then realize it's not going to work within of a few minutes of writing ten lines of code.
In a way, bad programmers as also fast or slow, but the disadvantages of those approaches outweigh their programming ability. So they either write really dirty code or take ages to finish something and it's not even a good design.
Due to agile and probably human nature fast programmers seem better. You know, the dev that did the thing in one weekend. Think about Linus Tovarlds writing git in a week or two. Sounds amazing, yet it had to be iterated a lot and it still suffers from some of the decisions made in those two weeks of initial development.
For the record I am a slow programmer, but I have devised systems to help me speed up to appear like a fast programmer when it's in my nature to want to think about solutions over writing dirty code.
1. Pilots who are good and they know it. These are people who are naturally good pilots: memorizing the checklists, failure states, what to do in bad conditions, etc come very naturally to these people and they don't need a lot of training or hand holding. Generally great to work with unless they are cocky.
2. Pilots who are good and they don't know it. Pilots in this category have everything going on from the first category, except they don't realize how good they are. Often times, these can be the best pilots to work with, because they stick to all the checklists, procedures, manuals, policies, and so on, because they know that they might not know what they are doing, and on top of that they can shine in tough situations because they are in fact good pilots. These pilots are great because it's very rare to get one with a lot of ego.
3. Pilots who are bad and they know it. These are people who are aware that they are not naturally strong pilots, and their awareness leads them to following checklists, spending lots of time reading manuals, procedures, policies, to a T. In most situations, these are very good pilots to work with because they are aware of their own limitations although they may need more training for bad situations. Again, there is often very little ego here. I think this is the level of awareness that we're seeing in the OP here.
4. Pilots who are bad and they don't know it. This is the worst group of pilots to work with, but they can be fixed with training and guidance from senior pilots. Often times if you asked a pilot in this group, which group they fit into, they would tell you they fall into the "good and know it group", but they're wrong: they might be skipping checklist items, missing key policies, or just generally be a bad team mate. I would liken this to a junior or mid level dev who thinks they know everything. Often times there can be a lot of ego in this group
As a manager observing people's work, people work at different paces and come up with different solutions. No two employees are the same. As long as someone is progressing their skills and getting work done in a quality manner, it doesn't really matter if someone is faster than someone else.
In my opinion, someone that thinks they are better because they are faster also has a higher possibility to have an attitude problem on the team which is a bigger issue.
As @andreareina points out, rate of completing work and the quality of that work are unrelated factors. In my experience many fast programmers turn out low quality work when you consider the amount of re-work their work requires over a period of time.
Here is the kicker, I completed the most features out of anyone of my team. What happens to them is they finish a feature and within a few sprints they have at least a couple of defects they have to address from their own code. So their feature + defects ends up taking longer than my feature coding speed.
Having said that in 2020 I started to try to devise strategies to iterate faster, mainly because I felt I could optimize my thinking process since I knew that I had mental loops I would get stuck in trying to solve a problem.
Of course this is just my personal experience.
Its about making good design decisions. Period.
And this is something you can’t google, only accumulate through experience.
Of course every programmer would like to make the best design, but sometimes there's no time for it, and that's when slow/fast/experiensed characteristics come into play
You need both experience and also reflecting on that experience —-- usually in a social process.
I try to be that ideal programmer that switches between being both the fast or slow programmer and situationally adapts depending on the climate of the product and the company.
Who would I hire?
The ideal programmer if I can find it but otherwise, I'd just hire a mix of both.
It might be that the slow programmer more than makes up for the time by saving hours, days or weeks of tester’s and support team’s time further down the line.
