7 Lessons from being a lead developer
By no means am I the best Lead Application Developer. But I have had the job for since 2014 and I haven't been fired yet. So I must be doing something right.
Lead Application Developer is one of those jobs I really had to grow into. Scratch that, I am still growing into it. I wanted to share X number of lessons I have learned for any future lead devs out there.
#1. Determine Your Leadership Style - lead from the front or from the rear
I was very lucky to work with two very good lead devs before getting promoted. The first lead dev I worked with did his very best to lead from the front. He was in the code as much as possible. Not every day, but the vast majority of days. The second lead dev I worked for was almost never in the code. He led from the rear with the gear.
Both leadership styles work. It is a matter of your personality.
It takes a certain personality to lead from the rear. You have to be very charming. You have to be a very effective communicator. You have build a fantastic core group of developers who think almost like you.
I tried leading from the rear. It failed horribly. I felt so lost on my own project. Not surprising. I like to think I am a pretty good communicator, but there is one thing for absolute certain. I am not a charming person. It took me almost 30 years to get my first serious girlfriend! I am most comfortable leading from the front.
#2. You won't have all the answers, but you can help get to the answer.
At least once a week one of the developers on the team calls me over to help solve a problem. Typically it is a problem they have been stuck on for a little while. By the time they call me over they know the code. They have looked at the unit tests. They have stepped through the code. But they still can't get over that last hump.
If I am very lucky they are in a section of code I help write.
Most of the time I am not lucky. I work on a large project with lots and lots of features.
When faced with a unfamiliar question I turn into a three year old. I ask one of the five W questions (who, what, when, where, why). A lot.
What is the problem? When did it start happening? What have you tried? And so on.
A good chunk of time the developer doesn't even need my help. They had the solution, they just needed a little prodding to get it out. Or they just needed someone to bounce ideas off of.
Other times we just need to sit together and see if we can come up with a plan of attack.
It freaked me out the first time I was asked a question I had no idea what the answer was. It was two days after becoming a lead dev. I was just finishing up work with my other team when my new team called me over. They asked a extremely technical question. The question boiled down to should we go with option A or option B. My first thought was "Holy SHIT, I have no idea what they are talking about." I just started asking questions to see if I could wrap my head around it. In the end option A was preferred they just needed to talk about it to make sure it was right.
#3. Be calm in the face of adversity
I worked with a developer whose favorite phrase was "Holy crap man, we are so screwed." Anytime anything difficult came up that was the go to phrase.
I also worked with a developer whose attitude was "Give me the details, we will figure it out."
Now ask yourself, which of the two developers would you want to work for?
It never does anyone any good to freak out. It amps up a already stressful situation to an even higher level.
And try to put yourself into developers' shoes. If you freak out over every little thing they are going to be wound real tight. Any little thing might cause someone to snap. I've worked with a developer who was so afraid to make mistakes he was paralyzed when he had to make a decision. It is okay to mess up. If the record gets deleted we have backups. If a bug happens it will get fixed. It is software development, something is always going to go sideways.
#4. Take the blame when something goes wrong, praise your team when something goes right
In other words, don't throw people under the bus. Don't. Ever. Do. That. Ever. Never. Ever. Unless you want to kill all the morale on your team. If that is your plan then go ahead and throw people under the bus.
Thankfully I have not yet worked for a manager since I graduate college who has done that to me. This did happen plenty when I worked part time in retail and fast food during high school and college.
When someone messes up they know they messed up. Unless they are a sociopath or a psychopath, they will beat themselves up enough. In some cases they will even say, "I'm so sorry, it won't ever happen again." And there is an extremely good chance it won't ever happen again.
My standard line is when confronted with a upset individual who is upset with a mistake my team made is, "I'm sorry it happened. My team and I will look into it right away and do our best to get it fixed."
On the flipside, don't take the glory. Everyone on the team works hard. Everyone on the team should feel appreciated. Make it a point to praise people on your team. Even a little praise goes a long way.
#5. Hold people accountable, but don't be their parent everyone goes tattling to
This has happened a few times, developer A finds out developer B didn't follow standards in some piece of code they wrote. Developer A asks me to swing by and look at developer B's code. I'm not 100% sure what their expectation is. Do they want me to chew out developer B? Burn off their fingertips? Break their thumbs?
Typically this comes about when developer A is fixing a bug with developer B's code. Most of the time they go the extra mile to get the code up to standard.
My standard line is something along the lines of, "please be sure to talk to developer B when you see them next and show them what you did."
A vast majority of the time, developer B may have forgot the standard, or it was done before the standard was in place.
In the past I sat down with developer B and had a talk with them. But it always devolves into "well developer A said this and developer A said that" and so on. Giving feedback through a third-part intermediary does not work.
Now at the same time if I come across some code developer A worked on that isn't up to standard then I'll bring them over.
#6. Learn to live with code not being written exactly how you want it to be
Every developer has their own coding style. Chances are it will not be similar to yours.
Work with the team of developers to establish coding standards the entire team is expected to follow. Everyone, or a large majority, should agree on the standard. Use code reviews to make sure the standards are met.
This was really tough for me to make my peace with. I wanted everyone's code to match mine. But that is just not going to happen. No matter how hard I force it.
For our team our rules are:
- Easy to read/maintain
- Follows standards
- Has good unit test coverage.
- Follows SOLID programming principles (single responsibility principle specifically)
As long as those rules are met I am good with the code.
#7. Distractions are a way of life
My job as a developer was a lot simpler. Pick up a story, work the story, finish the story. Very little distractions.
As a lead developer my work life is nothing but distractions. It is not uncommon to be responding to an email when an IM comes up from a developer and at the same time my boss comes over and needs to talk about something. It is the nature of the job.
The worst thing in the world is to get upset at those distractions. They are not going to stop. Getting upset will only make you more frustrated.
The human brain can only focus on one thing at a time. When more and more piles on just attack the pile as best as you can. The only way to get the pile down is to just dive in. Do the easiest one first. Or the highest priority. Reprioritize. Delegate.
Conclusion
Being a lead developer is a very rewarding time. It is also a very difficult job. Each day is a learning experience. I'm by no means perfect. I still make mistakes. I try to learn from them. These are just some of the lessons I wish I knew going in.