101 Things I Wish I'd Learnt at Engineering School
Twenty years ago I finished university and started working as an engineer.
At that point I had a huge amount of theoretical knowledge and could confidently write you a mathematical model of anything in five minutes flat. I assumed that I had basically finished learning and was about to put all that hard-earned knowledge to work solving the world’s problems.
Then I entered the world of work and spent the first two weeks waiting for the IT department to set up my login. My boss was an idiot who couldn’t understand the simplest differential equation, and we spent most of the time in pointless meetings. Apparently I still had a lot to learn.
Since then I have worked for huge companies and small startups, on academic research and on freezing building sites. These pages list some of the things I’ve learnt about the non-technical aspects of engineering. None of the insights are new and none of them are my ideas, but they have taken me many years of work to collect.
#1: Read XKCD
XKCD is essential weekly reading for geeks.
#2: Back up your work
Sooner or later your laptop will spontaneously combust or get left on a train. Work on the basis that this could happen at any moment.
#3: Recruiting good engineers is really hard
Finding and recruiting a good engineer will take far more time and effort than you thought possible.
#4: Hire bright people who can learn, not experts
No job ever remains static, so the most useful attribute an engineer can have is the ability to understand new stuff quickly.
#5: Many of the best jobs are not advertised
Many of the most fun jobs are filled by word of mouth rather than through conventional recruitment.
#6: Customise your CV for each job application
This stuff seems like obvious common sense, but having sifted a lot of job applications over the years it would appear that it is not obvious to everyone…
#7: If you hate your job then stop moaning and quit
You only have one life and it may be shorter than you expect. Don’t waste 8 hours a day doing something you think is pointless. You can always earn more money later, but you can never get that time back.
#8: Fire useless people as soon as possible
Recruiting good people is hard, and sometimes you make a mistake.
#9: You have most energy in your 20s
Please don’t waste it doing a dull or pointless job.
#10: Don’t blindly accept the status quo
When you start a new job, the work is usually already in full swing and there is a lot to learn. Often the way certain things are done will seem odd or contradict your previous experience. There is usually a good reason for the choices they have made, so ask polite questions, try to understand the reasoning and in general go with the existing flow.
#11: State your assumptions
Every piece of engineering is based on assumptions. Write them down clearly at the start of any report.
#12: If they don’t understand, that is your fault
I was taught this on a Technical Writing course and it changed the way I thought about my audience, whether I was speaking or writing.
#13: Label EVERYTHING
This simple tip will save an amazing amount of time and confusion.
#14: You will forget what you did (so document everything)
As engineers we design and analyse things, so we are usually focussed on delivering a result of some kind.
#15: You will forget what you did (part 2)
The previous item talks about recording your assumptions and analysis when delivering a result. Another time when it is important to document everything is when you are testing or fault-finding.
#16: FMEA
Learn about “Failure Modes and Effects Analysis” and apply it to your designs.
#17: Be aware of the economics of the organisation
Don’t spend extravagantly just because it isn’t your money.
#18: Draw on a whiteboard in meetings
It is usually a lot faster to describe engineering problems graphically than verbally, but for some reasons many meetings don’t make use of this.
#19: Write lists on the whiteboard in meetings
Another time when the whiteboard comes in handy is whenever someone lists more than five things, particularly if the list emerges gradually during the meeting.
#20: Corporate IT will waste a huge amount of your time
If you work in a large organisation you will probably be issued with a standard Windows laptop with the standard corporate image. If you can do your entire job using only Microsoft Office then this is great (or at least adequate).
#21: Trace faults methodically
Sooner or later you will spend time attempting to work out why a system isn’t working. After you’ve poked it a few times and it definitely doesn’t work, start working methodically rather than just randomly changing things in the hope that you will fix it.
#22: Swap for known-good parts
A standard technique for fault finding, but one which requires care.
#23: Use binary search for faultfinding
You typically have a chain of subsystems to work through. You could work your way logically along the chain, starting by checking the output of the first stage and then moving on to the next. However, it can be much more efficient to start by checking the output somewhere in the middle of the chain. Hopefully this will immediately tell you which half of the system your (first) problem is in. You can then repeat the process to isolate the fault.
#24: Insist on completing timesheets accurately
Consultancies and larger companies usually make you fill out a timesheet recording what you have done each day. There is often pressure to fudge or lie so that it looks like you are super-productive and your manager is amazingly accurate at predicting how long each task will take you.
#25: Build something as soon as possible
You learn far more from building a rough mock-up and playing with it than just speculating, even if it is extremely primitive.
#26: Define the problem in one sentence
What fundamental problem does your design solve? Or what question does your analysis answer? If you can’t write it in one sentence then perhaps you don’t have a clear understanding of what you are trying to achieve.
#27: Capture requirements in a structured way
I use the term “requirements” to mean criteria against which a product or project will be judged a success or failure. If you can capture all the customer’s requirements before you start then the project is much more likely to succeed.
#28: Expand the problem to expose solutions
Actually, this one was taught in my university course, but it is still very useful.
#29: Try to answer the question on the back of a fag packet
An order-of-magnitude estimate is often good enough to answer many questions, or at least to discount possible solutions.
#30: Keep designs as simple as possible
Always look for the simple, elegant design solution.
#31: Always look for the 80/20 solution
The “Pareto Principle” became very fashionable a few years ago, and it can definitely be useful to remember.
#32: Learn about Poka-Yoke
This was part of the Japanese manufacturing craze a few years back, but it is definitely worth keeping some of the principles in mind when designing anything. It basically translates as “idiot-proofing”.
#33: Consider security from the beginning
This mainly applies to electronic and software systems, but can apply in other domains.
#34: Design for installation and maintenance
As engineers we tend to focus on the normal operation of our products, but for many products the main human interaction will be during installation and maintenance.
#35: JFDI
Sometimes you need to analyse every option and optimise everything to the nth degree. Other times you’d be better off just making a decision and moving forwards even if it isn’t perfect.
#36: A task needs an owner and a deadline
If you want something to happen, you need to make a single person responsible for it and agree a deadline.
#37: If they don’t write it down, assume they won’t do it
People forget things. If someone agrees to do something but they don’t immediately reach for a pen to write it down*, you should work on the basis that they will either misremember what you wanted or forget about it altogether.
#38: Only agree to realistic deadlines
If you know you can’t deliver by the end of June, say so up front even if it means annoying your boss or the customer.
#39: If you want me to do this, what should I drop?
People keep giving you stuff to do. Each individual task is doable and has a realistic deadline, but cumulatively you can’t actually deliver them all without working 30 hours a day.
#40: Give lots of presentations
At university and as a graduate, presenting to a group of people was always billed as A SCARY THING which we should get really nervous about and avoid at all costs.
#41: Learn to write
You might be a competent engineer, but if you can’t spell or use an apostrophe then I’m going to assume you are an idiot until proven otherwise.
#42: Learn to write well
Writing clear and readable technical documentation takes time, practice and skill. Learning that skill is a vital part of becoming a good engineer.
#43: Read Strunk & White
Start your quest to become a good writer by reading a small book called “The Elements of Style” by Strunk & White.
#44: Be consistent when writing
In technical writing, ignore the normal guidance about using synonyms to make your writing less repetitive. If you mean the same thing, use the same word.
#45: Write “tech notes”
This tip completely changed the way I work.
#46: Write most of the report before doing the work
Please try this once even if it sounds weird!
#47: Avoid being a bottleneck
Some people like being the only person that can do a particular task. Some even claim that it makes them indispensable and therefore keeps them in a job. This is nonsense and you should actively avoid being the only person that can do any given task.
#48: Delegate as much responsibility as possible
Remember Tim Ferris in the 4-Hour Work Week book. He had an online business and had outsourced his customer service, but got 200 emails a day from the customer service agents asking permission to refund customers, re-ship products, etc.
#49: Delegate even when you can do it better yourself
This is obvious in theory but hard in practice.
#50: Check delegated work at an early stage
If someone is doing some work for you, it is often worth checking in with them about 10% of the way through the task to check that they have understood the task and haven’t hit any unforeseen problems.
#51: Are you accidentally training people to punish you? Bad dog.
This is my dog, Skip:
#52: Wear headphones, even if they aren’t plugged in
Most jobs nowadays are in an open plan office, which is terrible for getting any actual (“deep”) work done. So you need some headphones.
#53: Time yourself working
Yes, actually time yourself with a stopwatch.
#54: If I only do one thing today…
Several times per day, check that you are actually working on the right task by asking yourself this question:
#55: Your time costs more than you think
It took me years to believe this one.
#56: Don’t use Excel for everything. Learn Python.
It is always tempting to use the tools you know and have to hand. I once saw an engineer write an entire 2-d finite-element structural model in Excel, which was strangely impressive but incredibly slow and vulnerable to bugs.
#57: Always try to validate your predictions, even if the project has already finished
Engineering is mostly about using assumptions and models to make predictions. For example, we predict the maximum demand on a circuit, then size the cable appropriately based on a predicted voltage drop, predicted temperature rise, etc.
#58: Write in plain English
Never try to impress people by using lots of technical terms or acronyms in your writing or presentations. It is far more impressive to explain a technical subject in plain English.
#59: Be your own first customer
This is classic advice from the software/startup scene, but it can apply to other types of engineering too.
#60: When debugging, don’t get confused by collateral damage
Sometimes I waste hours trying to fix a problem only to find that I’d fixed the original fault ages ago and the system is now not working because of something I’d done as part of the debugging process.
#61: The instruction manual is dead
When I was a kid, every tech product came with a paper manual the size of a paperback novel. This even applied to consumer software like drawing packages and word-processors. Sometimes we even had to read parts of the manual to figure out how to make things work.
#62: Prune your ideas
Every year a fruit tree generates lots of new branches which could all bear fruit in future years. However, in order to get the best yield and the biggest fruit the grower cuts most of them off, leaving a few selected branches to grow strongly.