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

Developer on Call

henrikwarne.com

Post reply on HN
Print view View original

141–150 of 246 posts

Re: Developer on Call

#141

Post by stevoski »

WrtCdEvrydy wrote: post #92
wink wrote: post #89

Earlier quoted context omitted.

This sounds so nice in theory. All those pesky developers refusing to fix their horrible code. While in reality at least in my experience the developer would be very much happy to fix the code, it's just that you don't get any time to do that. It's only new features and new products.

Bug fixes don't sell your software unless it's a heavy customer product.

In a SaaS business, bug fixes can help reduce churn.

A simplistic description is, "sales and marketing increase MRR, a quality product decreases churn".

Often a company becomes financially viable by fixing churn.

Re: Developer on Call

#142

Post by onemoresoop »

ken wrote: post #115

There's a lot of words, in the article and the comments, about being compensated for on-call time. The software field seems very anti-union, for reasons that I don't entirely understand. Protecting your time is one feature that unions offer. Want to be paid for every hour you're on call? Get the union to put it in their rules for employers. The alternative we have now is that each developer is responsible for negotia…

But being on call and suddenly having to fix an urgent issue takes the more energy: warm-up energy, context switching from dining with the family or playing with the kids, or being woken up from sleep. How can that be calculated so that nobody gets taken advantage of? And there's a downside, if being on call becomes profitable, say pays 2X or something like that, I bet new urgent issues would be engineered so that they're taken care of while on call time.

Re: Developer on Call

#144

Post by sebringj »

There is a huge difference in the way you write code when you have to support your own code around the clock and it really changes your perspective as a developer as before this I would work for a company with a team of testers and fire and forget code that is deployed and let someone else worry about it later. I now feel bad that I thought this way. After writing my own two products from scratch with ongoing support/subscriptions that ecommerce stores depend on to do transactions my eyes have been opened. It is critical things go right or the client gets very pissed off and loses sales. When its your personal time that gets interrupted from your own work, you simply start to cut the bullshit out of the equation. You end up seeing more code and clever code as a bad thing and tend to simplify everything so it's both easy to understand , reliable, quick to fix, along with ensuring its easily testable in a sandbox env and has great monitoring for uptime and redundancy and can be quickly deployed as a hotfix. My point being is, you do get a better 360 picture when you have to care more deeply because you will effectively make your life a living hell if you don't.

Re: Developer on Call

#145

Post by thanatropism »

ken wrote: post #115

There's a lot of words, in the article and the comments, about being compensated for on-call time. The software field seems very anti-union, for reasons that I don't entirely understand. Protecting your time is one feature that unions offer. Want to be paid for every hour you're on call? Get the union to put it in their rules for employers. The alternative we have now is that each developer is responsible for negotia…

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.)

Re: Developer on Call

#146

Post by mamcx »

WrtCdEvrydy wrote: post #92
wink wrote: post #89

Earlier quoted context omitted.

This sounds so nice in theory. All those pesky developers refusing to fix their horrible code. While in reality at least in my experience the developer would be very much happy to fix the code, it's just that you don't get any time to do that. It's only new features and new products.

Bug fixes don't sell your software unless it's a heavy customer product.

Not..exactly. Maybe is only a local thing in my country, but you will surprise what is called "features" and "bugs" from non-developers. (features: Everything including bugs bugs: Everything that is annoy and not allow to continue... but sometimes also called features)

I mean, are intermixed ALL the time. I literally this week was working in a feature (that was, in reality, a bug) meanwhile only talking to my partner that give support and see him ignoring a red modal windows with a error message (oh, that is not a bug, it allow to work(???)).

You can turn the bugs and anti-features of the competence in your own selling points (our product sync the offline database without the need to have a operator that restart the service and click on "sync" in the dashboard!!!) and stuff like that...

Re: Developer on Call

#148

Post by notyourday »

tristor wrote: post #128
wink wrote: post #89

Earlier quoted context omitted.

This sounds so nice in theory. All those pesky developers refusing to fix their horrible code. While in reality at least in my experience the developer would be very much happy to fix the code, it's just that you don't get any time to do that. It's only new features and new products.

It's actually more complex than that, even. I'm speaking from being an engineer for some time (~13 years) and a product manager now. The issue is that Customer A, B, C, D, and E want Feature A to behave in one way, and Customer N, M, O, P, Q, R, S, T, U, V want Feature A to behave in another way, and those two ways are mutually exclusive insofar as it can't merely be configurable, since Features B-F rely on Feature A…

> How do you ensure that your business doesn't get coopted by BoM (Buckets of Money) to basically be a contract development house and eventual acquisition target by your largest enterprise customer while ignoring/harming all your other customers who were earlier adopters?

You don't. You remember who pays your salaries ( i.e. it is the customers who pay you buckets of money, not Joe Random User that bitches about paying $5/mo ) and you prioritize the features/requests of the Bucket Of Money customers.

If you have a real product, then the requests of Bucket of Money customers would closely match the requests of other customers and your product will grow gangbusters ( see AWS/Salesforce/Dropbox ). If they do not, then it is quite possible that in reality you are nothing else but the custom dev shop for one or two bucket of money customers and you dont have a real product.

Re: Developer on Call

#149

Post by notyourday »

brobdingnagians wrote: post #138
jpalomaki wrote: post #71

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'…

I agree (conservatively). I don't like taking customer calls, and doing it a lot seems like it could waste valuable time, but I think it is important for engineers to at least occasionally interact with customers so that they understand what this darn piece of software is _actually_ supposed to do. We can sometimes get caught up in feeling like we know what it is supposed to do and implement it, only to find out (or…

I subscribe to Tom Siebel's view of taking customers calls -- unfortunately I have to paraphrase it as I don't remember the exact quote:

>

Re: Developer on Call

#150

Post by logfromblammo »

msla wrote: post #140
ken wrote: post #115

There's a lot of words, in the article and the comments, about being compensated for on-call time. The software field seems very anti-union, for reasons that I don't entirely understand. Protecting your time is one feature that unions offer. Want to be paid for every hour you're on call? Get the union to put it in their rules for employers. The alternative we have now is that each developer is responsible for negotia…

> The software field seems very anti-union, for reasons that I don't entirely understand. A few ideas, not in any specific order: It would kill start-ups, wouldn't it? If you have to obey union rules, you can't have one person who's the DBA and the project lead and the primary programmer and and and because those are all different jobs and require different union employees. Great if you're Microsoft and can afford it…

Only union members, and employers with significant numbers of union employees, are bound to obey union rules. The union negotiates their contracts.

If the union so desires, it could state that no union member may do all the aforementioned jobs at once unless they have at minimum an indelible 5% ownership stake in the company; bear the title of Chief Technical Officer; report only to the CEO, COO, or directly to the board; and have no employee subordinates. It sets the expectations for any company wanting to do that. Any company wishing to ignore it can still hire non-union employees, but the union employees are instructed to embargo any company that does not meet the standards for employment.

Hobby projects are irrelevant. There is no employer. Unions are a cartel for paid labor by employees, where there may be a power imbalance between owners, managers, and laborers. In a hobby project, the worker is always the owner.

FOSS is likely unaffected. Any employer that has FOSS projects is already reined in by the threat of forks. In the extreme case, the union could manage their own forks of FOSS projects, and refuse to merge changes that don't meet union criteria.

It isn't about whether anyone is paid, but about whether everyone is following the cartel rules.

Post reply on HN