Seventeen 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 Dilbert and XKCD

Before I went to university someone gave me a book of Dilbert cartoons. I thought they were ok, but assumed that the world could not possibly be like that in real life. Then I went to work in an engineering office.

Continue reading…

#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.

Continue reading…

#3: Recruiting good engineers is really hard

Finding and recruiting a good engineer will take far more time and effort than you thought possible.

Continue reading…

#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.

Continue reading…

#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.

Continue reading…

#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…

Continue reading…

#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.

Continue reading…

#8: Fire useless people as soon as possible

Recruiting good people is hard, and sometimes you make a mistake.

Continue reading…

#9: You have most energy in your 20s

Please don’t waste it doing a dull or pointless job.

Continue reading…

#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.

Continue reading…

#11: State your assumptions

Every piece of engineering is based on assumptions. Write them down clearly at the start of any report.

Continue reading…

#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.

Continue reading…

#13: Label EVERYTHING

This simple tip will save an amazing amount of time and confusion.

Continue reading…

#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.

Continue reading…

#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.

Continue reading…

#16: FMEA

Learn about “Failure Modes and Effects Analysis” and apply it to your designs.

Continue reading…

#17: Be aware of the economics of the organisation

Don’t spend extravagantly just because it isn’t your money.

Continue reading…

#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.

Continue reading…

#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.

Continue reading…

#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).

Continue reading…

#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.

Continue reading…

#22: Swap for known-good parts

A standard technique for fault finding, but one which requires care.

Continue reading…

#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.

Continue reading…

#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.

Continue reading…

#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.

Continue reading…

#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.

Continue reading…

#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.

Continue reading…

#28: Expand the problem to expose solutions

Actually, this one was taught in my university course, but it is still very useful.

Continue reading…

#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.

Continue reading…

#30: Keep designs as simple as possible

Always look for the simple, elegant design solution.

Continue reading…

#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.

Continue reading…

#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”.

Continue reading…

#33: Consider security from the beginning

This mainly applies to electronic and software systems, but can apply in other domains.

Continue reading…

#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.

Continue reading…

#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.

Continue reading…

#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.

Continue reading…

#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.

Continue reading…

#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.

Continue reading…

#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.

Continue reading…

#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.

Continue reading…

#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.

Continue reading…

#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.

Continue reading…

#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.

Continue reading…

#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.

Continue reading…

#45: Write “tech notes”

This tip completely changed the way I work.

Continue reading…

#46: Write most of the report before doing the work

Please try this once even if it sounds weird!

Continue reading…

#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.

Continue reading…

#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.

Continue reading…

#49: Delegate even when you can do it better yourself

This is obvious in theory but hard in practice.

Continue reading…

#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.

Continue reading…

#51: Are you accidentally training people to punish you? Bad dog.

This is my dog, Skip:

Continue reading…

#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.

Continue reading…

#53: Time yourself working

Yes, actually time yourself with a stopwatch.

Continue reading…

#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:

Continue reading…

#55: Your time costs more than you think

It took me years to believe this one.

Continue reading…

#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.

Continue reading…

#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.

Continue reading…

#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.

Continue reading…

#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.

Continue reading…

#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.

Continue reading…

#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.

Continue reading…

#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.

Continue reading…