Stories about Software


Reviewing Strangers’ Code on Github

Editorial Note: I originally wrote this post for the SmartBear blog.  You can check out the original here, at their site.  While you’re there, check out some of the pieces by their other authors.

I make part of my living these days as an IT management consultant, and in this capacity, I’ve developed an interesting niche: evaluation of codebases.  Specifically, an organization’t management will bring me in to spend a week or two looking through a codebase, sizing it up, and making recommendations for what to do with it going forward (e.g. “stay the course, rework the architecture, targeted training, scrap it, etc.”)

As you might imagine, this part of my practice leads me to looking at and quickly grokking a lot of unfamiliar code.  Every few weeks, I’m squinting at strange classes, running static analysis tools, and making lists of assumptions and questions to ask the development team.  And I’ve found that this practice has benefits to me beyond helping me earn my living.  I’d argue that it makes me a better programmer.

Consider the opposite situation — one that describes an enormous cross section of industry developers.  They come in to work each day and deal with the same codebase.  This continues day in and day out for weeks, months, or even years.

This year, my wife and I are hoping to make a visit to the Galapagos Islands, which are noteworthy for the uniqueness of the wildlife there.  The animals living there have been isolated from the wider world of fauna for millions of years, and the result is that they’ve developed unique and unusual characteristics that cannot be found anywhere else.  This is what tends to happen to codebases in shops where the majority of developers work in relative isolation.  A bubble forms, and practices drift toward the unusual.


For an individual, this isolation tends to put a damper on skill acquisition and can even be career limiting.  It’s the polar opposite of the situation in which I find myself — constantly immersed in unfamiliar code.  So how can you remedy the isolation if your professional life shows you the same code in day in and day out?  (Without drastic career moves, that is).  Well, the dead simplest thing I can think of is to seek out and review other people’s code.  And to do that, there’s no better place to go than Github.

Here’s what you can do.  Every few weeks or so, poke around idly on Github, searching for random codebases in your language of choice.  Big or small, popular or niche, active or forgotten — it really doesn’t matter much.  They just need to be different and new.

Once you’ve found one (and just about any one will do), clone it and get the code locally on your machine.  Open it up in your IDE/editor/environment of choice, and start looking around.  If you start to perform this exercise with some regularity, here are some benefits that you can expect, in my experience.

Read More


Why is Github Taking over the World?

Editorial Note: I originally wrote this article for the SmartBear blog.  Click here to check out the original.  If you like this content, take a look around at their offerings and their posts from other authors.

There’s a word out there that you’d be a lot more likely to hear from journalists, pundits, and authors than you would from techies: zeitgeist.  The dictionary definition of the word, “the general beliefs, ideas, and spirit of a time and place,” is straightforward enough.  But when used by the people I mentioned, zeitgeist, as a descriptor, imparts gravity on the thing it describes.  It I say that Github captures the zeitgeist of the programmer world of the 2010s, I am thus saying that Github is at the absolute core of the software development universe.

And I do say that.

If you’re not familiar with Github, I’ll offer a brief description.  It is a website that wraps a software version control system called “Git” and allows software developers to host their code online for free (though there are paid models available).  If you’re a software developer, Github is a repository for you to store, exchange, trade, and talk about code.  This may not sound like the stuff of which zeitgeists are made.

The sheer, raw popularity of Github alone doesn’t explain this classification, either, though it is popular.  Alexa, a web analytics company (not to be confused with Amazon’s Echo personality), ranks Github as the 83rd most popular site on the planet, as of the time of this writing.  That’s particularly impressive when you stop to consider that Github’s audience is the slice of software developers that feel like freely exchanging source code with one another.  Other popular sites occupying top rankings, like, Facebook, Amazon, or Google, on the other hand, have an audience of literally everyone on Earth.

It isn’t the improbable, raw volume of traffic to Github that elevates it to Zeitgeist level, however.  It isn’t even the growth or the market cap of the company or the number of contributing developers.  Those things alone can’t explain why Github is a zeitgeist — why it’s taking over the world.  To do that, let’s look at it in a bit more detail.

From Improbable Beginnings

Let’s take a little known, somewhat pedantic approach to storing code, wrap it in a cute user interface package, sprinkle a little social media on it, compete with an entrenched market dominator (sourceforge), give it away largely for free and change the world!

If I could go back to around 2008, when Github was just starting out, I can’t say I’d be clamoring at the bit to become an investor.  At least, not without 20/20 hindsight.  It doesn’t really sound like a game-changer, and yet that’s what it became.

And yet, if you look at tech trends, the makings were there, if subtle.

Distributed Version Control for a Remote World

If you’ve been writing code for a long time, you no doubt remember the bad old days of remote work when it comes to source code version control.  At the time Github first started attracting notice, centralized version control schemes were the standard, and when you were somewhere the source control server wasn’t, things could get painful.  I remember using a tool called Rational Clear Case that was setup in such a way that it took me most of the morning to commit a few files to source control if I was working from home.  As bad as that sounds, it could be worse — if you were on a plane or somewhere without internet access, you wouldn’t be able to work at all, unless you had planned ahead of time to acquire an “offline” version of the code.  And then, getting it back online could be quite painful once you re-connected.


Git, the version control system upon which Github is based, changed all that with distributed version control.  Git was the version control of Linux — a decentralized, democratic tool that could support ad-hoc, global collaborations.  Github, the website, wrapped Git up and encouraged you to work with the full safety of source control wherever you were.  And, don’t worry, they reassured you, it’ll be a breeze to sync back up when you’re connected again.  And it was.

Github offered remote coding to an increasingly remote workforce.

Read More


Github and Code Review: A Quiet Revolution

Editorial Note: I originally wrote this post for the SmartBear blog.  Go check out the original here, at their site.  Stick around and check out some of the other authors and posts over there if you’re so inclined.

