What I Learned From the Lead Developer I Never Want to Work With Again

Photo by Ryan Snaadt on Unsplash

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:

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.

There was no talk of how the project will be structured or if we’ll use JavaScript or TypeScript or what style guide we’ll use; sass or Styled Components or even which linting process we should go with. Of course, we had a Standard Coding Guide which I followed but unfortunately, this developer didn’t and so that led to clashes 😬 and in the end, throwing away a lot of code.

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.
- Decide on the technologies: TypeScript or JavaScript, sass (BEM or not?) or Styled Components, etc
- 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.

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 choice
ACGiven that I am on the page
When the page loads
Then I can see a dropdown list of different alarm tones
Given 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 selected
Given that I have selected a tone from the list

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.

A frontend developer with a passion for Javascript and React. I write on Medium to learn from others and share what I've learned along the way

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store