5 Rules for Software Engineers to Live By
Software Engineering and the Technology industry in general is varied, with many opinions, legacy and rapid innovation.
In the midst of all this, there are 5 simple rules which hold true to every Software Engineer at any level in any industry.
1. Question Everything
As Software Engineers we are there to deliver business value, help our team realise our goals and deliver value for our end users. If you are discussing a proposed priority as a team, a piece of work, no matter how big or small you must always be questioning everything about that proposal until you understand the value it brings to the organisation or how it moves the needle on your team’s goals.
If the value is not clear and doesn’t make logical sense, at least at a birds eye view for smaller initiatives, then you should resist prioritisation in favour of something that has more proven value.
2. Always Ally with Product
Product will be your greatest friend. They are extremely good at identifying what success looks like, communicating with stakeholders, understand business priority and then communicating that. If you have ever worked with a great product person before you will completely understand the value they bring.
You should always ally with them not resist them, like I have witnessed in previous organisations. Work with them to understand what the benefit is for the user. Work with them on the best way to communicate project wins. Work with them on aligning team goals to business goals. There input will 10x your teams trajectory.
3. Keep it Simple Stupid (KISS)
This applies to your code, architecture, communication, metrics, proposal and just about everything that you will do as a Software Engineer.
Don’t look to overcomplicate a solution to account for variables that are not true yet or have no measurable way of even being remotely true. For example, in a startup don’t jump straight to microservices. It’s very likely a monolithic architecture is the right solution here for speed of development.
This is true in communication as well. Write up your comms, then try to shorten it whilst keeping the same output. And then do that again until you cannot shorten it anymore and you have kept the core information on progress, goals, metrics etc.
4. Be Selfless for the Team, Be visible
You need to be there for your team, being selfless to help achieve the team goals and deliver value the customers and the business. You also need to be visible, and highlight your contributions for those crucial levelling discussions and promotion opportunities.
One way you can do this is to create a ‘brag sheet’. This can be a simple word doc where you set time in your diary every friday to fill out with what you did that week that you thought would be great to discuss with your manager. This can help with managing up. This also helps you not have to try and remember everything you did when the important conversations happen (which they should be regularly via 1-1s, appraisals, levelling discussions etc). I have had many situations where I am twiddling my thumbs trying to remember everything I did, and forgetting about loads of the great stuff I did.
5. Always Expect to Pivot
We have all been there, we have become attached to what we are working on, and then we need to suddenly move to working on something else.
You cannot get to attached to the direct project you are working on. The reality is in business that priorities change for varying reasons constantly. I encourage you to actually think of this as a positive because it shows that your organisation is willing to change direction in order to unlock value and grow.
You must always expect to pivot what you are working on at any point. This doesn’t mean you shouldn’t commit or be less innovative or strive less for your team’s goals.



I would add to the fifth one - be ready to pivot and throw away work 😅
It happens that you develop something that fails. As long as it was relatively quick, and not a huge project - that’s ok, it’s part of our job. Get something fast in front of the customers, receive feedback, and decide what to do.
Often with engineers are frustrated when a project they worked on is stopped in the middle. This is actually a good sign - it you never had to change plans, it means your product is bloated with useless features
It's interesting how all the 5 rules are not tech-specific but communication rules.
- Communicate to ask questions and seek the truth
- Communicate with the product and don't be in a cave
- Keep your communication simple. Clarity of mind -> Clarity of code
- Communicate your achievements
- Understand when things change. Communication is not only talking but listening.
If I were to add one, I'd add learning. Learn to communicate, learn new technologies, and learn the responsibilities of other roles.