Posted on

Key Skills for Software Development

If you understand how these things relate to software development work, then you require no training or coaching.

Self-discipline

Handling stress and working with others requires self-awareness and emotional control. All the skills listed here also require self-awareness and emotional control.

Learning How to Learn

It is widely agreed that software development teams are either improving mindfully, or they are deteriorating in their effectiveness. There is no steady state. To make improvement possible, team members must be open to learning new things and willing to question things they already know.

Focus

To achieve anything, you must focus on it. That means uninterrupted time to think and work. It means finishing one thing before starting another. It means not getting distracted. It means keeping your eyes on the goal and not on dwelling on the difficulties.

Persistence

Overcoming challenges and meeting objectives requires persistence. Embracing change to improve our work requires persistence.

Collaboration

In almost all cases, software development work benefits from collaboration between two or more people. “The more you share, the more your bowl will be plentiful.” – James S.A. Corey, The Expanse.

Trust

Effective collaboration requires trust and the courage to be seen as vulnerable or imperfect.

Leadership

Leadership doesn’t mean giving orders. It means giving credit, giving time, giving space, giving encouragement, giving opportunity, giving trust. The more you give, the more you get.

Rhythm

A steady, predictable, consistent, and sustainable pace of work helps ensure continuous flow, maximize delivery effectiveness, and minimize team stress.

Technical Skills

The field of software is constantly changing. Software architecture, design patterns, programming paradigms, methods and schools of testing, of analysis, and other areas, programming paradigms, design principles, development practices, automation, operations, and everything else is a moving target. To get started in this field, you need basic education/training in analysis, programming, and testing, and the non-technical skills listed above so that you will have the ability to keep yourself current with technical advances and to collaborate with and learn from your colleagues.

Without the basic training, you will have no foundation to build on. It would be like trying to run a foot race on top of loose ice floes on water. The general discussion of what skills are necessary tends to emphasize the non-technical side of things; don’t take that to mean there are short-cuts on the technical side. The reason for that emphasis is that the non-technical skills have been underappreciated in the past. On the other hand, don’t worry if you feel as if there’s too much to learn. Once you have the basics, you can build on that knowledge little by little.

Posted on

An incentive to collaborate

Recently, I tweeted that I had presented a virtual training class in which we used remote mob programming for the lab exercises, and at the end the participants said their main take-away was not the technical content, but rather the value of direct collaboration. Colleagues who already understand and appreciate the power of collaboration were excited to hear the story.

But what about people who do not already understand and appreciate the power of collaboration? What was unique about the situation that brought collaboration to the fore, above and beyond the technical skills that were ostensibly the subject of the class? How closely does that situation align with more-typical software development realities?

Continue reading An incentive to collaborate

Posted on

Whither Tuckman?

There’s a common model people seem to believe in implicitly, known as the Tuckman model, named for psychologist Bruce Tuckman, who published the idea in 1965. The idea is that all teams go through several distinct stages: Forming, Storming, Norming, and Performing. You can probably guess what those stages are like based on their names. The model has been a mainstay of agile coaches for many years.

But I’ve had doubts about the Tuckman model for a long time. My personal experience has been that once people get used to working in a collaborative way, they can move to new teams without any friction.
Continue reading Whither Tuckman?

Posted on

Collaboration

Contemporary software development methods emphasize collaborative work over solo work. I remember this idea gaining momentum from as far back as the 1990s, when Extreme Programming was becoming known, including one of its core practices, Pair Programming.

In retrospect, I can recall many instances when people collaborated in an ad hoc way to solve specific problems, going back to the beginning of my IT career in 1977. I’ve read articles and heard stories about the value of collaborative work in engineering going back at least to the 1950s. There was even a deliberate experiment in 1975, carried out by the US Army, on the value of “two-person teams” in software development (the article does not appear to be online anymore, but there is an excerpt in this old blog post: Does pair programming work?).

In all these cases, from formal studies to informal “war stories” told over coffee or beer, direct collaboration provided immediate and palpable benefits to the people involved. That has been my experience, as well. And yet, it seems as if solo work continues to be the norm.

Continue reading Collaboration