You’ve just gotta fight your way through

This afternoon I saw a tweet by Jamie González that quoted Ira Glass, "Nobody tells this to people who are beginners, I wish someone told me. All of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, it’s just not that good. It’s trying to be good, it has potential, but it’s not. But your taste, the thing that got you into the game, is still killer. And your taste is why your work disappoints you. A lot of people never get past this phase, they quit. Most people I know who do interesting, creative work went through years of this. We know our work doesn’t have this special thing that we want it to have. We all go through this. And if you are just starting out or you are still in this phase, you gotta know its normal and the most important thing you can do is do a lot of work. Put yourself on a deadline so that every week you will finish one story. It is only by going through a volume of work that you will close that gap, and your work will be as good as your ambitions. And I took longer to figure out how to do this than anyone I’ve ever met. It’s gonna take awhile. It’s normal to take awhile. You’ve just gotta fight your way through."

That was me. As a young graphic designer fresh out of school, I was frustrated by my inability to be as awesome and creative as the designers I was working with. At some point I stopped becoming a designer and identified as a developer because I thought I was a better developer than I was a designer.  

Today, while I do some graphic design and focus on the client end of development, my company pays me for pushing bytes, not pixels. 

The funny thing is, the only reason the same thing didn't happen to me in programming was that I was isolated and ignorant as a beginning programmer and thought I was great at it. Had I had the good fortune of working with great developers early on, I might have given up on that, too. 

Sometimes ignorance really is bliss.

Polyframework

Last year at MADExpo, I was introduced to the world of Ruby. While I have only gotten half-way through the getting started guide, just being exposed to a new language, and more importantly, a new point of view for development, has made me a better developer. But this isn't a post about being a polyglot, for that go listen to Scott Hanselman talk with Ivan Towlson on Hanselminutes. I want to talk about a being Polyframework.

Recently I began to learn Backbone.js in ernest. For the last six months I have spent a majority of my time developing pages with Knockout.js, so as I started learning Backbone, it was only natural for me to compare what I was learning with what I do daily in Knockout. What I am finding is that learning Backbone has helped give me a better understanding of Knockout. I think this is because working with a new framework helps give you a new perspective.

It got me thinking about all the other frameworks I use, and how knowing more than one framework for any given problem domain has made me better at using all of them.

The open source community has a love affair with Ninject. At work, we use Autofac. I find that each does something better than the other. I find that the perspective of using one makes me better at solving problems with the other.

When I first learned TDD, I was taught using MbUnit. It took me months to stop complaining about NUnit. Now I usually choose NUnit but having used MBUnit, NUnit, and xUnit have prepared me so that I won't have to complain when I get that project that requires me to use MSTest. I will have enough perspective to figure it out and get on with my life.

As I write this it occurs to me that this doesn't just apply to just frameworks, but toolsets as well. Last month, just for kicks, I set up a new VM so I could try using CodeRush instead of ReSharper. Man talk about moving my cheese. But I learned that its not a matter of, "can it refactor" but more a matter of "what key command initiates refactoring?"

I complain a lot about SVN, get lost in bash hell when hunking a commit in Git, and love the TortoiseHg Workbench. All of them have taught me how to evaluate a good implementation of a feature vs a bad implementation and reflect on each tools pros and cons.

So the next time you find yourself in File > New Project, consider trying a different NuGet package for logging/testing/injection/scaffolding.

Talking About What You Do

I live in the metropolitan DC area, and it seems like whenever you meet someone new, the first question after introducing yourself is usually, "what do you do?" I have become increasingly self concious about how I answer that question in the last year. My typical response is either, "I'm a software developer," or, "I build websites". But that to me is not a satisfactory answer as it in no way relays the challenges or rewards of how I spend the majority of my waking moments.

When my wife asks me over dinner how my day was, I struggle to formulate and answer that conveys the frustration of a useless expection message, or the joy of seeing three hours of work come to life inside a UI -- without having her eyes glaze over in the first thiry seconds.

Some days an analogy comes very easy to me, but most days I keep my answers short, such as, "I had a bug that took me all day to figure out how to fix," or "I made this really cool interface today."

