What kind of programmer are you? What kinds of programmer are there?
Are there 'real' vs 'fake' programmers? Is there a difference between a 'developer' and an 'engineer', and if so, what?
Large parts of the software industry seem to focus on stacks (e.g. Java vs PHP), environment (e.g. front end vs. back end) and/or industry/sector (e.g. tech vs. banking).
It might 'feel' right to distinguish PHP programming from Haskell programming. Each of those languages involves differing skills and knowledge. And yet, programmers can work at a very advanced or very basic level within either of those languages.
Or it might 'feel' right to distinguish UI programming from back-end programming. And yet, quite often, common concerns crop up in both: speed of execution, testing, algorithm design, etc.
I wonder whether these divisions truly represent where the real differences in skill and focus lie.
I wonder if our language will evolve in future, to better describe the different kinds of programming and programmers.
My attempt to 'play' with the categories of programmers and come up with some new groupings begins with 'camps'. These are groupings of people who program, independent of their level of 'maturity' (expertise, experience, etc).
Three main camps I see:
Tool users - people who have expertise in some specific field, e.g. biology, medicine, trading, music, whatever - and use programming as a powerful tool to augment/extend their pre-existing expertise.
Tool builders - people who use lower-level languages to create higher-level languages for tool users and/or for other tool builders. This includes people who invent languages, libraries and APIs.
Tool appliers - people who combine some expertise in both the above, in order to create applications which consume tools and are consumed by tool users. This includes various shades and varieties of software professionals - developers (such as myself), engineers, architects, analysts, recruitment agents and many other kinds of specialists.
Across these three groups there are also various levels of maturity, rigour and sophistication, depending on the nature and demands of the work being done and the competency of the practitioner.
I group these into 4 broad levels (which I caveat with a lot of fuzziness between the levels):
- Googling, StackOverflow, forums. Learn-as-you-go. Copy/pasting fragments.
- Applying frameworks and libraries. Consistent approach to structuring applications and code. Unit testing.
- Hand-picking architectural styles, design patterns, algorithms, data structures. Domain modelling. Design and planning up-front, as opposed to just writing code.
- Developing theories, proofs. System-building. New fields of research. Innovation. Pushing the envelope.
In these levels, I place myself somewhere between 2 and 3. Personally my interests lie between 2 and 3, but I could just as well have found opportunities around 1.
One of the coolest aspects of software and computing (in my opinion) is that you can (at least, at the time of writing) achieve personal and professional success at any of these levels. You're not necessarily 'stagnating' by remaining at one level, as long as you are actively working on something useful.
It's possible to stay at level 1 and get very far. For example, building an enormous and profitable online community with millions of users, using simple forum software such as BBCode, patched together with some StackOverflow code.
You could go to level 2 and build a good long-term salaried career, perhaps combined with some specific expertise in a particular industry, community, framework/library, software ecosystem, etc. For example, many advanced .NET developers have stuck with 2 and ended up being hired by Microsoft.
You could go to level 3 and build a career as a problem-solver, again, combining it with some specific expertise. This could lead to working as a niche contractor, running your own consulting business or working up the chain in a larger consulting company, taking a technical leadership role within a business, or simply improving your problem-solving abilities and perhaps publishing books or articles and becoming a 'thought leader' ala Martin Fowler, Mary Poppendiek, etc.
Then there's level 4, the realm of the most passionate, inquisitive, maybe obsessive minds. Theorists, synthesisers, system-builders, innovators. The inventors/discoverers of relational databases and relational theory, or of functional programming or of Reactive programming, etc. I think there's a bit of luck involved here as well, but it could just as well be attributed to an all-consuming obsession that drives certain individuals to invest an amount of time and energy that would be practically guaranteed to yield some kind of new insight, whatever field you did it in.
In summary, I see programming as a layer of human-machine augmentation, which overlays almost every field of human endeavour. Rather than a simple continuum of beginner to master, the space is more like a two-dimensional matrix in which you can choose any point or combination of points to focus on, work within and build knowledge, expertise and wisdom around.
As with many things in life, it's my belief that you get what you put in.
Thanks for reading!
Top comments (8)
Great post but I would have to disagree with the levels especially placing Googling, Stackoverflow etc as low competency. Development is constantly evolving and we are often tasked with implementing new things we have never touched. As a Principle Developer I find that this happens to me a lot as I am the person that people go to when things need to be done. Part of being a good developer is being able to source the right information and apply it whilst having an awareness that the information you have found is relevant and correct. I would argue that this actually requires a greater level of competency and understanding that you have given it credit for.
Thanks for your feedback.
Yeah perhaps it is a mistake for me to to grade it numerically. Each of those areas can go very very deep.
As you point out, being able to source the right and correct information and apply it is huge, and probably a competitive advantage for many businesses.
Based on your feedback I think I might change it to a bulleted list, or find some other way of indicating that each of these levels is a world unto itself, and that you can (and often are well advised to) go very deep on one level and ignore the others.
In fact, I suppose software/computing itself makes this 'selective ignorance' advantageous, with its 'layers of abstraction'. E.g none of us would be so foolish as to manually manage our own memory; we leave that task to the operating system and its layers of abstraction.
Yeah, also you never stop needing Google and Stack Overflow since most open source doesn't have good documentation and outsources that work to the wider community.
In addition to what you have outlined, I find there is a set of focuses:
Business - Engineers that focus on the business they are working at.
Novelty - Engineers who keep their eyes on the next big framework or language.
Fundamentals - Engineers who focus on best practices. This corresponds to people who want to be level 3 I think.
Tickets - Engineers that don't really care about any of that and just get tickets done.
Thanks for your insights!
Business - I would consider this to be the same category as 'tool appliers' or application developers. Basically a developer who applies tools built by 'tool-makers' to a business domain with help from business domain experts / 'tool-users'.
Novelty - I would consider this to be the same category as 'tool-makers', as essentially, they are creating a new kind of tool, whether that's a new framework, new language, new architectural style, etc.
Fundamentals - Yeah I consider this to be level 2 or 3. People whose problems require (or at least, appear to require) a deeper level of expertise than just 'make it work somehow'.
Tickets - I think this is also huge, both in number of people and depth of the skill. From the outside, it can look like simpler or more mundane or repetitive work, but from the inside, there can be a lot of depth and nuance in dealing with a large quantity of work. One skill is being able to switch quickly from one focus to another. A different skill is the 'intuition' that you develop, that enables increasingly accurate estimates of how long work will take. This might look like something that machine learning will eventually automate, but I think machine learning may struggle with work that is high volume and also constantly changing. Machines may get too focussed on the past data they've been given and fail to adapt to a changing context in the same way that a human mind could. This is all just conjecture, of course, as I'm no machine learning expert!
Ticket focus isn't so much about repetition or anything. This is all fluid and no one fits nicely into any categorization, but ticket focused people are the ones who always have end-of-year review in mind and know that knocking out tickets is the best way to look good to their boss. They don't necessarily care about the latest tech, or best practices, or even what is good for the business. They can be very smart people and that may even be why they are focused on knocking out tickets.
A further addendum.
This 'layering' of software over the world may not be as disruptive as we imagine.
It seems like many of the 'roles' we play are continuing, it's just that they express themselves in new and different ways.
For example, the role of 'customer service'. They might have new tools (CRM, analytics, machine learning) and a new environment (digital data sets and streams) but they also have the same focus as in the past (acquiring new customers, retaining existing customers).
Or take the role of the 'designer'. They also have new tools (digital tablet and stylus, graphics/3D software, image editing software) and a new environment (digital images), but here again, they are still focussed on creating visually pleasing artifacts.
The above might not even be correct or applicable descriptions of people's roles. I am just offering examples/analogies, to demonstrate how I see roles, tools and environments interacting.
The essence of what I'm trying to say is that there are some essential and fundamental human capacities that will continue to be expressed, but that they will be expressed through new tools and new environments.
Another addendum...
I'm seeing businesses improving how they hire people and how they put teams together by thinking differently about the kinds of programmer they hire.
For example, if a business needs a tool to be built, they look for a tool builder who has worked on similar tools, even though they used a different language or worked in a different vertical.
Or if they need an application to be built, they look for a tool applier who has worked in the same tech stack but a different business domain (or vice-versa). Then the tool applier only has to learn about a new business domain or a new tech stack, but not both, and can quickly become productive.
This is making for some interesting and surprising opportunities in the job market. In my own case, I am finding myself being sought after for roles and companies that I never would have anticipated several years ago.
On the other hand, it makes for a challenging competitive landscape, as I now have to compete with talent who may look very different from the peers I am used to working with.