Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Doing nothing at work

seangoedecke.com

Post reply on HN
Print view View original

111–120 of 168 posts

Re: Doing nothing at work

#111

Post by jiggawatts »

Arainach wrote: post #101
derangedHorse wrote: post #99

Earlier quoted context omitted.

The game theory should make is that those teams that recurring lay lose customers due to issues will be punished accordingly. If they aren’t, then maybe the problems that result from shipping fast don’t impact customer retention as much as might think.

This works across small entities like companies with distinct customers and budgets. It does not work for large corporations with pools of billions of dollars and various incentives to staying within the ecosystem. It's impossible to measure the contribution of one feature team to perception and retention of something like "Microsoft Intune" or "Google Chrome", and without the ability to measure that no effective che…

The most spectacular instance of this I've seen is Jeffrey Snover getting demoted for "forcing" PowerShell onto Microsoft. Meanwhile from a customer perspective its the only good thing about Windows Server and the only reason I haven't pushed for 100% Linux adoption everywhere I work!

See: https://corecursive.com/building-powershell-with-jeffrey-sno...

Re: Doing nothing at work

#112

Post by jiggawatts »

dj_axl wrote: post #103
Arainach wrote: post #97

This is a good post, but once again incentives rear their ugly head. > Second, preventing or mitigating an incident early (even by just knowing the right feature flag to turn off) can save huge amounts of money: both immediate lost revenue during the incident and future lost revenue from customers who would have pulled their business or refused to sign pending contracts. Time and time again at many companies, includi…

Thread.sleep(100000) everywhere until it breaks. Then lo and behold you have fought fires longly and bravely until midnight on Friday after the release. Don't ask me why it's rewarded, and, of course every now and then they switch to rewarding different things.

Correct multi-threaded code is... sss... hard.

Much easier to liberally sprinkle mutex locks and "Thread.Sleep(1000); // Quick fix" everywhere until the problems almost always go away!

Meanwhile the guy screaming that this is eldritch madness and can't ever work is "not a team player" because the guy that wrote the code was a hero for applying yet another layer of band aids to the gaping wounds.

Re: Doing nothing at work

#113

Post by Arainach »

bumby wrote: post #87
fridder wrote: post #80

Earlier quoted context omitted.

My pushback isn’t the credit part it is when they try to spring things on you directly instead of going through normal channels. A lack of planning on someone’s part is not automatically an emergency on my part. I see this far more often than credit stealing

I can see that. The counterpoint is that it can create bureaucratic bloat. If the proper channel means coordinating with finance to allocate money, get it assigned to labor codes, and reflected in my bi-monthly time allotment, I think I'd rather just jump the job and get it done this week than get it properly assigned two months from now. It does require a certain amount of cover and trust within an organization, tho…

I've never worked somewhere where the proper channels meant "coordinate with finance", but "file a bug/feature request to track this work and time time spent on it" should be standard. If it's not worth 5 minutes for the requester to do that, it's not worth however long it would take me.

This makes it easier to query and show what you've done in a time period. It makes it easier to go through the list of your assigned tasks and understand where it fits in the priority order.

Re: Doing nothing at work

#114

Post by m463 »

wiseowise wrote: post #58

> I also believe that being too helpful leaves you vulnerable to predators. Tech companies are full of people who want to extract uncompensated work from software engineers4. This is different from work that arrives via normal channels, and for which you’re compensated by promotions, bonuses (and just your normal salary). I’m talking about work that arrives via backchannels, from people who don’t have the ability or…

hmmm...

At good companies, they have a culture, and people help each other out.

Like lunch-table talk that helps people understand things.

But yeah, maybe not doing hours of work for someone.

Re: Doing nothing at work

#115

Post by elevation »

wiseowise wrote: post #58

> I also believe that being too helpful leaves you vulnerable to predators. Tech companies are full of people who want to extract uncompensated work from software engineers4. This is different from work that arrives via normal channels, and for which you’re compensated by promotions, bonuses (and just your normal salary). I’m talking about work that arrives via backchannels, from people who don’t have the ability or…

> willingness to ensure that work is formally recorded under your name

