Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.

When coders grow up, do they become developers?

Screenshot 2014-03-20 14.54.10

Would you describe yourself as a developer or a coder? When writing this post, I knew in my mind the distinction I wanted to make between what I thought a coder and a developer was, and what they do that makes them different. However, when I came to writing them up, I found it a lot harder to succinctly define.

It’s clear and fair to say that everyone is different and will have a different idea as to what a coder and developer is. One thing that is for sure and likely something I’m sure we can all agree on, the world wouldn’t be a better place if we we’re all coders or all developers. As with anything, a blend of skills and focus areas is key in any functional team, in the same way it’s key to blend cultures, gender, age etc. into your teams.

A coder and a developer do still share many of the same traits, but it’s where their focus lies which makes them different. Here’s an example table with what I believe a dev and coder have as their focus areas.

Task Coder Dev

Problem Solving

Low level

Range of high and low level

Language Patterns

Detailed understanding

Shows usage of

Code producer

High amount of code

Med amount of code


Within team

Business, Line and Project Management


Code maintainer

End user/Customer

Knowledge sharer

comments/iteration demo

writes docs and blogs


Went to church once, didn’t go again.

Presents and interacts with community/forums

When did we become Geek 1.0?

Let’s look at where it all started… when we first learnt about coding. I’d say the vast majority of us were at school, typing out some code from a magazine straight onto a spectrum – we were coders. Sadly, web app code for financial applications don’t appear in magazines–trust me, I’ve checked!

Let’s think back to what made us decide to walk the path of a software engineer in the first place. We were leaving school and wanted to learn more about this programming thing, so we had a play with some code and at that point we caught the coding-bug. But what is the coding-bug? Is it the really interesting problems and puzzles that can be solved with thought, design and coding? Is it watching your changes realise themselves at runtime, enabling you to see a feedback loop of your own awesomeness? Maybe it’s all of these things, and more. Hang on, think again… are you sure it’s not communication with the business? Understanding business requirements and learning how to deal with project managers? Writing documentation/user manuals? Giving demos or reading through high level specs? Aren’t these the things which drive you? No? Really?

OK, some of that might be interesting, but aren’t we here for the code, the raw design and programming, rather than all the crap that just gets in the way of my special Eclipse/IntelliJ/NetBeans time [delete as appropriate]? Well at least that’s where it started. Maybe the difference is simple: coders are developers who truly love *everything* about their job. Whereas developers are coders who have to put up with a load of unfavorable stuff that just gets in the way.

So what changed?

Universities and educational institutions churn out coders rather than developers – Why? Because developers face real world problems and produce real world solutions, so practicing being a developer isn’t as simple as writing up a solution to a coding exercise. Once you brave the real world and get a job, it’s not uncommon for software engineers to evolve from being a coder to a developer during their working lives.

But many, whether out of choice or not, stay as coders. And let’s face it, we live in the real world. A world where we’re ultimately tasked to produce the best product we can, not the best code. If we can do both, then that’s awesome, but if we had to choose, product should always trump code. Why? Because if the product isn’t right or fit for purpose then who cares how well it’s coded? Also if the business isn’t producing applications fit for clients/users, it’s missing it’s market and will fail. So a team full of engineers focused on coding will likely fail, even though they will produce a wonderfully designed and coded application.

Before I offer up my opinion as to what a coder and developer are, take a moment just to think for yourself to determine what the roles mean to you… got it? no? ok, take more time… how about now? You have, awesome! See how close they are to my definitions/bios below.

What is a coder?

A coder is someone who primarily writes and tests code and will react to anything other than these tasks. Typically a coder understands all corners of their preferred language inside out and sets their primary objective as a quality, neat, performant implementation. A coder is most comfortable writing code in several monitors at once, and gets angry if they’re away from their IDE for too long. A coder will turn hard requirements into code, caring less about where the requirements come from or their correctness. Their goal is to translate them into the best bytecode they can. A coder drinks caffeine to excess :)

What is a developer?

A developer has a broader reach over a coder. Their focus is more around the business and the stakeholders of their project, which lead to a closer interaction with other development teams and users to gather and verify/question requirements or restrictions. A developer cares more about the design of the interaction with other features and products, i.e. it’s usage in the real world, than just the design of the code they’re writing. A developer might be seen as a more teamy and social person. A developer welcomes time away from thier desk to interact/present/reach out to the community, or maybe go to a conference. Their day job isn’t just in their IDE, but they do still spend a lot of their job coding. A developer drinks caffeine to excess :)

