Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Working Solo and in a Team

by eyepopslikeamosquito (Chancellor)
on Feb 13, 2017 at 09:29 UTC ( #1181886=perlmeditation: print w/replies, xml ) Need Help??

I've worked solo, and in teams, for many years now, and in many different organisations. Yet I still feel dissatisified somehow.

While I enjoy working alone -- especially when I'm in the zone -- I have to acknowledge that individuals working alone in my organisations have produced some pretty quirky and unmaintainable code over the years. At least, that's what I've seen.

Moreover, I write better and more relevant code not when working solo, but when receiving regular feedback from others.

Sadly, I've found that working closely with others can be difficult and stressful, especially when personality clashes arise. The tragic human condition -- as I'm reminded every day when reading the news -- is that there are so many factors that can cause conflict in teams: gender, politics, religion, baby boomers vs generation-y, introvert versus extrovert, perl vs java, the list goes on and on.

Pair Programming

One of the drawbacks of being chosen to lead humanity's push to become an interplanetary species is having to give up your privacy. "You could hear everything else that happened in the dome, and they could hear you," Ms Johnston recounted.

-- What it's like to spend a year pretending to live on Mars (news article)

I've tried pair programming eight hours a day and hated it. Like the budding Mars astronauts, I discovered how much I value my privacy.

High Performing Teams

Despite my unfortunate pair programming experiences, I acknowledge the crucial importance of teamwork and effective teams. Though I've rarely experienced it personally, I know that the elusive harmonious, high performing team is certainly possible. How best to achieve it?

According to a recent study at Google the five keys to a successful team are:

  • Psychological safety: Can we take risks on this team without feeling insecure or embarrassed?
  • Dependability: Can we count on each other to do high quality work on time?
  • Structure & clarity: Are goals, roles, and execution plans on our team clear? Do we have an effective decision-making process?
  • Meaning of work: Are we working on something that is personally important for each of us?
  • Impact of work: Do we fundamentally believe that the work we're doing matters?

Some ideas you might try from the Google study to improve teamwork:

  • Google's gTeams exercise: a 10-minute pulse-check on the five dynamics above, a report that summarizes how the team is doing, a live in-person conversation to discuss the results, and tailored developmental resources to help teams improve.
  • Google found that teams who adopted a "new group norm" improved more than other teams. An example of a new group norm is "Kick off every team meeting by sharing a risk you took in the previous week".

Feedback

I'd love to hear of your experiences. What's been your workplace experiences, both working solo, and in a team? Which do you prefer? I'm especially interested to learn what you feel is the key to working in an effective team.

References

Replies are listed 'Best First'.
Re: Working Solo and in a Team
by afoken (Abbot) 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". ;-)

      ...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.
        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". ;-)

      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.

        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 slashot 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". ;-)
Re: Working Solo and in a Team
by eyepopslikeamosquito (Chancellor) 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 nurse, unsure of the dosage, considers calling the doctor at home ... but remembers the disparaging comments he made about her abilities last time she called.
    • A junior co-pilot too scared to query the senior officer about what looks to him like a serious error of judgement.
    • An executive too frightened 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

      I like this. But how do you handle personalities who undermine efficient operation by being too inquisitive and are too free to be intrusive? Having every decision getting questioned or second-guessed is probably just as bad as no decision getting questioned or second-guessed. It can be tough to find a good balance. All it takes is for a few people in one direction or the other to throw things out of whack and turn a good work environment into a dysfunctional one.

      $PM = "Perl Monk's";
      $MCF = "Most Clueless Friar Abbot Bishop Pontiff Deacon Curate";
      $nysus = $PM . ' ' . $MCF;
      Click here if you love Perl Monks

Re: Working Solo and in a Team
by nysus (Priest) 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.

    $PM = "Perl Monk's";
    $MCF = "Most Clueless Friar Abbot Bishop Pontiff Deacon Curate";
    $nysus = $PM . ' ' . $MCF;
    Click here if you love Perl Monks

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://1181886]
Approved by marto
Front-paged by Athanasius
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (4)
As of 2017-11-18 18:09 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    In order to be able to say "I know Perl", you must have:













    Results (277 votes). Check out past polls.

    Notices?