5 ms·

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 des

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
    - closeparen 4y ago
      Thinking though those kinds of issues is bread-and-butter software engineering, we would not work with anyone past new intern/new-grad level who couldn't handle that.
      - Fire-Dragon-DoL 4y ago
        That would be amazing, but we are faced with the reality that when a lot of people need to be hired, the bar can't be that high, or there is literally a barrier in how many people you can hire. If you are in a smaller company, totally agree. Get way stronger foundational developers.
        closeparen 4y ago
        I mean, there are thousands of us, but we do pay competitively with FAANG.
Fire-Dragon-DoL 4y ago
Absolutely reasonable, however how do you know who are the more experienced folks? In a small organization, that's doable, but when you get to 50 engineers, knowing who to ask is important.
- closeparen 4y ago
  We have a weekly meeting of a group of designated approvers for design docs.
  - Fire-Dragon-DoL 4y ago
    That's really cool, but isn't that equivalent to having an Architect team, just without a name?
    - closeparen 4y ago
      The legwork, thinking, and writing come from the software engineers who are also going to be building and maintaining the thing. The review simply verifies that their plan is reasonable and perhaps suggests some angles they hadn't thought about. Reviewers are engaged in the same kind of work as the people going up for review - which is how they are able to make useful suggestions. After the meeting, some will be going back to coding, others to investigate the alerts they just got paged for, others to design/UXR workshops, others to go run sprint planning, etc. I would expect an Architect team to deal directly with the product requirements, stakeholders, etc. and produce a design that they hand off to others to execute, while they move on to the next set of requirements. Architecture is part of the project lifecycle for everyone. This process is simply the architecture complement of code review, only slightly more formal.
      - Fire-Dragon-DoL 4y ago
        What happens in case the design is actually highly incorrect, will the people restart the work from scratch? Regarding the Architecture team, that's literally what caused problems in so many companies, that's the definition of how to have bad architects: the architects are so disengaged with the system that they cannot make recommendations. An architect team should be highly integrated, participate in the coding aspect and only once something is shipped, moves on.

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
  - closeparen 4y ago
    Thinking though those kinds of issues is bread-and-butter software engineering, we would not work with anyone past new intern/new-grad level who couldn't handle that.
    - Fire-Dragon-DoL 4y ago
      That would be amazing, but we are faced with the reality that when a lot of people need to be hired, the bar can't be that high, or there is literally a barrier in how many people you can hire. If you are in a smaller company, totally agree. Get way stronger foundational developers.
      - closeparen 4y ago
        I mean, there are thousands of us, but we do pay competitively with FAANG.

Fire-Dragon-DoL 4y ago

Absolutely reasonable, however how do you know who are the more experienced folks? In a small organization, that's doable, but when you get to 50 engineers, knowing who to ask is important.

closeparen 4y ago
We have a weekly meeting of a group of designated approvers for design docs.
- Fire-Dragon-DoL 4y ago
  That's really cool, but isn't that equivalent to having an Architect team, just without a name?
  - closeparen 4y ago
    The legwork, thinking, and writing come from the software engineers who are also going to be building and maintaining the thing. The review simply verifies that their plan is reasonable and perhaps suggests some angles they hadn't thought about. Reviewers are engaged in the same kind of work as the people going up for review - which is how they are able to make useful suggestions. After the meeting, some will be going back to coding, others to investigate the alerts they just got paged for, others to design/UXR workshops, others to go run sprint planning, etc. I would expect an Architect team to deal directly with the product requirements, stakeholders, etc. and produce a design that they hand off to others to execute, while they move on to the next set of requirements. Architecture is part of the project lifecycle for everyone. This process is simply the architecture complement of code review, only slightly more formal.
    - Fire-Dragon-DoL 4y ago
      What happens in case the design is actually highly incorrect, will the people restart the work from scratch? Regarding the Architecture team, that's literally what caused problems in so many companies, that's the definition of how to have bad architects: the architects are so disengaged with the system that they cannot make recommendations. An architect team should be highly integrated, participate in the coding aspect and only once something is shipped, moves on.