Live data from Hacker News

The Developer is Dead, Long Live the Developer

paperplanes.de

11–20 of 32 posts

Re: The Developer is Dead, Long Live the Developer

#11
I argue that the shared responsibility mentality is distracting and diminishes the power of an individual. It's hard enough being a good programmer let alone one that also knows how to configure networks, firewalls, and operating systems; one who knows how to manage security policies, LDAP organization charts and ACLs, etc. I still believe that the jack-of-all-trades is a useful individual but I don't believe an entire organization should be formed around their ideals.

As in all things in life -- the truth is somewhere in the middle. If you build significantly sophisticated systems you will need specialists at some point. I don't recommend wasting their talents on getting reamed out for forgetting to configure the firewall properly.

Re: The Developer is Dead, Long Live the Developer

#12
This reminds me of going back towards a 90s job title trend - the webmaster. While that applied very much for small Geocities sites, there seems to be an awful lot of overlap and even business alignment toward minimizing operations staff / budget such that today's so-called devops engineers would really have been the webmasters then and in SaaS shops we're just a team of webmasters that have deeper specialization / interest in specific areas.

Regardless, this pretty much only applies for SaaS shops I'd say. There's still software delivered the old way that's viable.

Re: The Developer is Dead, Long Live the Developer

#13

I argue that the shared responsibility mentality is distracting and diminishes the power of an individual. It's hard enough being a good programmer let alone one that also knows how to configure networks, firewalls, and operating systems; one who knows how to manage security policies, LDAP organization charts and ACLs, etc. I still believe that the jack-of-all-trades is a useful individual but I don't believe an enti…

I don't think that's what the author is arguing for. More like, "You build it, you run it" (quote via article). Instead of handing your code off to someone else to be 100% responsible for testing, for release, for production support, the author argues that it is better to have developers share responsibility in those roles. It's very similar to what I'm doing now.

We don't hand off code to be installed, we give a release plan, an installation plan, and the code. We are on call for first runs, and there's always a subject matter expert developer on call to support overnight issues if the support team needs help. If you have this responsibility, you write more responsible code. If I may support something overnight, I'm not going to unthoughtfully make it hard to support. We share testing and documentation responsibility as well (although documentation is an issue), so again testers and support are doing their job in a vacuum because they don't have the developer's insight to the program. In fact, devs do most of the testing. It's not always easy to write test cases for a system you didn't write or design. I've kind of always thought that it's common sense to support your own product in test/production as needed (though not the first point of contact). You wrote it, you're the expert.

Reading this article surprised me because I thought it was the same everywhere. Having no responsibility for testing or prod seems like asking for bad code. If you're just writing code, you're not going to focus on what it's going to be like to support it, install it, maintain it. You'll have other, more concrete (to you) things to focus on. Coding standards may become more important. But are standards really as effective if they're not informed by / don't care about responsibility for a production product?

Re: The Developer is Dead, Long Live the Developer

#14
post #3

> Putting developers in charge of not just building an app, but also running it in production, benefits everyone in the company, and it benefits the developer too. How do companies which do this keep the support workload of developers low enough so that they have time for development? It's a great idea, because as the linked interview with Wener Vogels proposes, it creates a developer that has more frequent contact w…

The concept of "everyone on support" is practiced in a lot of orgs, with varying implmentations (e.g. "one whole day a month", "one whole week per quarter", "one week of half days per quarter"). What works for your company depends a lot on it's current workflows and workload, how long support cases tend to last for. Most mentions of it refer to his post = http://signalvnoise.com/posts/3676-everyone-on-support

Re: The Developer is Dead, Long Live the Developer

#15
Elephants in the room: unfunded mandates, disparate equity, control issues, and deadlines.

Ideally, people should support their own work. If I build something and have complete ownership of it, I'll make sure it runs. If I'm the one who's getting the money and career progress, and I'm picking the deadlines, I'll be the "3:00 am guy". It seems fair that it should be that way.

