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).
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.
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.
And I hate this title - I've seen too many so-called architects who can't distinguish SOAP-call and MQ-message.
Q: You have WebSphere Process Server - do you use BPEL for your scoring workflows?
A: What is BPEL??
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
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.
you don't have to respect anyone.
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.
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 :)
an "architect" [sic]
Why did you pick those as "basic subjects" for a "junior engineer"? Are they important to your particular 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!
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.
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.
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?
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.
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.