How to balance your time spent in theoretical and practical engineering?

in the past months I met a few of the most successful founders of the Valley, from Midjourney's David Holz, to Worldcoin's Alex Blania or Manafunds Max Novendstern.

as a young ambitious founder i wanted to seecpicialy figure out how these peiople look at building ventures, how they are able to biuld these super ineetrsing technogieuies

in the past months I met a few of the most successful founders of the Valley from Midjourneys' David Holz, Worldcoin's ZTin the past months i met a few of the most sucseful founders of the valley from Midojursneys David Holz, Wroldcoin's zt

I am currently trying to figure out how the best founders on earth balance their time

time and energy spend on thinking and doing:

A combination of Paul Graham and Brian Machado would say sth like:

"Don't try to make theorteical enrgineering and praicitali engineering two difreent mental models, dont divied which should be one.

The onluy/ rela mentla mkode of engineering should be to just do things - just trial and error and let the unvires attrasct you to waht fascaintes you

- dont try to make architecretiung and - it's one fucking mode - just do things - but do them intelligently."

Think about the WHY instead of WHAT: - don't think about WHAT tools you would like to have ("a rewind for x, figma for y") - think about WHY you would like to have the tool in the first place.

Should you "trial and error" your way to the right solution (thinking and implementation as one real-time process), or should you architect a system and then try to implement it (thinking and implementation as two separate processes)?

• First off, engineering is an iterative/repetitive process. Most problems are not solved by first thinking really hard about the solution and then implementing it. It's a constant switch between thinking about solutions and trying to implement them, knowing more about why the current solution does not work, rethinking your implementation, implementing it, and so on.
• So this is not an either-or question, but about finding the right sweet spot between how much time to spend on system design and hands-on problem-solving.

I think these are two pitfalls to fall into:

1. Never zooming out or never zooming in:
   • Never zoom out; you might end up with a completely wrong direction in tunnel vision.
   • Never zooming in:
     • You don't learn & gain experience
     • You never test if your architecture actually works
     • You never create something (no impact)

Generally, I would say that most humans in the world tend to overthink and fail to implement their thoughts.

• This happens because thinking is the way of least resistance.
  • It's much easier to think about how to engineer something, and you have the feeling that you're progressing. This is a very dangerous sign of pseudo-productivity. In your head, there is already a whole product, but implementing it in reality will unveil the true fallacies and give you more data.
• The biggest fallacy is that you could even think that you get something done by thinking. Thinking can be a kind of pseudo productivity. If you never implement your ideas, you never have any impact on the world.
• Excellent CEOs of truly innovative organizations balance both theoretically engineering the solution with a huge 10-20 year vision ahead, but also run the portfolio end with huge urgency and drive to accelerate trial and error.
  • Steve, Elon, and Sam are the most famous examples of founders having insanely big visions and hunting them down as aggressively as possible.
    • Hunting your vision down and putting all the force you can bring up to tackle a physically hard engineering challenge feels like bending the universe to follow your ideas.

The time between a theoretical idea and practical implementation should be as short as possible.

So if I had to choose one of those, I would always go with hands down building, because you definitely learn things when building, whereas when just thinking about ideas, your surface area of learning is very limited.

• Zooming in and practical engineering can refine your zoom-out vision.
• You cannot figure out the engineering details while staying zoomed out.
• It's hard, if not impossible, to figure out detailed engineering solutions on a whiteboard without using the tool.
  • You need to zoom in and do the thing.
  • Your zoom out architecture should always be low-fi; there is no value in writing real code on a whiteboard - you cannot compile it.
  • There is less value in creating high-fidelity Figma prototypes before nailing the UX.

Mastery lies in balancing zooming out and in:

• It's hard to put this into a clear decision-making algorithm, and by working on multiple projects you will develop an intuition for this.
• But being aware of the parameters that go into this decision making is definitely some good food for thought.

So how much time should you spend on zoom-out systems design before zooming in?

• You develop an intuition for this over time, but just as Elon wrote down his 5 engineering principles, it makes sense to be aware of the parameters that go into the decision making. Ask yourself these questions:
  1. How much experience do you have in solving the problem practically?
     • If you have never developed an app, go directly into building and try to get some intuition for how it works, instead of spending too much time on system design. Your system design will most likely be suboptimal anyways.
  2. How many unknown variables does your problem have?
     • When building complex physical hardware systems, you are often unable to simulate the full implementation of your idea.
       • Often times there are too many unknown variables making it hard to think through the engineering process in your head.
       • Software engineering is different in that you are describing your product in an abstract language, which you can definitely think through on a whiteboard to some extent.
     • As long as we don't have high-fidelity real-world simulation tools and a way to feed these simulations with our ideas in a fraction of the time compared to trying to implement the idea in the real world, this will remain the case.
  3. Are you working alone or in a team?
     • Sharing knowledge in larger teams can quickly become messy and distract the team from accomplishing tasks. Teams often do not document their ideas because their goals change so rapidly that documentation becomes outdated too quickly. As a result, they innovate so rapidly that the real world serves as their documentation.
  4. How far away is the language you use to design the system from the real world implementation?
     • Pseudocode is closer to real code than a sketch of a rocket is close to the physical rocket.
       • When developing software you just translate your thoughts into natural language/diagrams → code.
     • Figma design is very close to the end result of an app.
     • Zooming out and outlining the structure of a book → then writing the actual book iteratively.
       • It's both natural language, so the work you do conceptually can be implemented in the end product easily.
     • If you don't use natural language for your conceptual work but another tool, how fast are you in this tool?
       • If you can draw quickly - using this as a tool to figure out mechanical implementations is powerful (Leonardo da Vinci using his sketches for engineering designs). If you are drawing slowly, it might be a waste of time.
     • There is a vast difference between the implementation of an fMRI machine on a whiteboard and its implementation in the real world. The whiteboard is simply not the right tool to capture the complexity of the engineering. A CAD program or a real-world simulation would be closer to the end implementation here.
  5. What is the scope of the project? Are you planning to work on it for years? Then zooming out is definitely worth it.

No matter how you balance your time between design and engineering, you should:

1. Always stay low-fi in the zoom out process (to save time)
   • You don't gain much when building a high-fidelity Figma prototype of your application in the beginning, but you might lose a lot of time.
2. Failing fast is a skill; you get more experience to learn from in a shorter timeframe.

Examples of zoom-out design mastery:

If the initial system design and the real-world implementation in the end share a lot of similarities, you can say that the initial design was definitely worth it.

• First design of Walt Disney Company vs Walt Disney Today
  
• First design of iPod vs first real iPod

This mental model attempts to pinpoint the ideal amount of time to be spent on and even allows for consideration of whether you should spend time thinking about your engineering solutions separately from the engineering process itself, or if you should think in real time while doing it.

Related

• Tackle the Monkey - Google X
• One of Sam Altman's most important insights about finding your life's work.
• Explore vs Exploit described in Algorithms to Live By
• Raphael Mosaic on X: "think about the WHY instead of WHAT: - don't think about WHAT tools you would like to have ("a rewind for x, figma for y") - think about WHY you would like to have the tool in the first place.