I've already mentioned some of the notes I took from the Software Craftsmanship of North America (SCNA) Conference, but I also wanted to give a summary of Robert Martin's closing keynote. Martin's talk was a lot of fun, as he really engaged the crowd. I was impressed; he’s a very talented presenter. If you've read some of Martin's stuff then you're probably familiar with many of the things he mentioned, though this time he framed his thoughts around the idea of craftsmanship and professionalism. Overall, it was a good talk.
My notes are as follows:
What is a professional? A professional is someone who is cool under pressure. But why is pressure such a big part of a software developer's job? Because people want stuff from us yet don't care about the other stuff that we care about (like clean, maintainable code). Thus we feel pressure, which is the fear of missing or breaking a commitment. However, commitments are necessary and inevitable; all professionals have to make commitments, and we have to provide estimates for these commitments. Nonetheless, our estimates will most likely be wrong, and work will take longer than anticipated. Then what?
The common reaction when the pressure mounts is to rush, but can you really go any faster or smarter? No, you can't. Rushing means you have to leave something out - some of your free time, part of a feature, etc. But more importantly, rushing means you stopped caring. Thus the definition of rushing is carelessness. Now you could say that you're merely acquiring some short-term "technical debt", but it's really just a mess - and messes slow us down. You'll never go back and clean the code (you'll fix bugs in the code, but not actually clean it) because your estimates are wrong, forcing you to be short on time.
Professionals, however, don't rush - meaning they care about their code. And because they care, they follow some principles of software craftsmanship:
First, do no harm
Do no harm to the code, to the functionality/behavior, or to the product. Our expectation should be that QA finds nothing wrong with our code (though they will). But how do we know that we're not doing harm? Our tests ensure that we're doing no harm, so we should strive to write many tests and get as close to 100% code coverage as possible (though we know that may not be possible). Furthermore, we need to be able to make changes to our software without exorbitant cost. But how do we make our software easy to change? By actually changing it! The very act of changing makes it changeable. You change the code, find out why it was hard to change, and then make it easier to change. Changeable software is software that has been mercilessly refactored.
But despite our efforts to write software that's well-tested and easy to change, we still could harm the software. When are we most likely to cause this harm? When we rush. Yet professionals don't rush, thereby requiring a tradeoff in order to prevent the rushing and its subsequent harm. The tradeoff might be putting in overtime or changing scope, but it's never quality.
Craftsmen have a work ethic
Craftsmen don't just code for fun or for themselves. They will work hard for their employer and deliver value to the customer. So they can't just focus on cleaning code; they must also deliver value. Craftsmen therefore must give forty hours a week to their employers. Things like on-going learning is done on your own time, not your employers – compare it to your expectations of your doctor, where you expect him or her to learn more on his or her own time and money.
So you're giving forty hours a week of hard work to your employer, but what happens to this work ethic when you're under pressure? Since you never compromise quality, another tradeoff must be made. You could put in some overtime (and thus tradeoff your free time) so long as it's not too much overtime - like a week or so. If a project requires more overtime than that, then you should talk to the project stakeholders about trading off something else, such as scope. This discussion can be difficult and awkward, but professionals are willing to have uncomfortable discussions when necessary.
Craftsmen know their field
You need to know principles, patterns, methods and processes, several languages (that are radically different from each other), algorithms, etc., etc, etc. If it's related to software, then you should learn it. And remember, education is your responsibility, not your employer's. Taking responsibility for your career is at the core of the craftsmanship movement.
Craftsmen are continuously learning
Craftsmen never stop learning. They practice software because they love to learn and live to learn. There's all kinds of learning, including: reading (books, blogs, articles, Twitter), going to conferences and user groups (own your own time, not your employer's), and practicing (like actually writing code). Utilize all of these types of learning, and keep pushing yourself. We need to always try to step outside our comfort zone in order to truly learn more and keep improving.
...and this is unfortunately where Martin had to be cut off, as he was already thirty minutes over his allotted time. Nonetheless, he packed a lot into the keynote, and it was not only entertaining but also informative and inspiring. He seemed to capture the key themes and overall spirit of the day, making it a great end to a great conference.