Improving as an Agile Developer

The question was posed: "I'm on an Agile team, and I'm undoubtedly the least experienced member. What could I do to improve my software development skills?" Here's what I answered:

There are many things you can do to improve, and I’m sure you’ll get some good answers. If your Agile team is worthy of its name, you will certainly improve by working with them, reviewing their code, and having them review yours.

From my point of view, however, there is one thing to do that underlies all the other suggestions, and especially learning from your teammates:

Never pretend you know what you don’t know.

Always be ready to ask for help in learning new things.

You may think you have to look extra smart and experienced to impress your teammates, but it’s quite the opposite. Just show your willingness and eagerness to learn. Besides, your Agile teammates will always figure out if you're faking.

Some people might not value this approach, but they’re not people you want to associate with. They’re probably pretenders themselves. They're certainly not good Agilists.

How do I get better at writing code?

Nobody writes perfect code. Anyone, no matter how experienced, can improve. So, you ask, how do I get better at writing code?

Of course, to get better at writing code, you must practice writing code. That much is obvious. Still, just writing the same poor code over and over, you're not likely to improve by much.

Writing is a different skill from reading, but reading code is necessary if you want to improve your writing. As with writing natural language, you build up your skill and confidence by reading—and not just reading your own output. So, find yourself some examples of good, clear code and read, read, read until you understand each piece.

Be careful, though. There’s lots of terrible code around. You can read terrible code, of course, and learn to analyze why it’s terrible, but your first attention should be on good code. Excellent code, if possible.

Where can you find good code? Textbooks are an easy choice, but be wary of textbooks. Kernihan and Plauger, in their book, The Elements of Programming Style, showed us how awful textbook code can be. Their little book can teach you a lot about recognizing bad code.

But bad code isn't enough. Knowing what's bad doesn't necessarily teach you what's good. Some open source code is rather good, and it’s easy to obtain, though it may be too complex for a beginning. Complex code can easily be bad code.

Hopefully, you will participate in code reviews, where you can see lots of code and hear various opinions on what’s good and what’s less than good.

Definitely ask you fellow programmers to share code with you, though beware: not all of it will be good examples. Be sure the partners you choose are able to listen objectively to feedback about any smelly code they show you.

If you work alone, use the internet to find some programming pen pals.

As you learn to discern the difference between good and poor code, you can use this discernment in your reading. After a while, you’ll be ready to start writing simple code, then work your way up to more complex tasks—all good.

And date and save all your code-writing examples, so you can review your progress from time to time.

Good luck, and happy learning!

Goals for Beginning Programmers

The question was, "What are some goals a beginning programmer should have?"

I’d have to disagree with those who answered, “Pick a language.” Instead, I’d say, “Pick at least two languages.”

I agree that you should avoid the “holy war” about which language is “better,” but the way to do this is to train yourself to be multi-lingual, or at least bilingual.

Pick two languages that are as different as possible, and do all your practice programs in both languages. Then take some time to figure out how each language has influenced your thinking about the program.

We’ve used this method for several generations of beginning programmers with remarkable results. One of our goals was to train programmers who could move into a new job where they used a language the programmer had never seen before.

Within two weeks, the programmer would be able to match the shop’s average.

Within four weeks, the programmer would be the best in the shop.

And within six weeks, the programmer would be teaching the others how to be better programmers.

Quite simply, our students achieved these ambitious goals, thus giving themselves a terrific advantage in the job market, with prosperous future careers.

Feedback to Yourself

Over the years, I've written a lot and taught a lot about feedback. See, for example, our book, What Did You Say?: The Art of Giving and Receiving Feedback. The book has been put to good use by thousands of readers, through two editions, and especially to teams. Recently our handyman, Abel, taught me that we'd missed something 

In the book, we wrote about giving and receiving feedback with one other person and with groups such as teams and projects. What we missed was feedback to yourself.

Abel had been fixing a variety of problems in the kitchen of our old house: broken tiles, a stuck drawer, a slow sink, a jammed ice-cube maker. It was a long list, and Abel worked until he had to leave to pick up his kids from school.

"Did you finish everything?" I asked.

"Yes, and I did a good job."

"You always do a good job, Abel."

