This is not a post about tech skills.
I'm not going to tell you about a new framework, library or exciting development. This post is about some changes you can make in how you think about your projects, teammates and approach to your work that will make a big difference.
If you're in a role that is focused on improving processes and making code more efficient, it can be easy to forget that there are people behind the project.
When the pressure is on, or the code you're reviewing isn't exactly how you would have written it, keep in mind that there might be more to it. Before asking 'what were they thinking?', take a step back and remember that people don't code in a bubble. There could be other dependencies, managerial pressure or any number of things going on.
Chris does an excellent job in his post talking about how "we need to respect the constraints and context the person who wrote the code faced"
Team culture is incredibly important. You will typically spend most of your day with your team so it's in everyone's best interests to be a team player. Put your hand up to do those little things that make a good team great. Organise a lunch out together, take on a project to improve wellness, or give a colleague some feedback for a job well done. Lead by example and be a champion of your team.
It's an art and a science to estimate how long a technical task will take. It can be tempting to just get started or pull a timeframe out of the sky based on what you did last time. Even if you are repeating a similar task there could be other things in your way that delay delivery. Access to data or systems, a bug you couldn't see coming or conflicting priorities from management mean it's important to manage the expectations of your stakeholders.
It's something I am working on doing better and have enjoyed reading the suggestions from Vikash on taking a step back and a more considered approach.
There's plenty of posts and opinions on how much time you should put into professional development and training. Whether it's on your own time or you are carving out some work hours to get it done, learning about a new technology or language is an important part of being a developer.
I'm making this work for me by allocating four hours each weekend to watching conference videos, doing tutorials or building my side projects. Four hours works perfectly because it's about the length of time that my laptop battery lasts. Once the screen goes blank, learning time is over. This keeps me on task as I know I need to maximise my time before it's over, and stops me spending my whole weekend hunched over my laptop.
You learn when you teach, reinforcing what you know, and answering questions along the way. It's a great way to help others and to solidify the core concepts for yourself. It doesn't need to be at a conference of thousands either. Simply explaining a new concept to a colleague or blogging your experiences is an excellent way to do this.
Even if you are not officially a manager or a lead you can still make a difference to junior team members.
Ryan's post shows that you don't need to be an expert, your experiences are important and you're doing your part to lift up the whole team. Remember when you were a beginner how valuable the time you spent with those more knowledgeable was?
Let me know if there's anything you are planning on working on to improve your leadership skills and teamwork. And if you are looking for that post on levelling up your tech skills, this post is excellent.
This post first appeared on helenanderson.co.nz