In August I took Mark Rober’s creative engineering course.

Here’s a video I made about my second build. I call it the ‘I Love You Bear’.

The course is about creative engineering – mixing creativity with engineering to come up with story-worthy, exciting and cool products.

Creative engineering… it’s actually a different approach to building stuff. Think Jazz not Classical, Improv not Shakespear.

In normal engineering you kind of know what you intend to build. Maybe you have a client or a spec doc or something. Your goal is usually to build that thing. You usually end up with a new website or vase or something… high quality but not really innovative.

In creative engineering you stumble your way to creating something new. You pick a direction – some rough problem or idea – then you explore using brainstorming and quick dirty experiments. When you’ve found something new and exciting your put in the polish.

I loved the course and I feel more excited about engineering than I have in a long time.

Here are some of the big ideas I took away from the course.

1. Constraints create creativity

I often face analysis paralysis. What will I work on?

Mark points out that it’s hard to make decisions without having ‘constraints’ – budgets, time, deliverable results all help shape what kinds of ideas one could work on.

This idea is a game changer.

I’ve begun including a section for constraints in my project plans. Whenever I feel like my idea tank is empty I try adding a few constraints. This unlocks creativity. What would I do if I could spend an infinite amount of money on a project? I’d add a budget. My brain can’t work with the ‘unlimited’ concept.

2. Relatable stories help people care

People care about humans, not machines. If you want your engineering to be exciting you have to use storytelling to fit your project into human life.

Googly eyes, great names, characters, points of view, etc… humanize projects.

Picking the right story matters. Some stories are more relatable than others. A story about a machine that helps you always make a basket in basketball will appeal to more people than a story about solving a bug in the ESP32 micro-controller… more people can relate to basketball.

Stories often involve problems. A simple, obvious relatable problem will connect with more people than a more obscure problem.

3. Break down a project into requirements

A story-worthy idea becomes a project when it gets broken down into requirements. Requirements are another form of constraints. Requirements shape what the solution must do for the project to succeed.

Mark often lists out requirements before thinking about how those requirements might be satisfied. He then brainstorms ways to satisfy the requirements.

I often skip this step (I actually did in build 3) and I usually regret it.

Skipping this step means you haven’t defined what ‘done’ is. How can you complete a project that hasn’t been well-defined? You can’t.

4. It’s valuable to explore the solution space with research and quick and dirty builds

Mark is always looking for the GREATEST IDEAS and THE BEST solutions.

Great idea or awesome solution can change the world, a mediocre idea will likely flop.

In order to find great ideas Mark uses quick research, experimentation and prototyping. This early research, experimentation and protyping is intentionally quick and low quality – duct tape and popsicle sticks not unit tested code and milimeter precision parts.

The goal is to explore an unknown solution space to find the surprising and interesting stuff. You polish later.

When you’re looking for a great idea you’re exploring the unknown. If you go with your first idea it’s likely you’re working on a sub-optimal solution. It’s only by trying a lot o things that you are likely to find the global maximum.

In my own engineering I often pick one solution – 3d printing or Ai or metal work – and spend lots of time trying to get it to work.

What I’m doing in these cases is trying to create polished work during the exploration phase. It’s a waste of time and resources.

As an example when I was working on the bear my first designs used a lot of big robust 3d printed parts. The parts took 10 hours to print and after printing they didn’t fit into the bear’s body. After this failure I realized I should have just used chopsticks and masking tape for my inital tests. Later I took what I learned from the qick and dirty tests to make a better 3d housing that fit.

Lesson: Save the polishing for the final-build stage.