Engineering Principles. What they don't teach in school.

How to build things. Lessons learned the hard way.

It recently dawned on me that I should write these somewhere, so here we are. I’ve been building things for a while now and while that doesn’t mean anything I built was good or worth emulating, I’ve learned a lot of what Not to do over the years. I see a lot (mostly young aerospace) folks make these mistakes, and be too stubborn to heed advice, which hey I was just like that, not shaming. These lessons are often hard-fought, and rarely are they taught.

In absolutely no particular order, here goes nothing. Note, this is not targeted at seasoned engineers, almost all of those folks know more than me, it is targeted at the college kiddos. I’m probably wrong on some of these things, but I suspect that at least in writing this, I’ll get closer to the true supreme engineering methods.

Iterate like mad. No it’s not more expensive.

Maybe my hottest take and the most offensive one, so care is being taken here.

I think that you should spend as little time designing on your computer as possible and spend as much time building and testing as possible. It should be about 10-20% max design time and 80-90% build/test. If you spend 10 months designing for a project that you plan on ‘assembling and testing in a month‘ you are in for a world of hurt. I say this because a lot of times when you delve into the details of a design, no matter how smart you are, you have to make assumptions somewhere, and often times those assumptions just wind up becoming requirements and constraints which aren’t really necessary and add extra cost and development time.

In a single person project, you can probably get away with this and catch yourself quickly, or delude yourself into never building the thing in the first place, but in team projects, these assumptions compound in the worst possible way, drawing out every single timeline and budget spreadsheet.

I think that it’s best to just copy the software fellas and get the MVP done ASAP. MVP being the Minimum Viable Product. Listen, us hardware folks have a lot to learn from our software brethren, a lot of which is about the process of making new things. They go from idea → execution → test → launch extremely quickly. Within hours to days. We need to emulate that, and truth be told, it’s not the hardware that’s the limitation here, for the most part we are the problem.

Just accept this simple fact: Your first iteration, will be absolute hot flaming complete garbage vaporizing in a bucket of acid. And maybe your second one.

It will be horrible. But you know what. It was cheap and quick to build. Right….? RIGHT?????

I seriously hope it was :0

In the vast vast vast majority of cases, it makes absolutely zero sense to pour all your energy into optimizing the first iteration because you have 0 real data on how your system will perform, short of what you scoured off the internet which may have confounding variables you aren’t aware of at first glance. The very first thing you should do is get the first prototype working so you can get some data out of it and see how it performs. Then you can optimize it to oblivion and fulfill your heart’s desire.

Prototype 1 summary:

• CHEAP.

• FAST TO BUILD.

• JUST WORKS. ( Kinda working is ok)

  • You literally just want to see if the thing will work period. Half the ideas I have are crazy and would never work. The first question to answer is would this even work? Not how to make it good, pretty, cheap or better. No, just does it work. Literally nothing else. The only singular objective of the MVP is to just do the thing.

Literally no other requirements for prototype 1. And you should strive to get there as quickly as you possibly can because your data before v1 is limited in proven cases and nonexistant in experimental cases.

Then you should just focus on making it better and adding features 1 by 1. Testing each little thing as you add it and seeing how it effects your system. Do not try to build the most complicated thing on this planet in one go and with all the features crammed into v1, you will cause yourself nothing but pain and huge monetary loss. Because no matter how many books and no matter how many papers you’ve read and experts you’ve talked to, you will miss something, and you won’t really have any intuition to debug your issues with.

Intuition is a weird thing here. It starts off wrong in a lot of subtle ways, but as you gain more experience your intuition suddenly renames itself to ‘gut‘ and suddenly you have a much better feel for your systems. Intuition is not something to be trusted in new projects because it’s almost entirely unfounded.

Building something, seeing it, debugging it, getting it’s core features to work and interacting with it, are the best ways to learn how something works. It’s also much much MUCH faster.

