10 ms·

> I can see, that I’m indeed a Systems Architect, and not a Software Engineer anymore. I find this distinction harmful. Are we going back to the days where the

• tetek 4y ago
  Of course I'm not just architecting everything by myself, and making decisions all day long. Every Software Engineer still makes a lot of architectural decisions on different levels - exactly how you described. There's just a lot of other activities that Systems Engineer does (and still consults them with the team, but is at the end responsible for doing them). (all the bullet points in "The realization")
• cryptozeus 4y ago
  No, architects also code. Google “lean architect”
• humbleMouse 4y ago
• Cwizard 4y ago
  Did you read the article? The description the OP gives does not sound like the situation you describe
• pjmlp 4y ago
  We never left those days on the enterprise space.
• swatcoder 4y ago
  It might be harmful if it was universal, but it's really just another facet of the normal, perpetual tension between generalization and specialization. Large organizations working on grand projects benefit from slicing up roles so that experienced specialists can anticipate and prepare solutions for the uncommon challenges that arise in those projects (and so that the bureaucracy of large orgs can be managed at all). Meanwhile, smaller organizations, or groups working on more modestly scoped projects, benefit from generalists who can hold much of the project in their head and develop highly cohesive solutions that can be delivered efficiently. A skyscraper requires seasoned architects or its going to crumble under its own weight, but even an extensive residential home renovation can be planned by a general contractor and done way cheaper than if many specialists were brought in. It sounds like there are some organizations/projects you wouldn't want to be involved with, but that doesn't mean that those organizations/projects are doing something harmful or regressive. They just don't suit the way you want to approach work.
  • Aperocky 4y ago
    But the existing situation is the reverse of what you described. The largest tech companies out there (usually? anecdotal) do not have this distinction, it's the smaller and older companies that continue to enforce this arbitrary divide.
    • gabereiser 4y ago
      A quick Google search of software architect jobs for Google proves otherwise. Like the comment above, large orgs slice up these roles and have architects (like myself) to help guide software teams into cohesion on platforms that require high collaboration between services to support a multitude of products. Anyone who says architecture isn’t needed, isn’t doing anything at scale (or blissfully unaware that their ship is sinking). Great Architects work closely with the dev teams to give them reference diagrams, proof of concept code, and the art of the possible. Bad architects drop a big requirements doc and walk away. Almost every large organization has architects (enterprise, solutions, software, and cloud).
      • 4y ago
• pphysch 4y ago
  > So for example, as a Junior Engineer you will define the design (architecture) of a feature within a service, This is how you end up with antipattern-laden monstrosities. And I don't mean that in the dogmatic sense, I mean juniors will find "clever" ways of getting the job done, often with far too much abstraction and reinventing core technologies like message-passing, task schedulers, databases, ORMs... It can be a good learning experience but they need a active mentor/architect overseeing every major decision. If you are going to reinvent something you should at least be aware of it. Juniors just don't have this broad perspective yet, almost by definition. OTOH, one of the my pet peeves is an "architect" who gives this advice I am giving but doesn't actually have the requisite technical background, i.e. saying "don't reinvent the wheel" while looking at a teacup.
  • zmgsabst 4y ago
    That’s why we have design reviews where SDEs present their designs, and often informal discussions before. It’s not like SDE 3 (senior) makes you immune to architecture over-complication.
    • pphysch 4y ago
      Yeah, code review is one format that can work for this, but my broader point is that trusting juniors to make architectural decisions even on the feature-level is a waste of time and effort. There must be oversight and guidance.
    • dilyevsky 4y ago
      In my current workplace it’s basically impossible to fail design review - like I’ve never seen it happen, and this is becoming the norm across the industry. At this point design reviews are just a cargo cult ritual
  • angarg12 4y ago
    This is where the fractal nature of the role helps. In your example, a mid level dev would oversee the architecture of the service. This dev would work to the junior to ensure their approach fits the rest of the service, and review their work. In turn a senior eng would oversee the architecture of the system owned by the team (possibly involving several services), and keep tabs with each one. Delegation doesn't mean lack of accountability.
