Posts Tagged 'Management'

Dealing With Arrogant Passive-Agressive Programmers

I don’t know what it is about programming and software engineering, but these two fields seem to attract a significant number of people with some serious personality issues.

One of the types I’ve encountered on a regular basis is what I call the APAP, or Arrogant Passive-Agressive Programmer. These are the people who will go in and rewrite existing code just to show off how clever they think they are, but can’t be bothered to document what they did or why. Heaven forbid that they should go and actually talk to the original author of the code before making changes to it. Another variation on this is the person who won’t talk directly to the person originally responsible for the design or the initial code, but instead go to the group manager, or someone not even directly associated, and discuss issues and changes with them instead.
Continue reading ‘Dealing With Arrogant Passive-Agressive Programmers’

Learning to Listen

Long ago I once worked on a long, complex project where the manager I reported to was probably the most mismatched person for the job that I’ve ever encountered. The tragedy is that I didn’t realize that until much later, after I’d already started pulling my hair out in frustration.

He had a favorite expression he’d use during almost every meeting: “I’m wrestling with…” where whatever he was wrestling with was typically something that the other engineers in the room didn’t seem to have any real issues with. It took a while, but then I finally realized that it wasn’t just a figure of speech; he really was having a tough time with it. This person didn’t have an advanced engineering degree and very little hands-on experience with complex electronic equipment and the software necessary to operate it. His background was in network administration. Yet he had somehow managed to get himself into an engineering management role.

The whole experience really drove home to me the fact that people will tend to let you know early on how well they are suited to their current role by how well they handle the cognitive challenges within the problem domain of the job. And they do it unconsciously, all you have to do is listen to them.

I try to be a better listener these days.

Slow Poison

There are many ways sure-fire ways to make certain that a software project dies. The well known (and well discussed in numerous books and articles) ways include being over-budget and/or late, delivering buggy code due to inadequate testing, and tyring to create something complex with little or no requirements, plan or discipline.

These are the ways of the quick death (mostly).

There is yet another way, even more insidious, to kill a software project and any future prospects for future re-use. It can be like slow poison, sometimes taking full effect long after the finished code has gone out the door. Its effects can linger far longer, tainting anyone associated with the project.

I’m referring to documentation. Yes, that stuff with all the words that many developers detest.

The documentation I’m thinking of isn’t just the user’s manual. It’s all the words necessary to define, implement, verify and re-use software. It’s everything that describes the project and the code that will result from it. It’s the detailed requirements, the design documentation, the test cases and test procedures, and, last but not least, the comments in the code itself.

There seems to be a trend nowadays to refer users to the source code if they have questions about how to do something with a particular piece of software other than just use it as-is out of the box. This seems to be particularly common with interpreted languages such as Python, Perl and Tcl. It never fails to annoy the hell out of me when I’m trying to use something and I get the point where the skimpy documentation states “refer to the source code for details”.

No. I refuse. That is a waste of my time, and a rude and inconsiderate stance on the part of the developer. If that person really wants me (and the other busy folks in the world) to drop their software and go in search of something else, that’s an excellent way to do it. Even if I can’t find something that has all the features of the rude-boy code, I’ll go with the alternative anyway if it has good documentation with it.