The second session of the first day was by Michael Feathers giving a demo of using functional approaches to different problems.

I took two main lessons out of it:
1. “Clever code” is relative.
2. Functional programming can help establish a common base of understanding that doesn’t vary from one problem domain to another.

“Clever code” is something that’s often looked down uponbecause it can make it more difficult for multiple developers to maintain an application and read its code. But what is “clever”, exactly? Michael Feathers made the point that anything that’s unfamiliar to us will at first look as strange and weird. But if we take the time to learn new functions and patterns, they will quickly become familiar and comfortable instead of too clever and complicated.

Another way to mitigate the gap between unfamiliar and comfortable is to use common functions. Functional programming is a good example of that: it is more about manipulating data without worrying about setting up abstractions to model it first. Functions built into a functional language aren’t trying to represent the domain of the problem. Instead, they simply perform common operations that do the same thing regardless of what kind of problem they’re applied to.

For example, the zip function is the same in Ruby, Python, Scala, Haskell, and other languages. This means that you can learn how it works once and if you find yourself working in another language or another domain, you can easily apply it there.

The same holds true for design patterns and, to an extent, frameworks.

Establishing a common base of understanding is important for ensuring that we write the best code possible. Sometimes this requires compromises to favour readability over efficiency or style, but other times we’re better off using some clever code on the assumption that we and our fellow developers will learn how it works and become better for it.

Craftsmanship is not about language or process. It’s about community and quality.

SCNA 2011 opened with a keynote by Corey Haines. He talked about the past and the future of software development as a profession, the trends that are emerging in the current economic climate and how that affects us as professional developers.

Where We Came From

Back in the 90s the tech sector virtually exploded and a lot of people got into software development with the help of all those “Learn X in 24 hours” books. This was great, but it did result in a lot of people quickly learning how to code and getting jobs without learning much about the profession overall.

That gave the impression that it was very easy to become a programmer. With the increasing numbers of new developers, there weren’t enough older, more experienced developers to train them. At the same time, companies employing developers at the time (and even now) just want results. They trust that the people they hire know what they’re doing, so it is rather up to us to self-organize and recognize that it’s relatively easy to learn how to program but there’s a difference between being able to write some code and developing maintainable software.

Where We Are Today

The tech bubble of the 90s is long gone and since then the economy has come down again. A lot of people got laid off from their jobs and either out of opportunity or necessity are starting up their own small businesses. Those businesses often need software, so developers are once again in demand. So are we doomed to repeat the mistakes of the past?

Well, maybe. But it doesn’t have to be that way.

What Next?

More and more trends are emerging that are promoting software development as a craft, something that needs to be practiced and learned and cannot be taught with a book and 24 hours.

Apprenticeship programs are starting up in various places and many companies are more open to the idea of hiring apprentices and having some of their developers spend time on training. There are also online organizations like Girl Develop It.

So, that’s all well and good, but why do we care? Didn’t the tech boom work out in the end? Aren’t we better for it?

Why Bother?

It turns out that software development is not easy. In fact, it’s quite hard. But companies are starting to wake up to that fact. As software becomes more and more ubiquitous every day, it’s easy to see good, maintainable applications and discover the badly written ones by  comparison.

For those of us who spend time practicing and learning new techniques, having untrained developers enter the workforce can be actively harmful.

So What Can One Person Do?

• Learn as much as possible
• Reclaim professional values:
• build communities, connect with others
• add value, do things that matter
• Practice the craft
• code retreats, coding dojos
• work on personal projects
• attend interesting conferences
• Be awesome.

Last week I had the opportunity to attend the Software Craftsmanship North America 2011 conference in Chicago, IL. I had a blast and I want to make a series of blog posts about my experiences. Since my attendance was very graciously sponsored by Stack Exchange, I will also try to link stuff I learned at the conference back to my “main” site – Programmers Stack Exchange.

I’ve been to two conferences so far: RallyON back in May and TechDays 2011 last month. I enjoyed RallyON, but I was largely in the company of project managers. TechDays was ostensibly of interest to developers, and I enjoyed some of the talks presented there, but the atmosphere was largely that of a sales conference and that made it difficult to connect with anybody. SCNA is the exact opposite from those experiences. It is a conference full of developers who actively want to be there. It’s amazing how much difference that makes.

The conference runs for two days and both days are pretty full of stuff to do. You’re on your own in the evenings, but I haven’t found that to be a problem — talking to a few people during the day more or less guarantees having company for dinner.

This year there were two tracks of talks with an unfortunate overlap between speakers. It wasn’t a problem for me for the most part, but I did have to leave a couple talks before they finished in order to get to the next one on time. There was also an “open space” room set up for hanging out, hacking on random things, and ad hoc pairing.

Despite the name, it wasn’t a traditional open space, well, space. Typically you’d see a board and some sticky notes for people to propose their own mini-sessions. This time, there were a few smaller groups getting together, but I found it difficult to figure out if there was anything special going on at a given time.

Many of the talks weren’t announced ahead of time, which made choosing ones to attend a bit odd. Still, a little mystery never hurt anyone, and I attended the following sessions:

• The opening keynote by Corey Haines in which he talked about developers: where we came from, where we’re going, and whether or not we are about to repeat some of the mistakes of the past.
• A demonstration of functional programming style by Michael Feathers.
• An interesting look at the evolution of programming languages by Gary Bernhardt.
• The apprenticeship panel that gathered several prominent developers and company owners to talk about why they take on apprentices and what they’re looking for when they do.
• “Architecture: The Lost Years” by Robert “Uncle Bob” Martin.
• A demonstration of the Roman Numerals kata in Ruby by Jim Weirich.
• A discussion of parallels between learning and practicing a musical instrument vs practicing programming by David Chelimsky.
• A critical look at software development education and propagation of popular methodologies by Zed Shaw.
• The closing keynote by Chad Fowler in which he talked about the values held by passionate developers.

I’m going to aim to make a post every week or so to summarize and, where possible, interpret each of those talks along with some other stuff that I learned about at the conference that I think is pretty cool (Ruby Warrior!).

So, check back here periodically. I’ll do my best to update this post with links to future posts, but they shouldn’t be hard to find either way.