• larve 4y ago
  I think the more accepted title these days instead of architect is "staff engineer". If you read older architecture books like "the software architect elevator" or "12 essential skills for software architects", most of the book is about technical leadership, driving change, personal skills, delegation. Building some theoretical construct and having other people build it is by itself bad architecture, resulting in bad team culture and bad systems.
  • blub 4y ago
    If the architect from your second paragraph works closely with the dev team for prototyping and iterates on their feedback I don’t see anything wrong with that approach.
    • larve 4y ago
      yes exactly. I was referring to what I think the OP was rejecting, a rigid top down approach to software engineering, with the architect and their UML at the top, and the grunts and their editor at the bottom.
    • oaiey 4y ago
      I agree. The architecture profession is radically different today than 20 years ago. However, there is a scale where that does not work anymore. Once you plan at the scale of 20 or more teams, "working closely" is very relative.
  • angarg12 4y ago
    I agree that Staff engineer is in practice the closest thing to the old Architect title. I still think this approach is better. If nothing else it's a shift in the responsibly of architecture. In the most rancid organizations there are silos where devs only code and architects only design. The joke of the Ivory Tower Architect is real. On the other hand as a dev II (between junior and senior) I was asked to design and implement a large scale green field distributed system that interacts with other teams. Our ladder and job titles not only allow this, but it's encouraged and sometimes expected.
  • 4y ago
• Fire-Dragon-DoL 4y ago
  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.
• gengstrand 4y ago
  I like how an ex-boss of mine described it in his blog https://bradhenrickson.substack.com/p/establishing-an-architecture-council?s=r https://bradhenrickson.substack.com/p/establishing-an-archit... where architects "can either be advisory or decision making" and the latter is the old school ivory tower style of architect being alluded to here. The prevailing sentiment here seems to me to be that we should do away with the title architect and allow senior developers to perform that function. I believe I saw a reference to Hohpe's "The Architect Elevator" as an example of the old school of thought in the comments here. Check out this guest blog of his https://martinfowler.com/articles/architect-elevator.html https://martinfowler.com/articles/architect-elevator.html where he makes the case that senior developers should set the architecture for services and systems but that there is also the need (in larger organizations) for architects to advise on software portfolios and technology radars.
• blub 4y ago
  Architect, developer, tester, etc. are project roles that are inherent to software development. The job title may say Staff Engineer, JavaScript Ninja, Principal Engineer, Senior Architect or any combination of the above, but in the end someone has to do the job. When your company didn’t use the specific title of architect the role of architect was still distributed between different engineering levels. For example you had the role of X Engineer + Architect… this can work well if the project is mostly of technical nature and doesn’t require a lot of technical requirements elicitation, negotiation, synchronization and other people and organization focused work. Because if it does contain such work, you’ll be spending so much time in meetings that you won’t have time to write code any more. Other companies assign the architect role to a specific person, or have multiple kinds of architects. An important duty of architects is alignment within and outside the organization and mediation between business and engineering. In large-scale projects such work is especially important and can’t be done by someone with the title of developer, because they would probably get bored out of their mind and also not actually develop anything any more. Neither of these approaches is wrong. I’ve worked with dev teams that expect to receive a design/spec that they will implement and at the other end of the spectrum with teams that love to design their own architecture. I will provide that spec for the former and I will make sure that their architecture remains cohesive with the platform architecture for the latter. And it did happen to me that teams would insist on designing their own architecture and then create an over-engineered heap of code. Too bad for them, because they have to fix the bugs, but still ok for the platform, since all the interfaces and platform requirements mesh as they should. Whatever level the architect is operating at, it’s crucial that they keep their technical skills sharp through building small prototypes, reading and analyzing code, code-review, etc. I can say from my own experience that whenever I neglected that, I started to become detached from the reality of the project and my decisions were poorer as my problem-solving approach became too abstract.
  • tetek 4y ago
    on point!
• twblalock 4y ago
  >So for example, as a Junior Engineer you will define the design (architecture) of a feature within a service, while as a Staff Engineer you will oversee the architecture of a system spanning several teams. Sure, but at some point "spanning several teams" means you will not be close to the code anymore. You'll spend most of your time in meetings and it increasingly becomes difficult to stay close to the code. Doing "grunt work" is increasingly a waste of your time and a distraction from doing things that have impact at your level. At that point you end up telling people what to build and having them build it.
