Just enough engineering

Erika Hall's "Just Enough Research" presented me with the idea of "just enough something". In that book specifically, she lays down just perfectly all the fundamental research knowledge a designer should have to be truly effective.

This general outlook is very appealing to me, more so particularly now, in this era of hard generalistic design engineering, where I easily and constantly find myself in a state of heavy anxiety because it seems like, all of a sudden, you need to have years of computer science context.

But then, this other side of me refreshingly remembers: the world is vast and for any given topic, there is an infinite amount of depth. You may not need the majority of it all to be truly effective. You just need to develop a sense for how deep to go on something.

It's still about solving problems

Design at its core is still about the same thing it has ever been. And although I've definitely seen a good number of designers be effective without much engineering chops, the best of the best I crossed paths with were still, without question, the technical ones. It's a mix of confidently knowing that the end delivery is still a solved user problem—as opposed to a merged PR—while comfortably getting there through technical iteration with engineers.

How do we define "being technical," though? What's really in scope? Some days, you're just trying to figure out how the has pseudo-class works in CSS. Not too hard, I guess. But in others, you're going down the mathematical rabbit hole of "how anti-aliasing actually works." Or even "how does one really implement a CSS feature?"

But while these are all absolutely interesting pieces of knowledge, they can also:

1. generate anxiety because they'll further surface a lot of fundamental technical gaps
2. be a total distraction that won't necessarily get you closer to solving that user problem

So, we've got to find the just enough point. Enough so that you know what to reach for—what tools to use, among AI, frameworks, templates, etc.—to solve the problem faster with confidence and craftsmanship.

But, the truth is...

The enough point is something you, ultimately, have got to find for yourself, given your personal curiosity and will, and your product's/company's context. You may not need to know how shaders work to design a killer real-estate product. But you may need to have an idea of how the Language Server Protocol operates if you want to be more useful while designing a text editor.

You also need to discover how to learn these things. For me, it's really hard to sit down and go "I will study what Rust tuples are!". No, I've got to find a situation where, suddenly, a tuple is the right thing, to which point I'll figure out that I need to use it, and only then really process and understand that "oh, so that's what a tuple is!".

It's really pattern matching, to some extent. And this is where AI has been the most useful for me, so far. Throwing questions at it that help me build my mental model of tools and technologies, piecing and grouping them together.

This has been my journey. Just enough engineering, to solve someone's pain.