Making shit work is everyone's job

This is because I'm very much the guy that "makes shit work" (comes with being a jack-of-all-trades kind of hacker, or maybe just with giving a damn about my work). "Hey, remember how we've set up that postfix-to-python email bot three years ago?" - I do. "Hey, the finance data import on the MIS is broken" - Ok, let me have a look .. there, I fixed it. This I don't mind. In fact I quite enjoy it.

However, in turn I do expect something back. The first and obvious thing I expect is that you don't mind that the software project I'm working on is going to be a few days delayed because I spent time digging in the bowels of some open source tool or staring at Wireshark. The other, and maybe not so obvious thing I expect is that you a) listen to my suggestions and b) don't get in the way of me working efficiently. What this means is that if I suggest you should go with solution A and not solution B (which your pricey external consultant suggested) and I take the time to show you several good reasons (not my job either, but comes with giving a damn) why solution A will work reliably and solution B will come biting you in the ass later, then you at least hear me out.

And then when solution B comes biting you in the ass and you come to me to work it out, at least give me the means to sort it out properly instead of forcing me to follow your pricey consultant down the slippery slope of exceedingly horrible workarounds, all of which I have to handhold him through and waste massive amounts of time because he can't use email and needs to do schedule a conference call in several days time with subjects such as "confirm the VPN is working".

Because once I'm sufficiently annoyed, I will gladly tell your consultant that something "isn't my job" just so he stops bothering me. And then I write my notice, because I don't like working like this.

I think they're completely missing the point of those comments, but regardless of that, I think there's a bigger point to be made here.

Over the years, I've noticed there are two types of developers: the ones who only want to work on interesting code/new projects/etc, and the ones who get shit done.

The first guy does NOT want to do any maintenance, only wants to work on new projects so he can get things "his own way", throws a hissy fit or refuses to do it outright when he has to dig through tons of horrible legacy code, etc.

And the second guy just gets shit done. No matter what it is, he understands that it just NEEDS to be done, and does it. He will not take it silently - sometimes, just like the first guy, he will be loud and obnoxious in voicing his opinion that this code totally sucks, what moron wrote this, and we should totally rewrite it, etc.. but then he sits down, rolls up his sleeves and does it (and then works on re-writing it in the right way, if there's time).

The first guy might be a much better programmer than the second. He will pass a technical interview with flying colors, he's usually up to date on all the latest technology, he's good and he knows it.

But after a few years of doing this, I will hire the second guy EVERY TIME.

Sometimes the best thing you can do for yourself is deflect the person away from you and towards the code's owner just so you can get your own work done.

Sincerely, jaded (nearly ex) large company employee

Of course, you should tell others to behave like that.

[1] http://www.ribbonfarm.com/2009/10/07/the-gervais-principle-o...

Sometimes people overanalyze generalized statements to hear themselves talk. This is just how 37s makes "making shit work" everyone's job to build a great product. Apple and Fb do it their own way. And so forth.

The key ingredient is empowerment (and recruiting). Employees must be trusted to own the product and customer experience without micro-managers getting in the way by shuffling papers and responsibilities.

I'm truly grateful when others step in to fix something I broke, but I then need to learn from them so I don't do it again. I was working with a team recently and kept breaking some of their git process with my check-ins. Code worked, but I was doing something that went against their flow. Took me a while to sort it out, and I felt bad because it was costing one of the other guys time. I finally grokked what he was asking for, and I've caused much less downtime.

His attitude initially was "hey, that's no sweat - I can fix this up". That started wearing thin by the 4th mistake, and I could tell. I felt bad, but eventually got to the point where I'm not slowing them down anymore.

I've been on teams where other people continually write crap code - never bothering to even check if it works - then I have the bad attitude for not fixing it: not being a "team player", etc. That's gotta work both ways.

So, yeah, "not my job" isn't a great attitude. You do have to ask tho, when you see that attitude, how much of it is endemic to that person, and how much of it is caused by something more systemic in the organization?

I disagree with:

“Oh, that’s not my job,” is the sound of doom. Maybe not imminent doom, but doom indeed.

because I have seen multinational companies [revenue $25B, $43B], where culture and many employee's attitude was “Oh, that’s not my job,”. These companies Net Income is billions of USD. Not sure I see how they are doomed. I would be glad to be doomed with $1B of annual income [after taxes].

I think it is important be realistic and understand that instilling such [make shit work] attitude is only possible in a small start-up or bootstrapped company, and only when most of the senior people posses such attitude.

As for the bigCo:

- It is statistically not possible to have A players with can do/will do attitude, when the company size grows above certain threshold. So eventually you pick-up some B/C/D people, who would start playing games.

- I have tried several times to put together a small team of doers within bigCo - it never works in the end because overall culture overpowers and draines you.

- My advice for a doer would be simple - either [1] calm down to avoid burnout [inevitable when everybody is dumping on you] or [2] run and find a place where your attitude and strengths will be appreciated, or even better, find a place and run....

The janitor gets to explain why something went wrong. Senior people do not. “When you’re the janitor,” Jobs has repeatedly told incoming VPs, “reasons matter.” He continues: “Somewhere between the janitor and the CEO, reasons stop mattering.” That “Rubicon,” he has said, “is crossed when you become a VP.

http://onproductmanagement.net/2011/05/12/leaders-dont-make-...

This case sets up a more generalizable rule, which is that if you're expected to make shit work, you should be compensated for it. When you're in a startup, making all the shit is everyone's job description, and it's part of your paycheck, too, in the form of equity.

I saw it as a personal insult if anybody I knew took any technical problems to anybody other than me. The problem with this is that you will often end up out of your depth flailing around in the waters of diminishing returns.

I am now a little older and wiser. For example, recently I was asked by someone if I could take a look at their Exchange server problem after I was done fixing something else. Of course the Exchange Server had not been configured by me but rather by a 3rd party consultant but they assumed I would be able to fix the issue quicker and cheaper.

Now I have a reasonable grasp of email (well I wrote a basic POP3 server in Java as a college project). But I have never used Exchange before or taken any courses on it. And I had no understanding of this particular Exchange setup. I could probably have fixed the issue after a bunch of RTFM, but would it have taken me 10 minutes? 10 hours? 10 days? I have literally no idea.

There is also the risk of bumbling into doing something that seemed right but would have screwed something up and had the guy who originally set it up badmouth me.

In the end, I just did some basic diagnostics on the users computers looking at mail headers etc in outlook when this was fruitless I offered to call their 3rd party consultant and describe the issue to them as I saw it but insisted I could not do anything further than that.

Would someone diagram "shit work" for me?

Is it noun verb or adjective noun?

There's so many parts to this that they actually need unpacking.

Someone discovers a problem... are they responsible for it?

Someone can't do an aspect of their work... how hard have they tried before seeking help? How busy is everyone else?

There's five things broken, is the new one higher priority than the other four?

You can tell when the situation's right: several people volunteer to help, one steps up, responsibility is shared. Likewise, when it's wrong, there's that awkward... silence...

I'm glad to read even a short post about this. My feeling is that people are mistaken if they think they can give away responsibility for something. Someone must choose to take it from you, and in all cases you share responsibility for getting it resolved.

It's what people say when they want to save face and not be labelled as someone who "can't do it".

It's a defense mechanism.

I sure as hell don´t wanna work there.

a. management releases shit as-is instead of using it as a temporary solution and dedicating resources to finding a better permanent solution

b. other developers hit me over the head with their pedantic view of how it should have been implemented, which would probably thrown the project months or even a year off-schedule

It's a thankless job.