Where I work the title "Principal Engineer" is a coveted, well compensated, and rarely achieved. Those I've worked with are all highly effective and personable, but I interviewed one about how he achieved the title at his previous company.

His strategy had been to help people and actively give away the credit. In 1 on 1s or in meetings with multiple layers of managers, he would consistently emphasized the value of his other team mate's work. This ingratiated him with his team; years later, when a high dollar project was behind schedule and several key engineers had quit, he carried the project to victory with some late nights, and was awarded the title+raise at his next review. While the key project pushed him over the edge, he wasn't the only engineer there working late nights. He credits his promotion to the goodwill he'd built during his tenure by actively giving others credit.

Re: Doing nothing at work

#116

Post by CobrastanJorji »

themaninthedark wrote: post #60
CobrastanJorji wrote: post #55

Earlier quoted context omitted.

Also, disaster is a good signal to the higher ups that there are problems in your org. If you keep putting out every fire with heroics, your boss will know (maybe), but his boss's boss's boss will see that your org is doing great and everything is all code green. If you let a few things burn down, your boss's boss's boss will notice the fire, and things may improve. It's perhaps the easiest way you have of communicat…

What if my boss's boss is the root cause of the fires and he just blames the "team" if his boss ever sees a hint the of issues?

Your great grandboss will not look favorably upon your grandboss passing blame downhill. Disasters are (hopefully) always the fault of the person in charge, which is why you'll notice that your bosses are unusually involved with meetings about how to avoid more disasters.

Re: Doing nothing at work

#117

Post by JohnMakin »

derangedHorse wrote: post #99
Arainach wrote: post #97

This is a good post, but once again incentives rear their ugly head. > Second, preventing or mitigating an incident early (even by just knowing the right feature flag to turn off) can save huge amounts of money: both immediate lost revenue during the incident and future lost revenue from customers who would have pulled their business or refused to sign pending contracts. Time and time again at many companies, includi…

The game theory should make is that those teams that recurring lay lose customers due to issues will be punished accordingly. If they aren’t, then maybe the problems that result from shipping fast don’t impact customer retention as much as might think.

Not necessarily. Not every job is shipping features that are visible to customers, or even to management.

You see this pattern of "make fire, put it out, get rewarded" a lot on devops type teams, almost always by the lead (IME). Often it is very difficult to determine customer impact of these types of events, especially if monitoring/alerting is lacking (very common), and even if it isn't, often these same teams have the ability to turn those knobs any way they want anyway.

Re: Doing nothing at work

#119

Post by wiseowise »

elevation wrote: post #115
wiseowise wrote: post #58

> I also believe that being too helpful leaves you vulnerable to predators. Tech companies are full of people who want to extract uncompensated work from software engineers4. This is different from work that arrives via normal channels, and for which you’re compensated by promotions, bonuses (and just your normal salary). I’m talking about work that arrives via backchannels, from people who don’t have the ability or…

> willingness to ensure that work is formally recorded under your name Where I work the title "Principal Engineer" is a coveted, well compensated, and rarely achieved. Those I've worked with are all highly effective and personable, but I interviewed one about how he achieved the title at his previous company. His strategy had been to help people and actively give away the credit. In 1 on 1s or in meetings with multip…

I know a guy who did all what you've listed and the only thing he received was a burnout.

Re: Doing nothing at work

#120

Post by prolly97 »

Arainach wrote: post #97

This is a good post, but once again incentives rear their ugly head. > Second, preventing or mitigating an incident early (even by just knowing the right feature flag to turn off) can save huge amounts of money: both immediate lost revenue during the incident and future lost revenue from customers who would have pulled their business or refused to sign pending contracts. Time and time again at many companies, includi…

With the way you're framing your opposition, I agree with you. But I'd like to add some nuance. Parts of building a product or a set of features is about search, rather than great engineering. Sometimes it's better to build two good-enough features to figure out which one is valuable to the user, rather than building one solid* one. I've always been in the "let's fuck around and find out" camp. I appreciate that someone with a different attitude built git! Just saying that there's a balance here, which will depend on the degree to which you're in the middle of a search problem.

*solid in a pure engineering sense - availability, maintainability, chance of leaking the users' nudes etc.

Post reply on HN