9 ms·

It is true that the effective developer environment sounds a bit too good to be true. Also, there seems to be a contradiction in it. We get an answer from the o

by cjfd 6y ago

It is true that the effective developer environment sounds a bit too good to be true. Also, there seems to be a contradiction in it. We get an answer from the other team very quickly but on the other hand there are no interruptions. It seems a bit hard for both of these things to be true at the same time. On the other hand one does have to notice that one can either be moving towards the effective developer environment or towards the ineffective one. It is a very important question in which of these two directions the actions of the team are headed. E.g., if the nightly build fails is somebody doing something about it or not?

Ma8ee 6y ago
And how do you resolve this contradiction? Teach your employees that if you don’t want to be interrupted you better write good documentation. And have one dedicated team member each day responsible for supporting other teams. I think both of those are mentioned in the article, but it was a little a while since I read it.
- leghifla 6y ago
  "Teach your employees that if you don’t want to be interrupted you better write good documentation." And reward them for doing it. If your company do "360 degree" evaluations where your peers praise you for your quick answers to their questions, you are effectively incentivised to NOT document and instead be interrupted...
  - pferde 6y ago
    One does not preclude the other. Your quick answers can come in form of sending them links to the relevant parts of the documentation you wrote earlier. And if their question is not something that can be answered that way, you can improve your documentation so that next time the question is asked, you do not have that problem.
- cjfd 6y ago
  I would be inclined to say that interruptions to help your colleagues should be accepted. Writing good documentation is actually hard and if you not willing to invest the time to do it well and to make sure the documentation can be found when needed you had better not write documentation at all.
- brokenkebab 6y ago
  It's not something to be taught. For majority of devs an average working day is too short to do everything they theoretically should. So they make choices based on feedback/motivation which rarely favors writing good docs over writing more code. On top of that many good devs are simply unable to write comprehensible documentation because its very different kind of skills, or just because English is not their native.
ownagefool 6y ago
The article specifically suggests there's a dedicated support developer, which means you're sacrficing one member of your squad (per week) for the productivity of the rest of them. We can debate whether the idea is good or bad, but it's not pretending that its magic. On the wider article, I think the litrature is a poor subsitutde for reality. And honestly I question whether a lot of these agile consultancies actually have the required experience to teach us how to be highly effective as opposed to what we can learn directly from orginsations that are highly effective, but I do believe they have enough experience to tell us that effective development teams invest in development tooling, dev focused user experience, and a dev focused culture. Who and how you'll build this is left as an excercise for the reader, which is unfortunte because we now have a legion of consultants who've never produced a line of code making a career telling us "culture is hard" and then forcing us into scaled agile frameworks and tooling that are contradictory to the ethos. Doesn't mean the underlying point is bad though. Engineering teams need some time to work on developer experience instead of just being feature factories; bigger org can hire teams dedicated to helping with this. This is a good thing, but many orgs fail at understanding and allowing the investment.
- ivandenysov 6y ago
  In my current company we have a daily devops and dev duty. With current dev team size each gets around 3 duties per year. Dev duty takes care of rollouts, crises, rollbacks, keeping an eye on performance and error monitoring. It's a great approach that works for us and allows every developer to get familiar with rollout process eventually, but I don't know if there are downsides for smaller teams or for projects that are split into several independent services instead of one monolith.
  - thargor 6y ago
    How large is your team? 3 duties per year sounds incredibly low.
- brobdingnagians 6y ago
  I'm torn about this article, I love the part about feedback loops and optimizing the parts of your day where you are in a tight loop for a long time; but for most of the article it seems he is _almost_ saying something profound, but there is too much clutter and buzzwords around it. I know these abstract consultancies have a use, but they seem to target what managers and executives _want_ to hear instead of the truth. e.g.: "The promises that were made to executive leadership about the latest technology are not coming to fruition quickly enough." It feels like he then proceeds to talk about how management can get the developers "organized" to make sure they get the job done. Having a developer doing support for the day kinda sorta seems like a nice idea until you realize that "Isn't that what the manager is supposed to do? Understand his team and get what they need/negotiate with other teams so that they can just get their work done?" It's kinda like he's telling managers how to outsource their work to someone else. Pass the buck and live in a fairyland. I know people who idolize Thought Works, Martin Fowler, Uncle Bob, and others in the "consulting set"-- but it seems like they fill a particular niche, and it isn't the phenomenal tech experts, it is more of the "how management views tech from an academic level and how we can get these interchangeable programmer cogs to get our project done w/ the least amount of effort". They rarely give hard advice, it is more of soft exposure to "new tech" and "here's something that works for some people, you might be that person". "We'd love to sell you on new tech that will be a silver bullet for all your problems" In any case, I learned some interesting stuff from the article, and I do think it is a valuable read.

