This is the transcript of a lightning talk that I've given to a few of my clients.

1. LESSONS LEARNED ABOUT SOFTWARE DEVELOPMENT
Hello, my name is Jeff Thalhammer. I've been a software developer for a few years. I still have
a lot to learn about my profession, but I would like to think I have acquired a few bits of wisdom
over the years. So in the next five minutes, I'm going to share with you the most important
lessons that I have learned about software development...
Lesson 1: The best code is no code at all.
The moment you begin writing code, you start creating bugs. Every line of code is a future
liability. So the less code you have, the less risk you take on. This may sound counter-intuitive,
but good software development is all about avoiding writing code.
Code-avoidance happens in a lot of ways. For example, you might be tasked with writing code
to add up the sales figures on the quarterly TPS reports. But if you do a bit of digging, you'll find
that you can just get the total by calling Mary over in the accounting department. Bam! Problem
solved with no code.
Open source and commercial products are another good way to avoid code. Despite what you
might like to think, you are not special. A lot of problems have already been solved by people a
lot smarter than you or I. And if their solutions don't seem to fit, then you really need to think
hard and justify why your needs are so different.
Software itself is actually full of code-avoidance mechanisms: subroutines, libraries, object
orientation, web services, virtualization, cloud computing. These all exist for the purpose of not
writing code. Use them.
As developers, it is hard to resist the temptation to write code. That's what we are here for after
all. But that isn't really your job. Your job is to help solve problems in the most effective and
prudent way that you know how. Code is just *one* of the weapons in your problem-solving
arsenal. So think about that before you write your next line of code.
Lesson 2: Code is for humans first, and computers second.
Once you've concluded that you actually must write some code, you need to remember who you
are writing it for. And no, you are not writing code for the computer.
Like all languages, programming languages are just a way for us humans to communicate with
each other and ourselves. We typically think that code is the "solution". But it's not. Code is
actually how we express the *problem*. Once you've fully expressed the problem, then a
computer will dutifully execute the solution. But -- this is key -- the problem is ours, not the
computer's.
Unfortunately, computers aren't very smart. So we have to invent these awkward little
languages they can understand. But we get so caught up in those little languages that we let
them constrain our own ability to express ourselves clearly, often to the point that we don't even
understand it.
So when you write code, remember that you are actually trying to express a real human problem
in an artificial language. So the more your code resembles a human language, the more likely it

2. is to be an accurate definition of the problem. And if the problem is defined well, then the
computer will probably give you the right solution.
Lesson 3: You Are Not As Smart As You Think You Are.
In many professions, you can at least identify the entire body of knowledge that you'll ever need
in that career. But the software industry is constantly evolving. Most of the things you learned
five years ago are no longer relevant, or may be down right incorrect. True, some changes are
just fads and some learning is inevitably wasted on dead-end ideas. But how will you know
which are which?
The only way for a person or an organization to succeed in this business is to constantly keep
learning. More importantly, you must learn how to learn effectively. You must question your old
habits, seek alternative perspectives, and acquire knew knowledge. And just as important, you
must act on that knowledge. Otherwise, it is just trivia.
So the challenge is to cultivate an organization that promotes effective learning. The good news
is that learning opportunities are everywhere. Every line of code, every presentation, every
meeting is an opportunity. But first, you must instill people (or yourself) with traditions and values
that enable them to recognize and exploit those opportunities.
Lesson 4: Software development is 80% social and 20% technical.
Writing code is the easy part. Anyone can do it. There are millions of developers in China and
India who are willing and able to write code for you. And when technical questions arise, most of
the answers are freely available. Just ask Google. The really hard part is figuring out *what*
code to write.
Figuring out what to write requires asking a lot of questions: What is the real problem we are
trying to solve? Which parts of the problem are constant? Which parts are subject to change?
How likely is it to change? Which are the critical features? Which features are fluff? What kind
of resources to we have available? The answers to these questions require conversations with
actual human beings.
So the message here is that to succeed in this industry, your social skills need be just as good
(or even better) than your technical skills. You need to be able to communicate with people and
find out what they really need, how they feel, what their history is, what their goals are, what they
are doing.
When working on a team, we all have different roles to play -- we each have our own areas of
strength -- and that's fine. But as a whole, the team must balance their technical and social
skills. The unfortunate thing is that most organizations don't (or can't) really operate as teams.
Developers end up playing lots of roles, some of which they haven't really mastered. So for
them to succeed as individuals in that kind of environment, developers also need to be mindful of
the balance between their own social and technical skills.
Final thoughts: Quality is not an act, it is a habit. --Aristotle
Thanks for your time.