How do you talk about what you do to people outside our profession?

How I Got Started (and Ended Up) In Computers and Programming

Scott Hanselman recently stated, "I like hearing stories about how people got into computers and programming. Perhaps if I blog my story, you'll share yours."

My first computer was a Commodore VIC-20. I was in the 5th or 6th grade at the time. I think it was a Hanukah present, and I remember being very excited about it. The coolest part was that my parents also bought a cassette player for it that allowed the computer to store and load programs from a standard cassette. 

Along with the VIC-20 came a few weeks for BASIC lessons from a local computer  store. I remember coming home after my first lesson and I wrote a program that would scroll my name across the TV screen as it oscillated through all the colors of the rainbow. From that moment on, computers had me hooked.

I remember getting magazines with games printed inside and I would spend hours typing in the code to my computer to play them. Usually I would modify the code in some vain way to make myself the main character or some other nonsense.

In 7th grade we actually had a computer class in school. We had a computer lab full of Commodore PET computers. I had been doing it home so much that I essentially became a teaching assistant helping other kids and helping the teach write programs to administer math tests.

My best friend got an Apple IIe and we spent a lot of time trying to dial into NORAD just like Matthew Broderick in "War Games." We also spent a lot of time with the game "Where in the World is Carmen San Diego." 

For my Bar Mitzvah I got an Apple IIc. It came with a green screen, but it also had an RF modulator so I could hook it up to our TV. I also got a subscription to Nibble and would enter in the programs from it. The one program I remember most was a simple program that was merely a list of pixel coordinates that when run would render an image of Alfred E. Newman.

For some reason, probably my interest in girls, I never got deeper into programming other that entering or fidgeting with the programs that were listed in magazines like Nibble. 

In high school we had these fancy new Macintosh computers, and they had a program called Page Maker. With page maker I could print out documents that looked like professionals had made it. That got me interested in graphic design. My only programming was to make flash cards and simple forms in HyperCard.

In college I took a semester of Pascal, but I found that spending a couple of hours in MacKermit writing a program and then having to walk across campus to get the printed result was not terribly exciting. I wanted to make video games, but somehow I could never get past the "Hello World!" part of any of the numerous C, C++, Turbo Pascal, etc. books I bought thinking that spending an hour with a book and a night on my Mac would somehow produce a blockbuster video game like Mortal Kombat.

So the programming thing never took off for me and I graduated with a BFA in graphic design. But I was still a geek, and the first job I got out of school was for a "New Media" company that was starting to make interactive cd-roms. My limited programming background made me more useful writing lingo script for Macromedia director than as a junior designer on a team of seasoned graphic designers. In addition to the cd-roms, we would occasionally make these things called HTML pages for this new thing called the world wide web. I got really good and being able to craft pixel perfect HTML tables that would look just like the Photoshop mockups. 

Eventually we were doing more website projects than cd-rom projects and our HTML pages were rapidly evolving from the giant image maps and needed more interactivity. I started learning how to modify PERL scripts I found on the internet for our needs. My company sent me to Java classes and I felt more like a "real" programmer having stepped up from a scripting language to something I could actually compile.

Then one day a friend from college called me and told me of an idea where foster children could log on an interact with their social worker using forms on a web page. I had built a few cold fusion pages but I had recently read about this new feature form Microsoft called active server pages and I told him that I thought ASP could do what he was asking. The next day I went to the book store and bought ASP for Dummies, fired up my PowerMac that had a Windows 95 emulator card in it that we used for IE compatibility testing, and wrote my first ASP application.

A year later I quit my job and went into business with my friend trying to sell this case management system. In the process I moved from the Mac and BBEdit to the PC and Visual InterDev. By the time we threw in the towel on our Dot-Com millionaire dreams i had gone from Graphic Designer to Designer/Developer. 

From ASP I moved up to ASP.NET using WebMatrix for a good long while before convincing my boss to splurge on MSDN so we could get Visual Studio. By then I was spending a lot of time on the MSDN website and was learning about good development practices and things like application blocks from the patterns and practices group.

