7 ms·

Huh. Where I work, Software Architects are people who get paid lots of money to dick around with "new" technologies like RabbitMQ. Then after spending seemingl

by moron 14y ago

Huh. 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).

dr42 14y ago
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 :)
- stephencanon 14y ago
  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".
  - dr42 14y ago
    It's not about the ability to research alternative approaches, it's knowing when it might make sense to do so. an "architect" [sic]
  - nathan_long 14y ago
    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?
    - stephencanon 14y ago
      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.
      - dr42 14y ago
        This is just not true. 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!
        ramchip 14y ago
        > 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.
- romaniv 14y ago
  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?
- moron 14y ago
  > How very cynical indeed. 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.
  - usedtolurk 14y ago
    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.
- imechura 14y ago
  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.
bitdiffusion 14y ago
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.
- moron 14y ago
  Yeah, that's what they all say. Problem is, all the ideas for change come from people who aren't software architects.
  - dr42 14y ago
    ok, now it's obvious you're just trolling.
columbo 14y ago
Are you currently hiring?
alttab 14y ago
I left IBM when I had the chance. You should too. Don't worry, the immediate pay cut is worth it.
- moron 14y ago
  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.
  - alttab 14y ago
    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).
    - moron 14y ago
      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.
      - alttab 14y ago
        Sorry - didn't know of many companies that played around with enterprise message queues and had "brown bags"
dabent 14y ago
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.
- Ingaz 14y ago
  I'm main Architect in my current company now. 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??
  - aik 14y ago
    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.
    - Ingaz 14y ago
      Of course. 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
klawed 14y ago
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.
- moron 14y ago
  Agreed. But that doesn't mean I have to, like, respect them.
  - dr42 14y ago
    they have to earn your respect by helping you succeed at your job. you don't have to respect anyone.
jaaron 14y ago
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.
- stickhandle 14y ago
  bingo

by moron 14y ago

dr42 14y ago

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 :)

stephencanon 14y ago
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".
- dr42 14y ago
  It's not about the ability to research alternative approaches, it's knowing when it might make sense to do so. an "architect" [sic]
- nathan_long 14y ago
  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?
  - stephencanon 14y ago
    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.
    - dr42 14y ago
      This is just not true. 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!
      - ramchip 14y ago
        > 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.
romaniv 14y ago
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?
moron 14y ago
> How very cynical indeed. 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.
- usedtolurk 14y ago
  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.
imechura 14y ago
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.

bitdiffusion 14y ago

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.

moron 14y ago
Yeah, that's what they all say. Problem is, all the ideas for change come from people who aren't software architects.
- dr42 14y ago
  ok, now it's obvious you're just trolling.

columbo 14y ago

Are you currently hiring?

alttab 14y ago

I left IBM when I had the chance. You should too. Don't worry, the immediate pay cut is worth it.

moron 14y ago
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.
- alttab 14y ago
  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).
  - moron 14y ago
    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.
    - alttab 14y ago
      Sorry - didn't know of many companies that played around with enterprise message queues and had "brown bags"

dabent 14y ago

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.

Ingaz 14y ago
I'm main Architect in my current company now. 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??
- aik 14y ago
  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.
  - Ingaz 14y ago
    Of course. 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

klawed 14y ago

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.

moron 14y ago
Agreed. But that doesn't mean I have to, like, respect them.
- dr42 14y ago
  they have to earn your respect by helping you succeed at your job. you don't have to respect anyone.

jaaron 14y ago

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.

stickhandle 14y ago
bingo