Github As The New View Source

I learned to make websites in the mid-90’s. It was a wild era where Firebug wasn’t yet a glimmer in the eye of our future saviour. It was a path filled with splash pages, pop-up site frames and lots of tiled backgrounds, pixelated construction workers and quite a bit of prejudice against third generation entities. A List Apart was years away and what knowledge there was out there to be shared was buried in Yahoo’s less than brilliant search results. We were all (mostly) making it up as we went along.

My story is not a new one. As the web grew in scope and reach many early website creators have used the medium to share their stories. I, like many before me, would find a site that I liked. I would use my browser’s “view source” menu item to see how they made it. I’d copy all the code and linked files to my own computer and start changing things to see what happened. This is how I learned every bad habit I had. I’d create borders in my browser window using an array of nested frames. I’d hide links in body copy by using CSS to remove the underlines and change the coloring. I learned how to nest tables, make links open in new windows and use images to make area maps.

What I also learned in those early days is perhaps the most important thing I’ve learned in my entire career. I learned how to learn from others. I wasn’t using a book or attending a class. I was like a mechanic, taking apart an engine to get an inside view of what made the car move, hoping that when it was all put back together there weren’t any stray bits laying around and it started right up.

As the web has matured, a lot has changed. We’ve gotten access to robust developer tools that offer far more functionality than our view source text files offered. But we’ve also gained build processes that break the bits of our site into many related and interconnected shards. Performance concerns have resulted in deployed code that is often unreadable and only generationally related to the markup that created it. When I was rebuilding my website I thought a lot about this as I configured my build steps. What I was gaining in file minification and concatenation I was taking away from those that were entering the field and could learn from me the same way I learned for others. I made the decision that I’d make the Github repo for this site public and add a message to every page of the site that made it clear where the source files were. Opening up my source code has a handful of direct benefits.

Being A Good Citizen

It’s my way of being a better citizen of the web. I’d like to see more of my peers make their personal work public, and publicize it once it is. Especially those peers that share a common belief that it’s our responsibility to share what we’ve learned with those that are just now learning. I believe strongly in the concept of what benefits one of us benefits all of us. The better other designers and front-end developers are, the better their interactions with their clients will be and the quality of their work will improve. That makes all our lives easier. In isolation, it’s just a person’s good reputation. It doesn’t take much, though, before those isolated incidents become the impression of our industry.

Open To Criticism

I decided to redesign, build, and launch this site refresh over the span of a week (a week where I was also attending upwards of 5 meetings a day). I made a lot of trade-offs between “good enough” and “perfect”. By opening my code repo I also open myself up to public critique and questions. That’s great! I have learned a lot in my career, but I haven’t learned everything. The worst that will come from questions and feedback is that I might get an email from someone pointing something out that’s already on my radar to be fixed. While it may not be through viewing source code, I’m still learning from others. Open and public discussion on the code that I wrote is just another way to do that. As you dig through the code, if you don’t understand something I’ve done, or think you’ve got a better suggestion, add an issue to the project or send me an email. I can’t wait to hear what you’ve come up with.

Designing In The Open

There’s a great movement in the design industry right now around the concept of designing in the open. It’s been building up steam for the past few years and there’s few other movements that have struck such a chord within me. I love the idea, and have been disappointed that I have not been able to apply it to my own client work. Working on this site gives me that ability. It also gives me a chance to learn from the experience. The stakes on my own website are low-pressure. I can begin to learn the benefits and drawbacks of the process first hand. This will make it easier to sell the concept to future clients that don’t readily see the benefits of sharing their work in progress.

TL;DR

The code for this site is public. I encourage you to read through it, ask questions, offer feedback, share with others and do the same for your work. The more we share, the more we can learn and the better off we’ll all be for doing so.