In what I consider to be a pivotal moment in my development career, I somehow stumbled across a DotNetRocks TV episode with J.P.Boodhoo. I instantly knew that TDD was the only way I wanted to write software, but the episode left me with a lot of questions, which I sent to J.P. in a long email that rambled on and on, much like this blog post. I really didn't expect a response, and I certainly was shocked when he called me the next day because he felt it would be easier to answer my questions on the phone than by email. not long after I was able to attend his Nothing But .NET class where I learned all about TDD and Design Patterns. 

When I look back, that was the moment that I feel I truly became a software developer. After that class, the development process made so much more sense. I began listening to Dot Net Rocks, reading blogs of other TDD/XP, and Alt.Net practitioners. I stopped thinking of software as job and began to appreciate it as a craft that I truly enjoyed.

Sometimes I feel inferior to my colleagues who can write "real" software, managing pointers or writing assembly language. Some days I wake up worried that I'm going to be shunned for not having graduated with BS, or for having never written a compiler. But most days, I get to go to work, write some code I'm really proud of, and produce application experiences that my product owner never thought was possible. And for those days I am always grateful.

Why Would I Write Unit Tests When I Get Paid by the Hour?

This morning I read an entertaining post by Jonas Hovgaard about how he has abandoned some sound patterns and practices for what he considers to be increased productivity. It is timely in that just this weekend I read another great post about “flipping the bit” by Uncle Bob. These two completely opposite posts have one thing in common, they both are concerned with productivity.

Personally, I’m on Uncle Bob’s side. But I am on his side because I am going to be the one maintaining today’s code tomorrow. This has not always been the case. I once was a consultant churning out website after website with pseudo CMS capabilities. I suspect that Jonas is as well based on his statement, “In my personal scenario (creating around 20-30 apps every year).” I imagine Jonas doesn’t maintain applications, but rather cranks out site after site at Acme Webapp Co. In that kind of environment, the business model works by spending as little time as possible getting the minimal functionality possible to get client acceptance and payment. In that environment code that is hard to maintain isn’t a problem, it’s a business model.

Jonas hasn’t abandoned testing altogether, as he as adopted acceptance testing using Selenium, and he is right about the fact the the most important test for your code is the user acceptance test. But in the end if its working for him, more power to him.

I would like to take a moment to comment on some of his ideas.

I agree, it's absolutely awesome that I can change the concrete type or lifecycle with ease, but for gods sake, I don't even dare to count the hours I have spent creating these abstractions, making me able to do something I never freaking do.

I don’t like interfaces for their extensibility. I agree that we hardly every swap implementations. Occasionally we may swap a logger but I have never needed to replace my SQL data tier with an Oracle one. That’s not why I love interfaces. I love them because it allows me to write one section of my code without worrying about how I am implementing another section at the same time. I use interfaces mostly because I want mocks. Even if I didn’t do TDD but were doing F5DD, I would still want to program against an interface, implement fakes for lower level layers, and code my way down from the html.

But also I spent hours trying to understand what Ninject or StructureMap did with my classes. When I finally understood, I handed over the application to the next developer who also was forced to spent time understanding some IOC.

Ah, the magic of frameworks. It makes me sad that someone would abandon sound principles because they didn’t like the tools they have chosen. I love IoC containers, but like Jonas I have often been frustrated trying to locate “where the magic is happening.” I had one particularly sucky day trying to locate how something was being injected in a global action filter. Magic on top of magic. The aversion to magic is a bad reason to abandon a sound principle. IoC is not defined by the containers that we use. I myself am very fond of the Service Locator pattern (scroll down half-way.) This is a no-nonsense pattern for straightforward dependency injection.

At the end of the day, I want to write code that I am proud to share. For me this means well tested code because my tests are my insurance to myself that I have done well. My tests also serve as a guide to my fellow developers as to how I intend my code to be consumed and the current requirements it was written to fulfill. And most importantly my tests (and my commit messages, but that’s a whole different post) tell my future self what the hell I was thinking when I wrote this crap because we all hate the code we wrote yesterday.

But hey, I have to maintain my code, and I’m not getting paid by the hour to do it.