The Architect Title Over-Specialization

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.

Read More

A Players Don’t Hire A Players — They Partner with A Players

There have been a few strands of thought dangling lazily in my mind for a while now.  Over the last year or two, they’ve threatened, on occasion, to become blog posts, but it never quite worked out.  But today enough of them came together to make the resultant rant semi-coherent, as opposed to incoherent.  So, as they say, there’s no time like the present.

Tonight, someone on social media linked to this post about hiring.  It started off by saying that a record is being set for the increase in hiring software developer in the coming six months.  It then went on to describe variance in the assembly line hiring processes of tech titans such as Google, Facebook, Microsoft, and, quizzically, Yahoo, among others.  I was hard pressed to divine a thesis from the piece, but it talked about the hoops through which one must jump to work for these places, how long the interview process takes, and how people feel about the interview process.  If I had to summarize the byline, it’d be, “tech companies, more desperate than ever to hire, still pretending to be in a position of strength.”  Let’s put a pin in that, though.

Last night, someone on social media linked to something that led me to this bit of corporate boilerplate masquerading as an enthusiastic blog post on medium.  If I had to give this one a byline, it’d be, “we’re like totally awesome and we like, love people that are, like totally awesome, and like 10x productivity and like Steve Jobs, and like awesomely awesome awesomeness!”  I mean, for God’s sake, it says “great over good” in the first 25 words, as if it were penned by Bill Lumbergh himself.  “Umm. yeah… one of our corporate values is greatness… so, if you could just go ahead and come in on Sunday, that’d be greeeeeaaaaat.”

“A Players” and Who They Hire

It then goes on to reference the 10x developer canard and says that to be an order of magnitude more productive than others requires having standards, being curious, and realizing that anything is possible with the introduction of caveats.  (As an aside, the first two things merit an eye-roll, but the last one is pretty insightful, in my opinion).  It’s a standard snoozefest from some mediocre company’s “careers” page, lacking only the highly ethnically diverse stock photos.  And then, there’s the Steve Jobs quote.

Read More

Enough with the IoT Naysaying Already

In terms of the vibe that radiates from this blog, I try to maintain a healthy mix of optimism and cynicism. “How to” and explanatory posts tend to be optimistic in nature, offering you a “hey, we can all do this” appeal. On the flip side, some of my most popular posts tend to be populist, cynical rants about corporate culture and office politics. I suspect they’re popular because of a shared catharsis that we can all experience together. Frustrated people love a good rant.

Today, I’d like to mix it up a little by offering what I believe will be an optimistic rant. I suspect that’s not something you see every day.

The subject of my ire, at the moment, is the now-ubiquitous skepticism about the so-called “Internet of Things.”   I’ll allow that some of this probably has to do with buzzword fatigue and the cloying sound of marketing types saying, “dudebros, tomorrow’s chief digital officers are gonna IoT it up with some Raspberry Pis and rock out with some quadcopters!” That sort of thing will bring out the cynicism in any domain expert.

But I think it runs a little deeper than that and into a very selective form of quasi-Ludditism. Luddites are people who rail against new technology as if it were the bane of their existence, and no one in my feeds is doing that. But what I see instead, and what I’m calling “quasi-Ludditism,” is greeting the prospect of progress as if it were a gimmick with a failure guarantee.

Remember in 2010, when Apple’s stupid new form factor was a terrible idea and would obviously fail?

Read More