There was this one concept in rocket engineering that took me so freaking long to understand you wouldn’t believe. The concept of a cryogenic dip tube. Basically when you stick a tube in a cryogenic substance, it boils out the top of the tube at a noticeable rate. This lets you read the level of a cryogenic liquid in what may be the simplest manner on or off this planet.

I spent months designing my stand without really understanding this principle. Then one day, I stuck a PVC tube in some liquid nitrogen and observed this behavior immediately. Suddenly everything made sense, all it took was 20 seconds with some liquid nitrogen.

I tell you, I overthought that stupid concept so much when in the design phase, it’s almost comedic. And then when I saw it and played with it, it just clicked. You don’t need to throw all your IQ at a problem, sometimes you just gotta go and play with it, test it, see what happens so you can build some solid intuition for it.

This is part of why you should just rush to building things not optimize your v1.

Now most common response I get is: “oh but I want to save money and only build it once. I can’t afford to iterate, I’m broke :(”

That might be the single most misleading thing ever said. Here’s what will happen. You’ll optimize your v1 to the teeth, make every single thing about it perfect. Then you’ll go and have some expensive parts machined and justify you spending all your budget on it because ah well you’ll only build it once right??

Wrong. Since you jam packed all your features into your first prototype, it’s now an expensive prototype, that took forever to build.

Now hypothetically, out of all the things you optimized on there, one of them didn’t work? Something broke somewhere, something you had miscalculated, messed up, or didn’t understand fully has now bitten you in the rear. Oops, now your core functionality might not work, your optimizations are not working as expected, and you are left holding the tail end of the stick after:

• Spending a boatload of your most valuable asset ( your time) designing the stupid thing.

• Spending some serious cash for the parts to be made.

Only to find out that something got messed up. Now, some people might say, oh no, I’ll get it perfectly the first time just after I do a bunch of research. Nope, not happening, that’s an arrogant argument. It’s saying that despite me knowing very little about this subject, I’m going to get the solution right on the first try. You first iteration will reveal loads of data to you that wasn’t obvious and is quite critical.

It’s like attempting to do long division on two 18 digit numbers after only reading about it in stories and expecting perfect results on the first try. Or like expecting to swim like Michael Phelps after reading intensely about swimming for 7 days a week 19 hours a day. Reading about every detail about Michael Phelps will not make you a better swimmer. Same as it goes for engineering something with any sort of complexity. Reading about all the details won’t prepare you for the real thing.

Anyways, let’s wrap this section up, you want to get your first prototype off the ground in as little time as possible. Then you want to slowly add in features to your prototype by modifying them in or building a new version when the old one becomes obsolete and you have better data. Ya’ll remember the launch of the folding phones? The first folding phones were hilariously bad, despite entire engineering departments in massive reputable companies having spent months if not years working on them. But the flip side was, once they launched, they got so much data on what was broken, that they fixed the majority of the issues in version 2, and now very few people remember just how bad version 1 was.

Build and test one feature at a time. Quickly though.

Keep it simple. Don’t jam pack all your fanciest features into a single prototype and expect everything to work, unless it’s little tweaks. There’s a concept here, not sure what the professionals call it, but I call it the iteration cycle.

It’s just: design → build → test → repeat cycle.

And you basically want to maximize the number of iterations in your product. Test one or two features at a time and keep moving, and fixing what breaks. It’s thousands of times easier to debug something when you have one variable that changes rather than debugging multivariate systems. It’s like solving a system of 5 equations. A complete nightmare, but if you break them into different iterations, you can approach them like univariate equations very simply using basic math and get there quicker. Unintuitive. Yes. Quite so.

All the best engineers I know build and test crazy fast, one thing at a time. Look at zipline, Pipedream Labs, SpaceX, Tesla, Midjourney. These people modify things on the fly and ship insanely quickly relative to their competitors. I used to be a programmer back in the day, and it taught me a lot about how to think about problems, ( did not make me a great programmer though lmao) and the debugging process in hardware is really similar. You need to make things univariate. Test one thing at a time, then test multiple tested things together, then test the whole thing and you will probably still have issues, but it’s okay, integration hell is waiting at the end of every complex multi-system project.

Summary: BUILD+Modify+Test Fast. And as many times as you can.

Be picky about who you work with. Keep your teams small.

Alright, let’s talk humans and team management.

A single person can do so much more than you would expect them to be able to. It just has to be the right person.

A 10x engineer is worth way more than 10 of his mediocre peers. This is because, say you had two projects, one being done solo by 10xer and the other being done by his 10 peers. The 10 person team will argue and communicate, and delegate and make excuses and have all sorts of bureaucracry, and argue over who does what, and try to look good for each other and each try to subdivide the work evenly so that everyone has something to do while the 10x engineer over here is quietly building after he did all the arguing in his head, went with a hypothesis in record time, tested it, got back to the drawing board and got to building way before the other 10 finished arguing over who does what.

Now. This scales. 3 10x engineers are way more powerful than 400 mid engineers. Yes the complexity scales a bit differently, but it’s not going to be true all the time that every one of the 400 people on the bigger team is going to be as dedicated to working on the project as they should be. And because in organization, information hides, and communication is always imperfect.

A truly potent small team is able to make decisions in seconds and minutes, whereas a large team, even of the highest caliber of engineers, takes days to organize some time to meet and discuss all the little details that got subdivided to all the little teams. It’s rather hilarious to watch. Most of the time in large team managed projects is just spent waiting.

Good teams have chemistry. They grow together and they watch each other’s blind spots.

Let me give an example. I’m happy to say that me and my co-founders, Michael and Matthew have an extremely good chemistry working together. We can make huge decisions in mere seconds if we all agree, and minutes if we don’t all agree. We collectively have built something which generally everyone who sees, thinks is super neat and has dozens of paying, active users.

Not even kidding, Michael and Matthew today ( or I guess yesterday now, 2:00 am moment :0) spent over $1000 in new equipment for the most part without asking me. I’m not the boss, we’re 3 equal directors here, so technically they could have simply outvoted me, but that’s not the point here.

The point here is that we work so well with each other, that we were in tune with what the shop needed, without having to even talk about it much. They knew what I would approve and what I wouldn’t. And I trusted them to do it, they delivered, and we were all super pleased with the results. They did great!

This chemistry developed over our last 3-4 months working together. This is not going to happen, even remotely in a large team. People will form cliques because they always want confidants, but that will mostly lead to rather unpleasant group dynamics in poorly managed scenarios. (I’m no manager, so take this all with a grain of salt, but I can tell you for sure, no 10+ person team would have been able to pull off what our 3 person team did today).

I know plenty of rocket teams who will accept anyone with open arms. I think, in terms of education, that’s great, but in terms of building things and getting stuff done in a timely fashion, it’s extremely counterproductive. For my signature projects, I’m super picky about who I work with, and will continue to be even more so perhaps and like to keep my teams extremely small <10, preferrably 5 or less.

The idea of subteams works well at large scales ( ones at which point, people stop calling you amateur) with small subteam sizes and rules. But for small projects, I think it makes most sense to have a small superteam of highly talented and flexible folks knocking out ideas asap.

Rockets for example. If I were to build a dream spaceshot rocket team who would I want on my team, type of people. 100km, liquid fueled, kerolox, SS, regulated.

An EECS genius.

Someone with tons of mechanical experience.

Wild card spot or two.

What’s most important is that these folks can work with each other and with their respective systems. So Mechanical guy, spending a ton of time with EECS guy, will learn a ton about EECS, and then they will be able to bounce ideas off of each other in an effective manner. The idea here is that they are flexible and can learn from each other on the fly. Compartmentalizing subsystems on a complex engineered system makes absolutely zero sense.

OH. Almost forgot.

A very very very important note.

Information get’s lost in big organizations. For example, some rocket teams will come asking me for help or advice and it’ll typically be the captain talking to me, and I’ll begin questioning their requirements.

Why are your tanks so high pressure? - me

Well, our engine needs 500psi.

What. Why?

Well, our engine team ran the numbers and it was 15% better performance.

Yeah, but you just gained 30% in weight on your total vehicle mass. That was a bad decision and you can make a much simpler and better feed system because your presssure requirements are driving custom tankage which is a whole ordeal in itself. This single poor decision is driving you to buy $3000 in extra expensive high pressure plumbing.

---

Information not being communicated properly between subteams is rather problematic and assumes perfect individual/subteam level engineering and tends to compound mistakes. Very rarely are engineering decisions easily compartmentalizable. Often a change in tankage will cause a change in aero, a change in structures, a change in manufacturing, a change in ports and sensor layout as well. You get the gist. It goes on and on, and there’s layers to it. Information likes to hide alright. There’s great power and understanding when it comes to concentrating things in a single person’s brain. Because they understand the ramifications of decisions, so they can make more decisions quicker. And this isn’t quicker as in 10-20% quicker, it’s 1000-10000% quicker. They can just think and check if something is true and change multiple variables on the fly with minimal consultation, or just at most one or two phone calls.

It’s a huge huge huge red flag to me when the technical lead of a project doesn’t understand almost every detail of it. How can they make executive decisions without understanding how their teammates ( supplying them that information) got it in the first place. Some subteams can just make an incorrect assumption, then impose it as a requirement, significantly complicating the work of another subteam and adding huge cost and overhead.

Whereas one or two engineers, they’ll hash it out, and they’ll be on their merry way building the system in a matter of minutes or seconds, both having a complete understanding of their system and working through their problems well. Having a small team forces your team to become interdisciplinary, which has huge benefits in checking the power and assumptions of teammates. If all the team members understand the ramification of a decision, then they can make the most informed decision right there and then, with out of all the meta team-building strategies, what might be the highest success rate.

Summarizing why you should be picky with your teammates (if you can be):

• Big teams have slower communication and iteration time, also have no chemistry and add massive overhead, literally unnecessary.

• Small teams communicate so much faster, it’s unreal and it compounds incredibly quickly.

• It makes great friendships and experiences for everyone involved!

• Information on why decisions were made does not get lost as easily in small teams.

• Accountability is incredibly clear and so is individual performance, therefore team issues are much much easier to detect. I do not need to be playing Sherlock Holmes trying to figure out who on my team is dropping the ball. It will become very apparent very quickly in a small team if a member is a bad actor or not aligned and they can be removed relatively easily. Much easier to communicate goals with fewer teammates.

There’s more to this point, I could drone on, but you get the point, smol team good, big team bad, big and small being relative terms that scale with complexity. *mic drop.*

Miscellaneous lil details.

For whatever else I missed :)

• Find advisors/mentors to bounce ideas off of, for when designing things and explaining why prototypes fail, but do not use their word as gospel. It’s useful to learn from someone in the beginning, but you can’t continue to lean on their knowledge as a crutch for making decisions. Sometimes, you have to just mess around and find out. Make mistakes

• Make peace with failure. You will fail a lot. It’s okay, everyone who succeeded big failed more times than you could possibly imagine.

• On simulations. A lot of aero is extremely simulation heavy, and while I think simulation has it’s place, it’s not that useful when not grounded with real good data. Garbage in, garbage out. And simulation != reality almost ever, unless they were measured on that reality, in which case your error goes up proportionally as you deviate from measured conditionss.

• Huge pet peeve of mine. A lot of folks start with designing the optimal thing by speccing out materials they can’t readily buy. For example, once upon a time I designed a rocket tank to be made with 1/16” wall tube at 8” diameter. Ok first off, who is going to sell me a 1/16” wall tube at 8” od. Nobody. I’m going to have to roll my own tube and have a longitudinal seam weld at 100% penetration, absolute perfection required, no margin for error. Then that cuts down on the amount of tanks I can make because for each iteration I have to weld flawless tubes. From this single decision my program now too much longer to get to test. Great, already a huge messup.

  • This could all have been cheesed if I just designed around readily purchasable 8” od, 1/4” wall tanks that are heaven forbid, 2lbs heavier. Oh please. it’s worth it. Every time it’s worth it.

  • Literally just start designing around what you have, and what you can easily get. Don’t design for random obscure expensive valves, or materials on the internet just because some university lab with more money than sense did it in their research paper. No. Be better.

  • TL;DR, DESIGN FOR WHAT YOU CAN ACTUALLY BUY / FIND.

