Live data from Hacker News

Developer on Call

henrikwarne.com

231–240 of 246 posts

Re: Developer on Call

#231

Earlier quoted context omitted.

"Objective" is a pretty slippery word. It's all about context. I'm glad I had that job and worked under those conditions, and I'm glad I left when I did. It was a good thing for me at the start, but then it got old.

Bad things can work out for your own personal good. Or even the good of the whole of society. However, that doesn't make them not bad. I'm glad that your situation worked out for your own personal good. Nice things happening to people make me happy. Things working out for people make me happy. However, the situation you describe is the latter not the former. That your bad situation, which ultimately worked out for yo…

This misses a big part of the picture. People—especially single young men—are ambitious and competitive. Someone with enough skill to be on-call at a modern manufacturing plant—let alone a software engineer—is not just scraping by. He doesn’t submit to long, hard hours because he has no choice; he does so because he wants to advance in his career. He has a real, meaningful choice: sacrifice work/life balance while he’s young in an attempt to maximize his earning power, or coast by comfortably—if frugally—and make roughly $PRESENT_AGE * 1000 (inflation-adjusted) right up until retirement. If you want to talk about sweatshops or sex slavery, sure, I’m right there with you. But let’s not kid ourselves.

Re: Developer on Call

#232
post #206

Earlier quoted context omitted.

> Does that not sound manipulative to you? You seem to be assuming there is a lot of peer pressure placed on you if you don’t want to do it. Why? I’m simply saying there are always social costs. For example you probably won’t be listened to as much when there are conversations around improving system stability. It’s like our after work Friday drinks are entirely optional - but lots of people build friendships and tru…

> For example you probably won’t be listened to as much when there are conversations around improving system stability. That sounds like not listening to people about things they might be good at and know something about, because you want to punish them for something completely unrelated. Namely, punish them for not participating in "optional" activities. All the while you don't want to openly and transparently say w…

In all seriousness, you sound a little antisocial. I see where you’re coming from and I sympathize, but the environment described by the poster you’re replying to sounds very mildly manipulative at worst. I’m not sure you understand that the whole “bad mate” thing likely comes from his peers, not from management. Human beings are social animals, and you’ll be better off if you adapt to that reality rather than rail against it.

Re: Developer on Call

#233
post #179

Earlier quoted context omitted.

If Silly Valley was run like Hollywood, you'd have Version Control Engineers as a class and no one with their Version Control's Guild cards would have any say in that field. (With how Hollywood is run, you might as well have While Loop Engineers.)

I think you're exaggerating a bit. Making movies is multi-disciplinary, where sound vs visuals vs set design are largely different skillsets at the higher levels. Sounds similar to engineering vs design vs product management to me.

Sure. But at least at my startup 3 of 5 founders are able programmers, two of five are able mathematicians (important to our R&D process), two of five have extensive strategy and financial consulting experience and one was a manager for a long time.

