Impact

A professional koan: of the projects I can work on, which has the most impact for the business?

Thinking about this highlights the importance of a prioritized backlog. If impact is a component of the prioritization, then the project with the highest impact is clear.

A senior manager recently commented on some faulty advice they’d heard about service development being more important than client development. They clarified that impact determines importance. We should be working on projects with impact.

“The Secret to Growing Your Engineering Career If You Don’t Want to Manage” makes several good points.

Many engineers become managers because management provides an obvious and well-defined leverage point to scale your impact.

It’s relatively easy to produce more if I can delegate work out to a team.

The less conventional paths outside of management require more creativity, and there are fewer available narratives of successful engineers outside of management for us to model ourselves after.

I can attest to this, and explore it further in “Technical-organizational balance”, but I find it surprising given the idea of parallel tech and management tracks is ostensibly common practice.

Your ability to decide where to spend your efforts to maximize your impact — what code to write, what software to build, and which business problems to tackle … You identify and solve problems that are core to the business, or you enable those around you to more effectively solve those core business problems.

Hopefully our ability to identify projects with high impact improves over time.

“How to Grow as an Engineer (Working Remotely)” also touches on impact.

It’s also not enough to just solve any problems. You need to be solving the right ones. You should constantly make sure there’s alignment between what you want and what the business needs…

Norvig’s summary of ML for software engineers

Peter Norvig summarized the value of ML from a software engineering perspective in his “Introduction to Machine Learning” for Google’s Machine Learning Crash Course:

First, it gives you a tool to reduce the time you spend programming … Second, it will allow you to customize your products, making them better for specific groups of people … And third, machine learning lets you solve problems that you, as a programmer, have no idea how to do by hand.

From my perspective, the first two can be rephrased as:

  1. Models add a new dimension to code reuse
  2. For a class of problems, training models scales better than hand-writing code

There’s also a fourth point linked from the bottom of the intro:

Rule #1: Don’t be afraid to launch a product without machine learning

That fourth point reminds me of the “build” vs “grow” domains – until we’ve built a product that lots of people find useful, statistics-based growth tools, like large-scale AB testing, can be relatively high-cost, low-value.We might even say such optimizations only make sense once we have more users than can be efficiently contacted directly. Put another way, if we only have one user, and she says she only wants to see articles about sports, we don’t need ML to predict her interests.

I think about these four points a lot, almost like a koan. They provide a helpful anchor as I try to distill a large amount of theory into tools I can apply to the problems I’m familiar with.