• Keep your team close. Try to eliminate remote work as much as possible. For some, they can do that, for most, it doesn’t work so hot. A lot of the chemistry, fun and excitement of building awesome things is lost when all is done online. I’d be more okay with it in software, but even then, nowadays, I insist that I be physically near to someone when building serious things with them. Because your communication bandwith just got smaked with best case a 90% reduction. At the very best. Note speech in person conveys about 180wpm, while most can type at around 80wpm. 50%, not to account for 70% of communication being nonverbal and time zone differences and whatever else messes remote work gets you into. Imo, almost never worth it, definitely not for me, been burned there once before. Also, team moral is lacking here. Some can do it, but don’t assume it’s the default state. It will always be working against you and almost never in your favor.

• Design for what you can actually build. Imagine you only had a garage with basic handtools, some saws, a drill press, and little else in the way of machinery. You know what you should not do? Design parts that need a 5 axis cnc to be made on. Even if someone is willing to sponsor them, as much as I love my sponsors, I wouldn’t ask them to continuously make parts for me as I know their paying customers will always come first and besides, making something yourself is a sure fire way to get way way better at designing for manufacturing. You realize shoot I can’t actually make that part with a cavity in it, it’s not manufacturable. Well since I’m the designer it’s pretty easy for me to change it.

  • Also listen, sponsorships are great, but manufacturing ones tend to throw you off of schedule. Just design for the tools you have and be in control of your project’s destiny. I know it may feel great to have all these big name sponsors on your project, but at the end of the day, you’re here to build things, not to collect big name sponsors, who won’t really help you learn as fast as you possibly can. Again, I love the shops that made my stuff for me, and all the sponsors that helped me, but waiting for them almost killed my project, and while of no fault of their own, it was my own. If I had just designed those parts to be made on a drill press with 3d printed jigs, I would have saved myself months of headache.