Abel smiled. "Thanks. There's a few things I could have done better if I had more time and a few things that weren't in your tool room. Do you want me to come back and touch things up?"

Abel explained what he could improve, and we agreed to another visit two days later, after he made a trip to Ace Hardware. That evening, I showed Dani all he had done.

"That's wonderful," she said. "Some of those things were beginning to annoy me. He did a good job."

"That's interesting," I said. "Abel said the same thing."

"What thing?"

"He said, 'I did a good job.'"

"Of course he did. He always does a good job.Just like you."

"Thanks," I said. "Maybe I always do a good job, but I don't always say so. I  think I was taught not to 'blow my own horn.'"

Dani nodded. "You know, I think I was taught the same thing. Like when you ask me about one of my consulting jobs. I say, 'Yeah, I did okay, but I could have done better.'"

"I do the same. I think it's the 'but' that makes us different from Abel."

"How so?"

"Abel said 'I did a good job," yet he left off the 'but I could have done a better job."

"I thought that's what he said?"

"No, what he said, in effect, was, 'I did a good job, and I could have done a better job.' In other words, he didn't fall to either side—good or bad—but he said both. He provided feedback to himself that was much better than the self-deprecating way that we do it."

In short, what Abel knew how to do was give complete and accurate feedback, something both Dani and I have taught for decades. But what Abel did was give himself that kind of useful feedback. He corrected himself, sure, but at the same time, he affirmed himself for what he did well without discounting it with a big "but."

Do you have a big but? If so, it's time to trim down.

Programmers, Testers, & Dogs

Danny Faught wrote to Dani Weinberg:

Of course, I believe you that you're using very similar techniques in both of your endeavors: dog training and management consulting. I can also see that both the work with IT people and dog people focuses on problem-solving. 

I've heard that basic dog training is actually more about people training - teaching people how to successfully interact with their dogs. Is that also true of your dog behavioral work? 

Can you give an example of how your work in one area informed your approach in the other?

Dani Weinberg replied: 

Weinberg and Weinberg works with people who do IT by problem-solving.  Dogs and Their People works with people who have dogs by problem-solving. I use the same skills—and many more (just as Jerry does)—and the same basic principles.

You might now know this.  As a dog behavior consultant, I do not teach people how to train their dogs to sit, down, stay, heel, etc.  I work with behavior issues, most of them quite serious, that cannot be resolved that simply.  In fact, many of my clients' dogs already have some basic skills.

What I do is essentially the same thing I used to do when I worked with Jerry consulting in organizations.

Jerry replied:

It's the same in my consulting. Years ago, I taught people how to write code and test programs. That kind of consulting evolved into consulting on "behavior issues, most of them quite serious." In fact, most of my clients' employees already have the basic skills of programming and testing.

Dani then wrote:

Take a look at the Table of Contents—the titles of the chapters—in The Secrets of Consulting. They describe exactly what I do in my dog-behavior consulting. Yes, it's heavily focused on the owner. I know much more about dog behavior—how to "read" and "listen to" the dog. So what I have to do is a kind of translator or interpreter process for the owner. Some of it is me doing with the dog what I recommend to the owner, allowing the owner not only to see the demonstration but also appreciate the results.

Here's a very simple example. The dog is black Standard Poodle, about 6 months old—a "teenager." The owner is a psychologist who has had many dogs in the past. The problem she hired me to help with is that the dog is constantly jumping on people. I go to the house and experience this behavior myself.

Jerry:

This type of problem is similar to a manager who complains that an employee is constantly interrupting him with all sorts of trival questions and comments.

Dani:

Turns out the dog has been taught to sit on cue. I give the cue, the dog sits quickly, and I give a high-value treat (turkey). Whenever the dog looks like she's thinking about jumping again (pure excitement and joie de vivre), I cue "Sit" again and repeat the process. In no time (like after 3 or 4 of these cued Sits), she approaches me and offers a Sit, not cued by me. I repeat the treat. She spends most of the remaining hour doing this, over and over again. The owner is delighted! Then the owner herself tries it, with coaching from me - and it works for her too.

We have taught the dog that this behavior (sitting) is rewarded heavily, whereas jumping evokes me turning my back on her. Dogs are pretty smart and realize where their advantage lies!

Jerry:

