Ask HN: Do most SWEs actually code at BigTechCo jobs?

I work at a Big Tech and I’d agree that the development speed is slow. However, I’d disagree with the characterisation that figuring out things like guarantees, capacity etc. are not “actual engineering work”.

My parents are chemical engineers and the work they do seems fundamentally pretty similar to Software Engineering at Big Tech (with different inputs and outputs and constraints), in that it’s less about getting any individual thing done, and more about getting many people to agree to a set of tradeoffs and implementation. Also, the scope for ground up work is pretty much non-existent and it’s a lot more about gluing together existing components with well known tradeoffs and tested characteristics.

Cross-team communication cost and latency can always be improved, but I think some slowness is unavoidable due to the possible impact that changes have.

There are pockets within Big Tech, which work on less critical things and they often have a much more startup mentality and approach to development. However, it’s still difficult for these teams to fully extricate themselves from the overhead imposed by the systems of other teams, since those systems are generally designed for bigger, more important and more critical systems.

That is a fair point, a friend is working on ChromeOS tooling for testing/deploys and seems to be able to move fairly quickly and his work has large impact internally but not millions of users directly, also less coupled to a multitude of internal services.

So finally it appears that the realisation is setting in that "engineering" does not equal "coding".

It seems it has been trendy to want to call coding as engineering, when that is like saying because I play with model rocketry on the weekends, I am a rocket scienetist.

Engineering is about assembling and/or integrating the efforts and products of many groups or individuals into an overall end product of some kind, usually to a known quality to a fixed budget and schedule (or at least that is the expectation at commencement).

In order to be resonsible for the outcomes of very complex efforts it is extremely difficult to "span too many levels", even if you have the ability and time.

Thus, on large engineering projects responsibilities are compartmentalised into modules and layers, just like software is.

You don't mix the very high and very low levels of software in the one module or layer, you abstract as you go up, maintaining a more or less similar amount of immediately need to know complexity for each sub-system with defined interfaces.

This is how complex systems that could not possibly be fully known by any one person, simiply because of the cognitive load alone, are constructed.

Engineering teams work in a similar way, so if you are near the upper levels an defining broad brush and system wide concepts, you are not usually also down in the weeds writing device drivers, so to speak.

The higher up you go in the levels, the more there is management of of the efforts of others. So that means expectations and interfaces, leading to more and more logistical and people management, and less actual nuts and bolts.

The person that designed the Golden Gate bridge probably never used a spanner in their life. (I could be wrong, I just make a throw away anology for the point of it)

Just to push back a bit, the promise/allure of software engineering is that you can have massive impact with a small dedicated team. Eg. WhatsApp had ~20 employees and was delivering more messages than the global SMS system.

Yes, I agree, but partially that is due to the cost of replication being negligible to the product manufacturer - the user bears the primary cost, being the device.

Also, 20 people, while it could happen, I doubt they self organised. There was at least one person with an architectural vision, plus there would have been back end, front end, mobile variants all needing to coordinate, I would have thought there was a number of "planners and organisers" and a number of "doers" in the mix, not to mention maybe some testing specialists.

I've not seen any background to the WhatsApp team and story, it would be interesting if anyone has any good links.

> Essentially, everything we do is between other mammoth systems and thus most “work” is actually configuring systems to talk to each other or talking to other teams about guarantees, capacity etc. The actual engineering work is minimal and the development speed is glacial.

This is something I found out the hard way too. At some point in life I fell in love with sofware (coming from IT). Made it into a fairly big company, and came to understand that its mostly meetings, sync ups and polishing tasks on jira. I figured that quitting that job, before I'd end up hating software was the best route to go. I now am an independent contractor and consultant, only working on projects that deeply interest me. It's less stable, and throughout my career the income will likely be a lot less than at any BigTechCo (30-50%). But at least there is room for personal advancement and working on adventurous things here and there.

I'm here with you on this. Tried bigcos multiple times. Couldn't last more than a year. Nobody wants to do this job and that's why they pay a lot for it.

Yep this is normal. The more senior you go, the more you are either managing people, or are just a subject matter expert that ends up either fixing problems or writing design docs.

There is an art of being able to code with people rather than your fingers as a senior engineer, but often time this requires a capstone project to develop from scratch which is far and few in between.

The thing to do with big tech is find a position that pays the most per time spent actually working (which is not always the higher pay), and enough to cover all your needs, and then work on personal projects in the off time. Or you can grind out for several years while saving money, then take unpaid leave.

The problem with personal projects is they almost always lack the scale, complexity, or real world constraints/drivers that real work does. Helpful to feel like you're actually building something but it is kind of boring to build things without a team. I really do enjoy learning from others with different approaches and learning from pairing and mentoring more junior developers and having to explain why we are doing things. There are just so few repetitions at BigTechCos that its hard to get that there.