by cjfd 6y ago

Ma8ee 6y ago

And how do you resolve this contradiction? Teach your employees that if you don’t want to be interrupted you better write good documentation. And have one dedicated team member each day responsible for supporting other teams. I think both of those are mentioned in the article, but it was a little a while since I read it.

leghifla 6y ago
"Teach your employees that if you don’t want to be interrupted you better write good documentation." And reward them for doing it. If your company do "360 degree" evaluations where your peers praise you for your quick answers to their questions, you are effectively incentivised to NOT document and instead be interrupted...
- pferde 6y ago
  One does not preclude the other. Your quick answers can come in form of sending them links to the relevant parts of the documentation you wrote earlier. And if their question is not something that can be answered that way, you can improve your documentation so that next time the question is asked, you do not have that problem.
cjfd 6y ago
I would be inclined to say that interruptions to help your colleagues should be accepted. Writing good documentation is actually hard and if you not willing to invest the time to do it well and to make sure the documentation can be found when needed you had better not write documentation at all.
brokenkebab 6y ago
It's not something to be taught. For majority of devs an average working day is too short to do everything they theoretically should. So they make choices based on feedback/motivation which rarely favors writing good docs over writing more code. On top of that many good devs are simply unable to write comprehensible documentation because its very different kind of skills, or just because English is not their native.

ownagefool 6y ago

The article specifically suggests there's a dedicated support developer, which means you're sacrficing one member of your squad (per week) for the productivity of the rest of them. We can debate whether the idea is good or bad, but it's not pretending that its magic. On the wider article, I think the litrature is a poor subsitutde for reality. And honestly I question whether a lot of these agile consultancies actually have the required experience to teach us how to be highly effective as opposed to what we can learn directly from orginsations that are highly effective, but I do believe they have enough experience to tell us that effective development teams invest in development tooling, dev focused user experience, and a dev focused culture. Who and how you'll build this is left as an excercise for the reader, which is unfortunte because we now have a legion of consultants who've never produced a line of code making a career telling us "culture is hard" and then forcing us into scaled agile frameworks and tooling that are contradictory to the ethos. Doesn't mean the underlying point is bad though. Engineering teams need some time to work on developer experience instead of just being feature factories; bigger org can hire teams dedicated to helping with this. This is a good thing, but many orgs fail at understanding and allowing the investment.

ivandenysov 6y ago
In my current company we have a daily devops and dev duty. With current dev team size each gets around 3 duties per year. Dev duty takes care of rollouts, crises, rollbacks, keeping an eye on performance and error monitoring. It's a great approach that works for us and allows every developer to get familiar with rollout process eventually, but I don't know if there are downsides for smaller teams or for projects that are split into several independent services instead of one monolith.
- thargor 6y ago
  How large is your team? 3 duties per year sounds incredibly low.
brobdingnagians 6y ago
I'm torn about this article, I love the part about feedback loops and optimizing the parts of your day where you are in a tight loop for a long time; but for most of the article it seems he is _almost_ saying something profound, but there is too much clutter and buzzwords around it. I know these abstract consultancies have a use, but they seem to target what managers and executives _want_ to hear instead of the truth. e.g.: "The promises that were made to executive leadership about the latest technology are not coming to fruition quickly enough." It feels like he then proceeds to talk about how management can get the developers "organized" to make sure they get the job done. Having a developer doing support for the day kinda sorta seems like a nice idea until you realize that "Isn't that what the manager is supposed to do? Understand his team and get what they need/negotiate with other teams so that they can just get their work done?" It's kinda like he's telling managers how to outsource their work to someone else. Pass the buck and live in a fairyland. I know people who idolize Thought Works, Martin Fowler, Uncle Bob, and others in the "consulting set"-- but it seems like they fill a particular niche, and it isn't the phenomenal tech experts, it is more of the "how management views tech from an academic level and how we can get these interchangeable programmer cogs to get our project done w/ the least amount of effort". They rarely give hard advice, it is more of soft exposure to "new tech" and "here's something that works for some people, you might be that person". "We'd love to sell you on new tech that will be a silver bullet for all your problems" In any case, I learned some interesting stuff from the article, and I do think it is a valuable read.