software-by-committee never works
How good engineers write bad code at big companies
301–310 of 333 posts
Re: How good engineers write bad code at big companies
#302it all comes down to being responsible (and/or accountable) for some process for which you have no power and control over. hence burnout. relinquish good code and save yourself.
Re: How good engineers write bad code at big companies
#303Earlier quoted context omitted.
I agree with literally every word you wrote. But what is this “mastery” or “craft” then? if we agree (rightfully so) that some special people exist, eventually (or immediately) other people get involved, we as industry accept “we had a deadline so it was cool to ‘cut corners’ etc…” - where is mastery or craft in this process? I have and I am sure you have worked with some amazing people over the years but to me our e…
I think people have a very weird notion of mastery and think it looks very different in other fields. That’s because mastery no longer looks like mastery once you attain it. Mastery also doesn’t look like the absence of imperfections - even art house films by master auteurs will have imperfections the masters will see and compromises they had to make to get a film done. Talk to a master builder and they’ll instantly…
if you have ever “cut corners to meet deadline” is where I’d start
Re: How good engineers write bad code at big companies
#304Earlier quoted context omitted.
> “You’re a senior engineer - why did fixing this take so long?” Because of the garbage I had to wade through to even find the problem. Because I wasn’t yet working here when this was written and I have to take time to get my head around the insanity. The arguably unproductive part of my brain craves to reach a day where I can say literally everything straight - if this would be a true description of the circumstance…
I agree it's often difficult, but I think it's possible to balance honesty with humility and being a so-called team player . For example, if you see something that's sloppy [1], your honest assessment will likely help both the coder and the manager. But you do have to temper your language, and sandwich the criticism in something that won't make the person interpret it as "you're sloppy/stupid" or "you don't deserve t…
> your honest assessment will likely help both the coder and the manager
While I'd like this to be always true, there will be cultures and even individual egos for which this will never be true.
Someone who's considered a senior dev in the org might dislike your assessment (regardless of what external resources and industry practices and any number of people's experiences say) and might turn your suggestions for how to make their code a bit better into a bikeshedding argument until either one of you tires out and gives up (no relation to which opinion is even right or what's best) or the manager gets pissed off at the both of you and has to intervene (not necessarily thinking badly of you) and the traditional methods like "pulling rank" wouldn't work either if it's a senior engineer. Even if you do everything right in how you approach it and frame it positively and everything else.
In part, this might be because there's no one set of guidelines for "this is what good code looks like", especially because of how fast moving and disjointed and underregulated the whole craft is (might settle down in a century idk). It might also be because that mess leads to vastly different opinions on what's good (e.g. how some people take SOLID/DRY as gospel, others don't, to the point where WET is a thing). And some people just don't care and don't see things the way you do.
Concrete example: once saw a bit of code that had nested service calls. Suggested to the person that this will lead to the N+1 problem in database interaction. They said that it's okay because the other code is written like that in the app already and that this code is easier to reason about. A month later I had to actually show them cache hit/miss statistics after implementing caching as a band-aid on top of the nested code because there were deadlines and nobody could rewrite the whole thing as a DB view. In that particular case, there wasn't even mean exchanges or whatever, just endless bikeshedding about whether something is needed or not that lead nowhere, even when graphs and data were presented by me.
Same for opinions on how much logging or code comments should there be, stuff like dynamic SQL generation vs DB views and a bunch of more nebulous things, though often with a quality of life impact instead of something so concrete as above, where pages started taking 20-30 seconds to load once the DB was properly populated with a lot of data.
So yeah, absolutely do your best effort and try to orient yourself towards open minded egoless developers in a cooperative environment. But sometimes that's not what life will give you and you might just realize "hey, naah, person X is the problem 100% here but it might be possible that I cannot do anything about it in this environment". I've also been person X, of course, but in general I think more honesty would be good.
Like figuring out why our national e-health project failed so badly as it did and putting the people responsible for the failure in jail after a proper root cause analysis is done, if they didn't seek proper remedies in an adequate amount of time: https://www-lsm-lv.translate.goog/raksts/zinas/latvija/09.04...
Re: How good engineers write bad code at big companies
#305I think, sadly, that's often "the job". My career has been good so far, all things considered, but I think it would probably be better if embracing that idea came more naturally to me. One of my first strange and unpleasant realizations in transitioning from studying computer science to "working in the real world" came in a 1:1 meeting with my manager at my first job out of school. I was complaining about code qualit…
I think about this a lot. My belief is professional programmers should not be artists. I think about other professions. A cook cannot spend time making every dish perfect. A bricklayer isn't perfectly aligning every brick. Even in movie-making there's a shooting schedule. Things go wrong and the best filmmakers know how to keep the production moving. I love the craft of programming, but I see a lot other craft-orient…
Your analogies don't work. Nobody pushes a cook or a bricklayer so hard that they cannot have a basic level of quality to their work. A meal that makes a customer sick or an entire floor of a building collapsing due to bad bricklaying is the limit the managers in those areas generally don't cross.
Not the case in commercial programming. If you manage to pull a heroic and still deliver something that does not fall over in a near-impossible deadline and with a lot of pressure then you are actually doing a huge disservice to yourself because the leadership will think "welp, obviously he can do it in those conditions" and next thing you know, next time around it will be even more difficult.
"Give them an inch, they will take a mile". Sadly this proverb very often applies to business people.
Most commercial programmers are extremely squeezed. I started daydreaming for another profession lately but yeah, ain't happening in my 40s with a very unstable financial situation.
I've read your sibling comments. It seems like you were on the other extreme and it does seem to me that now you are overcompensating by being too sympathetic with business and management. Whiplash effects are very understandable while one is still trying to find their balance. Still, don't give those people too much credit.
Re: How good engineers write bad code at big companies
#306I think, sadly, that's often "the job". My career has been good so far, all things considered, but I think it would probably be better if embracing that idea came more naturally to me. One of my first strange and unpleasant realizations in transitioning from studying computer science to "working in the real world" came in a 1:1 meeting with my manager at my first job out of school. I was complaining about code qualit…
> "... so you're saying they wrote bad code on purpose?" Depends how you define "one purpose". I feel like I could polish any code to perfection forever. But the threshold of bad is going to be very murky. Is it still bad after 5min? After 30? After an hour? After a day? Wherever you think is the right effort/benefit threshold, it will turn out to be different in a few weeks. And you'll find people who think it's too…
> I feel like I could polish any code to perfection forever.
Then you know what to work on to become an even better engineer. My recursive function for improving code has clear exit conditions. One of them indeed includes aggressive timeboxing, so on that point we're aligned.
I feel you are trying to make an argument against better code. I get it, there are very fussy programmers out there who can indeed polish stuff until the heat death of the Universe (and still be unhappy) but bringing up extremes is not very interesting in a discussion IMO.
> Is it still bad after 5min? After 30? After an hour? After a day?
Generally, time spent on code has near-zero correlation with the quality you'll get. That correlation only becomes stronger when you have a lot of trust in the person writing the code (including yourself).
As above, don't try to make managers look like the reasonable people. I've met some and I adored them but the 99% are egotistical snowflakes that will fire you the first time you say "no".
---
Nobody is saying "accommodate the insufferable nerds and give them two weeks to do what junior Joe will do in 2 hours and it'll be pretty good" here in this entire thread. People are saying "maybe we the programmers should have SOME power in some decision-making as well". I am OK with my influence being somewhere between 10-15%; that's expected, I am neither a manager nor a financial stakeholder. What I am not OK with is when that number is 0-1% and sadly that has been the norm during my consulting and contracting period. And it's the main reason due to which I am trying hard to end this period right now and settle somewhere).
Re: How good engineers write bad code at big companies
#307I don't think there's an objective assessment of good code. I've been writing code for over 20 years at this point and most times I've seen what people describe as their own good code I disagree with various decisions. Experience CAN remove pitfalls, though developers even disagree about those sometimes. Organization, chosen abstractions, naming etc are basically personal thinking and have differed on every team I've…
Good code is subjective, especially once you start wandering into the territory of more esoteric approaches such as functional programming, domain-specific languages, code-generation, etc. Bad code is one of those things that we can almost all agree on, often even the person writing it. Alternatively: I don't know how to make a good movie, but I can recognise a really bad one, and you'll almost certainly agree with t…
Yep, you beat me to it. Arguing over good code is pointless. We should instead agree on various metrics on what a bad code is and try to avoid those.
Re: How good engineers write bad code at big companies
#308Earlier quoted context omitted.
I think people have a very weird notion of mastery and think it looks very different in other fields. That’s because mastery no longer looks like mastery once you attain it. Mastery also doesn’t look like the absence of imperfections - even art house films by master auteurs will have imperfections the masters will see and compromises they had to make to get a film done. Talk to a master builder and they’ll instantly…
if you have ever “cut corners to meet deadline” is where I’d start
Can you give an example? Every art, industry, or discipline I’ve ever read about has masters doing this.
Re: How good engineers write bad code at big companies
#309Earlier quoted context omitted.
The GP has been homeless and lived off of discarded food. You're right that saying "no" is a privilege. But also there's nothing as empowering as knowing that it's not going to be as bad as it was before. Stop making assumptions about me and start trying to communicate with me. We can't talk if you want me to be wrong and just reinforce your position. And sorry, I'm not as good as doing the cat wrangling in social se…
I did talk to you. Seniors don't matter, neither do junior, janitors, and to large part execs and CTO. Processes, and the whole structure of company, and past events determines the outcome not individuals. And on top of that broad economic movements. A good carrot in a rotten soup, is just a rotting carrot to be.
You're right that it is the whole structure, but the whole structure is made of people, individuals. Collective action can't happen without individual action. You don't just magically go from no people doing something to everybody doing something. You start with one person doing something, then more, and more, and it spreads like a virus. Both good and bad behavior spread this way, not instantly.
Look, our literal job is to take hard problems and break them down into small and more manageable problems, right? Addressing the whole company is too big of a problem, you have to break it down. You, you are an addressable problem that you can change. The people close to you? Harder, but easier than those far away. They're also easier to convince when you make the change yourself.
Or you can just give up and rot in the soup. Would you rather try to remove the rot from the soup or bathe in it?
Re: How good engineers write bad code at big companies
#310Earlier quoted context omitted.
I think about this a lot. My belief is professional programmers should not be artists. I think about other professions. A cook cannot spend time making every dish perfect. A bricklayer isn't perfectly aligning every brick. Even in movie-making there's a shooting schedule. Things go wrong and the best filmmakers know how to keep the production moving. I love the craft of programming, but I see a lot other craft-orient…
Your analogies don't work. Nobody pushes a cook or a bricklayer so hard that they cannot have a basic level of quality to their work. A meal that makes a customer sick or an entire floor of a building collapsing due to bad bricklaying is the limit the managers in those areas generally don't cross. Not the case in commercial programming. If you manage to pull a heroic and still deliver something that does not fall ove…
What do you mean by basic level of quality?
What are you being pressured to do to meet a deadline that's on the level of building collapse?
"skimp on the tests" or "do this hard to maintain fix as the solution" is maybe the hardest I've gotten pushed. Are people telling you to skip auth to hit a deadline?