principal software engineer vs architect

#PRINCIPAL SOFTWARE ENGINEER VS ARCHITECT SOFTWARE#

Most teams and projects - however large or small - all shared a similar approach to design and implementation: I've had this discussion with peer engineers working at other tech companies, FANG (Facebook, Amazon, Netflix, Google), as well as at smaller startups.

#PRINCIPAL SOFTWARE ENGINEER VS ARCHITECT SOFTWARE#

So how did we get things done? And why did we not follow approaches suggested by well-known software architecture approaches? Software design at tech companies and startups However, there was no need to reference them in the design documents themselves. Some of these did come up during brainstormings. No mentions of microservices, serverless architecture, application boundaries, event-driven architecture, and the lot. Third, we had practically no references to the common architecture patterns and other jargon referenced in common software architecture literature, such as Martin Fowler's architecture guide. While these experienced developers drove the design process, even the most junior team members were involved, often challenging decisions and offering other alternatives to discuss. However, no one person owned the architecture or design. For all the projects, we did have experienced engineers involved. Engineers at higher levels, like staff engineers, are expected to still regularly code.

True, neither Uber nor Skype/Microsoft have hands-off software architect positions.

No IT architects or enterprise architects. Second, there were no architects on the teams that owned the design. Two diagrams within the same design document often had a different layout and were often added and modified by different engineers. Just plain old boxes and arrows, similar this one describing information flow or this one outlining class structure and relationships between components. We created plenty of diagrams, but none of them followed any strict rules. We did not use UML, nor the 4+1 model, nor ADR, nor C4, nor dependency diagrams. First, none of these designs used any of the standard software architecture planning tools.

Let me start with a few things that might sound surprising. Rewriting the Uber app was a project that a few hundred engineers worked simultaneously on, porting existing functionality to a new architecture. The payments system rewrite had to replace two, existing payments systems, used by tens of systems and dozens of teams, all without having any business impact. They were also not just greenfield projects. The designs then boiled down to a design document that was circulated for more feedback before we started building.Īll of these systems were large at scale: hundreds of developers build them - or on top of them - and they power systems used by millions of people per day. All of these systems had thorough designs, going through multiple iterations and had lots of whiteboarding and discussion. I've taken part in rewriting Uber's distributed payment systems, designing and shipping Skype on Xbox One and open-sourcing RIBs, Uber's mobile architecture framework. I had my fair share in designing and building large systems. Menu Software Architecture is Overrated, Clear and Simple Design is Underrated

Principal software engineer vs architect