No, big tech engineers are highly motivated. There's lots of money, good management, and plenty of incentive. (I'm a Google engineer myself).
The problem I observe is a fairly universal one: management doesn't care about good code, it cares about results.
It's generally hard for anyone without specific experience with a codebase to tell what you're doing with it. Management can't evaluate the value of maintenance work, so it doesn't value it at all.
> The problem I observe is the universal one: management doesn't care about good code, it cares about results. It's generally too hard for ANYONE to tell what's going on in a codebase unless you're experienced with it. Management can't evaluate the value of maintenance work, so it doesn't value it.
I think this is a very telling statement, but perhaps not in the way you intended. I would agree that management only cares about results, but I would posit that maybe that's a good thing. If you don't have ground-truth knowledge of a problem, you must rely on either the word of someone who does, or metrics that can be used as a yardstick.
When all a manager has to go on is someone's word, it can be really hard for them to gauge the depth, severity, and impact of the problem being expressed to them— and without any metrics, they have no way of tracking progress on resolution. In a modern codebase, you could spend YEARS on improving maintainability and still not "finish". The key (that I've found, personally) in this situation is to give the manager some form of metric to describe the problem. If you can establish a number to measure what you're advocating for, and quantify the consequences of not doing it into actual business impact, I've talked managers into taking my suggestion more often than not.
> in this situation is to give the manager some form of metric to describe the problem
how do you have a metric to measure a future issue that got prevented by having good maintenance?
Either you cannot actually imagine nor describe the problem that was prevented, or you could just make something up which cannot be disproved nor falsifiable. So if you asked for time/resources/budget to do maintenance, you cannot then give proof that this maintenance was useful!
The only way to get a metric is to have an incident or have issues crop up, and then in the retrospective, claim that certain maintenance work could've prevented it.
It's because the only people who can understand the code are people who write the code every day. And sometimes the devs don't even really understand it.
Occasionally you'll have a manager who manages in the day and codes at night, which is fine if not bad for his personal life. But HIS manager almost never does that. And his manager's manager? Forget it.
To be fair to management, it is the results that matter.
Management cares about what their management cares about. So this boils down to what the CEO cares about. The CEO cares about what the board cares about. The board cares about share prices going up.
I do believe that e.g. retaining engineers is something that helps the business. It's stupid that someone ramps up for 2 years and then goes to a different job just as they start becoming really effective. It costs companies a ton of money which they could instead just use to get people to stay. But I'm not on Google's board. It's only when Google board decides that fostering the right engineering culture is important enough for the business that something is going to change. And so far- they don't (s/Google/BigTech).
Re: Incentives- Obviously(?) the incentives are not right. So when you say "plenty of incentive" what it really means is incentive to ship sloppy code and get promoted. Or the incentive to go from Google to OpenAI and get a pay increase or whatnot.
> To be fair to management, it is the results that matter.
To be fair to me, I don't recall ever signing a contract through which I am directly responsible for the company's financial and customer-acquisition / retention efforts. I sign up as an individual contributor who helps advance the customer & product mission forward. I am NOT a cofounder.
So that shows, yet again, how myopic and egocentric managers are. Wise ones -- the all 2-3 I have met throughout a 20+ years of experience -- understand that they must enable you to produce the outcomes they care about.
Unsurprisingly, I worked fantastically well with those managers and we achieved near-miracles in some measly 4-5 months.
But all others? "I never gave you time to optimise cloud spend but now I am angry at you for not doing it in your sleep", more or less. Or "I pushed you to the brink of 12-hour workday regularly and started reaching into your weekends and you rushed that feature I pressured you for and it has one small performance regressions? You are fired!". Deal with it.
/rant.
Not directed at you, obviously. Got triggered a little.
We need to disconnect the question of bad managers from the structural issues though. I try to be a good manager but I still have people jump ship for better comp and where we won't match it. I still need to deal with an incentive structure that doesn't match what I am trying to do with my team.
This same structure is also what helps bad managers. Who is going to get promoted to a director role? The person who stands up for their team and argues with the VP or the person who toes the line? The things that you think are near-miracles are not visible and the people that play politics will make their stuff look more valuable to the company.
Yours and my experience are not mutually exclusive, I think we both see it. I dream of managers like you but I never get hired under them for some reason. (Likely regional culture, experience shows.)
I'm at a stage of life and career where I'd happily take a small pay cut for a year just to establish myself in a place and have stability. Then we'll talk about competitive compensation.
My chief issues are with people that are best described with the proverb "give them an inch and they will take a mile".
Yours seems to be that you deal with people that constantly think that they can do better in terms of how much they take home (let's not sugar-coat it, they're spoiled -- I was too).
Heroics being invisible and people who have their coffee with leadership getting the money and the influence is the wrong system. Always was and apparently always will be.
It's interesting that you talk that there's a lot of good management, followed by a list of things I'd call bad management: Forget about good vs bad code, of course that's unimportant. But insufficient maintenance that causes lower velocity on the next set of changes matters. Good engineering will tell you when the issue isn't just about code that is ugly, but code that slows changes down so much you'd be better off improving it.
If you set incentives that say that being sloppy and leaving landmines for the next group of people is the way to get promoted, guess what? the management is bad. Often because they are also looking at their own self interest, and expect to leave the consequences to whoever comes after them. This isn't new to big tech: You'll find this all described in books about corporate dysfunction written in the 90s.
It's all traditional principal agent problems, which just get worse and worse as you add layers of management, as the principal has agents upon agents underneath, all using the misaligned incentives. One either wants t avoid getting fired while doing the minimum, or sacrifice the health of what is around them for a good enough promotion packet/review. And since there's no reasonable way for individual objectives to align well with long term objectives, people leave landmines. When there's enough landmines everywhere, you are always better off in greenfield development. And at that point, doing any maintenance, or being stuck in a project that isn't getting fed a bunch of capital to grow it is career suicide. All about bad incentives, set by bad management.
> The problem I observe is a fairly universal one: management doesn't care about good code, it cares about results.
The thing is, good code is a form of a good result. You need to solve the underlying problems (which manifest as impact) but if you used code to get there, that code if well designed is extensible, reusable, then you pay low maintenance on it and that same code can be used to solve other problems (ideally).
It's a difficult judgement call to make though. If your org doesn't have the right technical leadership and the performance management structure doesn't reward it then you get what you see.
It's a lesson that's always learned far too late when it becomes slow and costly to deliver something new because you've amassed so much tech debt so it's often cheaper to start from scratch (which is saying something).
I see this all fwiw in big tech myself and with my peers at peer companies.
> It's a lesson that's always learned far too late when it becomes slow and costly to deliver something new because you've amassed so much tech debt
No, it is just standard operating procedure: deprecate a working system and write a new system from scratch, with 50% of features not supported. This side-steps the tech debt and gives everybody artifacts for promotion. It screws all users of the system but who cares about them!
The thing is shipping sloppy code is orders of magnitudes easier, because that's the default result. Any sufficiently determined hack-job can do it. On the other hand, steering a team of 5-10 engineers to deliver quality on (or before!) a deadline requires excessive amounts of coordination and skill. Now, is this trade-off "worth" the effort? I guess that's a matter of opinion, though I would argue in the long term quality wins out by a large margin.
Sometimes teams will do the sloppy thing because it's the quickest path to resolution of an issue deemed to be critical, which can make sense in the moment, but if you do this too many times without spending the effort to improve the solution after the immediate pressure is gone, issues like this will continue to get more common. I like to use an analogy of trying to put out a fire on the other side of a building by filling a cup in the sink and then running across to toss the water onto the fire; in the short term, it might be the best fix, but if you keep finding yourself having to do this, you're probably better off installing a fire hose even if it requires a lot more effort up front.
"management doesn't care about good code, it cares about results."
And management is probably right: code is a mean, not an end
It is us, as software engineers, to make that better code brings better results
Some benefits of better code can be:
- less infrastructure cost
- more speed / efficiency / whatever metrics available from the users
- easier to integrate new features
- less issues, less time spent in maintenance etc
At my current job, we have some instance of people who animate around bad practices: they scan everything, identifies some "bad practice" (which can be whatever) and then raise the issue to all teams and give them a month to fix the issues
Very political stuff
I try to do good code. My team is rarely cited in that list of "bad players". Management does notice.
Corollary: our roadmap is not messed up. Product managements notices.
Also, good code must mean robust infrastructure. We have very few incident. Almost all our changes are successful. Incident and change managers notice.
Anyway, my point is : if good code brings no benefits to the outside world .. how is it good, exactly ?
Yup, tolerating inappropriate tech debt for too long leads to bad results. I see this going wrong all the time and I thought it was mostly due to being surrounded by bootcamp grads given nothing but year after year of pressure and no examples of what good code can look like. Surprised to hear the same thing happens in big tech.
There is also a lot of money, there is also good management, and there are also lots of incentives.
But management depends on your manager; at scale it becomes likely there are bad apples in every management tree. Incentives may not align with what you want or need, with work From Home policies getting shrunk. Even money sometimes is a point of contention.
That's just the thing though: I want to know what those other incentives are and I was never told anything else than a hand-wavy "money" blurb with zero elaboration.
I mean OK, technically the ad viewing experience in f.ex. iOS is terrible; you sit through 30 seconds, then a white button on an almost-white background appears (dark pattern, they want you to sit looking at the ad longer), then when you "dismiss" is, an AppStore pop-under shows up and you have to dismiss that as well, and ONLY THEN you get another screen where you have to wait 5-10 seconds until the blessed micro X button finally appears.
This can be made much better: the ad platform might enforce the top-left corner be always black and the X button to appear only once and be effective immediately, for example. No shenanigans with bluffing that you are now leaving the ad but haha, you have fallen into our trap! Here's our AppStore page!
But why should Apple care? The money is literally pouring in! And humans operate on fight-or-flight responses much more than what 99% of them would be willing to admit; an Apple executive can drown you in executive jargon but the naked truth would still be "We don't want to change anything that might slow down our income". Or even more bare: "Don't touch it if it works and makes money".
So yeah, that's one of the examples where the hand-wavy "money" blurb would make total sense; I get it.
But in all my career I was never told in clear certain terms -- and they must also make sense -- about why not investing just a measly two hours more on technical excellence is so extremely unwelcome. Of course they always cite velocity and customer retention and how we must make sure we don't miss a potential client but I've never seen even one little piece of evidence of customers churning because a feature was delivered on Wednesday and not Tuesday. I am sure it happens, mind you, but I could never shake the feeling that those dangers are always hugely exaggerated.
Was McNamara really thinking that's how you win a war and people just went along with it or was it just another excuse in a long line of excuses to keep the gravy train going?
The problem I observe is a fairly universal one: management doesn't care about good code, it cares about results.
It's generally hard for anyone without specific experience with a codebase to tell what you're doing with it. Management can't evaluate the value of maintenance work, so it doesn't value it at all.
People who ship sloppy code get promoted.