So much of what we do as programmers, as software engineers, is social. And most of us, are not the most social people.
Programming appeals to the quieter ones. The thoughtful ones. The ones who perhaps don’t want to go out and party but are happier instead looking at the code, or searching for some solutions, or working with far flung groups of others on the internet.
Because software is social, but software engineers are not usually the most socially confident. We believe in the code.
So, what can we do to make our experiences better? If you’re aware of Conway’s Law – you’ll know that software architectures follow the communication patterns of our organisations. But what does it mean to have no opinion about these social interfaces?
Aren’t we as engineers missing out on an opporunity to find out what our software means to the world? And more to the point, should we care?
Unhelpful Frameworks
When we look at some of the complicated toolkits that we, as engineers and architects, get drawn into by our art – it’s obvious that we thrive on overcomplication. Starting with the huge choice of programming languages, front end frameworks, API design, database schemas and network protocols. Then let’s add in practices such as test driven development, behaviour driven development, unit testing practices, contract testing, integration testing not to mention all of the associated frameworks. Add in cloud architectures, infrastructure as code, DevOps tooling, CI/CD pipelines, YAML, JSON, Domain Drive Design, Wardley Mapping, even new theories that aim to simplify like Residues . None of these are simple concepts. You can’t take a new, young, software engineer with you on this journey. It’s too much to take in.
However, as senior engineers we seem to thrive in this messy world.
The assumption is that you need to have battle scars and you need to keep adding to the complexity. But often in the most successful products, there is clarity of technology and simplicity of stack.
It’s often true that the frameworks and patterns we have in place inherently overcomplicate our process of building cool software.
If we then add in all of the ‘usual’ processes around task organisation, sprints, meetings, planning and so on, we have an immense amount of cognitive load added to our software engineering lives through so-called helpful frameworks.
These are not helping us. These are working against us.
Helpful People
How do we navigate this complexity? By using people.
People help us. We ask for help, they can oblige. So rather than being alone with your browers, or alone with your GitHub Copilot or Stackoverflow, what about just asking someone?
The more I’ve worked as a manager, a leader, a team member, a consultant, an on-call engineer, I’ve learnt that we depend on each other more than we depend on the systems. Often the systems are unhelpful.
So what are the takeaways that we can use every day to make our lives and the lives of our colleagues better?
These are a few tips that I believe keep us pointing in the right direction. Despite whatever language, frameworks, way of working and challenges we have, as engineers we can make a difference every day by sticking to a few core principles.
Respect and Listen to Each Other
No matter what age or experience of your colleagues, show respect for their ideas and abilities. Not everyone expresses themselves well or in the same way, but often it’s useful to listen to what people are trying to say in the way that they interract with us.
For example, it could be that certain team members don’t always speak up in meetings. This is ok. Don’t pester them to contribute, at the same time, be aware that they might be showing their opinons in other ways through code, through documentation, through talking to other people.
Continuously Work on your Process
Whether you’re working in Scrum, Kanban, Scranban or even Waterfall, don’t let the process block the changes you want to make as a team. Ensure that there is no one person leading the conversation, and make sure there is the ability for the team to decide how the next period of time should look.
Fix things that are obviously broken or make sure you take responsibility to put it into your backlog and prioritise it.
Work with Customers
Whether you think you work in a customer-facing team or not, you will have customers. Even if you’re working in a platform team, those who consume your services are your customers, even if they are internal to your organisation. Spend time listening to their complaints and working with them to understand what you can do better.
Take an active role in working with customers to anticipate features and potential bottlenecks and even provide input on the product’s future. You’re working on something which other people use and validate.
Mentor and Be Mentored
Take opportunities to work with those who are more experienced with you but also take opportunities to mentor others. The moment that you stop learning is the moment that you’re opening yourself up to the idea that you know everything there is to know. No one person is that smart, particularly with our increasingly complicated systems there simply is no way of knowing for sure. What you can do though is work on learning more about what you don’t know.
Use this as an opportunity to implement better monitoring, better observability and insights into both your application state and status plus visibility on your development process and pipelines.
Beware though, observability is also a minefield of potential complexity. Implement what you need to make it work today, don’t worry about setting up a complex monitoring environment if you don’t need it.
Don’t Push Frameworks, Push Ideas
Rather than fixating on the latest framework or cool sounding way of working, focus on the ideas behind those frameworks. It’s more than likely that you already have enough technology in your stack which is already fit for purpose. A lot of the ideas that you think are new, are actually retreading and recycling of old ideas.
Search For the Connection Through Your Work
Underlying all of this advice is a common thread – listen and communicate with your colleagues. Don’t make yourself a silo, make yourself part of a team. There is nothing more rewarding than solving problems together and learning together. Software development offers us the ultimate opportunity to build high quality systems if we can treat each other with respect, keep our minds open and focus on delivering the best solutions to our customers with minimal overhead and complexity of process.
While this might sound simple, it places a large burden on the individual to stay alert and interesting not only in their own work but also in each other. It’s also important to realise that this won’t happen every day. Not everyone arrives at their desk in the morning in the same headspace, so rather than focussing on perfection, aim simply to take the time to look after yourself and look out for each other in the small things that you do.
Importantly, learn to enjoy your work and each other’s company. Software is a team game, and it’s one played by high-performing individuals. Respect them, respect yourself.