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.