Be your own first customer

This is classic advice from the software/startup scene, but it can apply to other types of engineering too. It is far easier to build a great product if you build something which is useful to you, not what you imagine someone else needs.

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. You usually have to assume some level of prior knowledge, but if in doubt write as if the audience is slightly less knowledgeable than …

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. The project often ends at this point.  We’ve done the modelling and produced a result or a design.  We …

Time yourself working

Yes, actually time yourself with a stopwatch. We constantly estimate how long things will take, mostly subconsciously, and it can be eye-opening to measure how bad our estimates are. Start by estimating how long a particular task will take. Ideally choose a task in the 0.5 to 2 hours ballpark. Then start your stopwatch and …

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. If you are any good at your job, you …

Write “tech notes”

This tip has completely changed the way I work. A Technical Note is essentially an informal written report.  The idea is that you can publish a tech note on any topic you choose, whenever you like, with no review process and no bureaucracy. For me, they have replaced having a lab book to record day-to-day …

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. If you talk about a spade on one page and a shovel on the next, are you just being careless or do you actually mean different tools? Any increased readability …

Read Strunk & White

Start your quest to become a good writer by reading a small book called “The Elements of Style” by Strunk & White. If you can’t afford £7 for a paper copy, there seem to be various PDF versions on the internet, although I’m not sure how legal they are.

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. Take time to revise as you write.  Read and re-read each paragraph, out loud if necessary.  You are aiming for something concise, readable and unambiguous, which is a lot harder than it …

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.


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. The skill is obviously in knowing which is appropriate for your current situation. If your personality naturally inclines you towards one or the …

Consider security from the beginning

This mainly applies to electronic and software systems, but can apply in other domains. Thinking about security from the outset is obvious in hindsight.  Adding security later is often awkward and sometimes impossible.

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”. Essentially you need to consider what someone could do wrong at every stage of manufacture, installation and use, and try to prevent it …

Keep designs as simple as possible

Always look for the simple, elegant design solution. Anything complex is likely to be difficult to design, fragile to operate and expensive to produce. It is often ok to sacrifice a small amount of performance if it lets you achieve simplicity.

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. “Could we use a counterweight? … quick calc … “yes, but it would weigh about ten tons so we wouldn’t be able to carry it in the van” … discussion moves on to other options.

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. Often you’ll discover that the part of the design you thought would be the crux is actually easy or doesn’t matter, but that some other aspect you’d overlooked is actually the hard part.

Swap for known-good parts

A standard technique for fault finding, but one which requires care. Eliminate possible causes by swapping parts of the system for known-working replacement parts, ideally taken from a supposedly-identical system which is working correctly. If the parts are expensive or you don’t have many left, be careful because a fault elsewhere in the system could …

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. See also you-will-forget-what-you-did-part-2/ about documenting this process.


Learn about “Failure Modes and Effects Analysis” and apply it to your designs. Spending time considering potential failure modes is always worthwhile. You don’t have to create a big spreadsheet like the formal FMEA process does, though a simplified version of this is actually surprisingly useful on many projects. Often the most useful ideas to …


This simple tip will save an amazing amount of time and confusion. If you are testing three widgets that all look the same, they get labels. If you discover something is broken but you can’t immediately bin it, it gets a massive label saying “BROKEN” so that someone else doesn’t waste an hour discovering the …

State your assumptions

Every piece of engineering is based on assumptions. Write them down clearly at the start of any report. Unless you are terrible at maths, if someone disputes your results they are probably working from different assumptions. If you haven’t made clear what you assumed then this can result in a long and confusing argument. Where …

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. Occasionally you need someone who has a lot of very specific experience, but most of the time I’d much rather have a fast learner who can teach themselves anything.

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. Store your actual work in a central location (company server or cloud) rather than having the only copy on your computer.  This also goes for any important data that you …

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. XKCD is also essential weekly reading for geeks.