Code and consulting

@bugsbane observed that I seem to be much happier when I’m deep in code.

It’s not as simple as that, and that’s worth exploring.

I’m more confident with code then with consulting. I’m in my element. If I were a fish, code would be water.

Consulting is still intimidating. I’m starting to be able to ask and answer the right questions, but there’s so much more to learn. And I can’tdon’t yet know how to write unit tests for an organizational process to make sure I’ve got things right. (Thanks for the reminder, Torsten!)

I could probably build a life with awesome code and do well. There is much to learn there too, and it’s a great way to make a scalable difference. I have many role models who show that this works.

But I’m curious about what better collaboration looks like, and what people and organizations could do if we experimented with better ways to work together. If I want to work towards that, consulting skills may be a big help.

There are lots of paths to this destination, and many possible journeys are worthwhile. I could focus on development and build apps, letting others focus on consulting. I could learn about consulting and work with people on implementation. I could switch between one or the other, or bring in something completely new.

But on a list of things that I would do if I had all the time, money, and energy I wanted, coding is there, and consulting isn’t. I enjoy learning about systems. I enjoy building tools. I enjoy hacking. I enjoy answering questions and giving people things that they can use to make their lives better. I know that consulting might be more generally useful skill, enabling me to make bigger changes, but coding lets me make a difference on my own, too. With consulting, you need the cooperation of many others. With code, you can learn more and make things happen almost at your convenience.

I’m so tempted to focus on coding, which I enjoy and which I do well, instead of investing the time in developing consulting skills, which seem a lot fuzzier and harder to learn. But consulting is worth a try, particularly if I can alternate it with projects that give me geek happiness.

  • @sachac In thinking about code and consulting, you might consider deductive and inductive modes.

    Deductive mode is similar to waterfall development, in that everything should be defined in advance, and there are no surprises. Consulting work, when structured, can follow this mode. The customer deliverables are specified, and satisfying expectations can be straightforward.

    Inductive mode is similar to iterative development, with modification of the direction and scope of work with learning. The more strategic consulting work tends to be inductive, because there wouldn’t be an engagement if the customer already knew the answer. It’s practical to specify the procedures/methods, but the end result can be an area of ambiguity.

    The higher value work tends to be in the inductive mode rather than the deductive mode. The deductive work can generally be formulated into a cookbook, which can lead either to automation or lower-skilled talent required for execution. Inductive work leads to theory-building.

    To be complete, there’s also an abductive mode, about which I wrote a paper some time ago.