Category: Uncategorized

Finding Fun

It’s hard to master software development if you don’t enjoy doing it, so you’ve got to find fun. There’s a lot of fun to be found in software development (unless you’re one of those people who really can’t program).

We should be thankful that our job allows us to have fun. There are plenty of jobs where it’s a lot more difficult to find fun.

So how to find fun?

Learn

Discovery and mastery are fun. If what you discover and master are relevant to your work, your employer will probably accept that at least a small part of your time is spent on learning. It’s in your employer’s interest to have developers who are up to speed. At a minimum you should be able to organize a “brown bag” session to learn during lunch time.

Share learning

Brown bag lunches are also a fun opportunity to share what you’ve learned with others. So is pair programming.

Gamify

Challenging yourself makes things more fun. Challenging others adds even more fun.

Doing TDD lets you create little challenges all the time for yourself. You can also challenge yourself to move the needle on certain code metrics (test coverage, cyclomatic complexity, PMD/Findbugs issue count, etc.), within reason (choose metrics which actually add value to your work). Following the Boy Scout Rule, you can challenge yourself to make a big ugly method into small, beautiful methods.

One suggestion I heard recently to make pair programming more fun is to play “TDD pong”. One member of the pair writes a test and then challenges the other to make the test pass. Then the roles switch.

I also heard recently from a scrum master who invented a role-playing system (using Star Wars characters to bridge the gap between older and younger developers) where each developer is assigned for a sprint a certain character.  Each character gets points for doing a different thing, such as writing “perfect” unit tests, facilitating communication between developers, enhancing code performance, etc.  Whoever has the most points at the end of the sprint gets a small prize. The idea is to get less experienced developers  to adapt good practices by having them focus on one practice at a time.

Take micro-breaks

When it’s not fun, stop for a minute. Even when it is fun, stop for a minute now and then. Your eyes and wrists will thank you, and things will stay fun longer.

Laugh

We can laugh at what we do, our processes, our teams, our way of thinking.

We live in a silly world. A generation ago, if you walked down the street alone while having a conversation, people would think you have some form of schizophrenia. Now they just think you have some form of bluetooth device. It’s best not to take things too seriously.

Laughing at your test data:
Be careful, because some of your test data might turn up in a commercial presentation which could make or break your employer’s reputation, and you don’t want to waste too much time on non-essential tasks, but you can make your test data more fun.

For example, if you have a test database which needs a list of video game titles, you could enter “game1”, “game2”, “game3”, etc.  Or you could enter “Accountant’s Creed”, “Angry Nerds”, “Bassoon Hero”, “Mimecraft”, “Unreal Fantasy”, “Shower Defense”, “Handy Crutch Saga”, “Grand Theft Lotto”, “Call of Booty”, “Resident E-mail”, etc. Your choice.

Create

We’re fortunate enough to do work where we get to create things with our minds. Don’t be afraid to break out your metaphorical “box of crayons”.

 

Advertisements

Toward Mastery

I’m starting this blog to share my experience and ideas and to participate in the discussions which shape the profession of software development. As an engineering discipline, software engineering, which is only about 60-odd years old, is a relative newcomer when you think about the engineering that went into building the pyramids in Egypt, the Parthenon in Greece, etc. As a profession, we’re young, dumb, and full of… scrum.

The goal of this blog is to participate in a discussion which moves the profession toward maturity, and which helps you, the reader, and me as well, move from pedantry toward mastery.

What does that mean? In “How to Solve It”, mathematician George Polya described the difference between pedantry and mastery as follows:

Pedantry and Mastery are opposite attitudes to rules.

To apply a rule to the letter, rigidly, unquestioningly, in cases where it fits and in cases where it does not fit, is pedantry. Some pedants are poor fools; they never did understand the rule which they apply so conscientiously and so indiscriminately. Some pedants are quite successful; they understood the rule, at least in the beginning (before they became pedants), and chose a good one that fits in many cases and fails only occasionally.

To apply a rule with natural ease, with judgment, noticing the cases where it fits, and without ever letting the words of the rule obscure the purpose of the action or the opportunities of the situation, is mastery.

This idea of pedantry, even if you never heard the word before, should seem familiar to most software developers. We are told many rules and things that we should or should not do, until we find that we’re “should-ing all over ourselves”. Technology changes quickly, so we can’t always wait until we’ve mastered everything, but mastery is the goal, and mastery allows us to do our best work.