4 ms·

But you just defined a person with a lot of more experience covering the bigger part of the design and the junior covering the smaller part, because of less exp

But you just defined a person with a lot of more experience covering the bigger part of the design and the junior covering the smaller part, because of less experience. So literally that's "hiding" an actual distinction that it's already there. I agree, every dev should be able to design systems. With software development becoming a highly desirable career due to money, this is just not true and possible anymore. The world is full of productive developers that are not skilled enough to design systems. Designing systems is also incredibly hard, I have rarely seen (in my very limited sample) more than a few devs able to do it in a company. So we have a category of people who put a lot of effort in becoming good at something, but we don't recognize them because "everybody should know that too". I think that's not positive. People who want to grow in the design skills are free to do it and resources should be available, but the reality is already that people at higher levels tell you what to do. Isn't that what you would expect, somebody with more experience driving you?

P5fRxh5kUvp2th 4y ago
The second you paint lanes is also the same second you're expected to stay within those lanes with ramifications if you don't. This is one of those arguments that looks good on paper, but causes untold pain in practice.
- mym1990 4y ago
  Hardly. As a dev, architects around me have no problem with me getting more insight into their work, and letting me do some things that are 'outside of my lane'. On the flip side, I can say that something is above my paygrade if I want to stay in my lane. Your ramifications statement is more of a reflection on particular company culture. On the whole, lanes are created by companies to create a promotion flow so that people can always keep trying to climb the ladder. We see more flat organizations today, but as an organization grows to become huge, hierarchy is almost necessary.
  - oaiey 4y ago
    We architects love engineers like you. Less work, more collaboration, less risk. And scale is exactly the point where real architects are needed. It is about culture. Which is very hard because many junior architects have a power trip over their fellow engineers.
    - mym1990 4y ago
      <3 Totally! To someone else's point, it is important that when I get involved in an alternate "lane", that I do not create more work for everyone and there is net value being created.
  - P5fRxh5kUvp2th 4y ago
    I would argue you acknowledge the point when you say you know when to avoid stepping outside of your lane ("above my paygrade"). lanes are created for specialization but when you do that it's a clear indicator that if you're not specialized in that area you should be deferring to those who are. You wouldn't want a devops person telling you how to organize the controllers in your application, and that devops person wouldn't want you telling them how to organize the management of the pipelines. That's not culture, that's necessity due to scale. The point being made is that should be put off as long as possible because when you put it into place suddenly the communication becomes a lot harder and it's not obvious it's always a benefit until there's real pain from not doing so. --- I would not consider understanding the large context of things to be stepping outside your lane and I suspect most people wouldn't either.
    - closeparen 4y ago
      It may surprise you that my very high scale employer in addition to having no architects also has no devops. It has instead an infrastructure group that ships a PaaS. Engineers click their own buttons on the PaaS. Only if things have gone very wrong would you end up talking to or having actions taken on your services by the PaaS owners. Now obviously to design such a PaaS successfully you should know a thing or two about ops, but the outcome of that expertise is a reusable software platform, not per-product (or worse, per-release) labor.
