3 ms·

I'm one and I still code in my free time. How anyone could actually BE an architect without a lot of actual developer experience is something I'd like to know.

I'm one and I still code in my free time. How anyone could actually BE an architect without a lot of actual developer experience is something I'd like to know. Are you sure you're not just being unfair to the architects around you for disagreeing with you on things? I cannot fathom an architect who wouldn't be a strong developer if slotted into that role.

varjag 4y ago
I've mostly stayed on engineering tracks where architects are untypical roles so had a fortune observing from a distance. Only did a few year stint with Java + CIM where architects were endemic. Now that you asked I sifted through memories a bit and yeah none of the one I worked with or observed have been coding for more than 3-4 years prior to their ascension.
- P5fRxh5kUvp2th 4y ago
  I just don't see how any architect can ever be very good without a strong background in development. I'm of the opinion that an architect who isn't regularly getting feedback from the implementing teams is probably a bad architect. Their decisions will often make the implementing teams job harder and they need to understand that in order to balance broader needs with implementation smoothness.
  - majormajor 4y ago
    > I just don't see how any architect can ever be very good without a strong background in development. I think the disconnect here is that the majority of architects I've worked with haven't been "good" in a technical sense from a "actually building software" perspective. I'm assuming this is true for a lot of folks here, based on people's responses in this thread. The day to day of some of these roles has been: * sit in meetings with high-up product managers and biz leaders * come up with pretty diagrams of how to totally re-build (sorry, re-architect) the system. Often this is jargon-heavy - protobuf this, envoy that, circuit-breakers the other thing. * talk engineering management into this plan What's been meaningfully missing is the details of point A -> point B to achieve their plan. None of the jargon is necessarily wrong but it's not grounded in the reality of the current software systems at all. This comes about when the technical VPs aren't hands-on with the system anymore either. If non-technical leadership is saying something like "improve uptime" and you go get hire an architect into the company and you'll get a lot of presentations about things the devs on the team may already know about but haven't been able to get prioritized, but it's still on the existing devs to actually build it. "Paying someone fancy to convince non-technical business leaders to let the devs build what's needed" isn't necessarily a bad decision from a CTO or SVP of Engineering, even! But the devs who have been saying the same shit this whole time only to now see the credit go to the higher-ups and the new architect, after getting the blame for the old status quo, don't exactly have a positive view of the architect's actual engineering competency.
    - P5fRxh5kUvp2th 4y ago
      > None of the jargon is necessarily wrong but it's not grounded in the reality of the current software systems at all. Oddly enough, I'm having this discussion right now with a few other people at a new company. They want new documents to describe the ideal and I want it to describe how things work currently and evolve it over time. OTOH, I've never gotten the impression that any of them are technically weak, I think they just view their role differently than I do. Much like how a TDD proponent will start imagining unit tests are the point, I think these architects have started to think these documents and diagrams are the point.
- pjmlp 4y ago
  My experience is a bit different, the end role for engineers that don't want to land in management is usually becoming an architect, or staying as tech lead forever, unless they branch out into consulting.
  - varjag 4y ago
    From what I've seen a rather typical trajectory is towards a product manager if you are in a tech megacorp or CTO if you are in a small upstart/company (who of course is nothing like CTO at a megacorp). YMMV of course.

varjag 4y ago

I've mostly stayed on engineering tracks where architects are untypical roles so had a fortune observing from a distance. Only did a few year stint with Java + CIM where architects were endemic. Now that you asked I sifted through memories a bit and yeah none of the one I worked with or observed have been coding for more than 3-4 years prior to their ascension.

P5fRxh5kUvp2th 4y ago
I just don't see how any architect can ever be very good without a strong background in development. I'm of the opinion that an architect who isn't regularly getting feedback from the implementing teams is probably a bad architect. Their decisions will often make the implementing teams job harder and they need to understand that in order to balance broader needs with implementation smoothness.
- majormajor 4y ago
  > I just don't see how any architect can ever be very good without a strong background in development. I think the disconnect here is that the majority of architects I've worked with haven't been "good" in a technical sense from a "actually building software" perspective. I'm assuming this is true for a lot of folks here, based on people's responses in this thread. The day to day of some of these roles has been: * sit in meetings with high-up product managers and biz leaders * come up with pretty diagrams of how to totally re-build (sorry, re-architect) the system. Often this is jargon-heavy - protobuf this, envoy that, circuit-breakers the other thing. * talk engineering management into this plan What's been meaningfully missing is the details of point A -> point B to achieve their plan. None of the jargon is necessarily wrong but it's not grounded in the reality of the current software systems at all. This comes about when the technical VPs aren't hands-on with the system anymore either. If non-technical leadership is saying something like "improve uptime" and you go get hire an architect into the company and you'll get a lot of presentations about things the devs on the team may already know about but haven't been able to get prioritized, but it's still on the existing devs to actually build it. "Paying someone fancy to convince non-technical business leaders to let the devs build what's needed" isn't necessarily a bad decision from a CTO or SVP of Engineering, even! But the devs who have been saying the same shit this whole time only to now see the credit go to the higher-ups and the new architect, after getting the blame for the old status quo, don't exactly have a positive view of the architect's actual engineering competency.
  - P5fRxh5kUvp2th 4y ago
    > None of the jargon is necessarily wrong but it's not grounded in the reality of the current software systems at all. Oddly enough, I'm having this discussion right now with a few other people at a new company. They want new documents to describe the ideal and I want it to describe how things work currently and evolve it over time. OTOH, I've never gotten the impression that any of them are technically weak, I think they just view their role differently than I do. Much like how a TDD proponent will start imagining unit tests are the point, I think these architects have started to think these documents and diagrams are the point.
pjmlp 4y ago
My experience is a bit different, the end role for engineers that don't want to land in management is usually becoming an architect, or staying as tech lead forever, unless they branch out into consulting.
- varjag 4y ago
  From what I've seen a rather typical trajectory is towards a product manager if you are in a tech megacorp or CTO if you are in a small upstart/company (who of course is nothing like CTO at a megacorp). YMMV of course.