(This was my ‘About Me’ page when I first started this blog site, which was development-centric in content)
I was a curious kid, a tinkerer, who liked to take things apart and see how they worked. I grew up in an 8-bit world in the 80’s and began dabbling with BASIC at the end of that decade on an Apple IIgs. My youthful forays into the world of code were not disciplined and a decade later, I found myself as an unfocused college student who had earned a liberal arts degree.
Although I still carried the dream of becoming a developer, it just didn’t wasn’t something I had natural talent for. But the passion was always there. One of my favorite books, one of the few I read multiple times over, was Steven Levy’s Hackers Heroes of the Computer Revolution. I needed to pay the bills and in the late 90’s I began a career as a system administrator, learning all that I could about Windows, Linux, and Solaris systems.
The rise of Linux in the workplace kept things interesting, but there was something fundamentally lacking in what I was doing. There weren’t enough outlets for my creativity and although I got into scripting, taught myself Perl, AppleScript, and some VBScript, it was primarily to automate repetitive systems management tasks. I craved to learn about the fundamentals of development – the heavy duty stuff. I would lament how I wished I would have applied myself more in college and achieved that CS degree! I just hadn’t been able to discipline myself to balance career and personal life, while also learning to become a “real programmer”.
The end of 2007 changed all this, when I was offered a real life development position. I was a “web engineer” contractor for a fortune 500 company at the time and asked if I would consider a position as a full-time developer, supporting some of the applications I had worked on as a web engineer. I didn’t even consider myself much of a scripter at the time. CVS confused me, Perl references were a mystery, but my quick ability to pick things up and self-learn, as well as my nine years of systems experience gave me the confidence to step into the position.
Initially my new development role entailed maintaining a couple of legacy apps, one in Perl and the other in Java. This was a great position for me to start with, since it maintenance meant there wasn’t a lot of coding required early and I knew I was on a team that was quickly growing. Career-wise this was the most exciting turn of events I could have dreamed for and I took full advantage and jumped into the world of development with two feet in the air.
My first few months as a developer had a learning curve as steep as Mt. Everest. It is hard to explain to someone who understands version control management, how confusing it all was to me. Merging and branching and committing, oh my! I was a little fish in the proverbial ocean. The land of development was a welcome change from the constant overflow of mission critical failures and help tickets (remedy, anyone?). Having the extra room to breathe gave me enough time to self-learn, research alongside being a productive asset to the company. This was what it took for me to finally pursue my dream of writing code, I had to do it for a living.
That first year in 2008 I began digging into Perl that and read the Learning Perl, Intermediate Perl and Programming Perl series from O’Reilly. I also made the switch from Vim to Eclipse as an IDE. I remember when I first looked at Eclipse thinking, “Shit, that’s a lot of buttons!”. Perl was a lot of fun and I’ll always have a fondness for it as it was the first language upon which I cut my dev teeth. I continually yearned to challenge myself and push my knowledge to the limits. And I found that limit when I got stuck in Damien Conway’s, “Object Oriented Perl”. I loved the complexity of the subject, but somewhere along the first quarter of the book, I became lost and my procedural brain, wasn’t able to wrap itself around OO programming, especially not in Perl.
At the same time I was getting lost with Perl OO, I joined a newly forming product development team charged to develop a multi-threaded Java application, which took data feeds and loaded them into databases. That Everest learning curve, just went K2 on me! It took the better part of a year to begin feeling comfortable with Java and OO concepts, at least to the point where I could intelligently read my coworkers code and understand what was going on.
I’d begun to develop a fairly thick skin to learning things that were completely foreign to my brain and persisting in a state of non-comprehension during my initial learning phase. I knew if I stuck to something long enough, the bigger concepts would eventually get soaked up by my synapses. The business world was more forgiving than college in this respect, and I was also a heck of a lot more motivated by my paycheck. Plus this was my dream job! By now, version control and Perl references had become my good friends.
Still having some difficulties getting into intermediate OO design and concepts I decided to start over and read O’Reilly’s Head First Java book alongside wathching Mehran Samahi’s Programming Methodology lectures from Stanford. It really just took time for OO to really sink in with me to the point where I could use it intelligently, about a year to be more exact. Yet moving on to more advanced topics was still slow going and I was having particular difficulty ramping up on all this, while my peers were busy leveraging their CS knowledge in designing our multi-threaded data loader application, which made heavy use of stored procedures, persistence, XML, I/O, concurrency, and many other libraries and frameworks.
Just after getting comfortable with OO the basics, but not being very fluent with Java, I began to latch onto the idea that I needed to learn more about OO design patterns, which were my gateway to understanding what my coworkers where talking about in the architecture and design meetings.
I once again became lost as I tried to understand patterns and concepts, and really had not yet developed a fluency in Java and likely not fully grasped all the basic OO concepts. When should I use final vs. static, what visibility should I give an object given my overall design, and what is the best way to implement polymorphism made my head spin. I didn’t understand what an Enum class was for, or how a generic method extending a comparator might be useful – there was just so much to learn!
Without a strong underpinning of Java and OO design reading the Head First “Design Patterns” was mind-blowing, yet I gave up after the first quarter. I was able to apply what I learned to some of my production code and was beginning to better understand things my peers were implementing, but I also felt horribly lost and more confused than ever before. I had to take a step back from where I was and learning design patterns. I wanted to “discover” patterns in well-formed design, not through rote memorization and explanation. I really felt that was the golden ticket, which would give me the deeper understanding, that I so desperately sought.
It was about this time that I came across the Structure and Interpretation of Computer Programs lectures and began reading about how people raved about this course, if you could stomach the math involved along with the difficulty of the material, as well as learning a new language, which you likely wouldn’t use in the real world. I began with the original Abelson and Sussman SICP lectures, but soon also discovered Brian Harvey’s CS61A lectures from Berkeley, which seemed a little more accessible to my already muddled brain, but as with the design patterns this effort didn’t last. Shortly after I watched the A&S lecture on the wonderful lambda, I became pretty confused and lost my drive. And when I was watching Brian Harvey’s lectures I just couldn’t bring myself to commit to learning a language, which had a reputation of having little practical value.
I took me the better part of a year before I came back to SICP. I knew I really wanted to study the course. This time I was prepared to discipline myself and get through the SICP lectures and do the exercises and just deal with learning Scheme, since I knew the knowledge gained would be universally valuable. I gave myself plenty of time and acknowledging the endeavor would likely take the good part of a year and that I needed to take my time to properly study the material.
This is what brought me to checkout the Clojure language. I had settled on using Scheme for the SICP, but I wasn’t sure which dialect to use, there were so many variants. One of my team members of had been coding unit tests in Scala earlier that year, so just out of curiousity I began researching what other languages people were using for the SICP exercises and if Scala might work.
I hoped to find a modern language, that would still allow me to gain the knowledge of the wizard book and be something I can run in all kinds of environments. Enter Clojure! The more I read about Clojure the more excited I became about the possibilities of this pragmatic Lisp. Wow, a Lisp dialect that runs on the JVM (like Scala), which had a great community following. The deeper I looked into Clojure, I knew I had hit gold. Even the eclipse plug-in looked more mature than the Scala plug-in and I was really digging rainbow parentheses.
I quickly began to read everything I could about Clojure to make doubly sure it was the language I wanted to commit myself to. The elliptical syntax made sense to me, unlike Scala, and there were bits that reminded me of Perl’s flexibility. Clojure had was a Lisp and was more than capable as a language for working through the SICP lectures . Plus plenty of other people were doing the same thing, so there was a community of support if I ever got stuck.
I’ve also recently begun this blog to chronicle my brain on development. It has been a great outlet since I really enjoy writing and that does come easily, so whenever I need a break from learning development, I can write about my escapades. I still have a giddy inner giggle knowing I’m learning a Lisp, that can run on the JVM. It is my hope that it will be my go to language for prototyping, scripting and one day even large scale development..