Where I work, Software Architects are people who get paid lots of money to dick around with "new" technologies like RabbitMQ. Then after spending seemingly weeks implementing a trivial proof-of-concept app with the new thing, they present some slides and Visio diagrams at a brown bag nobody attends, and the rest of us ignore them so we can keep building things that actually provide value. Then they go on vacation to Aruba (probably).
Which is why they're worthless if that's what you have them doing.
I was chief architect for a startup and my job was basically filling in for everyone else wherever I could. I did all the documenting no one had time to do. I took every task I could off of the senior engineers so they could focus on shipping code. I tried to be that guy that had the whole system in my head, meaning I had to watch all the commits, regularly build, run, test and debug the system.
The most typical software architecture work I did was prototyping, but in this case, it was generally evaluating a set of clearly practical options so that we wouldn't waste everyone's time trying to make a decision. Again, this was so that the engineering team could actually get sh!t done instead of arguing about useless technical bikesheds. Any prototype had to be the sort that the developers could directly use as a seed for building the next feature on the backlog.
To me, that's what an architect is about. It's the job that any good senior engineer should be able to do and should absorb, as much as possible, all the crap that keeps those senior engineers from being as productive as possible.
I've seen the Software Architect role defined in many different ways. Some are the ones you've described, some are "paper only" architects who never code, but theorize to some unknown end.
The ones I've see that are most productive are the ones who more closely match the description in the article. They aren't above anyone, but they are supposed to be some of the most technically knowledgable people in the organization. Too that end, they have some of the most demanding jobs in the group and have to do more and understand more than a Senior Developer, who may only be well versed in one language or have the depth of understanding at all levels of the stack that an architect should.
Architects at my current employer will be called on to write production level code in more than one language, have the charge to watch over the commits and have the responsibly and authority to fix problems they see. They also end up being the janitor sometimes, pulling wires in the server room when the network engineers are short handed. It's a system that works pretty well.
I don't think this is for your point, but here's a counter-example: A large company uses 100 widely different technologies, and obviously no one can be an expert or even slightly knowledgeable about all of them. However when you're a SOFTWARE ARCHITECT [oooh!] it seems like there's an expectation that you should be an expert at everything. As soon as you're not (e.g. your example), you're seen as incompetent. In this case there's an unfair expectation.
But 100 really widely different technologies is A LOT.
My specialization - telecom industry. I'm dealing with families of technologies and they are not so plentiful. Messaging is messaging, DB is DB, application servers are application servers. Backoffice-frontoffice-mediation-billing remains the same in essence even if you change every component.
I think that I can become good (after 2-3 years) in banking software or manufacturing.
I think it almost impossible for me to become proficient in something like game production, high performance computing, many others
Ouch - this hits a little too close to home being from the architect camp myself (hell - I even spent the last week dicking around with rabbitmq! - talk about coincidence!)
Anyway - as I'm sure other comments will allude to, one of our jobs is to take the time-out from frantically delivering features to investigate new technologies/techniques and distil them in a 5-minutes-or-less style format to the rest of the team. Ideally, organisations should allow all members of the software team to participate in this activity, but it seems that when push comes to shove and clients are waiting for stuff to "get done" this kind of activity is one of the first to fall by the wayside.
If someone finds an employer willing to pay them a SA salary for the above job description, there's no way I'd fault them for taking that job and working it for the rest of their careers.
No, my company is awesome. They treat us very well. There's just one or two posers who are institutionalized enough to have this job, that's all. They are harmless, really.
Hell, I'm probably just speaking out of envy since I'd totally take the $150k they're (probably) making to dick around with NodeJS or whatever.
I wasn't trying to suggest that IBM is a terrible company. I worked there long enough, and in multiple offices in vastly different parts of the country to know that unless you are over 40 years old and have established your career to the extent you are happy with, finding another company that will give you a better overall experience is more important than waiting around simply because you're comfortable (I was definitely comfortable).
Uh, I was trying to say I work for someone way smaller than IBM and way cooler and who treats their employees way better. The architects aren't really representative of the workplace culture in general.
How very cynical indeed. Speaking as a software architect, sometimes it's important to get people to lift their heads up from the day to day adding value and look at new technologies. Many times developers are so focused on the bug/feature du jour, that they aren't aware there are other ways to do things, possibly better.
Having been a developer for a long time, the thing I have found is how much technology repeats itself, and how at its core, its all very much the same. The same algorithms I have used, like bloom filters or priority queues for example, have application in social networks and 3d rendering engines etc. Having done most software paradigms, an architect us supposed to know which ones work, and when they work.
I haven't written slides or visio in years. Nor have I been to Aruba :)
sometimes it's important to get people to lift their heads up from the day to day adding value and look at new technologies. Many times developers are so focused on the bug/feature du jour, that they aren't aware there are other ways to do things, possibly better.
Why can't your developers lift their heads up? Are they just lazy and don't care, or are they overloaded and discouraged from trying new things by the development process and company structure?
Very interesting perspective. I was a developer for over a decade before my path recently started moving towards architect. I find the opposite in my environment than what you are explaining.
We have so many developers working on different projects that someone needs to suggest/enforce some consistency across implementations otherwise you will have 30 projects, each developed in the favorite technology of each team and face resource problems when it comes time for support and maintenance.
To those with more negative leaning comments I would point out that not all development shops are the same. A software architect at my old 8 person startup would have been silly but I don't see how it would be possible to run development and operations of an airline or major finance company without people in this role.
Some of the systems in large IT organizations are vast and span multiple departments and integrate in many ways with multiple other systems.
The expectation that developers should perform their design/dev/test responsibilities while deciding/enforcing consistency across the organization as well as worrying about vendor contracts and negotiations while simultaneously acting as technology's face to the executive office is in my view an unrealistic expectation.
I would hesitate to hire a junior engineer who didn't understand basic subjects like bloom filters and priority queues and when to use them. I certainly wouldn't hire one who didn't know how to research alternative approaches on her own, without guidance from an "architect".
I'll bite. I consider myself a decent developer (but then, who doesn't?). I don't know what you mean by "bloom filters" or "priority queues" without Googling for them. I feel pretty confident that if they were the best solution to a problem I was having, I would find them through research.
Why did you pick those as "basic subjects" for a "junior engineer"? Are they important to your particular area of work?
I'm a micro-optimization and numerics guy by trade (mostly I write math libraries); they are almost completely irrelevant to my area of work.
Priority queues should be covered in a competent introductory data structures course. Bloom filters are marginally more obscure, but I still expect a good candidate to have come across them at some point. They're so widely used that it's pretty hard to avoid learning about them if you've done any significant amount of work or just spend time reading HN (they come up in someone's blog every month or so).
Note that I said "would hesitate to", not "wouldn't hire". If someone were otherwise a strong candidate, but happened to not be familiar with these, I would almost surely still hire them.
I should clarify that a typical candidate for a junior position on my team is either coming from graduate school or has 3-5 years experience in industry. I have correspondingly higher expectations for their background knowledge.
Bloom filters are marginally more obscure, but I still expect a good candidate to have come across them at some point.
Possibly in your area the candidates you get may have come across them, but then they wouldn't be junior engineers, by definition. If you're advertising for "strong algorithms" candidates then sure, but I bet half the people reading this have never used or come across any probabilistic data structure!
> then they wouldn't be junior engineers, by definition
I don't think so. My impression is that junior/senior is defined by years of experience more than technical skills. Having been out of university for one year now, I know I sure as hell won't get a job as a "senior engineer" anywhere, even if I could easily implement both these structures.
Those aren't basic at all, and I'm not sure why the commenter considered them so. As we all know, junior engineers have very limited exposure to a small area of tech, that's the very definition. It might just happen to be that the dev just finished a CS degree and is great at some of these algorithms, but that doesn't translate into a wide spectrum of technologies, which is only found in people with many years experience.
I was the one that actually picked those, just out of thin air to illustrate my point.
This I feel pretty confident that if they were the best solution to a problem I was having, I would find them through research. is exactly my point. How would you know that a bloom filter might be the best solution unless you know of it's existence in the first place. An architect's role is to suggest areas of research to junior engineers, who very likely may only have some vague memory from algorithms class.
I got a real kick out of this part, thanks. I'm imagining a scrawny, somewhat aged nerd-type but with a monocle flying off his face. Hilarious.
Anyway, this is pretty much the same thing architects always say, but where I work the ideas for technologies they play with come from "normal" devs like me. Like, RabbitMQ wouldn't even be on their radar unless someone less experienced told them about it.
I know how the "adding value" thing can come off like hard-nosed cowboy coder nonsense. But in truth, we lowly plebeian devs are capable of writing code and keeping apprised of new tech at the same time.
A good architect doesn't pretend to have a monopoly on ideas or trending technologies. Their job is to make sure that the really good ideas aren't ignored and get adopted more broadly.
Where I work, Software Architects are people who get paid lots of money to dick around with "new" technologies like RabbitMQ. Then after spending seemingly weeks implementing a trivial proof-of-concept app with the new thing, they present some slides and Visio diagrams at a brown bag nobody attends, and the rest of us ignore them so we can keep building things that actually provide value. Then they go on vacation to Aruba (probably).