It’s easy to have a bias of thinking that you and the company you work for have different interests, and there is a trade off between being selfish or doing what the company wants. With this mindset, self improvement feels like something that shouldn’t be done on the company’s dime, or should at least be regulated, so that the employee and the employer can both strike a compromise where both interests are met to some degree. In other words, you think of your role at work to be that of a “Feature Machine”.
At my previous company, I’d experienced release cycles of 1 to 3 months, and release day was usually pretty stressful, especially when a big change was going in! We had various branching strategies to make sure only the code we expected to be released would go in. (Whilst in theory it should be fairly simple because no new code should be committed after taking the release cut, in practice, there was always last minute changes going in and I remember keeping these branches up to date, or merging code between master and the release branch sometimes turned into an absolute nightmare.)
It’s been a while since I’ve written a post on here – and a lot has happened in that time! I’ve started working at another company – a much smaller place with a greater focus on technology and culture, and I’m loving it so far! I’ve learnt a huge deal even in the short time (one month) that I’ve been there, and had many interesting conversations with people.
I do need to start writing again, as I’m worried the huge amount of stuff I’ve learnt will very rapidly fall out of my head, so here’s the first post of a series of random musings based on interesting conversations I’m having or facts I’m picking up along the way. This one’s on a conversation I had this week about immutability.
Last week, I attended an LSCC (London Software Craftsmanship Community) open space, hosted in the Codurance offices for the first time! We celebrated LSCC’s 6th birthday (so there was cake – my kinda meetup!) and a very decent vegetarian pizza. But, this isn’t a food blog so let’s move swiftly on…
It started out with some interesting lightning talks, we had someone talking about communities and how the culture of a community defines that community; we had another talk introducing the some of the concepts of DDD; some people describing their company’s transition from horizontally aligned teams (one in charge of the database, one in charge of the UI, etc) to more feature aligned teams (where every team had the expertise to deliver a whole feature, front to back); just to name a few!
6 months ago, I had barely written a line of Java. Now, I can feel a marked improvement, I can read code and understand what is going on. I can understand how to make simple changes to the code given a requirement, and I know where to go in our enormous code base to find the touch points of a change. I can honestly say that the biggest advancement in my learning has come from pair programming.
One of the things I’ve had to learn on this journey into the unknown is how to use Git instead of Subversion as my version control system. I started by using a personal account to just save the practice I had been doing, but it is SO different when collaborating with others and using it for huge projects! On first impression, I felt that it was overly complicated as a tool and kept doing things that I didn’t understand, and I began to resent it (why bother using something more complicated when Subversion ain’t broke?!)
Regardless of which version control system you use, if you are working with other collaborators on a project (or even just to keep track of your own thought process over time), you will end up writing a commit message every time you make a change to your code. Don’t make light work of this commit message, it is a bigger entity than you or I, and without it we are all doomed…