In this blog post, Nicky Thompson, Engineering Manager, shares a few simple tricks and tips learned over the years, which helped her be a better software engineer.
This blog post is a write up of a talk Nicky gave at LRUG in July 2020. To watch the video of that talk, check out the LRUG website.
“Perfect is the enemy of good”
“In his writings, a wise Italian says that the best is the enemy of the good” — Voltaire
The first time I heard this phrase I got very excited, because it changed the way I approach how I do my job. Something clicked in my brain and I thought, “Wow, this is going to make the rest of my life so much easier!”
As a front-end developer I’d often fallen into that common trap of wanting to make everything exactly pixel-perfect every time, and the effort had started outweighing the benefit. When I heard this phrase I realised it was more common than I thought!
Looking back at my career, I realised there have been a few times I’ve had that feeling about some advice I’ve been given, or some random comment a colleague made at work. A piece of advice or comment that turned out to be so game-changing for me and really levelled me up in my career.
This blog post is a ragtag bunch of the most useful things that had that effect on me and helped me do my job better.
Some are practical tips and some are more philosophical insights or just things people told me that I found helpful. These are things I have actually done throughout my career. They are tried and tested! I’m hoping by sharing these they’ll help you too. So let’s get started.
Ask for help
I know, I’m sorry, it sounds so trite and obvious, but it’s true. Sometimes it’s due to imposter syndrome or lack of confidence, but I’ve often put off asking for help and banged my head against a problem for a long while, thinking I should be able to solve it on my own. Other times it’s because I wanted to learn by solving it myself.
But eventually I realised that asking for help isn’t a sign of my engineering weakness — it’s a sign of my engineering maturity. By asking for help when I need it, I know that my ego isn’t at play, that I want the best solution for the problem in a timely fashion, and hopefully I can still learn from my colleagues.
Don’t take this to mean that you should never try to work anything out for yourself, and to always ask for help right from the off. Definitely roll up your sleeves and get stuck in and try to work it out yourself first.
But also set yourself a timebox. If you’re still not sure of the approach after your set time — might be an hour, might be 15 minutes, or a day, up to you, then ask someone.
If the idea of asking for help freaks you out and you think, “Oh, my colleague looks busy”, or “Hmm, I’ve already asked this person for help twice today…”. Don’t ask them for help, ask them for advice.
Ask for advice
I found this mind-bendingly useful. Think about how you feel when someone asks your advice, and they’re asking about your favourite subject, it’s something you know loads about and you’re perfectly placed to help them. You feel smart, right? And flattered, that they’re asking you — people love being asked for advice!
So maybe thinking of it like that will help. But also maybe before you do this:
Try to rubber duck! There’s a reason this is such a cliche and a trope. It totally works! The idea of rubber-ducking is this: you explain the problem to somebody else and suddenly you realise what it is you’re trying to solve. That act of having to explain it crystallises the understanding for you and helps you get to the answer on your own. So instead of asking for help or advice, you explain your problem to the duck first and see if that helps.
I have done this countless times. I have many rubber ducks. Maybe now you’re working at home you don’t need a duck — if you have a pet, or a plant, explain the problem to them instead.
The idea of the breadcrumb trail is to leave yourself a trail pointing you back to your work, like Hansel and Gretel in the fairytale leave themselves a trail of breadcrumbs to lead them out of the forest.
Tom Stuart mentions a similar idea in his talk Get Off The Tightrope (which I recommend watching, it’s really good).
So I always leave myself a “breadcrumb” — something still to do when I leave work for the day. In Tom’s talk it was a friend of his who says he never leaves his desk without a broken test, so there’s always something to easily hook back onto when you get back. I would just make sure I left something unchecked on my todo list.
So when you get back to work after lunch you don’t have to think, “hmmm… now, what was I doing?”, you have this obvious string to pull on, or a breadcrumb trail leading back to what you were working on.
This is my way of saying: “GET ORGANISED”. Write stuff down. Make notes of things to come back to. Get in the habit of it. This gets the incidental random stuff out of your brain so you can concentrate on what you planned to do.
For example, if you’re working on something and you come across some other code you don’t like the look of, you don’t have to stop and refactor it immediately, you can put it on the list, tell your future self what you saw and what you wanted to do about it, and carry on with your life. It’s out of your head, safe on the list, and you can continue with what you planned to do when you first sat down at your computer.
All of the best developers, designers, product managers and CEO’s I have ever worked with in twenty years have all had some form of this habit.. They are super smart people I would work with again, they are effective, they get stuff done, which makes other people want to work with them more, and working with them made me much better at my job. This habit turned me from a “sure, fine” engineer to a “wow, this person gets things done!” engineer.
As with all advice, take this with a pinch of salt, your mileage may vary. Some people don’t like to do this. If your anxiety level of leaving something undone is higher than leaving a broken test to pick back up in the morning then maybe this won’t work for you — but try it sometime if you haven’t.
Do something else
While we’re talking about flashes of insight, I think this is a legit problem solving mechanism: to do something completely different. If you’re not in a company or a team where this is ok, you could try to find one. Do something else. Go for ice cream, go for coffee, go for a walk, make a phone call. If you’ve left your breadcrumb trail and taken those notes, you don’t need to worry about forgetting anything, and as a plus you’re priming your brain to work on the problem in the background.
I am absolutely not advocating that you go home and continue to think about work! But maybe you’ve had that experience of working on a complicated problem, and it’s only when you do get home and start making dinner, that you get that flash of insight and that eureka moment. So take a break, get your head out of the problem and sometimes the answer will come to you.
If you’re a software engineer, the likelihood is that you’re working from home a lot now, and hopefully as we’re all also working during a pandemic, your employers are giving you some leeway about what hours you’re working and when. So don’t feel bad about getting away from your desk — it’s a good way of getting a little distance from a problem in order to solve it.
Perfect is the enemy of good
There’s a reason there is the cliche of the developer who massively over-engineers things that never get used. I know! It’s really difficult not to be a perfectionist!
Forward thinking is important and quality is important, but you can go too far. Please don’t take this to mean you should make something bad! You should try to do good work, but it doesn’t have to be super super super perfect with all the beautiful refactors before you ship it. It just has to be good enough to get the job done. What is the job that you’re trying to do? Have you done that with this piece of work? Good job. Go do the next thing.
How do you develop this sense? That’s the hard part and there’s probably a whole other talk in it. Just being aware that this is a common trap is a great start.
You have the power
This is tricky and it took me a long time to realise it. It’s your hands on the keyboard. You have a LOT of power in the relationship of who builds what and when. You’re the one who is closest to the work that needs to be done. If you start building something and you get that spidey sense and think: “hm, this needs refactoring before we can work on it”, then do it!
Put it on your todo list and do it. Nobody can stop you from writing code.
Or if you think: “hm, this is probably not going to work for some reason”, whether it’s a technical reason or an ethical reason, tell someone. Nobody can force you to write code either.
Part of the process of growing as an engineer is realising that and figuring it out with your team and testing it.
CAVEAT: This advice works better for some people than others, if you are in an environment where you’ve seen people get punished or reprimanded for speaking up or asking difficult questions then obviously you need to protect yourself first. I hope no one reading this is currently in that kind of environment.
Get some sleep
There is a lot of research about sleep and stress and their effects on work, some of it shared and linked in this Twitter thread. There are whole books and papers studying the quality of code in software engineering, and I think the results hold true for any type of work.
From that Twitter thread, summarising some of the research: “your sleep quality and stress level matter far, far more than the languages you use or the practices you follow”.
The terrifying thing I found out from reading more about this, one of the biggest factors in improving code quality is not pairing or testing or language, or the seniority of the engineers on the team, it’s how much sleep you got the night before. The only other thing that comes close to having the same impact is code review.
I was both surprised, and not surprised, and also quite horrified by this research. Ever since I read about this I’ve been telling anyone who will listen because it’s so weird and true.
If you’re interested in finding out more about this, there’s a fascinating book called Why We Sleep that goes into detail about how sleep helps us learn, the effects it has on memory and recall, and more. Building the habits I’ve shared today have definitely helped me relax more outside of work and get better sleep — for example, feeling that I don’t have to lie awake worrying I’ve forgotten something, because I’ve left it safe on the list for the morning.
These are some of the tips and tricks that I’ve found helpful to keep in mind during my career as a software engineer. I hope they help you too. Thank you to LRUG for having me and thank you for reading.
What‘s the best piece of advice that you’ve gotten over the years that have helped you become a better software engineer? What things did you wish you had heard earlier? What’s your best tip for people new to the tech industry? Next week we’ll be asking these questions to our engineering team — so stay tuned to hear more!
If you’re interested in joining the FutureLearn Tech Team, we’re currently hiring for several roles (a Technical Lead, a Front-end Technical Architect, a Data Engineer and an Information Security Manager), which you can see on our jobs page.