When the winds of change blow through the programming world, they don’t necessarily hit everyone with equal force.  The start-up folks cranking out reams of Ruby code on their Macs probably feel a gale-force headwind, while a Software Engineer III toiling away in Java 1.5 for some Fortune 500 bank might feel only the slightest breeze.  But on a long enough timeline, the wind changes things for everyone.

Github has proven nothing short of a revolution for a lot of small, nimble organizations, startups, and cutting edge companies.  For heavily regulated, locked down enterprises, this effect is certainly muted, but I would argue that its subtly perceptible nonetheless.  Github is changing a lot of things about software development, and this includes the nature of code review.

Let’s consider some properties of Github.

Social Coding

Github is often described as a social network for programmers.  The term “social coding” has even appeared in some of Github’s marketing material.  It is a platform meant, specifically, for maximum interaction.

Sure, Github is a vehicle for open source contributions, but that’s hardly a difference-maker for them.  Sourceforge was around for a long time and it would host source control for open source projects for free.  There have also been other communities oriented around contributions and code sharing, such as Code Project.  Github, however, came along and truly married social with coding, introducing feeds, followers, ubiquitous collaboration tools, and even a social network graph.  Having cute octopus buddies as their mascots probably didn’t hurt matters either.


The result is an unprecedented amount of enthusiasm for global sharing of code.  20 or even 10 years ago, you probably would have hoarded source code of a side project.  You wouldn’t have wanted to give away your intellectual property and you’d probably also have been embarrassed until you could tidy it up to put your best foot forward.  Now the default is to throw your side work up on Github and show it off for the world and your followers to see.  Code is being shared as never before.

Read More


The Joy of Adding Code to Github

These days, a good portion of my time is spent on overhead tasks: management tasks, strategy meetings, this sort of thing. In my role, I also am responsible for the broad architectural decisions. But what I don’t get to do nearly as often between 9 and 5 these days is write code. All of the code that I write is prototype code. I’m sure that I’m not unique in experiencing drift away from the keyboard at times in my career — some of you do too as well. As you move into senior or lead type roles and spend time doing things like code reviews, mentoring, etc, it happens. And if you really love programming — making a thing — you’ll feel a loss come with this.

Of course, feeling this loss doesn’t have to be the result of having more overhead or leadership responsibilities. It can happen if you find yourself working on a project with lots of nasty legacy code, where changes are agonizingly slow and error prone. It can happen in a shop with such intense and byzantine waterfall processes that most of your time is spent writing weird documents and ‘planning’ for coding. It can happen in an environment dominated by loudmouths and Expert Beginners where you’re forced by peer pressure or explicit order to do stupid things. It can happen when you’ve simply lost belief in the project on which you’re working or the organization for which you’re working. And it almost certainly will happen to you at some point in your career.

Some call it “burnout,” some call it “boredom” and some call it “losing your way.” It has a lot of names. All of them mean that you’re losing connection with the thing you’ve liked: programming, or making a thing out of nothing. And you need that. It’s your livelihood and, perhaps more importantly, your happiness. But, you can get it back, though, and it isn’t that hard.


Recently, I decided to order a few more home automation pieces (blog to follow at some point) and reboot the design of my home automation server to make use of a Raspberry Pi and a REST service in Python. I don’t know the first thing about Python, but after the parts arrived, and I spent a few hours reading, poking around, failing, and configuring, I was using Fiddler to turn all the lights off downstairs (code on github now — work in progress).

There is nothing quite like the feeling of creating that new repository. It’s daunting; I’m about to start learning a new programming language and my efforts in it will most certainly be daily-WTF-worthy until I learn enough to be passingly idiomatic in that language. It’s frustrating; it took me 15 minutes to figure out how to reference another code file. It’s tiring; between a day job taking 50+ hours per week and the work I do with my blog and Pluralsight, I’m usually coding at midnight on school nights. But forget all that because it’s exhilarating ; there’s nothing like that feeling of embarking on a journey to build a new thing. The code is clean because you haven’t had a chance to hose it up yet. There is no one else to tell you how, what, or when because it’s entirely your vision. The pressure is off because there are no users, customers, or deadlines yet. It’s just you, building something, limited only by your own imagination.

And what a powerful feeling. If you’ve got a case of the professional blues, go out and grab this feeling. Go dream up some new project to start and chase after it. Recapture the enjoyment and the excitement of the desire to invent and create that probably got you into this stuff in the first place.


FeedPaper is Born!

As of Thursday, 11/02/12, a baby ASP MVC project named FeedPaper (later to be feedpapyr.us) has arrived. It is healthy and weights 0 pounds and 0 ounces. Both it and I are doing well, and while it does not yet have much in the way of functionality, it does have its father’s logo and some functional unit tests. (As an aside and leaving this strained metaphor, I’ve never really understood why the weight of babies is announced to me as if someone were trying to sell me a ham — what do I care how much anyone weighs? It’s always tempting for me to respond by saying, “big deal – I totally weigh more than that.”)

Anyway, you can find the source for it on Github. As I mentioned in a previous post, the main thing that I’m interested in is getting this thing up and running, so I’m happy to accept pull requests, suggestions, help, and anything else you’re willing to offer. The plan is to get it going as a website and then perhaps later port the presentation portion of it to phone/tablet implementations as well. But, no sense putting the cart before the horse — I have to figure out ASP MVC 4 first.

So, look for sporadic work on this when I have time and feel like tinkering and am not working on home automation with Java and MongoDB. I will also make posts here and there about lessons I learn as I ham-fist my way through it, talking about my experiences with the frameworks and toolsets involved. Also, in general, I’m looking for the best options for hosting the site, so suggestions are welcome (should I try out Azure, go a more traditional route, etc).