OK, so we’ve done a lot of labeling there, and I think with enough beer and discussion we’d get other indicators of what makes a coder or developer. Cue the barrage of disagreeing comments… While, you’re at it, you might as well just accept that Java will be here another 20 years, Eclipse *IS* the best IDE and YES, Jetty *IS* an application server.

So what’s the nirvana? A team full of developers? Like anything in life a mix is always the best solution (unless you’re talking about drinks, and then if you have to, always go beer->wine), as then you achieve individual focus on various aspects. But what is key to the success is communication, something that agile has taught us, and that must be maintained well beyond it.

How to be a better developer

Read/Write moreTo broaden your skills and think outside your problem space, it’s important to understand what others are doing as well as being a thought leader yourself. Reading and writing blogs will broaden your technical mind and put you on the path of a thought leader.

Engage with the communityI don’t just mean join a JUG and you’re done. Participate, go to JUG meetups, join in forum or mailing list debates, discuss and present on topics at the meetups, and be an active, visible leader in any product/project communities you’re involved in to better understand your users. (You could even join up with the vJUG and engage with us there!)

Take on wider responsibility not just moreResponsibility doesn’t mean just more ownership of your codebase, but think more about the architectural decision making, the spec ownership, and the API discussions. These are the areas you want to be influential in.

Think about your *real* stakeholdersYour real stakeholders are the users of whatever it is you’re producing. When writing code, documentation, APIs/SPIs, think about how someone is going to actually make use of them and ask yourself if this is suitable.

“Whoa” I hear you say! “I don’t want to be that much of a developer! I already do too much outside of Eclipse as it is! I wan’t to do more coding! Help me do that!”. Ok, here are some things which you might want to do to become more of a coder than a developer.

How to be a better coder

HeadphonesOne of the best, and well recognised, methods of getting into the zone, and staying there is to apply headphones. People tend to disturb you less, and you’ll be able to focus on code and not lose track. This also means people will be less likely to dump stuff on you as you get involved with fewer discussions :)

Reduce your focus areaTry to become an expert in a particular subject matter. The broader this becomes the less of an expert you will really be. It’s important to be a master of your codebase and to understand it from edge to edge.

Limit your emailLimiting your email exposure to once or twice a day has two repercussions. Firstly you have fewer interruptions (unless you get ‘that guy’ who walks up to your desk to tell you they’ve sent you an e-mail – seriously, well done) and can focus on your code and secondly other people on cc will cover tasks so you don’t have to, allowing you to focus on your goals.

Ignore overheadsBasically, anyone who doesn’t want to talk about code – this can range from managers to project based people asking for status. They can get that detail from other people. If you just want to deal with code, break away from the other stuff that doesn’t interest you.

Personally, I was a coder through university who evolved into a developer at IBM and grew into a technical evangelist at ZeroTurnaround, possibly because I didn’t wear headphones anywhere near enough and found too many interesting projects to join and agree to help with! So this is a reflection on my journey as well as reflecting on others I’ve had the pleasure in working with. I’d be keen to hear how your opinion differs and hear about your experiences in the comments section below, or ping me on Twitter at @sjmaple.

  • Erkki Lindpere

    “Reduce your focus area – Try to become an expert
    in a particular subject matter.”
    If the purpose is to spend more time writing code, this might actually be detrimental as people will want to talk to you more. Unless you become a secret expert.

  • Ben M

    I tend to think in terms of Coders (Code Engineers) and Software Engineers. Building code and Building software are very different things. There is a lot more that goes into building a software system than simply writing code. A large group of Coders will never deliver a great product (unless, of course, the audience is other coders, or other software engineers. even then someone needs to document that framework/engine). A large group of software engineers certainly can. That isn’t to say there isn’t room for coders, but they have to be willing to understand that there is more building software than just the bit fiddling piece of it.

  • Brandon

    “A world where we’re ultimately tasked to produce the best product we can, not the best code.” As someone who takes my craft very passionately, I feel that the best product is that written with the best code.

  • Kislay

    I liked the headphone part, I do the same to focus, while coding.