- Fire-Dragon-DoL 4y ago
  The same could be said about the opposite. No lanes are placed, the junior developer (or intermediate) will design a system that they are not qualified for and the problem will be discovered only at pull-request time, when a huge waste has already occurred. Or worse, the PR will be reviewed by a senior developer that's not experienced in system architecture and will get approved. It's pretty common even in senior developers to not be experienced in system architecture, so the problem is not resolved with this approach (based again, uniquely on my experience. I didn't run any statistics)
closeparen 4y ago
What I would expect is what I actually have: you own the design and architecture of your own work, but you get feedback from more experienced people on your design proposals until they are in line with what the more experienced people would expect.
- switchbak 4y ago
  That's sounds preferable to having a few blessed folks do all the high level planning, completely detached from the lessons being learned from trying to implement those ideas. Anything that harms those feedback loops is going to create pain.
- oaiey 4y ago
  There are two stages: an architect defining the big picture and then a technical senior person reviewing the small picture. You describe the later. The big picture you cannot do like you describe.
  - closeparen 4y ago
    I guess that depends how you define “big picture.” If you’re talking as a company what kind of infrastructure are we going to buy, what will be the storage platforms, ingress, message brokers, service mesh, sure. That is handled centrally by a platform group, which gives product teams a relatively constrained sandbox to play in. But specific products, features, and services are handled directly between product management and senior engineers, with a design doc reviewed by other senior engineers. No one has the title Architect and the same person generally owns architecture and implementation of the same functionality.
    - Fire-Dragon-DoL 4y ago
      What if the feature/module designed has to interact with other parts of the system? I saw that all the time, it's really hard to identify the right partitions in a system. It requires a lot of research and experience. Whenever one of those partitions is missed/overlooked, the software gets muddy and hard to work with around that area. When brought to the extreme where very little boundaries were identified, this is common in CRUD apps where entities are confused with partitions the entire time, every change to the code ripples from the database all the way to the frontend. In Rails world, this is a highly common problem: a change to database schema affects the UI directly, so every time something is changed in the schema, the following has to change: - JSON renderers - React or HTML views - db schema Even for additive changes

P5fRxh5kUvp2th 4y ago

The second you paint lanes is also the same second you're expected to stay within those lanes with ramifications if you don't. This is one of those arguments that looks good on paper, but causes untold pain in practice.

mym1990 4y ago
Hardly. As a dev, architects around me have no problem with me getting more insight into their work, and letting me do some things that are 'outside of my lane'. On the flip side, I can say that something is above my paygrade if I want to stay in my lane. Your ramifications statement is more of a reflection on particular company culture. On the whole, lanes are created by companies to create a promotion flow so that people can always keep trying to climb the ladder. We see more flat organizations today, but as an organization grows to become huge, hierarchy is almost necessary.
- oaiey 4y ago
  We architects love engineers like you. Less work, more collaboration, less risk. And scale is exactly the point where real architects are needed. It is about culture. Which is very hard because many junior architects have a power trip over their fellow engineers.
  - mym1990 4y ago
    <3 Totally! To someone else's point, it is important that when I get involved in an alternate "lane", that I do not create more work for everyone and there is net value being created.
- P5fRxh5kUvp2th 4y ago
  I would argue you acknowledge the point when you say you know when to avoid stepping outside of your lane ("above my paygrade"). lanes are created for specialization but when you do that it's a clear indicator that if you're not specialized in that area you should be deferring to those who are. You wouldn't want a devops person telling you how to organize the controllers in your application, and that devops person wouldn't want you telling them how to organize the management of the pipelines. That's not culture, that's necessity due to scale. The point being made is that should be put off as long as possible because when you put it into place suddenly the communication becomes a lot harder and it's not obvious it's always a benefit until there's real pain from not doing so. --- I would not consider understanding the large context of things to be stepping outside your lane and I suspect most people wouldn't either.
  - closeparen 4y ago
    It may surprise you that my very high scale employer in addition to having no architects also has no devops. It has instead an infrastructure group that ships a PaaS. Engineers click their own buttons on the PaaS. Only if things have gone very wrong would you end up talking to or having actions taken on your services by the PaaS owners. Now obviously to design such a PaaS successfully you should know a thing or two about ops, but the outcome of that expertise is a reusable software platform, not per-product (or worse, per-release) labor.
Fire-Dragon-DoL 4y ago
The same could be said about the opposite. No lanes are placed, the junior developer (or intermediate) will design a system that they are not qualified for and the problem will be discovered only at pull-request time, when a huge waste has already occurred. Or worse, the PR will be reviewed by a senior developer that's not experienced in system architecture and will get approved. It's pretty common even in senior developers to not be experienced in system architecture, so the problem is not resolved with this approach (based again, uniquely on my experience. I didn't run any statistics)

closeparen 4y ago

What I would expect is what I actually have: you own the design and architecture of your own work, but you get feedback from more experienced people on your design proposals until they are in line with what the more experienced people would expect.

switchbak 4y ago
That's sounds preferable to having a few blessed folks do all the high level planning, completely detached from the lessons being learned from trying to implement those ideas. Anything that harms those feedback loops is going to create pain.
oaiey 4y ago
There are two stages: an architect defining the big picture and then a technical senior person reviewing the small picture. You describe the later. The big picture you cannot do like you describe.
- closeparen 4y ago
  I guess that depends how you define “big picture.” If you’re talking as a company what kind of infrastructure are we going to buy, what will be the storage platforms, ingress, message brokers, service mesh, sure. That is handled centrally by a platform group, which gives product teams a relatively constrained sandbox to play in. But specific products, features, and services are handled directly between product management and senior engineers, with a design doc reviewed by other senior engineers. No one has the title Architect and the same person generally owns architecture and implementation of the same functionality.
  - Fire-Dragon-DoL 4y ago
    What if the feature/module designed has to interact with other parts of the system? I saw that all the time, it's really hard to identify the right partitions in a system. It requires a lot of research and experience. Whenever one of those partitions is missed/overlooked, the software gets muddy and hard to work with around that area. When brought to the extreme where very little boundaries were identified, this is common in CRUD apps where entities are confused with partitions the entire time, every change to the code ripples from the database all the way to the frontend. In Rails world, this is a highly common problem: a change to database schema affects the UI directly, so every time something is changed in the schema, the following has to change: - JSON renderers - React or HTML views - db schema Even for additive changes