3 tips on becoming a better software engineer

Success in software engineering means different things to different people. With technologies and methodologies changing at such rapid pace it becomes almost a given that to succeed you need to be constantly improving.

As a software engineer who's worked in a variety of roles over the last 15 years I thought I'd share a few tips which I feel have helped me become a better at what I do.

Embrace learning

The nature of modern software engineering is that it's a fast moving beast. With constant change comes the need to keep ones skills up to date. Being open to learning new things is a core tenet of becoming a better engineer. You should strive to be curious about all parts of the stack as well as technologies outside your current sphere of knowledge.

If you are a frontend engineer it's easy to throw up your hands and say "I don't care what happens on the backend! That's not my problem!" but you'd be doing yourself a disservice. Knowing how things work beyond your area of expertise makes you a better more rounded engineer.

With knowledge comes intuition. Tips and tricks you may learn in one programming language or framework are often transferrable to other languages. Why choose a relational database over a NoSQL database? What's the trade-offs between the two? How does my browser interpret JavaScript? What's an interpreter? Why might I choose a compiled language over an interpreted one? Ask questions. Seek answers. Be inquisitive.

I like the analogy of building a wall. Brick by brick your learnings support more complex knowledge and ideas. Imagine learning algebra without first learning arithmetic. The arithmetic brick supports the algebra brick. Likewise in software engineering, fundamentals like algorithms, data-structures and design patterns are all important foundations to build further knowledge upon.

How you learn new things is really up to you. From books to video courses there's a slew of resources for learning almost anything. Every little bit counts.

Take breaks

Ever been so stuck on a particularly gnarly coding problem or bug that you lose track of time only to come back after taking a break and find a solution almost immediately? In the book A Mind For Numbers, author Barbara Oakley Ph.D posits that our brains have a 'focused mode' and a 'diffuse mode' which she compares to the strong beam of a flashlight versus it's soft wide-angle mode. Our brains are surprisingly capable of working out complex problems in this 'diffuse mode' so taking breaks often is a must. A change of scenery can do wonders for unsticking your focused brain and make it open to new pathways of thought.

Get up and go for a walk (outside if you can). Stretch. Run. Talk to a collegue. Whatever. Give your focused brain a small break and you'll often be surprised how time away from a problem can send you down a different path towards a solution.

Accept you don't know everything

Not all problems have single solutions. Our own congnitive biases can sometimes cloud our better judgement and prevent us from seeing solutions tangential to what we perceive as "right". Perhaps there's been times where you have gone in head-first to tackling a problem only to be presented with an unequivocally better solution by a fellow engineer?

Software engineering is in many ways a solo endeavour. The stereotypical aloof, hoodie-wearing hacker isn't too far off the mark for some. Though perhaps that's why it's at times important to try to step outside ones comfort-zone. People are naturally conflict-averse so putting ideas out there to be picked apart and criticised can be a scary endeavour. However in my opinion it's in this sharing of ideas where magic can happen. It gives our laser-focused frontal lobes a deserving reality check when we realise we haven't necessarily considered all options.

The takeaway here is to be cognizant of potential biases in your thinking. Get up and speak to other engineers on your team and discus how they might tackle a problem. Doing so may help shine a light on things you've completely overlooked. This is especially important for Junior engineers as getting buy-in on a given direction can save time for everyone when it comes to accepting pull requests. Perhaps a colleage might have a completely different take on a solution or even raise concerns over things like security which you may not have considered.

Conclusion

Software engineering is more than simply writing code. Having a thirst for self improvement and acknowledging your cognitive biases are imperative in becoming a better software engineer.

Photo by Bill Jelen on Unsplash