Can we versus should we

I made a conscious choice to use the phrase “should we…” when asking a question about technical implications rather than “can we…”. The difference is subtle and very significant.

There is a lot of self-pride in being able to solve the problem in the engineering community. Using probably too hasty a generalization, culturally its a bundle of people who love to solve puzzles. As we’ve been solving problems, some of the side effects or impacts of those problems are really about the organization we’re impacting, or the people consuming our tooling.

I mostly work on open source related tooling and projects these days: back-end or server-side code, distributed systems, micro-services if you want to use the buzzword bingo. In the end though, it’s all about making tools – and tools are for people. Michael Johnson, who makes tools for the folks at Pixar once offered me a bit of advice when I was at Disney making tools for their back-end developers. I’ll summarize what I remember, because the specific words are lost to my memory:

Pay attention to what the tool is doing as much as the technical work of doing it. Tools will shift the balance of an organization and how it works significantly.

That bit of advice has really stuck with me, and is something I think about when setting out on a project or even discussing adding some capability. What is this enabling? Who is it helping? How will they use it? What impact will it have?

It’s very easy to not look beyond the immediate impact of what the result of tool will enable, but it’s critical to make something really effective. And that’s why I try to ask the question “should we” – to set up the context for the discussion of not only what a feature in a tool can do, but what it means in a broader sense. In the end, it’s really just another puzzle – so getting a diverse set of brains working on possible solutions usually ends up with some good solutions, and surprising insights. It’s really a matter of just getting the right questions framed, and then getting out of the way to see what ideas come up.

Published by heckj

Developer, author, and life-long student. Writes online at

%d bloggers like this: