4 ms·
> It's just reads that the author works/worked at horrible companies. Hard disagree. > Boring meetings, working during the weekends, stress and awful legacy t
by hnfong 3y ago
> It's just reads that the author works/worked at horrible companies.
Hard disagree.
> Boring meetings, working during the weekends, stress and awful legacy tech is not a necessity.
Boring meetings are not a necessity, but meetings are. (Article mentions no "boring" meetings.) If you don't think so, you're not senior enough.
Working on weekends is not a necessity, but when unexpected crap happens the senior engineers will be called upon whether it's a weekend or not.
Stress is not a necessity, but most people feel it out of increased responsibility. This is a personal/subjective thing, but it doesn't reflect that the company is horrible. Quite the opposite -- if you believe your work is meaningless, and feel OK with doing meaningless work, there's actually not much you can stress yourself about. It's only when you believe there's high stakes that stress becomes high.
As for legacy codebases, it doesn't have to be awful (also note "awful" is not mentioned in the article). A senior engineer who has worked on the project/team for a couple years probably had a role in creating it, or at least has the most experience with it, which is why it tends to be the senior engineer who has to debug it. And if you think overhauling systems just because they're almost 10 years old is always a great idea... well you're not senior enough.
To be fair, I suspect in the contemporary scale of "senior" titles, the stuff in the article is more akin to "staff" level roles than "senior" roles (the latter AFAICT basically means you're technically capable of doing things independently, which is what you're alluding to).
The realization that you need to hold meetings to align and share information with the team (and management), that if you don't fix the outage at 2am nobody else could, that you rather fix the issue in the legacy codebase yourself than assign it to junior team members and subject them to endless frustration... is probably beyond the experience of the typical "senior" level dev.
- lolinder 3y ago> Working on weekends is not a necessity, but when unexpected crap happens the senior engineers will be called upon whether it's a weekend or not. But the headline for that section wasn't "senior engineers spend more time on a formal on call rotation", it was "it’s fine, I’ll finish the work on Saturday." Unexpected issues should be expected and planned for with a dedicated on call rotation that is almost never used because you're setting time aside during the work week to fix common issues. Unexpected issues shouldn't lead to random senior engineers getting called when they're not expecting it. And as for "I'll finish the work on Saturday", it's a hard red flag of a bad work environment if that's happening with any kind of regularity. Normal work bleeding onto weekends and evenings should be a five alarm fire that gets addressed immediately in any company that values their employees. It should not be in a list of things to expect as a senior engineer.
- hnfong 3y agoI generally agree with what you say. Except that I think it's more likely a red flag for the author of the article, not necessarily the company (but of course could be), depending on whether which side had the greater authority to set or influence the deadlines. Sometimes it's easier said than done though. At some point of seniority you basically have to make the engineering estimates whether features/tasks could be done within a deadline. If you made a mistake, you might end up having to own it.