Inspired by my recent sojourn to SCNA 2013 (the annual Software Craftsmanship of North America Conference), I've been thinking about ways to improve the mechanics of my programming. One part of the software craftsmanship movement is unconscious mastery of the mundane. As knowledge workers, this allows us to focus on the "hard" parts of the job, all the while leaving a wake of clean, maintainable code with little cognitive overhead. For the sake of brevity, I'll assume this is a good idea and leave a discussion of the merits of this approach for another day.
When I say "mechanics", I'm referring to the most fundamental aspects of coding and styling. This includes purely mechanical skills (e.g. typing, tooling, formatting, language features, build management) and mastery of basic software tactics (e.g. styling, patterns, code organization, TDD). By practicing our programming outside of our forty-hours-a-week, we can become truly proficient in languages, IDEs, low-level implementations, and testing. The end-game is that, when trying to deliver software, we can focus on the problems that really require a professional's attention -- elegant architectural solutions, business-driven value, and polished end products.
Some of these methods are obvious, but worth stating. A few of these were new to me when I picked them up off of the various craftsmen in attendance at SCNA. I hope that you'll get at least one idea for a new technique that works for you. Rotate these into your weekly routine and you'll undoubtedly see dividends on your journey to mastery!
1. Code Katas
Code Katas are a great way to practice some of the lowest-level fundamentals. In short, you take a small (but non-trivial) requirement and build out the code needed to implement that functionality. Then, once you're done, you discard your results and do it again! Undoubtedly, there are diminishing returns to performing the same kata over and over until you have it memorized. However, it's very instructive to watch your approach shift between implementations. Summa Technical Consultant Zack Mance suggests doing one daily first thing in the morning for maximum results.
Katas are great for mastering the process of getting a project up-and-running, for mastering new language or IDE features, and for practicing TDD. There are many available resources online describing the philosophy, as well as bountiful lists of problems to solve. If you're feeling really feisty, some people like to turn katas into a performance art... just make sure you have a good soundtrack to back you up.
Here are a couple of resources I've found with ideas for what to code:
http://codekata.pragprog.com/2007/01/code_kata_backg.html#more
http://codingdojo.org/cgi-bin/wiki.pl?KataCatalogue
http://projecteuler.net/problems
2. Pair Programming
I don't want to harp on this one too much, but if you've never tried pairing, you really should. It's staggering how many times you'll have your subconscious paradigms challenged within the first hour of pairing with a new partner. This is particularly great for picking up new ways to attack a problem, subtle style tips, line-level coding tactics, and especially for honing code clarity.
3. Read Books
Definitely one of the obvious ones. If you're looking to hone your mechanics, focus on books that discuss general programming practice (Pragmatic Programmer, Code Complete, Clean Coder, etc.) or ones that provide a hands-on walkthrough of a particular language, technology, or architecture. If you've never read it, TDD By Example is a quick read and a great starting place. As an architectural example, I'm planning to start Single Page Web Applications soon.
4. Online Courses
This one is equally as obvious and equally as broad as "books". However, given the recent preponderance of free online resources (affectionately known as "MOOCs"), you'd be doing yourself a disservice if you didn't take advantage of the excellent teachers that are putting world-class instruction out on the internet. I'd also group online tutorials under this category. There are even some amazing online tutorials that provide in-browser REPLs or similar functionality for hassle-free forays into new languages. When I was first dipping my toes into functional programming, I was able to learn Clojure and F# without having to download anything... it's difficult to overstate how convenient that is.
The three biggest MOOCs right now seem to be Coursera, Udacity, and edX. Many universities are also offering free lectures directly.
5. Code Koans
Code koans are a set of questions, phrased in code, whose answers are meant to be instructive to a programmer when learning a new language. While koans are not necessarily suited for practicing mechanics, they are an interesting way to learn a new language -- or technology! (Some platforms are starting to adapt koans as a way to introduce developers to their features). Code koans are the rough spiritual successor to Buddhist koans, questions asked to provoke thought and test progress in acolytes on their way to enlightenment.
At this point, many (maybe all?) programming languages have sets of high-quality koans freely available for download. I have found them useful to get a feel for a new language, although I usually need to do something more practical in order to really learn the language features. That said, it can be very nice to view idiomatic syntax before striking out on your own. Also, returning to koans after you already "know" a language can be very zen.
6. Solo Pet Projects
Again, file this one under obvious. Work on personal projects in your free time. There are certain challenges you can only ever learn to defeat when you are the one ultimately responsible for a code base. Also, refactoring your own six-month-old code can be a very... uh... "instructive" exercise.
There's a real growth that occurs any time you own every aspect of a full-stack development process. It's really easy to stand on principle when you're butting heads with a team member. When you're the only one accountable to your decisions (process? language? build tool? package structure?), winning an argument is never a consideration. You have to live with the consequences of every tooling, styling, and implementation detail.
In my opinion, this is probably where the most time should be spent. However, if you never step back to incorporate external learning and practice your skills in a sterile environment (à la kata), you'll never progress past a certain point.
7. Code Retreats
I experienced my first code retreat while at SCNA, and I must say, it was pretty fun. It's kind of like a code jam (code weekend? hackathon? whatever the kids are calling them these days) meets pair programming meets code kata meets musical chairs meets Fluxx. If you can get into a code retreat with developers outside of your usual ecosystem, then you'll get to relearn the basics from a bunch of people you may never see again -- and that's a learning opportunity that is hard to replicate. However, the best part is the shifting rules of the game.
While repeatedly pair-solving a coding challenge, the code retreat may impose rotating restrictions on the code you write. Some example restrictions were no iterating through loops, ping pong pairing with no talking (not recommended for day-to-day usage), and only three lines of code per method. While some of these are toy challenges, occasionally you'll forge a few new neurons learning a more elegant way to solve a problem you'd otherwise have solved through rote repetition.
8-10. Open Source Software
Why open source software? Because A) you can and B) you have unfettered access to the raw source code of a worldwide network of passionate software developers. Think about that! It's a mind-blowingly staggering resource! There's more than one way to benefit from this opportunity.
Firstly, you can read open source software! To borrow a metaphor from Dave Thomas at SCNA - do you think any great writer ever broke through without reading some of the masterwork literature of authors past? Of course not! So, why aren't we spending time reading code from great open source projects? Sure, the metaphor's not perfect... but if you really want to learn idiomatic constructs or learn how to apply TDD and single-responsibility to keep an overwhelmingly large project manageable, look no further than open source. It doesn't take long to pick up lots of perspective. And c'mon... you can literally see exactly how world-class programmers are doing things. It's amazing! Amazing! The greatest! And it's free! Free!
(Quick sidebar, you can also get a good feel for what bad code looks like if you want to. Sometimes it's good to get a perspective between grok-able code and gobbledygook. Just make sure not to internalize the bad stuff.)
Secondly, you can contribute to an open source project. Don your tough exterior (you know, to protect your sensitive, passionate interior) and get ready for the unwashed masses to weigh in on your handiwork. It's like crowd-sourcing code reviews. You couldn't pay for that sort of feedback even if you wanted to.
Thirdly, you can participate in testing or code reviewing open source software. In addition to doing humanity a service (unless you're load-testing the next script kiddie bundle), you'll get a more hands-on experience in reviewing code than you do just by reading it. This is a great way to practice reading code and to learn how implementation decisions impact readability and testability. As we all know, reading code is a much bigger percentage of our jobs than writing code.
If you're looking for a place to start picking open source code bases, Summa's very own Ben Northrop has a great page that compares some open source projects by static code analysis metrics. Certainly not a definitive measure of what's "good code", but it's a useful starting place.
Have you used any of these methods to improve your programming? Would you add anything to the list
With New Years Resolutions looming, I know I'll definitely be adding some [if not all] of these to my career plan. Then, once we hit mastery, the real work can begin! Cheers.
