Software project managers must handle difficult application developers

Software project managers tend to work with a variety of applications developers and have to deal with multiple personality types. It’s important to handle each of them appropriately.

Application developers, in layman’s terms, are folks who can take business requirements and translate them into a working product using specific programming languages or by applying minor tweaks to packaged software. Project managers are the folks who make sure those software developers stay on track and deliver high quality applications on a timely schedule. Project managers tend to work with a variety of applications developers and have to deal with multiple personality types.

In my experience with working with a multitude of software developers I have found them to fall into one of the following categories:

  1. The developer who has a holier-than-thou attitude
  2. The developer who really shouldn’t be a developer
  3. The RockStar


The developer who falls into this category can be identified by their:

  1. Rather overly presumptuous belief that they are God’s gift to the technical world
  2. Overwhelming conviction that they know the requirements best, they know the clients best, they know the solution best, they know the technology best… well, you get the drift
  3. Thinking that business requirements are an unfortunate thorn in their path to attaining technical nirvana

The developer who really shouldn’t be a developer

Lack luster programming skills, convoluted logic in their code, and inability to produce a “Hello World” statement – makes these developers stand far out from their brethren. Sometimes, though not always, these folks may have attained their credentials via fly-by-night technical schools or in some cases may even be self taught. In an unfortunate failure of the recruiting process, these folks slip through the cracks and end up on a project that you may be involved with. (Shoring up the recruiting process – now, that’s the subject for another article altogether)

The Rockstar

These folks, ironically enough, may be tougher to identify than the two categories of developers highlighted above. These are the kind of developers who have a true passion for what they do, get under the skin of the requirements and the business process, question the logic of requirements, and keep usability at the forefront of every solution that they develop.

I have been fortunate enough that I have had more than my fair share of “Rockstar” developers – which is not to say I have not had my run-ins with the first two categories.

Dealing with dubious developers

So – how do you deal with the first two categories of developers – short of pulling your hair out? The answer is simple – Nip it in the bud.

How do you deal with difficult developers? 
Nip it in the bud.


Whether you are dealing with a "holier-than-thou developer" or a "developer who really shouldn’t be a developer" – it is infinitely less painful in the long run to sit the developers in question down and address the root of the problem.

A lack of technical skills can sometimes be overcome by training – provided your project timelines and budget allow for it. It’s more difficult to find a satisfactory solution to the developer who exhibits the holier-than-thou attitude.

The solution is akin to removing a band-aid. Deal with the termination or transition of the developer's responsibilities swiftly – even if it will mean a short term hit to your project.


Finally, let’s not forget the rockstar. They need to be encouraged to take on more responsibilities, acknowledged for their contribution to the project, and in general made to feel like their input counts.

To all my rockstar developers – Thank you!

Dig Deeper on Java application deployment

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

In my opinion, I think every good and self-respecting developer may appear "holier than thou" if their manager is incompetent.

I for one have been in a situation in which my manager was a failed developer who quickly transitioned into being a manager with a high level knowledge of what is going on without getting dirty with code.

From her point of view, I was like a rebel (Because I emphasised the importance unit tests which goes against short term delivery time), but I had a developer which she preferred, even though, unknowing to her, I was the sweeper propping up my fellow developer to deliver his project on time(The guy just does what is requested without questioning logic), he believes doing that will keep him at peace with the manager, after all, the long term technical debt may be another developer's job due to regular job hopping. 

It will be interesting to see this issue from a technical manager that can get hands dirty when required. Developers live in a different world often not understand by mortals, so they are not just "holier than thou" to some people, they are "gods".

May I add that the developer eventually left the job so quickly( after like 3 months) creating a mess of a code due to unstructured code management regime.