I’m wondering if I’m just not worth as much money or if I’m not paid as much because I don’t work in California or both, lol. I work for an enormous company. I’ve got about 8 or so years experience. As of right now I’m a sr architect and I work on enterprise-level systems - either designing or enhancing existing processes and platforms. I don’t really code much these days, though I do write a lot of sql, build lots of diagrams, and build a lot of sample requests for various groups when they aren’t quite getting something from the docs. I make 180 TC and live in the north east though not NYC or Boston. That said, I also have a two floor plus fully finished basement home with three bedrooms, four bathrooms, a nice yard, garage, and a nice deck that I can work on when the weather is nice. So, I’m not complaining, I feel like I live comfortably. But man if I had an extra 200k to just throw into savings and investing? Whooo boy…
Writing SQL and drawing diagrams for enterprise systems inside of a huge company is not what the highly-compensated senior engineers tend to be doing. If you want to make more money, move out of being an “architect” and into being a principal engineer at a tech company (one whose business is making software; not a company that just happens to employ software developers).
Its not about diagrams and SQL, its about a bunch of things, that can be broadly related to "making everyone more effective at the work they do", "lead huge company changing projects" and "create enough value to have a budget to hire a large team and build a thing to achieve a business goal"
What the heck, principle engineer is considered higher than architect? What about principle architect? I might need a flowchart somewhere that describes all the tech levels above "senior software engineer".
From what I've seen architects are alongside engineers, not above. Also depends on what kind of architect - solution architecture tends to be a completely separate track, etc.
My job isn't to sit down and write code, most of the time. What I do is take a business requirement, go back and forth with a ton of business people to nail down exactly what they need or want to do, and then go on a series of requirements gathering sessions after figuring out the impacted or required systems. So let's say someone wants to digitize a specific set of communications. It makes more sense to build internal and scalable capabilities to be able to digitize any communication - so working out the technologies required to do that, the integration points, the patterns for how to do it. It involves learning a lot and then evaluating what you learned, and eventually diagraming it all out into an architecture that the domain and solution architects use.
The domain architects then would add in more detail and requirements within the systems that are affected and finally the designs get to the solution architects.
The solution architects go through the whole sketch and make sure it makes sense, that the data or whatever required will get to them and that their platform(s) are empowered and capable of performing the work thats being asked. They then design the solution for those technologies and when programming needs to get done then that is sent to the engineering teams to actually build it.
In terms of hierarchy the programmers/engineers tend to be the recipients of requirements rather than really being involved conversationally. I don't necessarily agree with this approach and I try to work directly with programmers where I can. And more often than not I'll work with them doing PoC coding in whatever technology - usually java, of course.
I often think about working to level up my actual programming abilities because I feel that, surely the folks who are pulling those kinds of salaries are working on really interesting problems. Part of my dissatisfaction with my job is that while I do work on difficult problems a lot of the difficulty comes from process or legacy systems. The really hard problems that my org faces arent the same league of hard problems that someone at a FAANG company (or similar) is working on.
> surely the folks who are pulling those kinds of salaries are working on really interesting problems
> ...
> The really hard problems that my org faces arent the same league of hard problems that someone at a FAANG company (or similar) is working on
You'd be surprised. What I work on is relatively mundane. I worked at multiple FAANG companies in the past and the work there is mostly mundane too.
For the most part the difference is in the order of magnitude of users that you have, so you get to look at edge cases more often, need to be more careful about having a stable codebase etc, but writing a Web service that gets X in input and spits out Y in output is not rocket science.
I think the carpenter/woodworker analogy for software engineering works pretty well. The very expensive carpenters do the same work as the inexpensive ones, the difference is in the details.
If you don’t mind my asking, what would you say you spend most of your time doing in a week? For me it’s a lot of requirements gathering and sketching things out then developers go off and build it. For example next week I’ll be working with a few other architects on some identity resolution projects. But we’ll just design the system, the engineers will take our specs and go off and build it.
I luckily still get to write code (not that common at my level), mostly gnarly undocumented bugs where you need to read the linux source code because the behavior is not documented anywhere else. But most of my time is usually split halfway between coaching and helping our junior and mid level engineers, pair programming, telling them that yes, they need all those tests, stuff like that and coordinating with other senior-er engineers on big projects, making sure we don't step on each other toes and lately optimizing the overall architecture of the product which has a lot of overhead right now (we build a big monolithic piece of software, not the easiest ship to steer).
COL is part of this, but I think the things to consider are that software engineers are worth more based on the scale of our work, and network effects can drive up our market price. I believe the scale argument is self-evident, so I'll expand on the network effects:
By being in the bay area you meet a lot of software engineers and provide value to companies you work at by referring good software engineers. This ends up being worth a lot of money to companies (more than they pay in bonuses).
By being an engineer in the bay area it's also harder to be retained. Engineers here are pretty transparent about compensation and working conditions. If someone I know is working 50 hours a week or being underpaid, I make sure they have referrals to good companies as soon as they want them and they get a good job.
Speaking to engineers who've moved here from other markets, that kind of culture and network just doesn't exist in most other areas.