So... we switch hats a lot. In the last six months I've been (a) deep into research, producing basically Beamer slidesets; (b) implementing that research in Python; (c) spearheaded the basic product design process, albeit based on the whole team's insight (my lemma was "I'm basically an anthropologist trying to make sense of what everyone's been saying", although I made significant calls (d) pitching in with front-end programming in Angular when our third party provider pooped out and it got to crunch time and (e) spent deep time writing finance spreadsheets and valuation models.

It's a tight ship and I'm not even the most multi-talented person in the crew.

Re: Developer on Call

#234
post #206

Earlier quoted context omitted.

> For example you probably won’t be listened to as much when there are conversations around improving system stability. That sounds like not listening to people about things they might be good at and know something about, because you want to punish them for something completely unrelated. Namely, punish them for not participating in "optional" activities. All the while you don't want to openly and transparently say w…

In all seriousness, you sound a little antisocial. I see where you’re coming from and I sympathize, but the environment described by the poster you’re replying to sounds very mildly manipulative at worst. I’m not sure you understand that the whole “bad mate” thing likely comes from his peers, not from management. Human beings are social animals, and you’ll be better off if you adapt to that reality rather than rail a…

I think that I am simply working in better place. The one where people can but does not have to socialize at Fridays and the one where if they want you to do something, they say it.

That means that fathers don't have to drinking Friday evening and can be with their families. It means that parents who pick up kids after work are not disadvantaged by it. It means primary caregivers (women) have smaller hit on their career then they would otherwise. It means that people can so sport on Fridays, abstinents do well, anyone can use Friday evening to travel.

It is not merely mildly manipulative. It is literally bad office politics framed as "being social". Peers being passive aggressive is no different from management being manipulative or passive aggressive.

Lastly, it also means that I can make open transparent agreements about my work and preferences and salary compensation. Because in your setup, such things are not talked about openly and conflicts are not solved directly.

Re: Developer on Call

#235
post #206

Earlier quoted context omitted.

> For example you probably won’t be listened to as much when there are conversations around improving system stability. That sounds like not listening to people about things they might be good at and know something about, because you want to punish them for something completely unrelated. Namely, punish them for not participating in "optional" activities. All the while you don't want to openly and transparently say w…

> would listen and judge system stability suggestions based on participation in supposedly optional activity unrelated to system stability. In my experience they are closely related. > You also openly say that you trust people work based on Friday beer Sure - there is an incredible depth of research on trust building via outside of work/after work activities. > That sounds like horrible workplace Strange considering…

I guess it is best for whom? It is certainly fun to be part of such clique and everyone who has real responsibilities or relationships outside the office or who want to directly openly discuss workload will leave after a while having no choice.

As in, they are fun places if you single, but if you don't want to offload all children or sick relatives care to partner, you will be punished for drinking with buddies less. Your actual in-the-workplace behavior and output will be irrelevant.

They are fun places because of ping pong table and x-box console, but you wont be able to make explicit agreements about your workload and nature of work.

Re: Developer on Call

#236
post #208

Earlier quoted context omitted.

So then you should probably only work on products that don't require out of hours support, or where the team is willing and able to hire people in another time zone. Instead, you think some ops guy should do it?

Perhaps the company should invest the resources into hiring people to provide out of hours support rather than expecting their employees to be on call 24/7 for certain weeks of the month. Otherwise, why shouldthe company bother offering out of hours support if it's not willing to pay for it.

Indeed, companys should pay what's required, but it's not really the point I'm making.

End of the day, an Ops guy who is not part of the development team can't really do all that much when a bad commit brings down the system. Sure, we can take a stab in the dark and roll-back, but we don't know if that's going to make the problem worse, or we can restart it but that's about the easiest thing in the world to automate.

So, why not get the experts of the system, who rolled out the change, and undertook the quality control, to be part of the team that fixes the outage (irregadless of what time we do it at)? Who is better suited?

Re: Developer on Call

#237
There are some issues that an application developer is very good at solving, usually if they relate to application logic.

And then there are other issues that classical operations people tend to be much better at finding, such as weird network/storage/compute/whatever disruptions or starvation, wobbly load balancers or firewall rules etc.

Of course, you can try to teach developers those skills as well, but then you could also teach operators more about application logic.

My point is that neither "developer on call" nor "operations on call" feel obviously right to me, and I haven't found a good solution yet. Maybe both need to be on call, and collaborate.

Re: Developer on Call

#238

Kayak.com co-founder Paul English on this topic (2010): "The engineers and I handle customer support. When I tell people that, they look at me like I'm smoking crack. They say, "Why would you pay an engineer $150,000 to answer phones when you could pay someone in Arizona $8 an hour?" If you make the engineers answer e-mails and phone calls from the customers, the second or third time they get the same question, they'…

The trouble is that 90% of your calls will be due to user error, and the vast majority will be something you just can’t improve, like people misspelling their own names.

Neither one of these problems are, "things you cannot fix".

Re: Developer on Call

#239
post #227

Earlier quoted context omitted.

If Silly Valley was run like Hollywood, you'd have Version Control Engineers as a class and no one with their Version Control's Guild cards would have any say in that field. (With how Hollywood is run, you might as well have While Loop Engineers.)

Hollywood isn't the only union in the world, and from what I can tell, it's unique in its manner of operation. Is there any other trade union which has "cards" like that?

Occupations aren't usually that narrowly defined. Hollywood is something of a strawman in debates about unions, but then - Hollywood is closer to Silly Valley geographically than most typical cases of heavy unionization.

Re: Developer on Call

#240

Earlier quoted context omitted.

Every such paper I have received has explicitly noted the following, paraphrased: - This is not a contract; any contract with us must be signed by the CEO. (Paper is not signed by the CEO.) - You are an "at will" employee. The employment relationship may be ended at any time, by any party, for any reason, or no reason at all. There are no notice requirements, and any and all obligations of one party to the other are…

> - You are an "at will" employee. The employment relationship may be ended at any time, by any party, for any reason, or no reason at all. There are no notice requirements, and any and all obligations of one party to the other are severed at the moment of separation. When I made my comment, I was trying to get a handle on just why Americans don't think of these as contracts, and the quoted bit is why I think. An emp…

About the only thing such papers are good for in court is as proof that an employer-employee relationship existed. You do what we say, and we give you money. It could be used if the employer did not pay you what you were owed for working, for instance, but there is not much else on the paper itself that is enforceable.

The only negotiable point is the rate of pay. The valuable consideration is money for labor. All other terms and conditions of employment are set by the employee manual, which is "do this, just like this, or we fire you".

As contracts go, they suck for the employee.

Post reply on HN