Engineering, for Non-Engineers
- Should I learn how to code?
- How do I work well with engineers?
- Do we need AI/ML/Blockchain/Microservices…?
- I have an idea, how do I make it real?
As an engineer at Forward, I get questions like these all the time. They’re usually from curious folks in other roles who are trying to collaborate better with engineers. These questions have always been meaningful for me to engage with. Thinking about them makes my field less arcane, and understand other fields better.
For me to answer these questions, I looked across multiple threads of the engineering discipline. It’s easier to understand engineers if you first can understand our work.
The Work
Wikipedia defines engineering as
The use of scientific principles to design and build machines, structures.
Now apply that to various fields to find the differences — the environments, risks, and rewards. At their core, engineers are the same. They surface the possible, and apply it to what matters.
Engineers Make things
A mechanical engineer might make a bridge. A software engineer might build a program to detect fraud. A chemical engineer might synthesize a drug.
I think of these “things” as artifacts.
artifact (n): an object made by a human being, typically an item of cultural or historical interest.
They are functional and made by humans. They exist independently, and link to form greater wholes.
“Making” artifacts is deep work.
Maker tasks, not restricted to engineers, have a particular quality. They immerse you in layers of detail as you create.
You’re trying to fit a door on a wall. To do this, you need to align the hinges on the frame. For which you need to screw on the brackets at right angles. Which means you need the right driver and the right markers. For which you need to get the measurements right. You’re absorbed in levels and levels of dependencies in your creation.
To a person looking from the outside, you’re just building a house.
Most creative tasks are like this. Applying connected thoughts to reality is fickle work. Interruptions are disastrous, and the results are tangible, transformative.
Engineers solve problems, with leverage
A doctor needs diagnostic tools to care for a patient. Commuters need safe, affordable transportation to get to work. People everywhere need clean drinking water. Good engineers ensure that they apply their skills to problems worth solving.
We use leverage to do so.
leverage (v): use (something) to its maximum advantage.
A ramp means we can use wheels. A repeated task says that we can automate it. A pulley lets us lift heavy without trying too hard.
A combination of problems and scarcity means engineers need these advantages. They help us create disproportionate change, achieve efficiency, and manage costs.
Engineers measure
What distance does the bridge need to cover? How much time does the computer have to make a decision? How much pressure can a brace withstand? Engineers obsess over measurements like these. They define the realities that a solution will need to address.
Failure to measure leads to failure, period. The Charles De Gaulle terminal collapsed because the roof wasn’t strong enough to hold the metal pillars placed upon it. Several unnecessary deaths happened that day because the measurements weren’t correct. The real question an engineer needed to ask is “how strong does this roof need need to be?”
Engineers build systems
system(n): an interconnected set of elements that is coherently organized in a way that achieves something (function or purpose).
Engineering projects try build useful, self contained, reliable systems. These can be as simple, or complex, as making a meal.
Most engineers (myself included) aren’t geniuses. We just think in defined systems. Systems help us describe a problem and break it into smaller problems. We then find ways to solve the small problems, and connect the solutions into bigger ones.
If you work as or with an engineer, I recommend reading Thinking in Systems, or a summary of it.
Engineers learn
New problems and advances force us to keep learning. It’s a way of life. We learn through consuming new knowledge and then experimenting with it.
For example, Kotlin, a language used to build Android apps, grew from powering 9% to 35% of Android apps in a year. There are 2.5 billion active Android devices. Engineers helped businesses by learning Kotlin. Changes like this happen all the time.
Engineers improvise
Most engineering plans encounter the unexpected. Being able to adapt is key.
A test of the Apollo 1 spaceship caught fire, taking its crew’s lives. Examiners found that a stray spark caused the mishap.NASA’s engineers responded with an updated model. They removed flammable gas from the shuttle and built better exit paths. They did this in months when others predicted it would take years. They didn’t see the fire coming, but they did respond to it.
Engineers manage risk
How likely is it that we fail? What can’t we control? Will we go over budget? It’s hard to predict how things might veer off course. They usually do.
Take the example of building a house. You might not know that the door isn’t going to fit before you start. Or that they make a weird, annoying noise. Or you that you’re missing the right wrench to fix them. On the first day of work, you thought you’d be done with the whole facade, but you’re still working on the door.
We can only zoom in so much before we start, but we have to take every step once we do. These steps are often new. We can counter these surprises, and it’s better when we scope them at the outset.
Engineers practice ethics
We are responsible for building things that work. Our failures can be disastrous and hard to predict. We manage them using probability, judgement, and morals. I recommend that every engineer understands engineering ethics to help make better decisions. A skilled but misguided engineer can cause a lot of harm.
Engineers collaborate
Talking to users and business experts lets us check that we’re building the right thing. Collaborating with designers improves products’ experience. Working with writers explains concepts of technology to those who need it. Engineers use tools built by other engineers. Impact doesn’t happen in a vacuum.
All said, it’s about connecting the possible to the important.
Applying this to your world
Engineering is a set of tools. It’s good for some things, and bad for others. Everyone can use them, if they choose to. I once told the CEO of the company I work for that I might not always be an engineer. He told me that I would, if I continued to use the tools. He’s right.
So, back to those questions.
Should I learn to code?
Maybe. Be intentional about it.
You should learn to code if at least one of these apply
- You find it fun.
- You want to take small tasks off of software engineers you work with.
- You want a job doing it and are willing to invest the time.
- You want to start building an idea.
- None of these apply, but you still believe it will give you leverage.
A common belief in software-influenced industries is that learning to code will always make you more impactful. I disagree — sometimes the barriers aren’t worth it.
What is always valuable is to build engineering intuition. This comes from understanding the work. It comes from learning computational and critical thinking.
Learn to answer questions like:
- Is there a pattern here?
- How do you automate things without code?
- Why is this an engineering problem?
These skills are accessible and applicable to most jobs today. Combining these with empathy and communication will make you very effective.
How do I work well with engineers?
A more general version of the above applies. Also,
- Respect maker time — when people are going deep. The likes of engineers, writers, analysts, designers will thank you.
- Learn to translate real world problems into clear, exact, and complete engineering requirements. This stops engineers from thrashing between abstract systems and the messiness of reality. Immerse us in this process.
- Learn to access and manage data. It’s all around us. It often blocks business and engineering decisions. Being able to get your hands on it and tell stories with it will take you far.
- Learn to automate tasks without, or with minimal amounts of code. Look up and learn to use tools like Google Sheets, Retool, IFTTT.
Do we need <insert technology here>? What is that word?
(in software) things like machine learning / artificial intelligence / crypto / blockchain / big Data / noSQL / IoT / microservices…
Remember that these are tools. You can understand, use, and talk about them. New ones will emerge. They’ll have their own terminology. Don’t let this discourage you.
While evaluating a tool, do the following.
- Start by asking yourself why this matters. It might be critical to your business, or people might be gossiping about it. Avoid buzz words for the sake of buzzing.
- Read case studies and compare them to yours. Companies often have links for decision makers who may not be domain experts.
- Explain the concept to yourself by analogy. For example, an algorithm is a recipe. It can produce salsa, or a Google search.
- Draw things out. Systems are better described in diagrams than in words.
- Talk to an expert and explain it to them.
I have an idea, how do I make it real?
Again, the answer might be to build it yourself. You can get a lot of autonomy that way. Whether you do that or not, you’ll want to learn to convince engineers. If it’s good you might bring on more engineers to grow it. Show them why a problem is worth solving. It might be impact. It might be a love of creating things. It might be financial reward. Focus on the why.
In closing
Being an engineer doesn’t always mean having a specialized degree in an engineering field. Sometimes it means solving problems like an engineer.
You’ll find several barriers while learning engineering. Lingo, diversity issues, gatekeeping, degree requirements, prestige, past experience. Don’t let these stop you. The tools are out there, often for free. Use them, and get help from people around you.
Special thanks to Amanda Fuchs, Eric Stoltz, Aubrey Blanche, and several others for shaping this essay.
