Lost two of my heros

This month I lost two of my heros: Steve Jobs and John McCarthy. As a child, I dreamed of being Steve Jobs. I admired him for what he accomplished and his impeccable showmanship. I learned so much from him and his vision. I'm sad that I will never be able to meet him.

When I got older and learned about how Xerox Parc and John Engelbart inspired the Mac, I found Lisp. My love affair with Lisp goes back to college when I didn't quite understand it, but thought it was strange yet elegant. The light eventually went on and the true power of macros and functional programming was eventually revealed. To this day, there is a source of amazement that comes with Lisp and I thank John McCarthy for that. I wish I could have met him as well.

I can't express how I much these men touched my life without ever meeting them. They both hit the ball so far out of the park that they will be revered for generations to come. The bar has been set and I plan on standing on their shoulders. Thank you.

Imitation and Repetition

I was recently reading Alice Cooper, Golf Monster: A Rock 'n' Roller's 12 Steps to Becoming a Golf Addict and had an epiphany. In one of the chapters Alice talks about the way to be great at anything. He explains one should mimic the greats by watching and then repeat what they do until it's natural. I immediately started to think about programming, of course. We all have programmers that we admire. For me, most of my admired heros are great writers. It's their advice that I adore. I soak their words in and then practice what they talk about. But, it's not the same as reading code. What Alice was talking about was studying what the greats do and repeating it until it's as natural as the way you breathe. Where can we find great code? I always felt my programming took a huge leap forward with Smalltalk. The reason I think that is now crystal clear: Smalltalk encourages you to read other people's code. All of the tools embrace reading code. If you don't know how to do something, you can search via the tools to find something similar and then repeat what they did. There is a plethora of patterns and good programming in any Smalltalk system. All of the GoF patterns came from Smalltalk originally.

That's fine and dandy, but what about Java, Python, Ruby, or other developers? It's just as easy as finding an open source framework you love and diving head first into the code. Study it, practice writing in that style, and repeat until it feels natural. Open source gives us opportunities that only Smalltalk and Lisp did in the past: a limitless supply of software to study in any language we choose. But, this begs the question: How do I know I'm studying good code? Alice touches on this in his book by saying that as you pass milestones in competence, you know what the next level looks like. Start with code that looks good to you now and keep practicing. For me, I strive for readability. How can I remove all noise until the code I write is nothing but the language of the problem I'm trying to solve. I'm always reading code to find new techniques for removing noise. I study code written in different languages and see how I can apply any new techniques in the language I am currently using. I've found a lot of gems by studying from functional programming and applying them to object-oriented languages.

This brings up another interesting observation. If it's good to read code and practice writing it, when should you use a new technique? For me, I always practice a new technique a lot before I apply it to production code. Normally, once a technique feels natural and I know it like the back of my hand. Most of the open source libraries I've written have been to explore an idea that I saw somewhere else to play around with it. There's nothing worse than not having mastery and immediately applying it because it was new at the time. Be patient. Read, code, repeat. Always be reading and practicing. It's the only way to get better.

Mentoring

One of the round table discussion at Des Moines Bar Camp was how to get students excited about our field. The discussion went from how to get students interested in non-coding aspects of software development like QA testing to finding the passionate students. One thing that I suggested was that we needed to mentor more. I think we need not only to mentor students, but people within in our industry.

Let's face it. There's no way to know everything about software development. I would even say it's impossible to know everything about Java (the number of frameworks and new ideas is overwhelming) which is a small part of the entire computing realm.

Getting back to mentoring students though. In the user groups that I attend, it's been rare to come across a student. We are they not coming? Could we be scaring them away? Are user groups too advanced? What?! I think it is none of those things. I just don't think we are marketing to them. How do we do that? I think simply putting up posters and targeting students is a start. Reaching out to teachers is another avenue. Embracing students who come to these meetings is also needed. We need to keep those passionate about what we excited.

Which leads me to that we need to mentor everyone. I've been blessed in my career to have several mentors and I try to be a mentor when asked as well. I want to give back to those that have given me so much. There's only so far that books can go. Experience is best handed down through mentorship. I think it also allows us to feel freedom to try out new things. As we move to move functional programming languages, wouldn't be nice to be mentored by the people with the most experience?

I would love to see our industry to move to an apprentice model. I think the caliber of developers, testers, and leaders would increase dramatically. We're an industry that is just starting to tap into networking (Bar Camps are excellent for this) and embrace sharing (open source). It's exciting times right now and I can see where everyone needs to be mentored. I'm always learning and love talking with people who have more experience in a technology. We need to keep the learning going.

