10 Lessons from an Accidental Engineer
Growing up, my ambitions changed from wanting to be a teacher, an astronaut, and a dancer to a physicist. But I never wanted to be an engineer — my dad is one and I wanted to be different. Today, I am a software engineer at Google. In the last ~2 years, working on ground up implementations, I’ve dabbled in frontend, backend, data and everything in between.
I’m an accidental engineer, and a fairly mediocre one at that. Here’s a collection of mistakes I’ve made innumerable times. Maybe that’s why you might find this post helpful.
Well, I am not really an accidental engineer for I do have a degree in Computer Science. I call myself an accidental engineer only because almost all through my college, I was prepping for an entirely different career path until the pandemic changed things (And also because it makes the title sound nice).
Nonetheless, writing this helped at least one person watch herself!
Observe the best at work.
I’m often amazed at how the best engineers are able to consider all the moving parts of the system, timeline restrictions and prioritise tasks or decide when and which shortcuts to take. Or how they are able to swift through hundreds of lines of logs across multiple tools to fix an inscrutable bug. Magically, they seem to know where to look! Like most skills, this is built on years of practice and discipline. Observe the engineers around you at work — How do they organise their work? Pester them to gain insights on how they think — How do they break down complex problems into mutually exclusive, collectively exhaustive sets? Be that junior who asks too many basic questions.
You have a lot to gain and very little to lose. Be stupid more often. Ask that silly doubt in the group that has too many people. Make mistakes. It’s easier to ask for forgiveness than permission.
Others aren’t as “smart” as you think they are.
There’s very little that you must “obviously” know. Most context is gained over time. While it’s easy to feel out of the loop, and assume every one else on the table is smarter than you because they seem to grasp things quickly, It’s likely that they have more context on the system. If it is a small group meeting, never leave the meeting without really understanding the problem that is being discussed. Ask questions, if you’ve been added to the meeting, you are meant to be there. You are wasting people’s time not by not asking questions but by not understanding. Do not walk out of a meeting without understanding everything.
Question Everything.
If you’ve been given a task, ask why — don’t take it as a given. Systems are made by humans, they should be questioned, understood and changed if needed. I’ve noticed myself (incorrectly, sometimes) assuming — “I’m sure they’d have good reasons for doing it this way”. Once you treat the system as a work in progress, you will try to solve the problem in the most efficient manner, instead of restricting yourself to a specific part of the system. Sometimes you’ll find crucial holes in the system, or simpler and scalable way to solve the problem; But at all times, you will learn.
Own your project.
You are the only one responsible for your project. If your task is to plant the crop, it is your job to ensure the soil is ploughed. Be proactive in checking for the dependencies and dependants. The right time to surface the uncertainties and blockers was yesterday.
Own your career.
Only you are responsible for your career — not your manager, however nice they may be. Ask. Be proactive in asking for feedback. Write the feedback down, and ensure you’re working on them. Ask for the next project you want to work on. Talk about your career ambitions, and help your manager help you.
Get Organised
The crucial part of ownership is to plan. While you might feel inundated by the scale of the project, take a day or two before starting the implementation to understand the task. Break it down to know the blockers, and estimate timelines, even if it is tempting to jump to implementation.
Document everything — from the issues you faced, the reading material, progress to the commands you run. Document the reason why you took a certain decision. Document the learnings.
Communicate
Poor communication is a top reason why projects fail. Share you work while it is in progress. Let the team know if / when/ how you are stuck rather than doing it in a silo hoping to be able to give one grand update.
- You’ll get help, learn some of the work you’re doing probably doesn’t need to be done in the first place.
- Your manager can sleep in peace because they don’t have to be worried about constantly checking on you. They know you are owning it.
- The other dependencies can plan their work accordingly
Build Discipline
This is cliche for a reason.
- Spend some time in retrospect— What could you have done better, faster knowing what you know now?
- Resist, resist the temptation to push things to later when you can go in your hole and read up and gain all the background context — that never happens, especially on weekends! Consistent tiny steps will take you far.
- Never work from bed. If you can, go to office more often.
It’s easier than you think
I often feel “I don’t know this.” Now that can be demotivating. You might try to find shortcuts like trying to copy the code from somewhere, or just procrastinate.
What’s the minimal POC you can do? Now read the documentation and tackle it one tiny step at a time.
Systems are complicated
You’re most likely going to wonder why the project took so long. At least for some of us, self deprecation comes really easy.
Focus on learning. If you got it right 100%, it wasn’t challenging enough anyway. If it helps, build your personal wall to track your progress to motivate yourself.
Just be kind to yourself. You’re better than your worst fears.
Like all advice in the world, this isn’t a one tool fits all. Pick and choose what makes sense to you! And if you find this useful, hit follow and subscribe. It goes a long way in encouraging me to keep writing :)
You can also find me on twitter @jnkhyati and medium Khyati Jain
