Tag: learning

Posted on by

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, 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 the 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 by

Against TDD

Test-Driven Development (TDD) is a tool. To get value from a tool, it’s necessary to:

  1. choose the right tool for the job; and
  2. use the tool properly.

Circa 2019, there are numerous debates about whether TDD is useful. It seems to me many of the arguments against TDD boil down to one of the following:

  • trying to use TDD in situations where it is not the right tool for the job; or
  • using TDD improperly.

Choosing the wrong tool or using a tool improperly are certainly things that we fallible humans do from time to time. However, when people have experienced those things with respect to TDD, that isn’t what they say. Instead, they say TDD categorically does not help. It is inconceivable that they could have made a mistake. The tool they used must have been at fault. They are here to warn you against being harmed by that tool.

Continue reading Against TDD

Posted on by

Take a walk in the desert

No one can see their reflection in running water.
It is only in still water that we can see. (Lao Tzu)

A friend of mine was telling me about the new apartment he and his family have bought. The building is under construction, and is located in a prestigious part of a major city. We got into a discussion about choosing where to live. He prefers large cities, and I prefer living far from a city (although I work in cities).
Continue reading Take a walk in the desert

Posted on by — 6 Comments

How does collaboration begin?

The question was posed in a discussion on LinkedIn. It received the following response:

Is the question "how does collaboration begin" or "how do specialists become generalists"? I assume the latter.

Um, well, that wasn’t the question. What’s the value in assuming a different question, because you’d prefer to answer the other question? After a number of comments extolling the virtues of the generalizing specialist, a person showed genuine interest in moving himself and his team in that direction. He want to get started. That’s a good thing.

Instead of helping him get started, however, people just reiterated the end state. Just do. Just be. Just blah blah blah. There’s a certain word in the question. It’s a little word; nothing ostentatious. But I think it’s kind of an important word. The word is begin. Continue reading How does collaboration begin?

Posted on by — 1 Comment

Don’t do anything stupid on purpose

It’s a familiar adage among engineers, often posted in work areas. Does it pertain to software development? The seemingly endless circular debates about software delivery methods lead me to think so. The latest chapter in the ongoing drama is the recent schism between Lean Kanban University’s flavor of Kanban Method and the rest of the lean/kanban community. And the paint hasn’t yet dried on the sumo match between Kanban and Scrum. A few years ago (mid-00’s, as memory serves) the same debate (except for the names of the methods) raged between proponents of Evolutionary Project Management (Evo) and Extreme Programming (XP). Prior to that, we kept ourselves entertained by debating whether RUP was Agile. Before we could do that, we had to settle the debate about the relative merits of Spiral and RUP, of course. And Spiral vs. linear SDLC processes. Tomorrow, next week, or next month, it will be something else. Important questions, all.

Yet, I can’t help noticing, as Ron Jeffries puts it, it’s all the same elephant. When I stopped arguing and started listening to the elephant, I heard it say "Don’t do anything stupid on purpose." What does the phrase mean in the context of software development and delivery? To explore the question, I think it would be helpful to define the terms stupid and on purpose for that context. Continue reading Don’t do anything stupid on purpose

Posted on by

The Shimmering

In the movie, Now You See Me, a certain idea was stated multiple times, phrased in various ways: "Look closely, because the closer you think you are, the less you will see." In the past decade, a lot of people have been inching closer and closer to something called "agile," and most of them are pretty sure they can see it.

Things are very different on each side of the "hump" in the diffusion of innovations curve. On the left side, the early side, where the Innovators and Early Majority adopters live, people tend to be forward-looking, open-minded, imaginative, proactive, and willing to take risks. On the right side, the late side, where the Late Majority adopters and Laggards live…well, not so much. Some people are interested in the left side, because that’s where breakthrough ideas are vetted in the proverbial fire of the (possibly over-rated) Real World. Others are interested in the right side, because that’s where methods and practices become scaled, integrated, and institutionalized to support large enterprises. Continue reading The Shimmering

Posted on by — 7 Comments

Why should we do code katas?

I participated in a coding dojo recently in which some of the comments I heard caused me to think about the purpose of practicing code katas. It seems that many programmers, including some pretty advanced ones, don’t quite get the point.

We were reading about some code katas online so that we could choose one to do for the dojo. We came across a description of the Bowling Kata written by Robert C. “Uncle Bob” Martin. A couple of the guys quickly dismissed it when they saw Uncle Bob’s name. “He’s too prescriptive,” said one. “I don’t want to be told how to approach the problem,” said another. They looked for a write-up of the Bowling Kata that didn’t try to guide us in how to approach the problem.

They found one and we used it. All evening we kept running into silly little issues and speed bumps, such that we really didn’t get a lot of value from the whole exercise. We went down tool-related side paths, broke our development environment a couple of times, forgot what we were trying to accomplish, and started over multiple times. It never felt as if there was any goal or even a general direction. Despite the fact the group included some very fine professional programmers, I have to say it was not the best coding dojo I’ve ever been in.

Obviously, due to the sort of democratic and participatory event a coding dojo is, I have to accept a share of the blame for that. I actively chose not to make suggestions to bring the activity onto some sort of intentional course, because I wanted to see where it might go. In the end it went nowhere, but the experience led me to sit down and reconsider the reasons we do these things, and how we can get value from doing them.

The key point is that there are reasons for Uncle Bob’s approach to katas. Rather than getting to the point directly, I’m going to begin with a couple of rambling digressions, as per my usual style. Continue reading Why should we do code katas?

Posted on by

Perception

A post on this blog received a very interesting comment from a reader with the nom de pixel Malapine:

"…my problem isn’t boredom but fear: the codebase sucks, we have no idea whether the features are what customers want, and if the product doesn’t sell, some of us may get laid off. If that’s ever me, I am screwed: my resume will show two decades with the same employer, the vast majority of it on Waterfall or ScrumBut projects."

"Off the job, I read books on Agile, go to monthly dojos, etc.; but on the job I can’t even do TDD properly — builds take 20 minutes just to compile, and nobody else seems to care."

I felt this called for more than a response in the comment thread. It seems to me it illustrates that perception can be more important than reality, and that is of interest to me presently.

Continue reading Perception

Posted on by — 1 Comment

With the benefit (and bias) of hindsight

This post could be subtitled, "A self-indulgent look at past writings."

In April of 2012, Paul Bowler (@spbowler) found some articles from my old site on the Wayback Machine and tweeted about it. I replied to him, "Thanks for finding that! Some of the articles make me smile; learned a thing or 2 since then. Others I’m glad to have recovered." That prompted him to ask, "Which articles should I avoid?" That’s not a question to be answered in 140 charcters.

The short answer is that people should read whatever they think will be interesting, and then use their own brains to arrive at independent conclusions. I’m not one of those people who insists that others provide published references to support everything they say or write. If anything, I’d rather people did their own thinking, and used published references as references rather than as a substitute for their own brains. I’m not so sure published references are all that special, anyway.

Now for the long answer.

Continue reading With the benefit (and bias) of hindsight