Yes you read the headline right, I am a programmer but i don’t actually like programming that much.
If you were to ask me to list my favourite things to do. I doubt programming would feature on the list. I might finally start to think about it when I am running out of things to list.
You see, I am not the kind of person who would ever think on my day off:
Let me pull out my laptop and do some programming.
Unless of course I have a goal to achieve and I need to use programming to get there.
Let me explain myself, I studied computing at university and I currently work as a software developer. I have been programming for a few years now. I see it as a way to create something. I enjoy being creative. I like being able to take a concept and move it to a point where it is substantial and others find pleasure in using it.
However I do not particularly like programming itself. I don’t freak out about design patterns. I never think about how I can optimise the codebase to shave 2–3 seconds off of the processing speed. I don’t get particularly excited about trying out new libraries, api’s or languages.
So why am i bringing this to your attention ?
I believe there is more than just one type of developer. I think others feel the same way as I do about programming but aren’t comfortable saying it. Why ?
Well it is kind of against the programming commandments.
We are consistently told to be rock star developers who live to code. We should have coding side projects we do in evenings / weekends and regularly be attending tech meet-ups. Articles constantly appear telling us how much others love programming — “I quit my job and fell in love with programming.” Interviewers expect us to know every little detail about obscure algorithms, design patterns and code optimisation as if the interview was an exam on data structures 101.
Most developers do enjoy doing the items I listed above. All I’m saying is that not all developers only want to be rockstar coder’s, they have different interests and priorities and that’s okay. Maybe around 5–10% operate differently and we need to start to understand these developers, their individual needs and then we can perhaps move forward and create more effective teams.
3 Key Developer Types:
I see 3 main developer types at entry level. However I am sure there are more and feel free to contribute in the comments below.
Source — FlatIcon icon’s used
There is room for all 3 in a team, we just need to understand each of them to help reach their full potential.
The “Get It Done” Programmer:
Firstly let me explain the category I see myself in which is a “get it done programmer”.
I feel I have been in this category since university. I have always been a high achiever at university and at work. This is not because I am great at programming or extremely interested in it. I just needed to get it done.
I would be assigned a project. I would be extremely anxious about not being able to complete it. So I would start early on the project and work hard to achieve the goal. That was the only advantage I had over my peers — I spent so many hours learning the concepts, understanding the problem then trial and error coding to produce a solution. Most of the time the end result was well received.
What interests me in day to day work is throwing around concepts, mock ups, working with users, presenting ideas and improving the final product. My main interests are everything around the technical build of the project however if i need to use programming to get me towards the goal then I can use it.
If you are managing this kind of developer:
- Try to find opportunities for them to develop their interests within the department and if that’s not possible then outwith the department.
- Have a frank discussion with them out about their interests and try to carve time/days where they can work on their interests and the other days they still work in the development team as a programmer. This means you are not losing your top talent.
- Don’t make false promises that you can’t keep when the pressure is on. If you do this it is almost a guarantee they will eventually leave to pursue their interests full time or find a role which can offer what they need.
As a manager don’t assume programming is the developers only interest or passion. Don’t make only technical training course and development programmes available. Appreciate they might want to learn something else e.g. Digital marketing, UX, product management, graphic design.
The “Techy” Programmer & Their Relationship With The Get It Done Programmers :
Techy programmers simply enjoy programming. They are the type of developer we are already catering for in industry and their are many great articles on how to keep them engaged. Therefore I won’t focus on my attention on this.
I would like to focus on the relationship between the techy programmer and the get it done programmer. Their skills can compliment each other greatly if the relationship is managed correctly. However it can often be challenging to get each the programmers to see eye to eye.
The geeky programmer will want to implement sophisticated solutions. The get it done programmer will want an elegant solution which wins the most points for the users.
Often both programmers want the same things but are approaching and phrasing it differently. The techy programmer will be focused on an optimal solution with maintainability and extensibility at it’s heart. They often hone in on technical details when explaining the solution. This overwhelms the get it done programmer who is more focused on timelines, needs, availability and simplicity.
The ideal solution is often a mix of both of the developers ideas. It is key to find the harmony while causing the least amount of tension. Managing this relationship and getting each developer to understand the others skill set as well as respect each other will be vital to creating a high performing team.
The “I don’t think I want to do this” programmer
Lastly the “I don’t think I want to do this” programmer.
This programmer similar to the get it done programmer, doesn’t like programming and yet has arrived in your development team…..
It is likely that they were unsure of their skills or their interests and followed the most available career path to them. They might never have really liked programming at university but thought they would keep giving it shot. They discover in the working environment they like it even less.
It is likely between the range of 3–6 months in they will tell you this especially if you are in a large company with rotational programs available.
In the beginning you might encourage them and give them simpler programming tasks. However even then you find too many of your other resources are being used to help these individuals. They have other skills, it’s just programming hasn’t come naturally to them and they don’t really enjoy it. If you don’t enjoy programming and you don’t have that inherit need to problem solve or get an answer to solution, it is unlikely you will have the urge to program and develop your skills. The best way to pick up programming skills is from trial & error and that comes from needing to solve the problem.
So what do you do when you realise they might not actually be cut out for programming ?
Most of the time I see teams just allocate the individual to a business analyst role in the team or create a business analyst or scrum master role that never existed before.
Often these roles are just a combo of all the other basic tasks no one else in the team has time to do — managing documents, testing, writing basic scripts, tidying up code. It is often a role the team never planned on having but hey at least they can say they are agile to senior management now, right ?
Wrong. You need to understand what the individual expected from the role, what skills they do have and what you can offer them. If you can’t offer them this then use your network to find them a suitable role. Don’t just create a unnecessary roles in your team because junior talent is free ( this is often true in larger companies with graduate schemes ). If you use your network to help find your team members the right role for them, it is likely your network will repay you if they find someone suitable for your team
On wards
All 3 types of developers have a place in the team, we just need to understand peoples interests and needs instead of placing them into a box based purely on the degree or job title they chose.