Tag Archives: projects

Side Projects

A number of years ago I was interviewing someone for a position as a senior software developer at a market leading financial institution. This was a job with a large pay packet, excellent benefits package and potential for reasonable bonuses, so we were being understandably picky. One of my [fairly standard, even now] questions was to ask what development activities he did outside of work. His response was that he spent all day working with computers and that he didn’t want anything to do with them during his free time. The interview was effectively over from that point on.

Software development, like most other technology disciplines, moves at a rapid pace. If you’re standing still you’re moving backwards and it’s frightening how fast you can become obsolete. While you can learn on the job it does require the job containing useful elements you can learn from, and the chances are what you work on day to day isn’t going to be bleeding edge.

The easiest way to reconcile this is with side projects; something worked on during your spare time that allows you to investigate new technology, new languages and new ways of doing things. Interestingly though, I generally find those developers who have side projects are not doing them due to a professional need to keep up, it’s from a personal need to learn. They’d be playing with this stuff even if they didn’t have to.

For me it’s this hunger to learn that makes a good developer. Experience helps, but you can gain experience, I’m not sure you can learn the hunger. It’s not just me who thinks this either, an increasing number of top name technology firms allow their developers to spend a certain portion of their work time on side projects. Even if the project itself end up providing no benefit to the company, the experience, lessons learned and morale boost this practice provides can only help the developer become better and more productive.

There is another side to this though. Developers can be fickle creatures and they can get bored easily. When this happens productivity crashes, and more than likely they’ll start looking for a new job. The day job is never going to be as interesting as the side projects buy its very nature – the product has to make money, and has to satisfy more criteria than simply “be fun“. By accepting that your top guys are going to have side projects, buy allowing them to find what interests them and spend a little bit of time during work time, you’ll find they keep themselves interested.

The question shouldn’t be “why is this developer spending a long lunch working on something not work related?“, the question should be “why aren’t all our developers doing this?“.

Replacing our Git branching strategy

The branching strategy we use at work is one that has evolved from us tentatively learning how Git works, reacting to our mistakes and avoiding the problems that have arisen. I have, on more than one occasion, had to rebuilt the history due to errant merges going into master. Mistakes can also happen resulting in contamination of release branches, or failure to update all required branches, including master. While it works for us, the fact that it can occasionally bite us on the bum, and the fact that I’m having difficulty documenting why we do what we do both point to the conclusion that the strategy is flawed. So I’m binning it, although not until I have a working alternative that we’re happy with.

Key to this new strategy will be how changes are reapplied back to the main and release branches. Rather than simply taking peoples word for why you should or shouldn’t be doing merges or rebases in Git I’ve gone right back to basics and made sure I fully understand what is going on when you merge or rebase and what the implications are – to the point of setting up parallel git repositories and testing the same operations with different strategies on each.

Secondly I need to look at putting branches back on origin. Being distributed can make git a pain in the backside for some things and sometimes you really do just need one place to go look for data. A prime example is Fisheye/Crucible which we use for viewing our git repositories and performing code reviews. Since our JIRA workflow looks to Fisheye/Crucible for information about code changes and code reviews we push all branches to origin. Would a move to Stash remove this need?

Thirdly is our habit of keeping all branches. This leads to a lot of clutter and may or may not be related to the first two points; I’ll need to do more investigation on that front, however, I suspect I’ll be able to greatly reduce the number of branches we have.

What I suspect we’ll end up with is a strategy where most branches are taken from master, with master being rebased back into the branch before the branch is merged into master and then deleted. Release branches will also be taken from master as needed. Fixes to release branches will be branched from the release branch, the release branch rebased back in when work is done, and then the fix merged into the release branch. The release branch will then be merged back into master. At some point the release will be tagged and deleted. Pull requests using Stash will hopefully obviate the need to push feature branches to origin. How well that plan survives contact with reality I don’t know.

Revisiting Git

I first discovered Vincent Driessen’s branching model¬†when I was investigating Git a couple of years ago. At the time I was desperate to get away from the merge issues that we were having with Subversion and was looking into both Git, and different branching models using it. Given the steep learning curve with Git we decided not to complicate things further and to stick with our old branching model; albeit with a slight change in naming convention borrowed from Vincent.

Now I’m a little more comfortable with Git it’s time to revisit our branching strategy, and use of Git overall. I’ve looked at Vincent’s branching model again, and looked at git-flow in great depth and have concluded it’s still not for us, however, the idea of codifying the workflow, and providing git extensions to aid using the workflow appealed to me immensely.

Currently we’re doing little more than branching off master for issues, with each issue (be it a new feature, or bug fix) living in its own branch. Issues are rebased into master when they’re done. Releases are also cut from master and any patches (either to the release version in QA, or to the release version in live) are cut from the release branch, rebased into that and then rebased into master.

In order to simplify our JIRA and Fisheye/Crucible setup we also push issue branches to origin making them visible from a central point, as well as providing a backup. These branches are considered private and not used by others.

Since we have tight control over all the branches a rebase only strategy works fine for our team, although we have had some problems caused by accidental merges. The next step is to improve the workflow and the merge/rebase strategies to survive all situations, codify these steps and then script them – something I’ve already started doing.

I’m also looking at this as a potential opportunity to possibly move away from Fisheye and Crucible to Stash, potentially saving some money whilst keeping the tight JIRA integration.

Always read the small print

I spent a fair few hours this weekend perusing Shutterstock for images for an idea that a friend and I are looking into. Since we were setting up an LLP I figured I could go grab something suitable to use as a logo for a few quid and use it to set up the website, among other things. The search was going well until it came to purchasing the image I’d settled on. Unsure as to which license I’d need I delved into the small print. What I discovered was rather upsetting: you can’t use Shutterstock images for logos or trademarks. In fact there are a number of restrictions on how the images can be used, some of which had me checking I wasn’t breaching the terms of the license on other images I’d previously purchased. In the end I resorted to spending a little more than I had initially hoped and got a professional to do a logo for me. I’m working on the premiss that they’ll do a much better job and we’re not leaving ourselves open for legal issues later down the line. On the plus side I did at least have a collection of images to use as a “mood board” for the new logo. Just goes to show that its always worth reading any licenses you’re signing up to.

Mobile Office

Part of the reason for relaunching my blog was to document and track the start of a few personal projects I want to undertake. Finding time to work on these projects is always fun, especially now there’s a little one running round the house. What I do have, however, is two consistent blocks of 30+ minutes on the train each and every working day. Can I turn this into a mobile office and develop some applications in my spare time?

Well lets look at what I need. Firstly there’s space. Somewhere to actually do the work. While, by habit, I tend to sit in an ‘airline style’ seat (i.e. not a table seat) out of habit there’s no shortage of table seats, even if I have to share it with someone for part of the journey. This is one of the many perks of no longer working in London and living in the sticks.

Secondly I need a development environment. I usually have my MacBook Pro with me, it’s loaded with the tools I generally use (and more can be added) so I’d say that’s sorted.

Thirdly I’m going to need internet for reference, looking for libraries, getting unstuck and humorous cat pictures when things are going badly. That’s not going to be so easy. While I have two iThings with mobile connectivity, both with the ability to tether my laptop to them, the mobile signal on the train is intermittent at best. Between my iPhone and iPad, which exist on two different networks, I have coverage for perhaps 50% of the journey. Annoying if you need to look something up now.

This is not, however, an insurmountable problem. I’m pretty sure that making sure I have a much as possible available to me locally, and by planning what I’m going to do in each chunk I can minimise downtime.

First things first though, I need to decide what I’m going to work on first.