Re: Working Solo and in a Team

[afoken]

"Managing developers is like herding cats."

I had a huge amount of luck in my first job to have a manager who was perfectly able to "herd cats". He created a, let's say, protected environment in which we "cats" could work undisturbed from corporate politics and management games. He was the interface between us developers and the rest of the company, talking "management speak" to other managers and talking "developer speak" to us. As a developer, he was not more than average, but excellent as a developer manager.

These conditions allowed good team work in a very competitive company environment. On the day he left, we hacked the intranet, his mental child, to show a black ribbon on the logo.

I left a few years after him, got a few other jobs, the previous and worst one lead by a perfect example for the Peter principle: An old guy at the dead end of his career, lacking both development and management capabilities, who got his management position simply by the fact that he "founded" the IT depeartment in his younger years. His main work principle was to start extinguishing the largest fire first, whatever that may be. As soon as that fire is reduced, the now largest fire has to be extinguished. Feel free to imagine how software looks and works after three decades in this environment. You won't even come close to the sad reality.

In my current job, my manager is one of two company owners, the other owner just gives his name and title. We are a very small team, creating high quality hardware and software for environments where bugs can hurt or sometimes kill users of our devices. We work in a very familiar atmosphere, and this is intentional. New interns and job candidates are choosen not only by qualification, but also by how good they fit into the "family". If you are the perfect developer, creating perfect, error free software in no time, but behave like an asshole, you won't be hired.

We split the software into parts during the design phase, and only one developer is responsible for implementing one part. Peer-reviews are part of the development phase. Bug fixing is often done by the responsible developer, but any developer with some free time fixes bugs in any part of the software.

During development and debugging, we discuss problems quite often, so that each developer has at least a good idea of how other parts of the software work. "Pair programming" happens only spontaneously, mainly during debugging. The fact that both developers know how the software should work, but only one knows the exact implementation at that time, is helpful. It naturally makes the other developer ask for implementation details, and forces the first developer to rethink how his code works. My manager also works as a developer, and so his work is subject to peer review and pair debugging as any other work.

Management of developers feels like it does not happen. We have a lot of freedom, and we are very aware that this freedom is not standard. At the same time, we are very aware of the fact that bugs could kill. We take a lot of responsibility. And I think this is part of how to manage developers.

You can't do a good job as a developer in a team where management does a bad job. Micromanagement is as worse as ignoring the problems of the developers. A manager who thinks is job description is "drill sergeant" won't be able to manage a team of developers. Developers are at least as individual as cats can be.

So, in one sentence, to work as a developer or programmer in a team, you need a good manager.

Alexander

[perldigious]

...a manager who.. created a environment in which we... could work undisturbed from corporate politics and management games. He was the interface between us developers and the rest of the company.

Nailed it, but this is only half of what makes a great manager in my opinion, essentially "letting as little of the shit flow downhill as possible". The other half is always making sure your team is enabled as much as possible to do what they need; that they have necessary resources, equipment, etc., and don't waste their own time having to find ways to do so themselves or otherwise find workarounds.

I had one manager like this in my career, and God help me I miss him. I stay in touch and still tell him so from time to time.

Micromanagement is as worse as ignoring the problems of the developers. A manager who thinks is job description is "drill sergeant" won't be able to manage a team of developers.

Nailed half of it again. The other half here is when said manager refuses to accept responsibility for failure and instead blames his subordinates and/or predecessors. I've also had one manager who exhibited these behaviors.

"I'm a genius and always the smartest person in the room. I also am the greatest expert on every topic ever as soon as I've thought about it for at least five seconds, none of my subordinates could possible know more about anything than me so I should always be micromanaging them and telling them exactly what to do in every situation, and if you think what I said blatantly makes no sense that's just because you are so simple compared to my vast intellect. Well, if we failed in our goals it's obviously the fault of all my various subordinates and not me, because after all, I'm awesome; in fact it's ridiculous they haven't made me CEO of this company yet! Almost all of my subordinates hate me, give me horribly unflattering feedback, and want me fired? Well this is obviously just a culture problem I've inherited from the previous manager, so the problem now is obviously all of my subordinates, it couldn't possibly be me, I reiterate, I'm awesome! Now excuse me, I have to go give completely undeserved promotions to literally the only two people working under me who do nothing but kiss my ass and inflate my ego."

[afoken]

The other half is always making sure your team is enabled as much as possible to do what they need; that they have necessary resources, equipment, etc., and don't waste their own time having to find ways to do so themselves or otherwise find workarounds.

You are right, and I really forgot that.

I started my first job as an intern, and during the first months, we (the team) noticed that database performance was less than optimal. I googled a little bit, read everyone recommending to use a Sun + Solaris as the base for Oracle, instead of x86 + NT. So I scribbled a three page Powerpoint file, showing the current NT database box as another application server, and a Sun in the center, running Oracle. Expecting nothing but a "nice idea, but we can't afford that" or a "we are a Windows company", I showed my manager that three pages. He asked what that Sun is and what it costs. "Umm, let me google that." A few days later, he told me "your Sun is coming." Imagine my face. I was about to ask "are you kiddin' me?", but he simply ordered that machine and the required software, for a five-digit number. And boy, it was fast! During the next weeks, we reorganized the servers and integrated the Sun, as a wrote in that Powerpoint file. End of performance problems.

Still makes my smile.

I had one manager like this in my career, and God help me I miss him.

I know what you are missing. Same here, for several years.

The other half here is when said manager refuses to accept responsibility for failure and instead blames his subordinates and/or predecessors. I've also had one manager who exhibited these behaviors.

"I'm a genius and always the smartest person in the room ..."

Luckily never met one of those, except perhaps in a failed job interview.

Alexander

[eyepopslikeamosquito]

He was the interface between us developers and the rest of the company, talking "management speak" to other managers and talking "developer speak" to us.

Good point. See also The Development Abstraction Layer by Joel Spolsky.

[afoken]

eyepopslikeamosquito++, can't upvote that as often as I want.

Programmers need a Subversion repository. Getting a Subversion repository means you need a network, and a server, which has to be bought, installed, backed up, and provisioned with uninterruptible power, and that server generates a lot of heat, which means it ... and if your programmers even spend one minute thinking about this that’s one minute too many. To the software developers on your team, this all needs to be abstracted away as typing svn commit on the command line. That’s why you have management.

Funnily, we are just building a nice little server room, based on my requirements (listed while emulating a sysadmin). One big project is done, other projects are still waiting to be started, so we have some time to polish our machines and our infrastructure. I know that all of my ten thumbs point to the right, but they are sufficient to hold parts of a drywall while a skilled worker gets rid of other parts of the drywall to make room for the server rack. So currently, I'm a developer emulating a sysadmin emulating a craftman's helper. That's ok for a day or so, and avoids reloading slashdot or perlmonks every five seconds. ;-)

Alexander