Trial & Tribulations of a Lead Developer

[Elle Atechsy]

Hi All,

I've been a web application developer for 6 years. I've been a lead developer for about 5 of the 6 years due to being catapulted into the position because someone from our team left, and no one else took the initiative.

Although, I love the chanllenge of being a lead, I'm finding the larger the application, the harder it is to keep control. About 2 years ago, our team went from using TCL/Vignette (non-OOP) to using Java/JSP. It was new to all of us. I've learned a great deal (Thanks JavaRanch!!) but, I still have soooo much to learn. That being said, I find that our apps encounter many issues that could have been avoided if we had just follow some standards/best practices.

I have read about standards and best practices, but I find that it seems like way too much work for a lead developer, who also still develops, to keep track of.

In your experiences as technical leads, did you do, or make sure all of the following got done, while trying to meet deadlines that the clients would not budge on? If yes, did you have some sort of strategy?

- Business requirement analysis
- Functional specs
- Technical specs
- GUI prototypes
- UML diagrams (which seems to become HUGE and Un-readable the larger the applicatio is)
- Learning (even after 2 years of learning, I still don't know quite a bit due to lack of time, and not knowing what to learn first)
- Coding
- Team mentoring & guidance
- Code reviews
- Product testing (before sending to the QA team)
- Meetings
- Application production support


Oh, and I forgot to mention, although many of the items above may be successive in the SDLC, but imagin that we are jugling multiple apps/releases, which are in diffent stages of the SDLC. Of course, if it were only one thing going on at a time, I think it would be much easier. But does that ever happen?

Can anyone recommend how can a lead developer, who is not an expert at Java, quickly gain and maintain control of their application in a non-control freak like way?

Any feed back would be greatly appreciated.

Thanks,
Lulu

[Jason Cox]

- Business requirement analysis
Yes, I've had to do this though generally it is has been handled by an architect on most project I've worked with. Even so, no matter what level I've been at, developer, senior, or lead, I have ended up involved in this process. I generally attend all the meetings, no matter how much I don't want to, take my own notes, and try to see how my perceptions of the requirements line up with what the customer is telling me. I've always found it good to be involved in this process even though it can be a huge time sink.

- Functional specs
No, generally an architect has supplied the initial specs. I may have had to make modifications later in the project, but that was about it.

- Technical specs
Same as functional specs. Though there have been times when we've had to supply initial expectations to the architect before they could begin work on the specs.

- GUI prototypes
Yes, but I don't know if this is typical for lead developers or not. I have extensive GUI experience, so it's often easier for me to bang out the prototypes, present them to whoever needs to look at them, and then hand them off to other team members. I do think that if you end up with some screens that are similar in look-and-feel that it might be wise to do one yourself and then have someone else develop the similar screen so that they can get some experience building these.

- UML diagrams
No in general. Typically an architect has handled the UML, however when I played "army of one" developer I did the UML myself. I have also seen it handed off to a senior developer on some projects. I think anyone with a good understanding of the high-level architecture should be able to do this.

- Learning
Yes. I typically learn by doing so I simply load up some API's and get to coding. When I get stuck I look for some examples and then try to figure out how I can make it work in my specific circumstances, especially since most example code is extremely contrived. In general you have to continue learning no matter what your position. Even people who end up in management seem to continue taking courses, reading books, and attend seminars.

- Coding
Yes, I haven't been hands off yet. I've never had a problem with coding though since it's just something I do whenever I'm not doing coding tasks. The biggest challenge I face is getting into a good "flow" when I work since I tend to get interuppted a lot more than when I was just another line programmer.

- Team mentoring & guidance
Yes, and I think this is one of the most essential roles of a lead developer. Generally speaking I let my people do what they think is best, I'm not going to make fine grained decisions for them. I do like to take a look at their actual code and will often make suggestions for better maintainability. Really, my best mentoring opportunities have been giving tasks to junior devs that I would normally handle myself. Helping them work through issues and answering questions that seem basic to me but maybe aren't to them. The hardest part is tearing yourself away to help out those that report to you. I know being a lead means you're probably working on 20 different things at any given time, but I always stop what I'm doing so that I can make eye contact and talk to my people. Of course, I don't spend a lot of time with senior devs other than make sure they're still on track or that they have something to do. I may be lucky, I tend to work with highly talented people so I don't have seniors that demand a lot of my time.

- Code reviews
No, so far this has been handled by an architect on every project I've worked on. I did code reviews on one project but there was no architect, there was no lead, and I was there not just as a developer but also as a consultant so it was kind of expected.

- Product testing (before sending to the QA team)
No, generally speaking I and everyone else are expected to perform individual unit tests. I did tend to test code sent to me by teammates but it was usually a less intensive test to make sure all the obvious stuff worked. So while I did do more testing than the people working for me I wasn't doing intensive testing on anything but my own code.

- Meetings
Yes, and they can be managable. I know this can be a major time sink but sometimes having the lead there is as much for assurance as it is for their input. Generally my metrics for meetings were to attend every one that was relevant to the project and try to attend every one I was invited to. If a meeting was not 100% relevant, I could get the information later, and I had a deliverable that was high priority than the meeting was not attended. How well you can do this depends on the confidence level your management has in you. For instance, if I were to skip a meeting at one client the assumption was simply that I had something more important to do than the meeting. I was given a lot of credit for my priority-setting. However, I still attended as many meetings as I could get away with because I know it's important to build up some credibility with management.

- Application production support
Yes, generally speaking if I was involved with coding it I ended up supporting it at some point. As time goes on and products became more stable, support and sales staff became more familiar with it, the time needed to support it decreased.

I know that being a lead is challenging and demands you wear many hats. I don't envy you having to take on a lead position so early in your career, but I can say that it is only by being challenged that any of us ever become good at our jobs.

Your best overall strategy is delegate whenever possible, get your people involved in the process. You're the lead, so you make the rules and your primary job is making sure those rules are enforced. On the first team I was the lead on, a position I pretty much took for myself since everyone senior had left, I established coding standards and presented them to the team. I was working with a team of mostly experienced developers, so I had very little guidance required. I took advantage of my new position to do some pretty radical things with the architecture and was able to tell the QA team to do full regression testing without having to get authorization. While I was busier and had more expectations, I was able to leverage my experience and position to get better results. In the end I had a very satisfied client.

Generally gaining control of any project is about knowing your teammates. Some people need very little guidance and some people need a lot. Some people just want lots of attention so they feel validated. If you find yourself swamped, get an experienced developer to mentor one of your junior people. Pair them off for awhile even if you're not a paired programming shop. I have not worked in a paired environment for awhile, but I am a big believer in collaboration. The lead developer does not have to be the one doing all of the guidance and mentoring, leverage the experience of your team to help train others.

Of course if you're team is entirely a bunch of college grads you may want to work on the more promising ones first and hope they can help train others later.

[Elle Atechsy]

Jason,

Thank you very much for your very detailed reply.

Lulu

[Srikanth Raghavan]

Wonderful explanation Jason.... A superb crash course on becoming a better software lead I guess.

I am just a developer now, but I would like to store this link and I will keep it safely in my tips folder and I would come back and read this when I become a lead.

Thank you!

[Jesus Angeles]

Also, if you have people who are dependable, you can go forward more easily. By delegation, you are able to manage bigger projects.

Hopefully, you have the appropriate hire-and-fire authority.

I am saying this based on my experience. I gave someone a task that is supposed to get 4 hours load off my back. The output was garbage and ended up adding more hours on me.
[ October 22, 2006: Message edited by: Jesus Angeles ]

[Jason Cox]

Interesting that not too long after I posted the initial response it was confirmed that I will be the technical lead on my next project. This will be the first time I start out in that position. In the past it has been something I took on as time went by.

Some more guidance I'd like to offer is this -

Lessons learned from a junior developer

and also see my comments in this thread about forgiveness

forgive and forget .... or ... not ???

plus for bonus points my comment here as well

Making friends at Work Place

I think that's a pretty comprehensive view of my experience from a "soft skills" perspective.

Personally, despite the challenges, I am looking forward to starting out as the tech lead this time instead of moving into the role later in the project. Even as I get less "hands on" I enjoy having more control over the technical direction of a project. Sometimes the best way to ensure a project meets the quality standards you'd like to see is to be in control of it.
[ October 22, 2006: Message edited by: Jason Cox ]