April 18, 2018

Having a spring clean, and "washing" my Github account

I’ve been “active” on Github for about 5 years; and whilst that doesn’t mean I’ve been commiting code daily, nor have I been using their more social features, it does mean I’ve built up quite the collection of.. well, pretty awkward and embarassing code.

Over the past couple of months I’ve tried to streamline a lot of my online presence:

  • I have this blog for technical topics, whilst I have musings.fergus.london for politics and current affairs.
  • I’ve kept the same username for Reddit, Github and Twitter: all cryptographically verified via Keybase.io… using the same username.
  • I’ve been keeping tabs on different recruiting agencies that have contacted me, and I’m preparing to use the incoming GDPR legislation to have my details removed. (More on that soon, I actually have a post queued up for May 25th - Happy GDPR Day!)

This has allowed me to tailor my writing to specific audiences, control who holds data over my professional life, as well as control my public online persona via tracking my common username. Although the last point was difficult with regards to views on privacy, it has a few benefits in itself. (That’s for another post though!)

It’s come to my attention that my Github profile has become a little.. erh.. messy though.

Splattered colorful paint over a white table with bottles of paint in Praia de Santa Cruz An illustration of my Github account. (Photo by Ricardo Viana / Unsplash)

Embarrassment is the key to progress.

It’s difficult to deny the beauty of the late Douglas Engelbart’s quote on embarassment:

The rate at which a person can mature is directly proportional to the embarrassment he can tolerate.

To truly develop in any field, or through life, you have to be able to look back and think “Yikes, why did I do that?”; that is, after all, a sign that you’ve learnt more and refined how you approach situations. That’s good.

The beauty of Git, and thus Github, is that all changes are timestamped - and thus it becomes clear that my code of yesteryear is not my code of today. (Yeah, I know Git timestamps can be modified.. but am I really going to do that to share some embarrassing code?!)

So it would be unfair to say that embarrassment was a key reason behind my decision to purge or archive some of my more unloved repositories; the real reason was far more pragmatic…

My Github profile no longer has any resemblence to my skillset.

I want my Github profile to do two things: (a) show cool stuff I’ve worked on in my spare time because I enjoy it, and (b) showcase my competence at things that I’m actually really good at. Unfortunately this is crucial in the Software Engineering industry today, because as important as a clean CV is, it’s always supplemented with a snoop around your Github profile.

With that in mind, I’ve opted for a four point plan:

1. Remove all forked repositories - of which I have surprisingly few.

I’ve never particularly understood the trend of “forking” repositories that you have no intention to contribute too, originally I felt it smacked of a masquerade - pretending to have involvement or knowledge of something that you simply don’t.

I’ve since come to realise that for some, this is simply a way of keeping bookmarks.. albeit stale bookmarks that soon go out of date. (Seriously, I rarely look at forks on Github because most are so far behind the original codebase.)

2. Archive all repositories that I have no intention of continuing development for.

I wrote some Mac OS X/macOS specific stuff around 3 years ago - specifically around AppleSMC and AppleSMBIOS - in both C and Objective-C. I enjoyed writing this stuff, and I’m quite glad that they’re two projects that people have actually engaged with - in fact I’ve had acknowledgements by email from people that have used this code in their own applications. That’s awesome!

Unfortunately I no longer have the environment (even my MacBook runs Linux now.) nor the inclination to continue working on it - despite the issues being tracked.

3. Remove all partially implemented repositories

I have a few repositories that are simply a “TODO.md”.. or less. These can obviously go.

4. Move all personal/educational repositories to Bitbucket.

I’ve always kept the source code behind my blogs (and often the deployment instructions and/or content!) publicly on Github.. but considering how niche and tightly coupled to my situation it is, I’ve began to consider relocating it to Bitbucket or Gitlab. (not necessarily private either)

In a lot of ways Gitlab specifically makes sense, as I can streamline the deployment using their CI/CD pipelines - and actively have a better development experience. Whichever service I opt for though, I’ll still have the safety of a fully functional Git repository backed by a remote in the cloud… I’ll just have a less noisy Github profile.

Similarly, I’ve a built up a library of educational repositories - such as my attempts at the CryptoPals challenge, my Jupyter Notebooks, or my repository demonstrating “C Tips’n’Tricks” - which are doing little other than acting as a noise at the moment.

Sure, when they’re complete they can come back - until then they can hide away somewhere else though.

© Fergus In London 2019

Powered by Hugo & Kiss. Source available on Github.