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.
NOTE: Comments have been disabled on this post due to large amount of spam.
FoxPro VFP
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 it out.
What about you? Are you a Programmer, a Developer, an Architect? What's the difference to you?
NOTE: Comments have been disabled on this post due to large amount of spam.
FoxPro VFP
Comments
I think they are kinda losing their place in the world as agile practices do small things at a time. Let the tech lead and his developers come up with the design... all the architect does anymore is put his stamp of approval on it.
Whichever you choose, you need to know at least basics of the other one.
If you are lazy one, I would recommend staring with design. People cant always tell bad design from good, but they can always tell badly coded, buggy website from a well coded
The term "architect" is more interesting. And more challenging - because there are so many conflicting viewpoints on what an architect should be. In software, it's important that - in order to be credible with the developers - and architect should have at least some experience of writing code professionally. But I think the notion that "architects should also code" is completely wrong.
An architect is not a senior developer. And architects that have only previously worked in development roles, make poor architects. The reason should be obvious - to a man with a hammer, everything looks like a nail. Their natural instinct is to problem-solve with code. A more rounded architect looks might choose to problem-solve with COTS. Or bespoke. Or a mixture of both.
And finally, architectural thinking involves *context* in a way that development does not. Choosing what language a new product is to be built in isn't just about the relative merits of the specific problem domain. It as much (if not more so) about organisation capability, and organisational strategy. If I have a large pool of Java developers, and only a handful of Ruby developers then my choice of language needs to take account of (but not be dictated by) that.
And finally, I do not expect (even senior) developers to have to concern themselves with things like the difference between capital and revenue expenditure. That's not their problem domain. But it is something that a architect should be able to understand. If they cannot understand organisational context, it doesn't matter how great their blue-prints are: none will ever be built.
Isambard Kingdom Brunel was an engineer. He build bridges, tunnels, railways, steam ships and more. He never learned to weld, or mortar bricks. Bu he is was surely more of an architect than a builder.
I didn't want to bring up engineer as part of the discussion but to your comment, Brunei "was surely more of an architect" but it's not about actually welding or mortaring bricks...it's about knowing HOW to.
Someone who builds bridges understands how to structure it, how to design it and yes, how to identify when there is a problem and likely how to resolve it.
Context is huge. And your note about cultural differences in terminology is great and it almost makes the Programmer vs Developer vs Architect move into the discussion of "Bear vs Grizzlie vs Polar" :)
Best Data Science courses in Hyderabad
AWS Training in Hyderabad
AWS Course in Hyderabad
Python training institute in Chennai
Python institute in Chennai