On the other hand, if I'm asked to build someone else's idea, to their deadlines, making technical compromises that I wouldn't choose, then I'm not going to be the "3:00 am guy" for shots someone else called. Fuck that shit, life's too short. If you want that from me, either pay a consulting fee ($250+ per hour) or give me serious equity (like, founder levels). Otherwise, That's Not My Job.

Salary jobs are for the stability of pay and work (i.e. not being the 3:00am Guy) and for career advancement (resume, respected titles, networking). That's what I'm paying for when I accept a salary 1/10 of what I'm worth to the business. If I'm expected to take on extra duties that don't advance my career, and not getting that stability, then I'm not getting what I paid for.

I'll gladly take the negatives of ownership if I get to partake in the positives (autonomy, self-direction, participation in the reward) but expecting me to take only the first is just unreasonable.

Re: The Developer is Dead, Long Live the Developer

#16

The developers should know how to do ops. And vice versa. We are moving into weird heterogeneous bugs territory. A lot of stuff that has wasted my time last year was caused by interaction of technology stacks and not by pure logical errors. Or error localized in even one package. I had problem with premature socket close on the response with just the wrong setup for all of nginx, haproxy, slim and php 5.4 ... lets pu…

The ops people you work with are also developers? That sounds great but has never been the case at anywhere I've been.

Re: The Developer is Dead, Long Live the Developer

#17
In my experience, the teams that run the best are full of generalizing specialists. So you have three people that are quite handy with the DB: One is the best of the lot, and is mostly doing DB work. The others are good at it, but they bring unique strengths in other areas. In the same way, you have a guy that is pretty strong at Unix administration, a language lawyer, some people that are big into UIs and such.

So while people will probably dedicate 80% of a week to a given kind of task, they can, and do, play multiple roles, depending on how much their specific expertise is needed that week.

For instance, I am the number one choice on UIs, but I also play support managing Postgres, because I did a whole lot of that in a past life, and we don't need a full time DBA. I am also leveling up in our scheduling system, all Akka actors.

At my previous job, the team had all the Database experience it needed, but domain knowledge was weak, so I spent much of my work working with users trying to figure out what they needed, and why they were unhappy with the product. They hired me for my UI strength, but reality said that I would be more useful doing customer facing activities half the time, so I did.

Re: The Developer is Dead, Long Live the Developer

#18
I think I'm a bit skeptical of how different the responsibilities of a 'DevOps' are different from a traditional 'Developer' in terms of actual complexity. The whole discussion seems to reduce technological change to just a little tiny part of this 'transition' to DevOps. How can you even develop a web SaaS application without having a basic knowledge of sysadmin/networking/IT/etc? In my opinion technology changed and development methodologies followed. I wish the author proposed an alternative to status quo [that would resemble the past a bit more]. Can anyone? Of course adopting PaaS and especially BaaS solutions can change it, but again, that would be a technological change rather than just a methodology thing.

Re: The Developer is Dead, Long Live the Developer

#19

The developers should know how to do ops. And vice versa. We are moving into weird heterogeneous bugs territory. A lot of stuff that has wasted my time last year was caused by interaction of technology stacks and not by pure logical errors. Or error localized in even one package. I had problem with premature socket close on the response with just the wrong setup for all of nginx, haproxy, slim and php 5.4 ... lets pu…

Whatever part of dev/ops that applies to me personally is very much tied up in 'full-stack' debugging of intermittent performance problems and heisenbugs.

I rely on the ops guys to keep vanilla installs steady and to keep everything patched, but there's very little way that they can get insight into application problems (especially in the framework du jour) that express themselves at some other location in the stack. I just have to know the whole thing.

Re: The Developer is Dead, Long Live the Developer

#20
I have never been in a shop where as a developer I was isolated from quality assurance or production. Fixing production issues was part of the job and insuring the fixes and original code got through QA was there too.

However I have also seen this branded as "soft skills". Something that seems to be yet another way to excuse many people for their lack of skills and reward them for doing other stuff. I have seen it used to keep really bad developers, if not reward them. It also tends to be a favorite term of those who cannot manage their team properly.

Post reply on HN