[davidgerard]

Yeah. I'm thinking of Joel Spolsky's 199/200 who are just the same bozos cycling through interviews until someone hires them by accident ...

"devops" is fighting words in our team. Damn, if I could get our devs who'd like "devops" on their CV to give a hoot about the "-ops" half of that buzzword ... when a dev shows awareness of ops issues with their shiny new thing, I make a point of mentioning their name positively to the dev manager. "X knows their stuff. Give them more good stuff."

[fsniper]

:) When devs are in the loop it always comes to "working in localhost" debate. I like to say developers are working or living in their isolated bubble. And whenever their code comes out of that bubble and reach the real world ops are on fire.

Always the ops guys are in fault.

I think every developer should be given sysadmin 101 and 102 lessons.

[davidgerard]

I'd just like to note here that the sysadmins know damn well when a dev tries to blame them for something the dev did ... and we NEVER. FORGET. So don't do that.

I'm not sure how to educate devs to think ops. Perhaps have their phone ring at 3am when stuff breaks? I think that would close the feedback loop nicely.

(Let me note again: I LOVE the devs who think operational issues, who think end-user issues - what customers are actually like - who think "developer of the whole thing from go to whoa" and not just "coder on my PC." As I'd hope we all do here.)

[devonkim]

As both a developer and admin, it's a little hard for me to not think across the aisle. However, I can think of developers that basically refused to think outside their solo - they tend to fit the type of person that really doesn't like to go too far outside the bounds of their workday tasks. Not saying that everyone is this way, but you wouldn't ask John Carmack to try to think about continuous integration and deployment stuff while he's stuck reading physics books and reading a bunch of papers, would you? Yes, good devs tend to have the curiosity and, more importantly, the concern to think beyond just their immediate day to day concerns of hyper focus and in-depth knowledge.

Sometimes you just need to hire more people or ask the rest of the team to accommodate someone that's that one random oddball. A management book I read mentioned Phil Knight talking about how the Bulls had room for one Dennis Rodman and only one, and made it clear that nobody else can pull the stunts he does without disrupting the harmony.

There's a huge difference between a dev that does something a bit out of ignorance and one out of indignance.

Some companies have developers spend some time in SRE (I believe Google practices this sometimes) so they can gain some insight, but it may not be the best idea for a lot of orgs. It's part of why most orgs that do some form of devops well tend to remove a lot of concerns off the table by using stuff like AWS. Meanwhile, silozation helps people maintain some sanity and focus in larger orgs where there's so much BS work on top of your technical duties.

Sometimes the culture is short-sighted and people are at odds with goals though. I've been penalized by managers and peers for not paying enough attention to my dev duties (which were pretty meh) when I was busy helping support and sales help bring in and retain $2 million in accounts that they later named me on calls as their informal engineering MVP.

But really, being aware of what other people care about in their job is a contentious issue that I mostly think boils down to personality and general ideas of teamwork.

[fsniper]

I'm sorry but 3am ringer is not working on my colleagues. They are still not giving a damn devs.

I don't remember how many times I had to debug instead of them or design better for them.

By the way, hacker news developer quality is really better than average or even better.

[davidgerard]

I'm sorry to hear that! Hmm. Have you tried electrodes? 415 volt three-phase can sometimes catch their attention.

(Ahhh, the BOFH stories ...)