What I Learned From the Lead Developer I Never Want to Work With Again
As developers, it's important to keep learning and one of the best ways to learn is by learning from others. And so I was recently placed on a project led by a senior developer (a contractor) with 10+ years of experience. My excitement level went through the roof as this present me with the perfect opportunity to grow.
But instead, it made me want to quit coding! Let’s talk about what happened.
In this project, we were creating a client login portal in which the clients with different access levels (e.g. admin, support, etc) are able to select dates/times and some other options to book a service they require. Once chosen, those selections will then call an API to check a list of available staff able to work the shift of the booking.
That doesn’t sound too difficult, right? But it was a disaster and the contractor Lead Developer was let go for making little to no progress after 4 weeks.
Here’s what I observed going wrong and what I learned in the process:
Lack of Planning
Planning is so important in almost all everyday tasks so when it comes to coding things like complex data flows and multiple components with different behaviors, it's really important to plan. Lack of planning leads to a lot of back and forth changes and that's exactly what happened.
What should we have done?
- Gone through the project design and made a list of all the components we needed to build if they weren't available in our components library.
- Set the ground rules as to what linter we will use.
- Make a list of the endpoints and use postman to check the shape of the data. If not available mock it — No hard coding.
- Create JIRA tickets to keep track of the tasks required
Hopefully, that should be enough to get started. A plan is better than just jumping into code.
Diminished the importance of creating GOOD Jira tickets
I have a JIRA board even for my personal projects. It helps me keep track of all the tasks I have left to do to reach my desired goal. Writing tickets is more than just explaining what task/feature needs to be developed. A good JIRA ticket leads to better-made components and more thorough unit tests.
Unfortunately, this developer’s approach was to just give JIRA tickets titles. It was self-explanatory he said.
I believe that good JIRA tickets are tickets that:
- have a heading that briefly describes the feature,
- Gives an overview of the feature
- Lists the various requirements of that feature
An Example of a good JIRA ticket (from one of my personal projects) would be:
As a user
I want to choose a different alarm tone
So that when the alarm plays, I hear the tone of my choiceACGiven that I am on the page
When the page loads
Then I can see a dropdown list of different alarm tonesGiven that I select a tone from the list
When I click on the play button
Then I can hear the sound of the tone I have selectedGiven that I have selected a tone from the list
Unfinished Pull Requests
I’ve always lived by a certain rule: Don’t PR if it's not finished. In some cases, this might not be possible especially if an endpoint for an API isn’t ready yet but what I like to do is after mocking the data I remove the mock data so at least the PR goes into the
develop branch as fully ready for when the API is complete.
Unfortunately, this developer left a whole load of
Todos commented out all over the place and merged them into the develop branch. This caused conflicts and left a lot of unfinished work and led to some unexpected results.
What we should have done?
- Keep PR’s small so as to avoid lots of Todos
- Finished the PR 😂
Thankfully I was still able to benefit from this experience. I learned that having good practices in place before jumping into code can make the process of coding so much easier. We hired a new developer who follows all these practices and I feel so much better about coding.
Hopefully, this post gives a small insight into what can be done to achieve better results. I hope that one day when I have to lead a project, I’m able to remain open to suggestions.