I think the new social networking tools could be used to great effect for setting up these relationships. So, let's get together and start mentoring. Create the developers we would like to work with and be.

Built-in Persistence/Transactions

We have long now been able to let the computer handle memory management in our programs via garbage collection. Why not let it also handle persistence and change management? I think these are things that should be built-in and it would be handled more easily by the virtual machine. There could be a low level API for hooking up different persistence strategies (relational, object, etc) and code would no longer have to be dirtied up with SQL or even worse HSQL. At the very least, change management of objects should be handled by the VM. How much easier would exception handling be if you could also rollback all the changes that had occurred and you could get back to the state you were in before the error? I think these should be the new primitives.

Gemstone is the realization of this on the server. It would be nice to make the code on the client as transparent as well. I know some might laugh at this idea, but I think it has merit. Just like garbage collection seemed strange at first, why not allow automatic persistent management as well?

Books on Design

In one of my comments, someone asked me the book that I would recommend from Rebecca Wirfs-Brock. And I thought why not just put some of my favorites into a list? So, here's my list in no particular order, but all of these come highly recommended:

• Designing Object-Oriented Software : THE book on OO design and analysis. This one keeps it simple and is awesome. Mrs. Wirfs-Brock will always be one of my heroes that I aspire to.
• Domain Driven Design: And I'm not saying this because of my involvement with TimeAndMoney. Eric is not a great mentor, but an awesome author. If you want to learn how to write REAL DSLs, this is the book. Learn to talk through your domain. Read this cover to cover. There is not one paragraph not to be savored. I went to the first Smalltalk Solutions just to meet him. Seriously...
• The Design Patterns Smalltalk Companion: This is the book where you learn a lot of the hidden secrets in Smalltalk and that all of the design patterns started there. This is an awesome book and reads better than the original. Buy this even if you don't know Smalltalk. It's that good.
• Structure and Interpretation of Computer Programs: I don't know one person who has read this and not have had the way they look at software be different. Learn to be a magician. This opened a lot of possibilities for me. It made me much more creative in my solutions.
• Prefactoring: A lot of Agile enthusiasts got upset with this book because they didn't read it. This book dares to followers to do what they say: Think about their designs. This is also a great book if you want to learn more about DSLs. All good OO models are DSLs. If you're not doing a language with your models, you are doing something wrong.
• Agile Software Development: Robert Martin hits a home run with this book. This is what people who think Agile is about no design, should read this. Being agile is about thinking. I know a lot of Agilists get that, but I have come across many who think it's all about coding and no thought. This book goes beyond Agile and talks about good ole great design.
• Software Fundamentals: These articles were written before I even knew what a computer was and they are still relevant today as they were then. You'll either walk away from this bewildered at what we keep rediscovering or notice how a lot of stuff that seems new is really rebranded. This book is just an awesome tomb of software experience from one of the early innovators. His views on encapsulation really changed the way I look at design. Awesome book.
• A functional pattern system for object-oriented design: Functional programming for object-oriented programmers. I love functional programming and by studying it. My thoughts on development and design have changed. This book shows that they both can share ideas from each other and become stronger. This is a fantastic book that should get more accolades. It shows what great things can be done if OO and functional programmers put their powers together for good.
• Every single book that Martin Fowler has had his name on or associated with. They all rock. Analysis patterns is really the crowning jewel (again, if you want to do DSLs, learn from the master). But, all of his books are easy to read and will teach you volumes.
  

I could go on all night, but I'll stop here for now. I didn't even get to the books that I love from Gerald Weinberg, Donald Norman, Shlaer-Mellor, and more, but I will make that for another blog entry. Also, I'm a big junkie for all of the pattern series books. Nothing takes my money quicker than a pattern book. They are chock full of ideas on design and clever solutions.

Theme Song For The Year

This year my wife, Michelle, came up with the great idea to pick a theme song for the year instead of make new year's resolutions. Basically, pick something that will inspire you for the whole year; something that will frame the year for you. I started out going through my collection and wanted some anthemic. I finally decided on Jean-Michel Jarre's "Rendevous IV". I've been a fan of Jarre for quite sometime and I always seem to listen to "Rendevous" when I've been triumphant or want to be. The music is catchy and it inspires me every time I hear it. I have a collection of music that I've always played before contests and interviews and this one is the last one I play now. I also picked this one because of the grand visions that I have when I hear it. I guess that comes from the first time I heard it was on Jarre's Moscow DVD and the imagery was awe inspiring! Needless to say, I expect 2007 to be a GREAT year! And yeah, Jarre RULES!