Occasionally I moonlight as a python tutor for someone. Sometimes I show them the ins and outs of the language, and sometimes I talk to them about their current challenges in the workplace.

That's when I was reminded of a management phrase I absolutely loathe, "Don't bring me problems, bring me solutions".

If that saying was a person, I would encase their limbs in concrete1, and smash it open again with a lump hammer. Then I'd do other unspeakable things to the rest of it.

I hate that phrase.

To me, it's a management smell. When I hear that from a manager, I wonder if I'm in the right job.

I had a manager who said that. I was talking about problems I was having working with another member of the team, and lots of other people had them as well.

My manager told me he didn't care, and to sort it out. He then followed it up with the grand proclamation of "Don't bring me problems, bring me solutions".

To me, that's entirely the wrong approach to management; at least, it's the wrong approach to managing me.

When I got my first Forever Job2, I used to have a one-to-one with my manager every 2 weeks. That meeting was basically an opportunity for him to tell me what he needed from me, but at the end of it, he'd ask, "Is there anything I can do for you?". It was a ritual for him, he'd always end the meeting with that. Mostly, I'd just say, "No", and totter back to work, but it was a useful hook for when I did need something.

Once or twice, I did need a path cleared for me, in order to do my work, or to ask a favour, and that was the perfect opportunity to raise non-urgent issues.

And, with this manager, they got looked at.

When I was an intern, I had another good manager. If I had a problem, especially technical, he frequently restated, reframed, and decomposed my problem into chunks manageable enough for me to be getting on with. In other words, I went in with problems, and I came out with things to be getting on with. Now, in fairness, I was an intern, and I'm pretty sure that manager saw his role as being a mentor in that situation3.

These days, I work in an "agile" environment, and a Scrum Master is meant to be the person that clears the shit from a developer's way, and lets them get on with their work. That's pretty much what I think a line manager should be to their front-line staff. This is why I don't trust someone that will say, "Don't bring me problems, bring me solutions".

Maybe the phrase is meant to mean something else, but I take it to mean, "I don't give a shit about your problems, get me results".

That phrase betrays an attitude that the manager has no hand in the results. They're given a requirement that they relay to the team, and they expect results. They may have a hand in planning, or anything else, but that's as much as they're willing to enable their workers to get on with it.

Sometimes a problem is beyond the control of the developer.

Sometimes a problem is about resources, or politics, or a lack of information.

Personally, when I hear that phrase, all I think is, "Well, if I had a solution, I wouldn't have needed come to you".

In most industries, the rank-and-file workers are not unintelligent. Frequently, they know what's going on, and they know what is and isn't within their control.

Sure, it would be good for any employee to know what the ideal solution would look like. Actually, no. It would be good to know what the end-state would look like. Sometimes the end-state will be as simple as, "the impediment is not there any more", but they shouldn't have the solution immediately to hand. It's great if they do have the solution to hand and say, "I need access to this device, but I need written approval from you first", but they shouldn't have to have the solution if it's not readily available to them.

The manager may be able to instantly point to a known solution. But in most cases I expect there to be negotiation. I expect a conversation as we work out what needs to be done to remove my impediment. Sometimes the meeting itself is enough. That meeting will be curtailed if the initial response is, "Bring me solutions".

Sometimes that meeting involves figuring out what end-states are most achievable. "Will it work if we just can get this to happen?". Again, if The Phrase comes up, it just suggests a fundamental apathy, a complete and total lack of engagement.

Personally, when I heard my boss say that phrase, that's when I started looking for a new job.

Management is a tricky job, and I don't want to do it yet. But it involves making sure your team works smoothly. As a manager, you aren't directly delivering results, but you make sure your team has the best shot of doing so. That means doing the hard sums of figuring out what colleagues don't play well with others and giving individual work to them. It means making sure that you don't have a single point of failure in your team (aka increasing your bus factor). It means keeping morale to a level where all your employees don't want to quit all at the same time, which itself means resolving interpersonal conflicts, or at the very least keeping conflicting employees in opposite corners. It means sheltering your team from the shit flung from further up the ladder, and from people on the same rung of other ladders.

