The Developer is Dead, Long Live the Developer
paperplanes.de
The Developer is Dead, Long Live the Developer
1–10 of 32 posts
Re: The Developer is Dead, Long Live the Developer
#2Had been looking for the source of that Werner quote for a while. Thanks Mathias!
Re: The Developer is Dead, Long Live the Developer
#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 with customers. I suppose eventually you have to shift resources around to start other projects, but then who supports what they're leaving? Even in large teams, eventually expertise will dwindle until you're adding new people to support an existing system.
Re: The Developer is Dead, Long Live the Developer
#4> 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…
It's about striking the right balance.
I don't really agree with the original totem-pole idea that devs can do anything QAs and ops can do. While it may be true that a good dev is capable of muddling their way through any challenge because they know how to get around the numerous blocks thrown up by technology, there are definite skills to QA and Ops that developers may be lacking and which will lead to the dev being a poor substitute.
That said, I think devs have skills which are applicable anywhere in an organization. This goes back to the virtue of a programmer being laziness. Being able to see how to build systems and automate things is something that is potentially useful everywhere. In the cases of ops and product support, there is an especially large amount of value from having devs poking their head in from time to time to pick off easy targets for improved automation, reporting, logging, or what-have-you.
Re: The Developer is Dead, Long Live the Developer
#5"X is dead, long live Y" is dead, long live original headlines.
Re: The Developer is Dead, Long Live the Developer
#6> What really matters is the willingness to change, to learn a new stack when necessary.
You've hit the nail on the head there !
Re: The Developer is Dead, Long Live the Developer
#7The 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 pure ops or pure dev figure that out.
Re: The Developer is Dead, Long Live the Developer
#8> 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…
> How do companies which do this keep the support workload
> of developers low enough so that they have time for
> development?
Of course, that's distinct from tier-1 customer support. "Devops" doesn't normally encompass client interaction.
Re: The Developer is Dead, Long Live the Developer
#9I read both articles and felt they both made good points.
It is in a company's (and the industry's) best interest to pair down well-paid developers and open up more entry-level positions, however, it's in the consumer's best interest for developers to maintain high accountability and "closeness" to the product.
I don't see these approaches as mutually exclusive I see how full stack development and silos can both exist in the same environment like if the Dentist in the counterpoint article's analogy takes over the hygienist's role when the hygienist is out on vacation.
Re: The Developer is Dead, Long Live the Developer
#10> 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…
It's about striking the right balance. I don't really agree with the original totem-pole idea that devs can do anything QAs and ops can do. While it may be true that a good dev is capable of muddling their way through any challenge because they know how to get around the numerous blocks thrown up by technology, there are definite skills to QA and Ops that developers may be lacking and which will lead to the dev being…
It's about striking the right balance.
Yes. My company has tried for a good many years to keep product development partitioned from operations. We build stuff, through it over the wall, and let the ops team deal with it. Certainly, we give support where necessary, but it tends to be grudgingly given, and we never actually track time spend doing that support. I've been pushing, along with several other developers, that we at least need some sort of rotating product support team so we can work with ops to resolve problems in the field without disrupting our own timelines. We've moving in the right direction, but there's a lot of inertia to overcome.