I do rather think it takes good engineers to successfully build around the real constraints imposed by large companies—which optimize their products around a set of business metrics. At the end of the day, engineering is all about building around constraints; bridges aren't built in thin air with idealized traffic patterns, atomically perfect metallurgy, and with unlimited budgets. Yes, bridges aren't software services, but nevertheless the things we humans build are rarely pure or serve a singular purpose.
How good engineers write bad code at big companies
241–250 of 333 posts
Re: How good engineers write bad code at big companies
#242Meanwhile, I have a ton of experience, am personable, am highly technical, and can't find something for some reason despite requesting a fairly moderate salary ($180k) given being 53 and having worked in technology for decades.
Something like if you are not a manager at 53 there must be something wrong with you? That’s what people keep telling me to watch out for.
I was last a Director of Engineering at a startup.
Everyone I hired is still there.
I'm fine with passing the baton, I enjoy mentoring.
Re: How good engineers write bad code at big companies
#243Maybe it's things like 4-year tenure, or shorter tenure, or something else. But I think it's a matter of motivation, Bob. > The thing is, Bob, it's not that I'm lazy, it's that I just don't care. It's a problem of motivation, all right? Now if I work my ass off and Initech ships a few extra units, I don't see another dime, so where's the motivation? ... my only real motivation is not to be hassled. That, and the fear…
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 wor…
"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
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 ?
Re: How good engineers write bad code at big companies
#244[dead]
Re: How good engineers write bad code at big companies
#245Earlier quoted context omitted.
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 wor…
"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 maintenan…
> And management is probably right: code is a mean, not an end
Absolutely!!!!
Our job is not to produce code, it's to produce a product. Code is just the way we happen to execute that goal.
Re: How good engineers write bad code at big companies
#246Earlier quoted context omitted.
Something like if you are not a manager at 53 there must be something wrong with you? That’s what people keep telling me to watch out for.
Not everyone wants to be a manager -- effective management and effective engineering are two very different and rarely overlapping skill sets. It honestly seems strange to me that transitioning into management is such a common career path for engineers.
Oh, I wasn’t trying to imply you should. I don’t want to. I’m perfectly happy as a principal. But people tell me I can’t keep doing that for the next 20 years and expect to keep my job.
Re: How good engineers write bad code at big companies
#247Earlier quoted context omitted.
> Why does bad code bother engineers so much? I’ll take a stab. Because I’m being held accountable for the bad results of the bad code. Because I’m being held to task to fix the problems caused by the bad code on a schedule that I didn’t agree with. Because management is using someone else’s bad code to deny me a positive annual review. “You’re a senior engineer - why did fixing this take so long?” Because of the gar…
Hm, those are all valid, but they're also from the perspective of only caring about external forces. It's as if the work itself is only relevant insofar as we get something out of it. I got into this career because I like mucking about with this kind of work. Programming is sort of like building thought sculptures. Ok, maintaining them too. I spend a lot of my adult life working with these systems, so of course I car…
I'm currently leading a team in a group of teams responsible for a terrible code base. It's riddled with tech debt, our DB is maintained by others and has absolutely atrocious performance, it often feels like I'm the only one who cares about all our tech debt, typescript errors, linting errors and browser warnings, and I worry that the reason I'm the only one is that I'm the most recent hire. I still care.
I'm now spending my weekend thinking about a problem where a really urgent feature I wrote doesn't work because the query behind it is too heavy for the database (the query isn't anything special, but it's against a view that clearly isn't properly indexed), and the DB people are complaining I'm overloading the DB. But it's going to be shown to the regulator for some important regulatory rule for which noncompliance is costing us tens of millions per year. Next Tuesday. Which they told me last Tuesday.
How am I supposed to write good code in that kind of environment?
Re: How good engineers write bad code at big companies
#248A note from someone who specializes in long-term system maintenance:
There is also one, very important aspect, that is - (un)suprisingly - rarely mentioned in comments: a lack of dependence between sloppy work and personal comfort of particular person, responsible for problematic changes.
What I mean? A badly installed or configured system would be a problem in next three, maybe five years: to time of major OS upgrade, HW replacement or refresh, framework deprecation and so, and so... In current, corporate culture, there is almost impossible to being bite by own laziness - almost no one is working in particular company or for particular project so long. Especially, when installation is conducted by external party in model "grab the money and run!"
So, very basic motivation for good work, that comes from awareness, that today technological debt would lead to personal, painful experience in future, doesn't exists at all in modern, corporate environment. The things are even worse - there are multiple relations about negative career consequences resulting from concern for the quality of work: "because we want that product fast a we don't like troublemakers and defensive thinkers".
In consequence, one cannot throw a rock without hitting a dozens of such a cases, like that one: https://discourse.ubuntu.com/t/release-26-04-lts-without-the...
Re: How good engineers write bad code at big companies
#249Earlier quoted context omitted.
Words aren't absolute. No reasonable interpretation of my comment suggests I'm saying you should do the impossible. If someone asks you to do the impossible you have to say no. Better yet, you should figure out what they actually do want. They can't get the impossible, that's not on the table. The worst thing an engineer can do is not learn how to say no. I'll even say, if you don't know how to say no then you're not…
My CTO, when told that adding scope, reducing headcount, and keeping the same timeline all while discovering new unknowns in the codebase was not possible, we were simply told to make the date and asked who's performance review will be impacted. The "no" was entirely ignored. "I don't accept that." How do you say no in that situation? Just quit?
> How do you say no in that situation? Just quit?
Apparently so. It seems GP never had to pay for their siblings to get through college, while paying rent.
Just say no, quit, and ruin life of your loved ones, and become homeless. Ez.
Re: How good engineers write bad code at big companies
#250Great article. I quite appreciate this one and the Pure/Impure engineers.