This post is taken from a presentation I made welcoming a new intake of excited young people on EDF’s Data and Tech Graduate scheme.
10 things that made me a good software engineer
This is a subjective list of some of the most important things I learnt throughout the last 17 years of trying to be a good software engineer.
Aside from a software development associates degree which provides knowledge needed for a career, this is a subjective list of some of the most important things I learnt throughout the last 17 years of trying to be a good software engineer.
1. Be honest about what you don’t know
Imposter syndrome has always haunted me so regardless of if it was true or not I always felt there was someone smarter than me in the room. I learnt early on that it was far better to ask questions rather than stress about not understanding something or trying to manage someone else’s expectations around what I was doing. As I’ve progressed through my career I’ve come to understand the truth in the statement “The more I learn, the less I know”. Don’t be afraid to say you don’t understand or of asking for help.
2. Be open to learning and helping others
Software engineering as a discipline moves very fast — you need to stay current. If you are honest about what you don’t know then when you share what you learn others will be more open to receiving it.
Don’t fear mistakes, they are great learning opportunities. On the flip side of this, as you progress don’t chastise others for making mistakes. A blameless culture is one where everyone levels up. All the highest performing teams I’ve been a part of have valued helping each other learn and grow. Psychological safety has been a key factor in identifying successful teams.
3. Challenge your norms and be open to change
It took me a long while to figure this one out. I like to feel comfortable, and familiarity makes me feel comfortable. Don’t sleep walk into decisions, choices and maybe more importantly behaviours. Just because you’ve always done something a particular way doesn’t mean there’s not a better way to do it.
Much of what we do in software engineering is subjective (technology choices, languages, tooling, code style) so listen to other’s opinions.
4. There’s always more than one way to do something
Similar to challenging your norms, software engineering is largely about making stuff up as we go along. Changing requirements, finding more efficient or resilient solutions, defects and bugs — they will all impact how what we build might change over time. So build as little as possible and don’t be precious about what you do build.
5. Don’t always be chasing shiny new things
Although this might seem to contradict the last 2 points, it’s important to recognise there is a balance that needs to be found between learning / exploring and delivery / stability. Choose where and how you apply your learning — a new business critical application is probably not the best place to use a new alpha technology with little support, knowledge or documentation. Many technologies have been around for a long time for a reason — they solve a problem and solve it well and have often built up a large community of support around them.
As an engineer I focus a large amount of time on learning foundational principles and staying up to date with that thinking. This really helps me evaluate new technology choices against established options.
6. Always look to improve things
Every system eventually sucks. Every system has bugs — you just haven’t discovered them all yet. Don’t worry about perfection, strive for continuous improvement.
Having a mindset of iteration will allow you to break things down and constantly be hitting milestones and moving forward.
7. Learn when to stop
Commercial software engineering is a balance between time (cost), purity (quality) and solution viability / practicality / pragmatism. Learn to compromise — no system is perfect.
This isn’t to say you should build something rubbish just to save time, I believe we all have an obligation of professional integrity that should respect quality.
8. Experience beats book smart
As someone that didn’t enter software engineering through a traditional academic route maybe I’m biased here but I definitely believe the best way to learn is to do. I learnt so much going down the rabbit hole of bug fixing a legacy application I had no hand in building. Even just the process of how to debug efficiently and play detective. All those bugs you fix will be filed away in your subconscious for the next time you say “ooh, I’ve seen something like this happen before”.
9. Become a good communicator
Communication is a skill that can be learnt. As a contractor I was often responsible for all the aspects of the project I was delivering and I learnt how much it had an impact on both how I was perceived and how successful the project I was delivering would be.
Being a good communicator is also about being a good listener, you need to REALLY listen to what your stakeholders are asking for as it’s not always what they are saying. Being a good communicator will help ensure the requirements are correct and the solution you build meets them.
10. Software engineering is about humans
At the heart of everything we build as software engineers is other humans. Ultimately we exist to deliver some value FOR other people. That value could be as a platform team enabling other software engineers, a contributor to an open source library used by other engineers, or part of a team building a web application used by millions of people.
You should find a way to become a positive contributor to the humans that are impacted by whatever it is you build.
