Levels of Abstraction

I'm not slowing down. I'm shifting into low gear.

I used to attack problems with enthusiasm, butting in with a solution - often a good one - as soon as I recognised the situation, like an excited quiz contestant shouting "ooh, I know this one!".

Now I tend to wait for people to finish talking.. and then a bit longer, often enough to make them a little uncomfortable, although that's not my aim. When I reply it can be very slowly, as if I'm feeling out each word, even if the problem is simple.

It's because I've shifted in how I think about solutions.

If I was coding, it would be the difference between thinking "I need to send an email, easy, <? mail("someone@example.com"... ?>" and starting with a whiteboard sketch and class UserEventNotifier < UserNotifier. It's thinking at a higher level of abstraction, trying to solve not this problem but this class of problem.

Because I need to think about, and even discuss, which level is appropriate for each problem, I've defined them. M0 is no levels of abstraction; I'm solving the problem.

At M1, one level of abstraction, I'm building the systems that should have solved the problem. Working at this second level has become routine for me now. I think of it as my job; if I'm working at M0, it's because something has gone wrong and I need to clean up the mess, or we're short-handed.

At M2, I'm building the systems that will build the systems that will solve the problem. So, for example, I'm training the person that will build the systems, or working out new techniques that will improve the way we build systems across the company.

Presumably it's possible to go deeper. At M3 I suppose I'd be "building the systems that build the systems that build the systems that do the work". I haven't yet done that. Instead, I go sideways: at MA, I'm "determining whether the work should be done at all, inside the context of the company".

By way of example: Alex comes to me and says we're going to fail sprint 7 on project WYC. I'm thinking:

M0: Fix the problem: "Right, what exactly's not working, how long have we got until the demo, can I fix it? Meanwhile, has the client been told? Does this impact a hard deadline, or affect the project budget? Is the team OK, and will this impact on their morale?"

M1: Fix the system: "How did this failure occur? How do we change the way we're doing things so that (after we've cleaned up this one), we don't see this failure again?"

M2: Fix the system that should have fixed the system: "Alex has brought me this. Is it because a) he can't handle it, b) he can probably handle it but thinks he can't, or c) could handle it but feels like I should be involved? If it's A, is he right, and how should we alter our training systems in response? If it's B, is this a safe time to encourage him to try, and should I be merely supportive without addressing the substantive problem? If it's C, have I delegated this area incorrectly, or is this situation dangerous enough to justify a second set of eyes?"

(Often I'll be talking about M0 and M1 at the same time, but thinking privately about M2.)

MA: Check that it's the right problem to solve: "I've been concerned that WYC is a poor fit for our company values and our development process. This could be another example. Perhaps we should reframe the situation as 'how should we eventually exit with honour?'"

So, if you ask me a simple question and I take a while to answer, that's why.