• Which brings me to my next point. Amass some sort of tools that you can access with minimal friction, whether that be, your own garage, a local makerspace ;) , a university that won’t look too closely what what you’re building, just try to get some sort of collection of tools so that you can build in more manufacturing capabilities into your design arsenal.

  • If you followed the last rule and designed for things that you can manufacture yourself, then the obvious next step is to increase the amount of tools you have. Tools have value, so in this economy, I’d put my money in tools. Only half kidding lmao.

• Ambition is great, but it’s not the hammer that fixes all your problems. Look I get it, if you can dream as big or bigger than Elon Musk, that’s lovely. Now think about how you’re going to achieve that? The achievement paths aren’t linear, and often times it’s daunting to actually start by building an ambitious project. It’s sometimes much more advantageous to start small and build bigger gradually. Like I’d rather have someone who built and fired a 2lbf ipa/lox rocket engine rather than have one guy who designed a 95millionlbf hydrolox rocket engine. First guy knows how much there is to doing the thing and is realistic about what he can do, second guy is insane. Ambition is not bad, not at all, but it’s not particularly practical to Start big. And I made that mistake quite publicly. If I had just downscaled my rocket, I would have had it launched by now and have some sort of success attached with it. It’s okay, I learned a stupendous amount of things from that and I’m quite happy with where I am now. However I know damn well I won’t ever make that mistake again. Better to have made it early and mostly on the down low. I’m not saying don’t be ambitious, but you should not start prototyping with your massive ambitious project when you don’t yet know what you are doing. IE if you are a rocket startup, don’t start by building something Sea Dragon sized is the moral of the story.

