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?
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.
<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.
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.
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.
I don't know what to tell you without de-anonymizing myself on the internet. It's a household name that you've probably used. Again, it is not that product engineers are "doing everything" - the road is paved by a very large platform org - but they just build the road, we have to drive on it.
I don't know any companies that use that word. Normally we are called software engineers. Amazon is the closest, with "software development engineer."
Nor do we use the word devops. Which is funny, because as I understand it, software engineers working on infrastructure automation in the same way that that we work on products are the closest thing to what "devops" envisions. The companies that are doing it don't use the word, and the companies that use the word are the most incredulous that anyone could be getting by without dev and (dev)ops as
substantively separate roles. It would be almost as if the people who most liked to talk about Agile were the ones most invested in very long range estimation and planning. Oh wait..
Whether it is lanes or 'roles and responsibilities' I think everyone benefits when they have a good sense of what they are signing up for. But, in the real world, sometimes you just can't get that kind of clarity. I will get responsibilities throughout the year that I clearly think "I don't really know how to do this"...and then I evaluate whether I can learn to do that thing well enough or if I should defer to somebody else.
In regards to culture and scale and lanes...what I was referring to was having a culture of people who are accepting when others ask if they can help, rather than telling those people to go mind their own business. If employees want to do what they are specialized in...totally fine...but if I am interested in a topic that someone else specializes in, I would like to have an opportunity to explore that(without being a PITA obviously).
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)
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.
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.
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.
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.
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.
We schedule follow up meetings with smaller groups of interested parties about the areas of controversy or deficiency.
>An architect team should be highly integrated, participate in the coding aspect and only once something is shipped, moves on.
At that point, why are they a separate role or team? That sounds pretty close to architecture being one of the responsibilities of the main development team.
Someone who is functionally part of the development team but has more experience than others and some kind of supervisory capacity over technical direction is, in my world, a senior or staff engineer. Do you also have those? How are they different from architects?
How are you going to design database schemas if you don't know Postgres? Controllers and models if you don't know Rails? Components if you don't know React? I don't think design and usage are such separate skillsets.
Put another way, wouldn't you want the Postgres expert to design your Postgres schemas? Or the Rails expert to lay out your Rails application?
Again, I agree on that, my perception of architect is that it's a strongest software developer with a high specialty in designing systems.
It shouldn't be a person out of the software loop, it wouldn't make sense.
I never intended to create a low bar for the title, nor a separate role from "software developer". I'd expect the architect to still be a software developer able to contribute to the existing stack.
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.
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.
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
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.
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.
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?