What's the difference between a software developer and a software/systems? architect?

Spelling. And salary. And SA codes less and does some DevOps

Depends on a project. In some projects a dev covers it all. In others a dev gets a task and writes the code to implement it, while an architect gets a new requirement from business and thinks of the most suitable solution for it, covers it with flow, sequence diagrams, introduces new technologies [or reuses existing ones] if required to maintain performance and integrity, prepares a solution "on paper". Dev and ops then go ahead and implement it.

Projects tend to be started by architects: the initial planning, tech stack, modules/services/monoliths, repositories, flows, docs, servers [requirements, technology, supportive solutions], network topology,...

Simply put an architect gets a requirement, takes a pile of white papers and writes/draws everything but the implementation itself on those empty sheets. He implements the whole thing on paper. Then, when every little thing is thought out and covered on paper, devs, ops, sre, brt and what not get tasks to implement all that. [white sheets could also be confluence et al :) ]

As mentioned before, very often an architect is a dev as well. It might depend on a project/company :)

other companies might have a different understanding of architect, so let's hear others out.

@netikras ah maybe that's why I never really understood the difference...

I'm both the dev and the architect most of the time. But I guess the big difference is that I can't tell other people what to do...

If I'm not the dev, I'm never involved in how they design their solutions and well their design abilities are lacking.... At least I make Visios and document requirements/plans...

@Devnergy sounds like I need a raise.... But I still code a lot.... When I'm not asked to fix other ppls shit...

Architect is generally the one that designs the system, the developer (builder) is the one who builds it.

Think like In terms of Construction builders.

@C0D4 but how does the architect make sure the developers build it according to what he said (the right way) instead of what devs think he said (the lazy, sloppy way)?

@billgates in theory it doesn't matter. If the architecture is right. All the components that need to be flexible are there and are loosely coupled. As the communication of the components (API) is also defined in the architecture.
Tests are written conform the architecture. So if stuff passed the tests and the design is sound it should work.

But if you have crap devs they
A. Take a long time to implement.
B. Don't report back arch changes based on practicality and hindsight.
C. Have lots of duplicate code.
D. Have lots of implementation bugs and uncovered exceptions.

Even though the architect does not have to be the developer they both need to understand the job of the other and collaborate.

Developers build a part that runs within the whole thing. Architects build the whole thing.

@billgates that's what a good system design is for, devs will then be managed by a senior dev/ lead to keep the devs on track and you would then have QA to ensure the what gets built aligns with the initial design spec before throwing it back up to the business for acceptance.

The better and thought out the design, the harder it is to creep away from it, unless technical limitations play a part which need to be called out early to prevent lost work or scope creep.

Now back to my original analogy, the architect hands the devs a giant blueprint that tells them exactly what needs to be built, where things will be placed and how it's going to work.

The only thing the architect doesn't do is write the code to do it.
the devs turn that giant image into a workable solution.

@billgates the explanation by @netikras is excellent.

I'll add that IMHO if you build it, you also design it.
In the worst case the strict division "planner vs doer" leads to architects asking how to make typing monkeys shut up and obey their overlords: https://workplace.stackexchange.com/...

It's an old issue. To quote a conference from 1968 (page 21 of http://homepages.cs.ncl.ac.uk/brian...):
"The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. And that is where most of our troubles come from."

At the very least there needs to be a tight feedback loop ("The design process is an iterative one"), at which point you can leave design and implementation to the same person(s) anyway.

@VaderNT but then how do you maintain or enforce code quality/consistency?

Current team, everyone is a Sr dev, but they never document well what they build and sometimes when I see the code, go wtf why? What does ur app do? Is for?

@billgates that makes me wonder how they ever earned the senior title.

I'll paraphrase your question as "how do you force bad devs to deliver good work?" (and please correct me if that's not what you meant). Well, I think you can't. You can see the same thing happening with bad offshore/outsourcing teams. You have to tell them what to do on a level of detail that it's basically easier to do it in-house. Their code will still suck so bad you better throw it away.

The best (only?) way to get good work is to have good devs that are themselves interested in consistent quality work. I may be a bit pessimistic, but the shit I've seen...

@billgates enforce good code?
You need a senior that can actually identify bad code and will speak up about it. You need code reviews with more then a "looks good".

You can't enforce good code, but you can make it harder for shit code to be pushed through, hell shove the devs kpi metrics onto code quality with a monthly review of everything they have touched.

They'll either get the message and start writting a high quality level of code, or quit.

Also, if everyone's a senior, then no ones a senior, it sounds like you need a lead developer to actually manage things.

@C0D4 but that would require me to be the boss...

These days I'm like the last guy that gets involved and by then it's too late...

@billgates then be the boss, add "team lead / lead developer" to your CV and aspire to management like ma man @AleCx04 😇

Im currently holding the reigns from senior (experience wise) to Lead Dev.
It's a jouney if it's own, but it sounds like you know what's right/wrong already. You just need the title or someone else to bring it into play.

@C0D4 being a manager is painful man