81–90 of 333 posts
> Big companies know that treating engineers as fungible and moving them around destroys their ability to develop long-term expertise in a single codebase. That’s a deliberate tradeoff. They’re giving up some amount of expertise and software quality in order to gain the ability to rapidly deploy skilled engineers onto whatever the problem-of-the-month is. And also to "keep the balance of power tilted away from engine…
> That’s a deliberate tradeoff. In my experience, while this line is often repeated, in practice it’s rarely really a “deliberate” tradeoff. Rather it’s mostly accidental.
Earlier quoted context omitted.
I've seen too much of the same. It strikes me that the pattern you describe also matches a lot of AI generated code I see, especially when it's big chunks of generated code. Are we automating this problem and going all-in on the long term costs?
> Are we automating this problem and going all-in on the long term costs? I feel that is a very likely scenario.
Every company I've ever worked at (from ISPs to health insurance to finance) every organize was just copying the fad of something else.
At the time I felt like it was because that was "the best way" but it was more likely do to engineers not having the freedom to actually explore good solutions. The made up constraints imposed by organizations against their workers are rarely for the benefit of the company.
It's not a surprise to see this being the case, most companies on the planet are ran like centrally planned dictatorships with the results being obvious in retrospect.
Earlier quoted context omitted.
Because businesses, as a rule, value moving fast. Being first to market makes money and generally results in winning. Oftentimes the circumstances are "we don't know the requirements", not because of shitty management, but because the problem is inherently hard to define. The business conditions that do heavily penalize bad architectural decisions, like physical structural engineering, can suck to work in compared to…
It is not only being first. It also is about responding to customers - not fun part is your customers don’t care about your app. They have to use dozens of different apps on daily basis, so when you have customer interaction you better be able to do stuff right there because they might be available in 3 months or next year to talk about your app. I don’t like all the fantasy about “just talk to the customers” - nah i…
Earlier quoted context omitted.
> If the foundation is built on sand then that needs to be fixed. Except this is the system working as designed. Leadership 1000% wants to do things as fast and as cheap as possible.
It works as designed if your goal is to get your next promo package. It does not work as designed if the goal is to actually make the company more profitable. This constant rushing rarely ends up in things bring delivered faster or cheaper in the long term or even the medium term.
I noticed an issue with a new feature i couldn't fix in a satisfactory manner monday. I talked a lot, with the lead and the other senior early. First i started doing a shitty fix. Then i asked for a carefull review from the other senior, we discussed the issue and managed to find the origin of all the bad code. Then i asked for more time (well, i "told" more than asked tbh) and did a full refactor, correct this time (hopefully) (the deployment + migration script will run next monday).
Writing bad code happen to everyone, at every company, especially when you don't have a lot of experience and domain knowledge. The issues appear when no one catch this bad code, or when people don't have the time or the latitude to fix it before it corrupt all the surrounding code.
Earlier quoted context omitted.
ive never actually seen someone get fired for making some deep architectural software mistake. its alway for moving too slow, or "low code quality". i think people that were promoted for building systems that turned out bad, should be demoted
Because businesses, as a rule, value moving fast. Being first to market makes money and generally results in winning. Oftentimes the circumstances are "we don't know the requirements", not because of shitty management, but because the problem is inherently hard to define. The business conditions that do heavily penalize bad architectural decisions, like physical structural engineering, can suck to work in compared to…
I 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 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-oriented programmers who want every line to be beautiful. If you want to write code poetry in your off-time, that's your business. But that's not the job.
At work we are bricklayers and cooks. We practice a craft, but also have time constraints. I try to do my best work while working at pace. Sometimes my code could be better, but it's not worth the time to fix. Ultimately the thing we make is the running software, not what's under the hood. The business people are sometimes right
In my experience at a FAANG working on one of the core services for both internal and external customers, essentially two kind of people crank out great code:
1. "rock stars": they joined the company at 25 and they're still there at 35+. they're allowed pretty much everything (eg: no RTO, work from home country) and they know many codebases across the services very deep. they aren't really motivated to go look elsewhere, their grass is already one of the greenest.
2. people with kids. the company pays enough. they aren't really interested in switching job, rather they want to provide for their family. they're good, and maybe every now and then will push through for a promo in order to face new challenges in life (another child coming or some kind of new financial burden).
i'm not saying either one is inherently good or bad.
but yeah. in such large companies you end up working in on a very large codebase that interacts with other very large codebases. all the codebases are proprietary and you're lucky if you can use some libraries that come from the outside world (that have not been heavily lobo^H^H^H^H customized - the libraries i mean).
you do what you can, you do your best, but you're essentially a relative beginner.