|
Re: Working Solo and in a Team
by afoken (Chancellor) on Feb 15, 2017 at 07:19 UTC
|
"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
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] |
|
|
...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."
Just another Perl hooker - Selling my %hash for $cash.
| [reply]
[d/l]
[select] |
|
|
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
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] |
|
|
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.
| [reply] |
|
|
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
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] |
Re: Working Solo and in a Team (Psychological Safety)
by eyepopslikeamosquito (Archbishop) on Feb 18, 2017 at 00:58 UTC
|
I've had a bit more time to research Psychological Safety
in the workplace.
In the Building a psychologically safe workplace TED talk, Amy Edmondson
provides three examples of workplace silence, when voice was necessary:
- A night shift nurse, who feels the dosage looks wrong, considers calling the doctor at home to double check ... but remembers the disparaging comments he made about her abilities last time she called ... so she doesn't make the call, putting the patient at risk.
- A junior co-pilot, bullied relentlessly by his senior officer, becomes too frightened to question the senior officer's actions ... resulting in a fatal air crash.
- An executive, new to the company, is too scared to ask awkward questions about a proposed takeover that everyone else is enthusiastic about.
Why do these sorts of incidents happen?
- No-one wants to look ignorant and incompetent!
- Don't want to look ignorant? Don't ask questions.
- Don't want to look incompetent? Don't admit weakness or mistake.
- Don't want to look intrusive? Don't offer ideas.
- Don't want to look negative? Don't criticize the status quo.
The above "Impression Management" strategy for self protection works.
It turns out that humans have evolved to be pretty good at "Impression Management" --
in fact, most folks have mastered it well before they reach high school.
This matters because not asking stupid questions robs
an organisation of vital learning and innovation
opportunities.
Psychologically Safe Workplaces
Psychological Safety is a belief that you will not be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes.
In a psychologically safe workplace, you are expected to speak up!
For managers to create such an environment, Amy suggests:
- Frame the work as a learning problem, not an execution problem.
- We need everyone's brains and voices in the game.
- Acknowledge your own fallibility. Provide safety for speaking up.
- Be a model of curiosity. Ask a lot of questions yourself.
Note that "Psychological Safety" is orthogonal to "Motivation and Accountability".
Most organisations need both.
If you have neither, well, you just have apathy. :)
References
| [reply] |
|
|
| [reply] |
Re: Working Solo and in a Team
by nysus (Parson) on Feb 14, 2017 at 23:30 UTC
|
I'm not experienced in working with teams as a programmer, but what you experience applies to many other endeavors. What I really I think this comes down to is intrapersonal politics. It's a people problem as old as time itself. And I think an environment that makes one person thrive will probably make another wither. There simply is no one best way, no holy grail.
As an older person, my advice is not to focus on the perfect, but how to make the most out of the environment you are in.
Hopefully, at some point, you will find the perfect work environment that suits your particular style, like a soul mate. If you are a unique individual, like I gather most programmers are, I think that's probably rare, but I'm sure it can happen.
| [reply] |
Re: Working Solo and in a Team
by hv (Prior) on Dec 20, 2023 at 00:01 UTC
|
I think the closest most people come to pair programming is an (often mandatory) code review process.
I love to do code review, and love to receive it. However power imbalance tends to weaken the value of code review in two ways. When (as it often is) the reviewer is a more experienced or more senior developer, the reviewee can perceive the review comments as a set of instructions. And when the roles are reversed, the reviewer will tend to restrict their comments to blatant bugs or typos: they will rarely feel confident enough to question everything that isn't clear to them, even though they may be expected to maintain it in the future.
Here's the psychological safety aspect: for a code review to be truly productive it should be a dialogue.
If a code review comment says "why did you do it this way rather than this other way", most people's instinctive reaction is to change to "this other way", when a preferable response would be a) to explain why you did it this way, or b) propose a modification that adds a comment explaining why it was chosen to do it this way. If there are arguments to be made either way, then have that discussion until consensus is reached (or if time does not permit, at least add a comment that the other way is worth considering).
When code review works well, multiple benefits are achieved simultaneously: the quality of the eventually submitted code improves; the reviewee learns something; the reviewer learns something; and the record of the review process serves as a useful historical document helping to explain why the code now looks as it does.
I have never experienced pair programming; I can guess that it needs a lot of respect and trust from both parties. But while I can imagine it resulting in better code (similar to a good review process), my guess is that it is less likely to result in the documentation improvements that a good review process can bring - I think that's a particular benefit to bringing in a fresh pair of eyes at the point the originator(s) consider a piece of work complete.
| [reply] |