Not all programmers are as smart as dogs, but most of them are smart enough to recognize when their manager ignores them when they interrupt. Eventually, they learn to sit down and perhaps raise their hand when they have something to say—if their manager rewards their behavior by recognizing their need. You don't have to give them turkey treats. "Recognition" is their high-value reward. If the manager responds to interruptions by telling them "don't interrupt," that's still a form of recognition, and teaches the employee to keep interrupting.

Is Waterfall the Opposite of Agile?

Agilists sometimes behave unreasonably by pummeling the Waterfall approach. Personally, I think such evangelists could better spend their effort producing solid, relevant code, but evidently they are on a crusade and need an enemy. If they need an enemy of Agile, however, they could have made a better choice.

There's nothing wrong with the Waterfall approach—if applied appropriately. For Waterfall to work well, you need to solve a problem that's not destined to change much, or, ideally, to change not at all. Some Agilists claim there is no such unchanging problem, but they're merely showing their lack of experience. I've seen a number of such invariant problems, and they yield very readily to a properly applied Waterfall development.

For example, Erik, a former student of mine, made a lucrative business of converting COBOL programs to new COBOL programs adapted to new versions of the COBOL compiler. Erik's customers wanted assurance that nothing would be changed in the conversion. This was a perfect situation for a simple Waterfall approach, one that Erik could perform profitably at a fixed price and schedule.

That said, the number of such invariant problems is not large, and it's usually difficult to know at the beginning if a problem will turn out to be so stable. In Erik's case, some of his customers would decide midway that they wanted a few "tiny" improvements in the converted application. Erik controlled that situation by charging outrageous fees for even the simplest modification. Most of us, however, try to control this situation by employing some Agile approach.

Let's be honest with ourselves: one consequence of an Agile approach is the loss of our ability to work to a fixed cost on a fixed schedule. Erik could do that, but only in a few carefully controlled situations. Many managers frustrate themselves over this lack of control and blame it on Agile. What's really to blame, however, is their inability to control the world in which they live. Things do change, and much of the time it's these very managers who instigate the change.

What do frustrated managers do? Quite often, they elevate their attempts to control the change by making rules. They may start using a pure Waterfall approach, but as their frustration with changes grows, they may add a Change Control Board, or change reviews, or a Change Tsar, or any of a number of other tactics. And, when those tactics fail to produce absolute predictability, they add more of the same kinds of rules and their supporting tactics.

After a while, these rules upon rules produce an approach that, though called "Waterfall," is actually something quite different—something for which we so far have no accurate name. This "something" is what Agile is responding to, so I suggest we name it.

What are these cobbled-together approaches like? First of all, they create a sad and dismal mood among those poor developers condemned to use them. When I visit a new client, I can generally detect the use of such an approach while I take a stroll through of the premises. I can even detect such approaches over the phone. How? Simple: the mood of my clients is mournful, gloomy, sad, unhappy, doleful, glum, melancholy, woeful, miserable, woebegone, forlorn, somber, solemn, serious, sorrowful, morose, dour, cheerless, joyless, and dismal.

That's quite a sobering list of adjectives, but that's what I can sense in many so-called "Waterfall" environments. Perhaps you recognize the list, but in any case, you can find that list in your dictionary as synonyms for the rare word, "lugubrious."

Perhaps the word "lugubrious" is unfamiliar, but that's good, because we won't often find it used in other contexts. Besides, it's a rather onomatopoetic word—a word that phonetically imitates, resembles or suggests the source of the sound or situation it describes. That's why Agile was invented—to replace those mournful, gloomy, rule-dominated approaches with brain-driven judgments of the actual builders.

So let's be truly Agile and stop bashing the true Waterfall approach. Instead, let's turn our contempt on every Lugubrious approach—or, to make a noun from the adjective, Lugubriousity. Maybe this more accurate name will help us defend our Agile projects from frustrated managers' attempts to smother us with yet more rules.

Or, to paraphrase DeMorgan, who in turn paraphrased Swift:

Great rules have little rules upon their backs to spite 'em,

And little rules have lesser rules, and so ad infinitum.

Never forget that's why we do Agile, not to dry out Waterfalls but to defeat Lugubriosity.

For more thoughs on the Agile approach, see

Agile Impressions