In my most recent position, a month after starting, I was promoted into the role of Lead Developer, in charge of 3, and at times, 4 other developers in the dev team. This was the first time I’d been the Lead Developer on a project (where I was not the sole developer). The project ran for a further 6 months and I learnt a lot in the process.
The core job description of the Lead Developer on this project was:
- Assign tasks to the 3-4 other developers
- Monitor the progress of those tasks and feedback to Project Managers (PMs), Account Managers (AMs) and other non-dev team members
- Try to maintain code-quality e.g. review Pull Requests (PRs), provide feedback to devs and approve/deny PRs
- Merge PRs into main code branch and update servers
- Be the voice of the dev team if there are any disputes about the work e.g. scope creep, unrealistic timelines
- Carry messages from non-dev team members e.g. PMs to the dev team
- Have the final say on coding decisions
- Presenting code demos to non-dev team members
- Keep (Quality Assurance Testers) QAs aware of progress AND finally
- Continue coding as usual
Okay, so, the last task is the hardest. When you are reviewing the PRs of 3-4 other devs towards the end of the sprint, trying to motivate them, trying to communicate their workload and your expected finishing times to PMs whilst trying to manage your own work was very stressful at times.
However, what I did enjoy was having some semblance of control over the final product and being able to say ‘we have coded this like that because of XYZ‘ and presenting that to UX/AM/PMs and generally being believed/respected.
Trying to maintain code quality
It was also incredible difficult to maintain code quality and speed of other developers; I wasn’t really prepared for this. When the deadline is looming and everyone is behind it became impossible to justify spending time enforcing specific coding guidelines like spaces before curly braces in JavaScript or alphabetised CSS rules and minimal nesting in Sass or that elements were exactly 20px apart or that the font size was supposed to be 11px and not 12px.
If I’d have had more time and more foresight I would have ruled with more of an iron fist in the beginning of the project which I feel would have prevented problems with the code further down the line. However, as I joined the team after coding had been started and I was then promoted after some code had already been written (in multiple styles), I did not feel practical to start refactoring every code after I became Lead. Nor was there the time.
Documentation >= code
Code is really important but keeping track of the code, documenting it and letting non-dev people know what’s going on is even more important. At the start, we were pushing, pulling and merging and trying to get our commit messages as good as possible but when you pass that on to a third party (or when you have a gap inbetween finishing the code and releasing it) you realise that you can’t remember exactly what has been changed and why.
Maybe 2 new functions have been added and 1 has been removed but why and what modules/pages etc does it affect? Why was the decision made to make those changes? If you don’t write it down someone will either override your changes later in the project because they don’t understand why a decision has been made or the end-client/non-dev team member will request a change that requires significant work because they do not understand the background.
Managing developers
Same goes for other developers, writing code when you are the sole developer is a very different proposition from writing code that a team of other developers have to understand, extend, delete, or upgrade. And part of the job of the Lead Developer is diplomatically trying to get all developers to appreciate this without causing offence – this was something I did not excel at, at first, and I admit that I found it quite uncomfortable trying to explain to developers (who had been on the same level as me at the start of the project) that they needed to improve. I like to think this is something I improved as the project wore on but that is for others to decide.
Agency development life
If you don’t work in an agency, it may be hard to understand how/why you have to make compromises on code quality. Every sprint (i.e. 2 week block of work) is timed and justified by the price paid by the client; if you slip on these deadlines and start falling behind the agency starts losing money.
It can be hard to justify to an agency that up-front costs are needed that may save costs down the line (e.g. setting up automated JavaScript testing, or properly planning all modules/components that the system will use before starting to code) because it’s hard to explain this to the end-client who just wants you to start coding and producing work straight away.
In different environments there isn’t always the same time-pressure and more of a focus on quality over speed can be used.
Occasional Tech Lead responsibilities
At times, when the Tech Lead was otherwise unavailable, I was also asked to take on some of their responsibilities for this project which included:
- Estimating development time based upon initial UX wireframes (this was prior to sprint planning with other devs where the timings were refined)
- Reviewing the end-client’s bugs and estimating time required to fix, whether bugs were really bugs or disguised scope creep
- Feeding back to the end-client on bug fixing status
Summary
I was very grateful for the opportunity of stepping up to be a Lead Developer on this project and whilst my next role will only be a Senior Developer and not a Lead I will be looking to be a Lead Developer again as soon as the opportunity arises.
I worked with some great people on this project and while at times the project was a slog, it was often a joy to come into work and spend time working with them.