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.
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.
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.
Finding and recruiting a good engineer will take far more time and effort than you thought possible.
No job ever remains static, so the most useful attribute an engineer can have is the ability to understand new stuff quickly.
Many of the most fun jobs are filled by word of mouth rather than through conventional recruitment.
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…
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.
Recruiting good people is hard, and sometimes you make a mistake.
Please don’t waste it doing a dull or pointless job.
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.
Every piece of engineering is based on assumptions. Write them down clearly at the start of any report.
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.
This simple tip will save an amazing amount of time and confusion.
As engineers we design and analyse things, so we are usually focussed on delivering a result of some kind.
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.
Learn about “Failure Modes and Effects Analysis” and apply it to your designs.
Don’t spend extravagantly just because it isn’t your money.
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.
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.
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).
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.
A standard technique for fault finding, but one which requires care.
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.
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.
You learn far more from building a rough mock-up and playing with it than just speculating, even if it is extremely primitive.
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.
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.
Actually, this one was taught in my university course, but it is still very useful.
An order-of-magnitude estimate is often good enough to answer many questions, or at least to discount possible solutions.
Always look for the simple, elegant design solution.
The “Pareto Principle” became very fashionable a few years ago, and it can definitely be useful to remember.
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”.
This mainly applies to electronic and software systems, but can apply in other domains.
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.
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.
If you want something to happen, you need to make a single person responsible for it and agree a deadline.
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.
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.
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.
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.
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.
Writing clear and readable technical documentation takes time, practice and skill. Learning that skill is a vital part of becoming a good engineer.
Start your quest to become a good writer by reading a small book called “The Elements of Style” by Strunk & White.
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.
This tip completely changed the way I work.
Please try this once even if it sounds weird!
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.
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.
This is obvious in theory but hard in practice.
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.
This is my dog, Skip:
Most jobs nowadays are in an open plan office, which is terrible for getting any actual (“deep”) work done. So you need some headphones.
Yes, actually time yourself with a stopwatch.
Several times per day, check that you are actually working on the right task by asking yourself this question:
It took me years to believe this one.
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.
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.
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.
This is classic advice from the software/startup scene, but it can apply to other types of engineering too.
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.
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.
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.