I received an email this morning from Brandon Savage‘s newsletter. Brandon’s a PHP guru (works at Mozilla) but his newsletter and books have some great overall perspectives for developers of all languages. However, this last one (What’s the difference between developers and architects?) kind of rubs me the wrong way. Either that, or I’ve just missed the natural inflation of job descriptions. (maybe, it’s like the change in terminology between Garbage man and Waste Engineer or Secretary and Office Administrator)
So maybe it’s just me – but I think there’s still a big difference between Programmer, Developer and then of course, architect. The key thing here is that every role has a different perspective and every one of those perspectives has value. The original MSF create roles like Product Manager, Program Manager, Developer, Tester, etc – so every concept may pigeon hole people into different roles. But the statements Brandon makes are often distinctions I would argue are the difference between programmers and developers.
While many advanced developers make assumptions such as “every programmer unit tests their code” or “everyone uses TTD”, most developers I’ve ever met know that’s not the reality.
Software developers write code. Software architects solve problems.
Actually, I thought it was Programmers write code and Developers solve problems. Architects build something even bigger.
That said, all of the points are valid – but I can’t help but think… if developers now write code, what do programmers do?
I see a big difference between the term “programmer” and “developer” – I know it’s all semantics but it’s an important distinction when hiring. Lots of people know how to “code” – technically, if you’ve dabbled in VBA in an Excel macro, you’ve “coded”. Does that make them a “coder” or a “programmer” or a “developer”?
A good example might be programmers code, but developers debug. Developers should be able to see the bigger picture. Programmers can write a program – but, in my mind, developers should be able to describe the problem, identify the solution, and explain it. I’ve seen enough amazing programmers who can use the most arcane or bizarre ( but cool ) methods for coding a function or problem but are inept at defending or explaining it.
But the other aspects of the newsletter have some interesting points on it.
Software developers see bugs. Software architects see the big picture.
Huh? If I hire a programmer, I expect them to fix bugs. If I hire a developer, I want them to do a bit more than that. Maybe a better way of looking at it is in scope:
Code —-> Library —–> Software Application —–> Broader Solution
I can expect a programmer to write code and maybe even an entire library. I expect a developer to be able to write/support a library and an entire application – heck, maybe even the entire solution. I do expect an architect to be a bit more than just a developer but the broader solution? I expect anyone in a more senior position (developer, architect, product manager) to get the big picture.
(now I have seen scenarios where S/As seem more focused on smaller issues instead of the big picture – but I don’t want to get into a p*ssing match with Systems Analysts).
Software developers focus on the computer. Software architects focus on the customer.
Once again – I suppose you could say Programmers focus on the computer, developers focus on the solution, architects focus on the customer – but I thought that was the purpose of the PRODUCT Manager (or Project Manager). Either way, the developer better understand and get what’s required. Developers should perhaps focus on their peers and ensuring they can explain what is involved.
Otherwise, don’t call yourself a developer, especially if all you can focus on is the code.
Software developers think about new technologies. Software architects think about trusted technologies.
This is an interesting one. I tend to think about it in terms of “problems”. Junior Programmers have a handful of ways of dealing with a problem and usually try to use them to fix a problem. Developers do (and should) learn about new technologies and see where they best apply. They should LEARN those new technologies but also be smart enough about when to use it. They should be able to evaluate those technologies and see if there’s a reason to use it in the resolution of a problem.
If all a software architect did was used “trusted” technologies, does that mean they only use “proven” technologies? (in other words, the old “no one got fired for using IBM, etc” approach)
Punch cards were once “trusted” but they moved to “tapes” and then “disks” and then “optical”. Which would you “trust”? It depends on your background.
I would go so far as to say architects think about trusted SOLUTIONS, not technologies and PROVEN technologies. A solution is the approach you take to resolving a problem – the technology is what you use to implement it.
When I got to the end of the newsletter, I started to think that it’s me. Maybe it’s the reason that you don’t see job postings for “programmers” but for “developers” – but let’s not simply evolve the definition of a programmer to a developer without making a huge differentiation between what those capabilities are.
One other point: referring to software “architecture” can really bug traditional architectural engineers. While software may deliver a lasting solution and there are parallels between physical buildings and software, this easily overlooks a lot of issues (but that should be a different post).
Programmers Program. Developers Develop. If you look at what an architect does in terms of requirements, it almost sounds most like systems analysis (because they often don’t build it). Maybe what we really want is a “Builder” term. But then, maybe we need a “Wizard” because businesses often want software that will work “magic”.
If you’ve never read any of Brandon’s stuff, do yourself a favor and check
What about you? Are you a Programmer, a Developer, an Architect? What’s the difference to you?