←back to thread

1041 points mertbio | 1 comments | | HN request time: 0.213s | source
Show context
seanc ◴[] No.42841499[source]
I've been in high tech for 30 years, and I've been laid off many times, most often from failed start ups. I _strongly_ disagree with a fully cynical response of working only to contract, leveraging job offers for raises, etc.

There are a few reasons for this, but the most concrete is that your behavior in this job has an impact on getting the next one. The author is correct that exemplary performance will not save you from being laid off, but when layoffs come your next job often comes from contacts that you built up from the current job, or jobs before. If people know you are a standout contributor then you will be hired quickly into desirable roles. If people think you are a hired gun who only does the bare minimum that next role will be harder to find.

On top of that, carrying around bitterness and cynicism is just bad for you. Pride in good work and pleasure in having an impact on customers and coworkers is good for you. Sometimes that means making dumb business decisions like sacrificing an evening to a company that doesn't care, but IMO that sort of thing is worth it now and then.

To be sure, don't give your heart away to a company (I did that exactly once, never again) because a company will never love you back. But your co-workers will.

replies(40): >>42841581 #>>42841597 #>>42841651 #>>42841813 #>>42841885 #>>42841938 #>>42842044 #>>42842177 #>>42842180 #>>42842250 #>>42842331 #>>42842374 #>>42842464 #>>42842616 #>>42842660 #>>42842679 #>>42842696 #>>42842705 #>>42842846 #>>42842996 #>>42843197 #>>42843394 #>>42843500 #>>42843507 #>>42843581 #>>42843805 #>>42843812 #>>42843830 #>>42844000 #>>42844148 #>>42844304 #>>42844779 #>>42845758 #>>42846127 #>>42847404 #>>42848237 #>>42848351 #>>42851893 #>>42870437 #>>42906633 #
ToucanLoucan ◴[] No.42841597[source]
> but the most concrete is that your behavior in this job has an impact on getting the next one.

[ citation needed ]

Every job I've worked at has specified when we provide references, we're to say "X was employed from Y to Z" and if we would hire them again, yes or no. The employee described here would get a yes from me. The fact that they didn't go "above and beyond" will not help them get a job, at least if they happened to work for any of the companies I have.

> If people know you are a standout contributor then you will be hired quickly into desirable roles.

I guess we could quibble over definitions then, because I as a senior dev managing other devs am perfectly happy with someone who clocks in, does the work on-time and to-spec, and then clocks off as a "standout contributor." I've chastised a few people in my time for committing code on the weekends too, not because I don't appreciate their contribution, but because I consider it part of my job to prevent burnout, voluntary or otherwise.

Burned out devs turn out worse work, and they feel worse in the bargain. Textbook definition of a lose-lose. Whatever code is being a pain in the ass today is just that; code. It will be there when you get back from the weekend, it will be there when you get back from a doctor's appointment, it will be there when your kid is done being sick. Life matters. Code... does, but to a lesser extent.

> On top of that, carrying around bitterness and cynicism is just bad for you.

Which is why I don't want people feeling bitter about their job, and putting in the extra work to, by your own admission, be just as damn likely to get the axe for reasons that are out of your control? That's embittering as fuuuuuuuck.

> Pride in good work and pleasure in having an impact on customers and coworkers is good for you.

False dichotomy. I love what we build, and I want my subordinates to have fulfilling, happy lives. And I proportion my energy to both of those things in accordance with their importance.

replies(6): >>42841617 #>>42841672 #>>42841703 #>>42841797 #>>42841852 #>>42846551 #
9rx ◴[] No.42841672[source]
> I've chastised a few people in my time for committing code on the weekends too, not because I don't appreciate their contribution, but because I consider it part of my job to prevent burnout

The best way to avoid burnout in my experience is to work when you have "the itch" to do it. If you're feeling it on a Saturday, why not go for it? You might not be feeling it on Monday and will need the break then instead. If you forego the prime opportunity and then force yourself to do it later when you are not in the right mindset, that is when the burnout is going to get you.

replies(1): >>42841714 #
pavel_lishin ◴[] No.42841714[source]
Answering the rhetorical question - because it may set a bad example for other, more junior employees; it may set a new expectation; if the good manager who prevents burnout gets fired, and is replaced with a worse person, they may come to expect you to work six days a week, and instead of preventing burnout by working when you want, you're now being burned out by working not only 5 days a week without any break, but also on one of your weekend days.
replies(3): >>42841781 #>>42841956 #>>42842532 #
ToucanLoucan ◴[] No.42841956[source]
To add: it also sets bad expectations from other leadership. If managers consistently see your guys putting in off the clock hours:

a) it makes me look a bit of a moron, because it implies they can't get their work done within office hours, and my job is to ensure that

b) they then expect that level of work regularly and will feel slighted if it stops being put in. See aforementioned comments about burnout.

replies(1): >>42842037 #
9rx ◴[] No.42842037[source]
> within office hours

You are running a factory over there? That makes the weekend perspective a bit more reasonable, given the constraints. Tech work, on the other hand, descends from agriculture. You work when the sun is shining and rest when it is stormy, metaphorically speaking. There is no reasonable concept of defined working hours. The brain doesn't operate on a set schedule like that, and trying to ignore that reality is where the burnout stems from.

If we were talking about tech, you certainly would look foolish applying factory concepts to an entirely unrelated field.

replies(3): >>42842436 #>>42842958 #>>42846603 #
roguecoder ◴[] No.42846603[source]
I was at one place where we tracked every bug introduced, and discovered more than 90% were in code written after 5pm. We dramatically cut our bug rate just by shutting down PRs outside of business hours.

The problem is that when our performance declines, so does our ability to judge our performance. We can feel more productive while actually doing a much worse job.

replies(2): >>42852756 #>>42853009 #
1. 9rx ◴[] No.42853009[source]
> more than 90% were in code written after 5pm.

Intriguing. Did you find that remained true through DST periods, assuming DST observance? Meaning, did you find that it was literally the clock that determined when bugs would seep in, or did bugs also increase if you didn't counteract times changes for whatever human factor (circadian rhythm?) made 5 PM significant?

> The problem is that when our performance declines, so does our ability to judge our performance.

Sure, but what sees performance magically decline at 5 PM?

If it was the clock, did you try removing the clock from the equation? Did bugs show up the same if developers had no idea what time it was?

If it was some other human factor, did you see uniformity across all participants? Were the "night owls" who were just getting started at 5 PM just as likely to introduce bugs after 5 PM as those who had been working since 9 AM?