Sometimes in the month or so after New Years, things pop into my head as “micro-resolutions.” Basically, it’s stuff that I ought to start doing that doesn’t rise to the level of importance of altering my life. One such thing is balancing the sorts of posts that I make here.
I want to start getting a little more even between how-to/coding, “life of a programmer” posts, and answering reader questions. Toward that end, here’s a reader question.
You’ve mentioned the fact that you don’t like the title “architect”. I agree with you because architect has different meanings for different organizations.
I have [seen] that it can involve writing code, designing UML diagrams or just write Word documents.
Don’t you think that a developer should be [a] programmer who is also an architect and a problem solver?
In my career, I’ve held all of these job titles, so it is with some degree of admitted hypocrisy that I offer my honest opinion. This is certainly a subject that I’ve covered in the past, and covered from a variety of angles. It’s no secret that I don’t put a lot of stock into job titles in general. But I don’t know that I’ve ever, specifically, held forth on the difference between architects and developers, either in terms of what I perceive it to be or what I think that it should be. The question here, as I read it a little between the lines, might be rephrased as, “shouldn’t every developer wear the architect hat” or, perhaps, “shouldn’t architecture be any developer’s responsibility?”
Simply put, my answer to that is, “yes.”
Yes, every developer should be a programmer should be an architect and problem solver. Yes, every developer should wear the architect hat. Yes, all developers should take responsibility for ‘architecture.’ Now, with that out of the way, I’d like to dissect the architect-programmer distinction a bit. And in this dissection, I think we’ll get to why there’s so much of the fuzziness alluded to in the reader question around what the term actual means.
Consider programmer/software engineer versus architect as a study in contrasts (I used this post by Simon Brown as a research point for what people perceive to be the differences between architects and developers).
- Focus scope: programmers focus on details while architects focus on “the big picture.”
- Leadership: programmers are led and architects lead.
- Seniority: architects have been doing it longer than programmers.
- Cachet: architects are important visionaries while programmers do relative grunt work.
- Tech Selection: architects choose while programmers live with the choices.
- Skill: architects are more technically skilled than programmers.
- Code: architects write less code on average than developers.
- Organizational interaction: architects deal more with “the business” in meetings than programmers.
- Pay: architects make more than programmers.
- Value (status): see the last bullet and understand that an architect is more valuable than a programmer.
This is how the industry at large perceives this distinction. Architects are more tenured, important, valuable technical people that are in high demand, but often too important to do the thing that earned them their stripes (writing code). It’s confusing and even contradictory, and this intrinsic role-fuzziness is what leads to the lack of standard across the board. It’s why architects in some organization churn out UML diagrams while architects in others are indistinguishable from software developers except by job title.
The problem is that we cram together orthogonal concerns and ignore any resultant cognitive dissonance. We have a pre-canned narrative that explains all distinctions as long as you don’t examine it too closely. It goes something like this.
Our lives are steady, slow marches toward mastery. We start out young and inexperienced, and with each year that goes by, we improve, are worth a little bit more, and reap the fruits of that effort. The environments in which we work are meritocracies that recognize our steady, gradual improvement and reward us accordingly. As we move along, we thus earn titles decorated with terms like “senior” and “principal” on our way to leadership roles described by things like, “architect,” “manager,” and “director.” The more esteemed the title, the more deserving the person, and the more well compensated and respected one can expect to be. Furthermore, as we progress, we necessarily do more leader-y and business-y things, naturally shedding distinctions like, “detail-oriented” and “diligent” for “big-picture focused” and “visionary.” We become “idea guys/gals.” We get our due.
Against the backdrop of this implied narrative, the role of “architect” and the job title of “architect” both make perfect sense. Both are your reward for paying your dues and ascending to something more important, more valuable, and better than what you used to be. This means performing different activities, serving in different roles, and having different levels of responsibility.
But what if we put aside all of the implied value judgment temporarily? What would you have then?
Well, it’d be a much narrower set of distinctions, and it would look a lot like simple experience differentiation in any number of disciplines. One role would make decisions, focus on “the big picture” and spend less time “hands on” while the other role would take direction, focus narrowly, and be entirely “hands on.” Think of a partner in a law firm making big decisions on cases, while leaving more mundane, simple work to an associate.
But here’s the rub. The hotshot partner and wet behind the ears associate are not doing fundamentally different jobs — one of them is just running point and delegating. If you took this comparison and re-applied it to the programming world, you would have a tenured developer making tech choices (and living with them), writing the hardest and/or most critical pieces of code, and carrying the team, while delegating tasks for which the newer developer was ready.
To then revisit the beginning of the post, any developer should be an architect in the sense that any developer should be concerned with both the big picture of the software and the details thereof. Some will be more skilled and more experienced (and deservedly better compensated). Those are the ones that should be making the important decisions about technologies and about who should work on what. But that is not a fundamentally different role — it’s just a different trust level, and a trust level toward which everyone should be working.
If I were putting together a team of people to deliver software solutions, I sure wouldn’t want to have to go look for two different sets of people: one set of people to do the thinking, broad planning and decision making, and another set of people to do the grunt work. Give me one set of people: those that know how to solve problems, including the problem of taking care of both vision and details.