How to code like a team – SPOFing in coding alone
By Sigurður Baldvin Friðriksson
In my professional career, I’ve been a team member, a manager and had a variety of responsibilities for assignments and projects. My team experiences have been outside of the tech industry, ranging from a stint at a pizza place to a local computer hardware reseller. It has been informal for the most part and very collaborative and had a flat hierarchy. Here are a few words about how to code like a team.
Often experience took lead over role.
In software development the process has been “We have an idea, let’s make it happen!”.
This freedom can be nice to have as one can decide on how to build, however it comes with drawbacks, such as running into weird issues or not understanding something. Then having to do a bit of googling and try different things until it works. This can be time-consuming and frustrating.
How to code like a team
I dream of a world, where I can bounce ideas off of colleagues and they can help me with the answer.
However, that has not been my experience which brings me to the title of this post “How to code like a team”, am I a seasoned expert in team management? No. Caveat: The below is a survival story and is best avoided in the long term.
The daily routine
Try your best to brain dump what you do every day – tasks should live outside of your head!
This is good advice for anyone, regardless of how large your team is. Popular project management tools allow you to put comments and thoughts into tasks and this provides a timeline for task progress and helps you follow up.
“Hot-fixes” tend to be more common than we care to admit and they tend to become “cold-fixes” as more tasks are completed to advance development. Since you are the sole proprietor of the advancement of the project, any backtracking, refactoring or documentation feels like stopping a fully seated bus during rush hour to clean the dashboard properly. It’s not that you shouldn’t do that every now and then, however, the timing tends to feel wrong. It’s always rush hour for people that are paying you to finish the project, so take the time to fix the issue. Most projects underestimate the time allocated in the scope anyway, so add more time to your estimations and remember, set time aside for refactoring and backtracks.
“Doing agile development is the king of the development process” – I don’t disagree. However, it also takes enormous discipline to maintain one-person teams for weeks on end. What helps with maintenance is doing stand-ups 1 or 2 times a week just to make sure you are on track. This may seem silly but it works – although your progress may vary.
You might have realized that since you are the only one working on the projects, you have to do everything. The upside of doing everything yourself is that you learn a lot of different things. Who would have thought setting server permissions could be such a thrilling experience after implementing your very rough, paper prototype (granted you didn’t just skip a step during the agile process)? Congratulations, you are now the fullest stack developer!
The single point…of everything
Now, imagine this. You find yourself sitting in a lawn chair, drinking a cold beverage at around noon, the sun is shining and you are enjoying your vacation, when suddenly *buzz*…*buzz* “System A isn’t working and we can’t do the thing, can you fix it”. You begrudgingly open your personal laptop because “Work should only happen at work, you don’t need a work laptop” but you knew better. A new hot-fix or server restart later, you reply “fixed” and carry on with your vacation. This is the single point of failure aspect of this post.
Some of these texts can wait and often they do. But it can drain you. You think about work for a couple of minutes or hours, thinking about what went wrong or imagining a solution to the problem, remembering that temporary “hot-fix” you made.
Bugs and issues can become very personal, since – well – you know that there isn’t anyone else that contributed to it. My solution to this problem is very simple but hard to execute. The “it’s nothing personal, kid” mindset. Bugs, weird issues, and interactions are a part of software development, no matter how experienced you get or how strict your testing process, something will inevitably slip through and cause issues. This happens at any team and company size. You just have to document the issue, provide a fix, and re-deploy.
Expectation management
You are a singular person with the same amount of time in their day as the next person, set realistic expectations to all stakeholders, and remind them if they don’t have the budget for additional people (or simply don’t want to add more people) that the project will likely take more time than with added resources. With these words I hope you have gained some insights into how to code like a team.