But, overall, it means keeping your team impediment-free, so they can do their fucking jobs.

Saying, "Don't bring me problems, bring me solutions" means you do not want to be part of that process.

If every employee gave you a solved problem, there'd be no justification for your job.

Obligatory footnotes )
So, this has been a mild rant in my head, and I feel like I need to articulate it somewhat.

Recently, I was out drinking with some developers, and I got talking about some pattern that some framework uses that another developer considered harmful1. To be honest, I didn't have a strong opinion on it, I just liked to use it on occasion when I was working with that framework a few years ago. However, the other developers argument against it is what I'll call an Appeal To Personality.

In this particular case, it went something like this, "I worked with the smartest programming guy ever, and he was really anal, and really obsessive, but he produced great quality code, and he said not to do X", with the implicit followup that I'm not going to claim I'm better than this guy I've not met, or otherwise challenge the authority of this Personality.

Similarly, when having a discussion about Agile, one of the developer said to another (who claimed Agile didn't work), "This was put together by some Very Smart People, and they found it worked. Who are you to argue with them?"

I have 3 words for this style of argument: Bull fucking shit.

My own personal take on this is simply that programming isn't a religion, there aren't the gods from on high, there aren't high priestess, priests or Great Rites that confer upon us the wisdom of the gods, and these great Personality Deities. Maybe it's just my own mental blocks, but I need a Reasontm to accept this. I need to understand why something is a bad idea.

Here's a list of things I know to be a bad idea:

  • Programming in really complicated Regular Expressions - I've done this before. I've had to debug some very complicated Regular Exression. As time went on, I spent less time fixing the broken big regex, and either reducing them to small ones in multiple phases, or just taking out the need for them altogether, because that was easier for me to debug

  • Similarly in python, I try not to use nested loop comprehensions. Yes, you can look smart and cool, but I don't do them. I can, but I won't because I've learned from regexes that just because you can do something is not a reason for doing it.

  • Operator overloading is cool, but unless the semantics fit what you're trying to do, you're just going to confuse yourself when you go back to it later

  • Don't write a one-liner just for the sake of writing a one-liner if you expect to rely on that code. If it fits more naturally in multiple lines, do that instead.2

It's not a whole load of stuff, really. They're just mistakes I made for myself, and that I've learned from. I learned a lot from mistakes I made. In fact, I'm pretty sure I've learned the most from mistakes I've made for myself.

Maybe it's a mental block that I can't accept wisdom from others without the memory of pain to back it up, or it's that I can't accept a good practice without a similarly good reason, but an appeal to personality is just not a good enough reason for me.

That said, there are Personalities that I will listen to. I have a few colleagues like that. One even gave a presentation on refactoring. He worked through an example from a book he was very fond of. So, you might be asking, how does this differ from the "Appeal to Personality" that I've just been wittering on about?

Well, in this guy's case, he didn't just rework an example application, following what was in the book, but he took the time to explain what he was doing. Moreover, he wasn't just explaining what was in the book, he was explaining his interpretation of what he'd learned in the book. He'd learned something, distilled it, and shared this knowledge with us. His personality lent a lot to the process, but he wasn't the reason. He didn't say, "I'm pulling out the code and putting it here Because I Say So", or saying, "Whenever you see this, this is a Code Smell and it must be moved", but took the time to explain why he was doing it. These reasons mean a lot.

I'd much rather hear someone who has lived through some pain share tales and stories of their pain, and reasons why they do what they do. I'd much rather have a good reason to do something, and because I'm told to by a Personality is not it. I don't care if Denis Ritchie said it, Linus Torvalds, or some super-smart guy in the back-ass of nowhere said it. I want good reasons, not the celebrity.

Herein lie the footnotes )



September 2015



RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 21st, 2017 03:27 am
Powered by Dreamwidth Studios