• LAC-Tech 4y ago
  I find this distinction harmful. Are we going back to the days where there were programmers who did the grunt work and architects who told them what to do? Doesn't this distinction exist in every profession? Experienced people start doing less and less of the day to day tasks, and start doing more strategic work. Only in software do we think this is a terrible thing, and that an acceptable use of someones 10 or 20 years experiences is for them to be down in the trenches centering divs with the new grads. Hence terms like "staff engineer", which is a modern architect but with a name that pays lip-service to egalitarian fantasies.
  • jackblemming 4y ago
    HA said the master craftsman to the apprentice. Doth thou really think a master such as myself would hammer nails? I am in important zoom meetings! Surely it would be distasteful to touch such dirty tools at my level.
    • xeromal 4y ago
      It's not snobbery. It's that their time is better spent planning and being strategic. it's like throwing Eisenhower into the trenches. Sure, he's a good soldier, but it's time and experience wasted.
    • LAC-Tech 4y ago
      How much nail hammering does a foreman at a construction site do? He's hammered nails before. Hammering different looking ones in a new location is not going to be very useful or educational for him. And I've seen what happens when a whole team of devs get invited into a zoom meeting like that - they're bored out of their skull, most likely sitting there browsing the social media du jour, and I can't blame them.
    • arinlen 4y ago
      > Doth thou really think a master such as myself would hammer nails? I am in important zoom meetings! Yes because aligning goals, putting together a system,scoping work, and synching business goals with technical milestones adds no value at all. It's the nail-hammerer who believes that JIRA tickets spring from the JIRA ticket tree magically aligned that caries the whole org on their shoulders.
• jldugger 4y ago
  > Are we going back to the days where there were programmers who did the grunt work and architects who told them what to do? As long as Conway's law holds, system design is going to be at the mercy of the person who designs the team organization. It doesn't really matter what title you give things. I can tell you from experience that powering through a conways law mismatch doesnt yield good results. "communications overhead" feels abstract, so let me make it more concrete. When the org structure has no mapping to the software structure, the following bad things happen: - there is no clear rule for who's job it is to fix a bug. You have to always inspect the code and guess. - same issue for code review, and your code quality standard ends up beholden to the team with the tightest deadlines - nobody knows which manager to escalate issues to, and the only effective strategy is to haul a bunch of PMs and senior engineers into a conf call to analyze and decide - the testing and release strategy becomes one size fits all, and cannot make any assumptions about independent subcomponents of software -- you have to test and release the entire product in one go This is the form communication overhead takes.
• arinlen 4y ago
  > I find this distinction harmful. Are we going back to the days where there were programmers who did the grunt work and architects who told them what to do? You're fooling yourself if you believe that that's not the norm already. In fact, it boggles the mind how anyone believes that inexperienced people who are taking their first steps writing code and don't know what a software architecture is have as much say in the daily workings of a project than the grey bearded guys with a couple of decades of experience under their belt.
• kodah 4y ago
  At certain companies that is the way it works. At other companies you're a working leader, but your knowledge is only leveraged for gap-filling. At a marginal amount of companies engineers are empowered to have reports and lead teams. These companies are fascinating places. I'm at one now and I don't intend on ever leaving.
• phantomathkg 4y ago
  > I find this distinction harmful. Are we going back to the days where there were programmers who did the grunt work and architects who told them what to do? No I don't think so. Where in the article did the author said he is telling other people what to do? What he said is > proposed software architecture consulted it with key developers, and made sure everyone is onboard Being an architect, or staff engineer in modern term, means that the person will need to use his experience and expertise to help the team to find appropriate solutions, present to the team, list out pros and cons, let them pick, and drive the change with other stakeholders.
• deleted 4y ago
  [deleted]
• yobbo 4y ago
  A title is relevant for the person claiming it, and the people around recognizing it. If it helps him feel proud and accomplished, who are we to argue? We - unaffected bystanders - don't really need to have opinions.