[dead]
How good engineers write bad code at big companies
321–330 of 333 posts
Re: How good engineers write bad code at big companies
#322Earlier quoted context omitted.
Actually I worked for a failed startup where everyone left because they disliked management. In that startup I was the lowest paid engineer and the only non "staff" level one who had a contract bringing in money to the company. My last employee review with the company was terrible even though they admitted in the meeting that I had achieved all the goals and gone above and beyond what they had requested I do to get a…
> This is part of why I'm insisting you need to work with me to be able to communicate. You are reaching for assumptions that justify your position. My opinions are shaped by these TERRIBLE experiences. Not really. I'm reaching my conclusion after several experiences in various domains (fintech, ad tech, logistics software, and government-adjacent firms). Each company is terrible in its own little way. The reasons ar…
Just because your experiences don't match mine does not mean mine are invalid.
> Again, you're assuming you understand my condition.
You'll notice I've made no such explicit claims about you. So maybe there's a difference between what I've assumed about you and what you assume I've assumed about you. Given the inaccurate explicit assumptions you've made about me, I think it is pretty reasonable to question your assumptions. To be explicit, question doesn't mean reject. Suspect doesn't mean invalidate.
Re: How good engineers write bad code at big companies
#323it's just the mindset of management 101.. you do not ever let your engineer be bored. literally the first thing they teach in 101 is you deliberately overburden them with crazy THEN set impossible deadline so that they build only the very core and you ship it immediately then refine later. sure the method might be different now, but the spirit of such process is the same, you do not ever let your engineer be bored as…
Can you expand further on that, and maybe send some sources? Interested to learn more about this.
Re: How good engineers write bad code at big companies
#324Earlier quoted context omitted.
I find these drive-by-attacks on CQRS to be particularly frustrating. Some people know CQRS or CQS are fairly straightforward ideas that can be nice to use and give you some benefits. Some people believe CQRS is some kind of elitist architecture authoritarianism bogeyman in the same category as the microservice pushback.
I searched for "CQRS" in both the HN thread that I linked and the article that that linked, and the only mention I could find was this: > Companies burned hundreds of thousands of engineer-hours migrating from monoliths to microservices, or from HTTP service calls to event-sourced architecture, or from event-sourced architecture to full CQRS, and so on. Is that what you're talking about? imo this hardly counts as an…
The reason you missed it is because it's a relentless attack on anything testing, anything DDD, anything CQRS, generally speaking across HN or Reddit or anywhere else. I didn't mean it was just this thread. The example I gave was just another one of them!
Re: How good engineers write bad code at big companies
#325Yes because having a deadline means you aren't set up for quality code...and codebases that are years old are no good. Of course. Sounds like a flavor of the month JavaScript developer. Or the mentality anyway. I know nothing of the author so I don't want to generalize or assume and I definitely agree with a lot of what they are saying. Some very sharp observations.
But companies can't be expected to toss out entire codebases every two years.
A lot of what's mentioned is also true at smaller companies. I see the same exact thing at startups. Now imagine you don't have any programmers who were around for some of the code. No one to ask why or where in the code.
You got 3 or 4 types of programmers that attribute to things in my opinion. At companies big or small.
1. Those who can read through the code and figure things out (or now use the help of AI to do the reading and hunting). These are your A players.
2. Those who try and are cautious but ultimately get tripped up and make mistakes. These are your B players, assuming they can be coached.
The next two types are the EXACT people who end up writing bad code that ends up sticking around for someone in the future. Note that #2 here can write "bad code" but they'll stay around to fix it and will learn and grow (with proper management and support).
3. Those who think they know what they're doing and either move too slow or create bugs. These can be very senior engineers. They're C players, they don't make the cut for long.
4. Those who think they know it all and are very comfortable with changing large areas of code. Who maybe don't tell you they are going to do so (scope creep, inventing problems that didn't exist, determining priorities on their own, etc.). They ship bugs to production and maybe they do go and fix them, great, but sometimes you find people who don't and leave it to others to handle because it's beneath them or something. These people, and they may have decades of experience, are D and F players who need to go asap.
You might see people in group 3 and 4 as "good" or "experienced" because they sound good, interview well, and may indeed know how to write good code - they just don't write good code with others or with an existing code base or just in general because they don't actually WANT to. They don't care.
This brings not only bad code into any company, big or small, it also brings toxicity in. It makes other programmers leave. For example, those that the author talks about as being around longer with limited time. Those people get burned out exactly like the article alludes to. The reason is because of people like 3 and 4.
So I guess that is to say I agree with much of the article, but it's for companies of all sizes and it's not because of deadlines or stock options. It's because that average programmer only sticks around 1-2 years. That's the problem. No one has any commitment. Lots of ego and no team players. That's a lot of what I see unfortunately.
Re: How good engineers write bad code at big companies
#326Earlier quoted context omitted.
> This is part of why I'm insisting you need to work with me to be able to communicate. You are reaching for assumptions that justify your position. My opinions are shaped by these TERRIBLE experiences. Not really. I'm reaching my conclusion after several experiences in various domains (fintech, ad tech, logistics software, and government-adjacent firms). Each company is terrible in its own little way. The reasons ar…
Just because your experiences don't match mine does not mean mine are invalid. > Again, you're assuming you understand my condition. I have not, but you've pretty explicitly made assumptions about me. You'll notice I've made no such explicit claims about you. So maybe there's a difference between what I've assumed about you and what you assume I've assumed about you. Given the inaccurate explicit assumptions you've m…
> You'll notice I've made no such explicit claims about you
That's not quite true. You assumed I'm in a similar position as you:
> You're not stuck where you are, so stop acting like that.
I explained that our circumstances aren't the same. I'm without wasting huge amounts of resources stuck where I am.
> Just because your experiences don't match mine does not mean mine are invalid.
It's true, but for a total statement, you need a total consensus; it's how logic works.
If I say "All seniors are immortal", you're can invalidate the statements by saying "Djikstra was a senior developer, and he is mortal."
Re: How good engineers write bad code at big companies
#327Earlier quoted context omitted.
A good system, i. e. one that got it right from the start, is one that is cost-effective to change. (“Will” has little to do with it.)
Change in which ways? A system designed to be cost effective to change in any way isn't going to be cost effective to change in a small set of ways.
Answering that question well is what makes the system good!
Re: How good engineers write bad code at big companies
#328Earlier quoted context omitted.
I searched for "CQRS" in both the HN thread that I linked and the article that that linked, and the only mention I could find was this: > Companies burned hundreds of thousands of engineer-hours migrating from monoliths to microservices, or from HTTP service calls to event-sourced architecture, or from event-sourced architecture to full CQRS, and so on. Is that what you're talking about? imo this hardly counts as an…
The reason you missed it is because it's a relentless attack on anything testing, anything DDD, anything CQRS, generally speaking across HN or Reddit or anywhere else. I didn't mean it was just this thread. The example I gave was just another one of them!
I'm struggling to make sense of what you're saying. Is there something concrete - some subtlety - that I missed?
I searched HN comments for mentions of "CQRS" over the past year. It's mentioned very infrequently outside of "who's hiring" posts, and mostly in a neutral manner. Very little of what I'd describe as a "drive-by attack".
Re: How good engineers write bad code at big companies
#329Earlier quoted context omitted.
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?
Here's mine from my most recent consulting engagement:
"We understand and recognize that this feature we asked of you absolutely cannot be done without the database denormalization you warned us is necessary several weeks ago, but we are still unhappy with you that you couldn't make it work without it and so we are ending our cooperation."
Consider yourself privileged.
I do all sorts of root-cause analyses and I don't sit to code until I am reasonably sure I'll make a positive impact. Long gone are the days when I started coding enthusiastically after hearing just two sentences.
It was still not enough.
I'll not start a flame war -- too tired for it -- but let us just say that some stereotypes exist for a reason.
Re: How good engineers write bad code at big companies
#330Earlier quoted context omitted.
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?
Here's mine from my most recent consulting engagement: "We understand and recognize that this feature we asked of you absolutely cannot be done without the database denormalization you warned us is necessary several weeks ago, but we are still unhappy with you that you couldn't make it work without it and so we are ending our cooperation." Consider yourself privileged. I do all sorts of root-cause analyses and I don'…
That's fair I appreciate you taking the time to respond, that's a helpful example