• Money will not suddenly make you a better engineering team. There are teams out there, who have taken money and just completely lit it on fire, because they just had money. I’m sure I don’t need to explain why, but it doesn’t quite make sense to light money on fire. How did they do it? Well, they just went ahead and overengineered, picked the best solutions that they had the money for. They had things custom made that should never have been custom made, let their team numbers balloon to corporate sizes, then spent on transport and logistics what might feed a small village for a decade, then sat there trying to do engineering with the 8-10 people who know how to do the engineering and got overwhelmed because after raising all that money they have very little to show for it.

  • I will not point fingers. But suffice it to say that this is a path that leads to misery. Money and sponsorships are not the solution to poor engineering. They are a sinkhole that sucks you in and leads you to waste time at worst. (In my book time is way more valuable than money, probably by 10x fold) . Best case though, they’re lovely. You just have to know what you are doing and know what you are getting into.

  • Note, I’m not saying that all money is bad. But in the wrong hands it can just lead to a long slow and painful death of an organization/team. Often if that team hadn’t gotten funded, they would have moved on to pursue more reasonable/cheaper/more time effective solutions. Like if they had just received their money after they decided that the things they wanted to buy were the cheapest possible components that would work, that would be amazing for them. When instead what happens sometimes is, we need $ X for the project, it get’s raised, then the budget becomes $ X when in reality the project could have been completed and the learnings achieved for less than 1/10x.

• Assume you are stupid in your initial prototyping. Don’t underestimate yourself, but also be honest about your assumptions and don’t build major design decisions on things that you aren’t totally sure about. Experiment, have fun, try things out, see what will just barely work for cheap.

  • It’s more fun to wing it the first time around, just see what you can get to work, just don’t put your personal safety at too much risk haha.

• Try to consolidate your design into a small team, your manufacturing to be done by you and your small team, and your testing to be done by you and your small team in as close of a location as possible as frequently as possible. Test fast, test soon and test often. Tests are your number one, number two and number three indicators of success and pretty much everything else about your project.

• Build in public, it’s cool and it may bring opportunities. Regardless of how poor you think your engineering is, you might learn something from the interweb discourses regarding you.

• Work on things that you find fun initially, then when you’ve developed enough, try to find things that are fun and meaningful to work on. Reason you shouldn’t do it initially is because you’ll start off as a pretty awful engineer, and generally shouldn’t get too emotionally tied up in your work because most of it will be garbage at first.

  • Or just work on fun things. Productive hedonim at it’s finest.

• Operate on a shoestring budget and like you have no time to waste, because you really don’t. Engineering motivation is almost comparable to that of an artist, it’s fleeting and comes in spurts. You never know what tomorrow brings. No matter how many millions you have in the bank, prototype one has got to be as cheap and as simple as you can possibly make it. Then you can feature creep nice things in later while operating as quickly and as cheaply as you can. Don’t pick the nicer option because you have more money unless it’s genuinely worth it. A lot of time it isn’t so be frugal. It makes your money live longer and increases your likelihood of success. Think in terms of opportunity cost. If you just spent $30,000 on a set of ASME custom welded rocket tanks, you could have built a whole spaceshot if you had just tweaked your engineering ethos. Instead you just bought some overpriced cylinders which you really didn’t need. :(

Alright. I think that’s maybe all the semi useful things I have to say about meta-engineering that I can think of on this lovely ….. morning. ( bro it’s 4 am. that muse smh)

Also please note, I don’t actually know jack squat in the world of engineering. I’m pretty stupid, so if I’m wrong about something, do correct me, we’ll talk. I’m just hoping that by publishing this, I can explain why I engineer thing the way I do and push people out of the ruts I found myself in years ago. If there’s a better version of this post out there on the interwebs, do point me in it’s direction.

Kind and quiet regards,

Photo by MARK ADRIANE on Unsplash

Ismail

Be extremely picky who you work with. And keep your team as small as possible for as long as possible.

In the rocket project, we made the horrid mistake of recruiting every person with an IQ of >120 around which mostly just wasted our time and gave us nothing but trouble for the project. It’s hard to keep a large team motivated and in sync for more than a short honeymoon, and the people who do it typically successfully have much bigger things to work on than me and don’t need my silly thoughts.