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.
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 means it’s important to manage the expectations of your stakeholders.
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 is perfect 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?