Hacker News Reader

Comment by cjfd | Hacker News Reader

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?

View on HN

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.

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.

How large is your team? 3 duties per year sounds incredibly low.

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.

Indeed.

The lack of hard advice is great for them because they're essentially never wrong but you'll also never fix the problem with the advice alone. Keeps the gravy train going; if they solved our problems with hard facts in blogs, we wouldn't need them.

That said, the advice itself is still pretty good if you have the chops to follow through, but I honestly don't think you can build the chops by hiring in the consultancy to tell you. In fact, it's actually a bad sign that you leadership both need obvious advice, and think they can enact change by hiring the consultancy.

The reality is, you'd probably have better results changing the leadership.

Asking for advice from a contractor is not bad.

Asking for leadership from a contractor is bad:

1. They don’t understand what you need or how to get it to you, but they sound like they do, and they look professional.

2. There are no great contracting options for something you can’t do yourself and that there aren’t requirements for.

Fixed contacts may start off looking good but they swap resources out and you end up incomplete or halfassed, overtime and maybe over-budget.

A renewable contract may blow really pretty smoke too and look like a high speed train, but that’s not what was needed, they never finish, or when it’s forced to completion, it’s incomplete or halfassed, overtime and over-budget.

If you don’t take care of your health on your own, you can’t expect a doctor to do that for you. Similarly, don’t expect a contractor to solve all of your team’s development problems, though some can give good advice or assistance.

Steps towards making yourself healthy may include exercise, eating better, adequate sleep, regular checkups, etc., while steps towards fixing your development team’s problems may include raising those to your leadership, own problems, foster trust, facilitate, and change your job if problems are not resolved.

Maybe.

Funnily enough I was a contractor providing leadership and helping orgs for the last 5 years. I did my best to varying degrees of success because the leadership themselves would either let you run with it or not. My 1 man band is very different from thoughtworks though.

Now I am leadership and it's way easier to just make decisions.

Sure, there’re exceptions.

But if you don’t understand the requirements, choose to pay someone to figure it out, and they finger-paint your business, you may have been better off without it.

Nothing sells better than crap. By that I mean literally nothing, like you could sell emptiness more feasibly.

Yeah, reasonble points.

To be fair, they’re selling to those executives. It’s unlikely that devs on the ground have the authority to sign off a large consultancy bill.

In my current team (and my previous one from another company) we have what we call "goalie" duties. Each week one engineer from the team is responsible for answering inquiries, not necessarily they have to know the answer but they are the ones to be interrupted and handle accordingly.

It works pretty well, our devs are capable of assessing urgency to either bring it up on Slack, wait for the next stand-up or call to arms if it's something critical.

It improves rapport with stakeholders and other teams; it improves morale, it's predictable who will be interrupted during the week, alleviating that from the rest of the engineers. And as a side-effect it helps to force knowledge sharing over time.

This is actually a great idea and something I'm likely to bring back to my own teams!

Isn't the typical responsibility of the manager or the team lead?

Inquire often is followed with more requests, if each developer serves as the weekly-speaker-of-the-team, will the external partner eventually figure out "John will do anything for us and Steve is mean"?

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.

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

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.

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.

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.

Reply on news.ycombinator.com