Mocks are Bad, Layers are Bad

In which I argue that mocks are a code smell, and layers lead to increased coupling:

Mocks are Bad, Layers are Bad (in ACCU‘s Overload Journal issue 127)

I also suggest some ways to avoid both mocks and layers, including Classical TDD, Selfish Object, Refactor to Functional and, of course, the Unix Philosophy. I work through a code example to demonstrate some of these things.

I also suggest that frameworks and inheritance hierarchies are bad, but the title was getting too long already.

You can also get the PDF of Overload 127.

How to ask technical questions in person

In a healthy team performing a technical task, there will be a lot of questions. Those questions will sometimes be asked by those with less technical knowledge, but (in a healthy team) there will be plenty of questions going back the other way too. Questions that come up in the normal course of your work are the main way knowledge is going to be transferred amongst your team members. They are to be encouraged, and you should never feel like a nuisance, or a technical wimp, because you’re asking them.

It’s easy to imagine, when you’re asking someone a question, that whether you get a good answer depends mainly on the person you’re asking.

In fact, an awful lot depends on you.

To get a good answer to a question, you need to prepare, to manage the Zone, and above all, to make the person you are asking feel clever.

What follows are some tips on how to ask a technical person a technical question when you’re in the same room as them. Some of them may also apply to asking on the phone, or even via instant messaging.

1. Prepare

You’re about to ask someone a question.

Breathe.

Think about what you are hoping to find out. This might sound obvious, but when you’re in the thick of trying to solve a problem, you may find you’re actually quite confused about what you’re doing. If you can, you want to avoid wasting the other person’s time with your confusion. Even worse, you might confuse them, and then they won’t feel clever.

This doesn’t need to take long – it may take half a second, but just let it cross your mind – what do I want to find out?

Think about the other person: what are they doing right now? Is it related? What do they know about? From what angle will they be approaching your question? Again, this will probably take almost no time at all, but it will help you ask your question well.

Now you need to zoom out. You are deep into a problem, so deep in fact that you’re stuck on a very specific part of it. This part of it is burning into your consciousness, obscuring the wider picture of what you’re doing. The person you’re asking is going to need that wider picture, so remind yourself what it is.

Once you’ve zoomed out, you will need to engage with the Zone.

2. Manage the Zone

The biggest problem you have when asking a technical person a technical question is that they may well be in the Zone. The Zone is a state of intense concentration in which you get really good work done (Rands elaborates in A Nerd in a Cave). The thing about the Zone is that it is difficult (sometimes even painful) to come out of.

If the person you’re asking is in the Zone, they will need to be coaxed out. When you start talking, even if they turn and look at you and say something encouraging, they are somewhere far away, solving a problem. Your problem is an unwelcome intrusion.

The first lesson about the Zone is: don’t say much at first.

When you start talking the other person doesn’t know whether you’re going to offer them a cup of tea, talk politics, or ask them how to implement quicksort. They haven’t disengaged at all from the problem they are working on. You need to let them know you are going to ask them a technical question, and start the painful process of pulling them out of their problem, and into yours.

Often the best thing to do is pick a single word or phrase that lets them know the general area you are talking about: for example, “import”, or “the C++ standard”, or “garbage collection”. If you say something like that, and watch their eyes, you can almost see the glaze of the Zone lifting.

If you can see they’re still elsewhere, give them a second – maybe they’ll even say something like, “I just want to finish this line.” If they do, let them – step back, take the pressure off – they will be much better able to answer you when the thing they need to remember is written down.

Now your job is to zoom them in on your problem, at their pace. It’s very important to watch and listen to the other person while you do this. Give them a problem area, and check they understood what you meant. Now give them closer context – maybe the directory you’re talking about, or the DLL you’re working on. Now tell them what class you’re editing, or what file.

As soon as you can see it’s needed, be quick to show them the exact thing you’re doing on your screen or paper – that way they can add any extra context they need themselves. Be very wary of drawing vague diagrams on paper or a whiteboard – they confuse more often than they enlighten – much better to show them the real code or document you are working on. They can handle it.

All the time, watch how they are reacting – are they remembering what you’re talking about, or completely in the dark? You may need to choose a different way into the problem. Remember, at this stage it’s your job to explain what you mean, not their job to guess.

If you do this well, they’re slightly in the Zone again, but this time focussed on your problem area. Now, and only now, hit them with your question. They’ll know exactly what you’re talking about, and feel really clever, especially if they know the answer.

There are a couple other things you need to know about the Zone. As we know, it can be painful to be pulled out of the Zone. That means that the person you’re talking to, no matter how nice they are, and how much they like you, may feel a distinct feeling of irritation when you start talking. To make matters worse, they were concentrating, so probably frowning already. Even if they don’t feel any irritation at all, they may look like they do. What can you do about this? Not a lot, except don’t take it personally – it’s normally momentary, and experienced technical people will recognise it’s a false feeling, almost a physical reaction, and put it to one side immediately.

Finally, understanding the Zone explains why preparation is so important. It’s very likely you are in the Zone yourself at the beginning of this process. You are submerged in a difficult problem, and quite possibly deeply irritated by your inability to solve it. To ask a question effectively (and thus get a good answer) you need to pull yourself out of the Zone and back into human interaction mode. This includes ensuring your annoyance is fully dissipated, or you’re going to say something you shouldn’t.

Throughout all this you need to make it your mission to make the other person feel clever.

3. Make them feel clever

Why would you want to make the person you’re asking feel clever?

I certainly don’t mean flatter them. If they’re deep in their work they don’t want you to waste their time telling them how good they are at something.

Think about it this way: how likely is it that you’ll get an answer if you’ve made them feel stupid? I don’t mean you won’t get an answer because they’re too annoyed with you to bother – I mean they’re feeling stupid because you’ve confused them, and so they have no idea what the answer is.

Bear in mind that it’s really easy to confuse someone. In your technical problem area there are thousands, or possibly even millions, of tiny micro-contexts that make sense within themselves, but sound like gibberish if you’re outside that context.

Turning to someone and saying something like, “How do I Frobnish the Pernicator?” without first reminding them that Pernicators get created every time the TunableBeadnest is RePreppered is very hard work for them: they need to ask you a series of questions before they can work out what you’re asking. Making them do this work makes them feel like they aren’t clever enough to hold the entire knowledge of your arena in the front of their mind simultaneously. Of course, no-one is able to do this, but everyone feels like they ought to be. Don’t make them feel stupid.

Even worse is to say something like, “How do I call this method?” In this case, even if they had total front-of-brain memory of the entire arena, they still couldn’t answer this question, without interrogating you about what you meant.

You goal should be that the first thing they have to say in the whole interaction is when they give you the answer, or at least ask a question that shows they have grasped what you’re asking, and makes them feel clever.

Of course, making them feel clever also makes them more inclined to talk to you next time you have a question, but that’s merely a side benefit. The real reason you want to make them feel clever is that when they feel like that, it means you have given them the information they need, in the order they want, with timing that works for them, so that they can give you a great answer.

Scalable Graph Coverage

If you’re interested in dealing with large directed graphs of dependent objects and want some tips on how to process them in a way that scales in terms of memory usage, you may be interested in the article I wrote for Overload, which is a journal of the ACCU (an organisation promoting “professionalism in programming”).

The article is Scalable Graph Coverage, or, in my original title, “Comparing scalable algorithms for walking all nodes of a dependency graph”.

It contains lots of code, written in C++, using BOOST Graph Library. The code demonstrates some of the algorithms that are available for choosing batches of nodes to be processed together to reduce the number of nodes that are loaded several times, and without running out of memory.