Matthew Lang

It’s become clear to me that there’s far too much stuff on my master list. It’s things that I want to do, but I’ve started reaching too far forward into the future and starting noting stuff down that I want to do but I won’t be able to do for at least six months.

Speculating on what I should be doing in months is no good. I need to see a short term list of things that I can be working on now rather than later. My master list is also slightly unbalanced.

One thing I can do about the issue of the number of items in my master list is to adopt an idea from
Kanban boards. In a previous role in an agile team, we kept a backlog of development cards that represented application changes that were next in line to be worked on.

In order to keep my master list lean but still keep a note of stuff for the future, I'm going to keep a separate backlog file that contains actions for projects that I want to do in the future but perhaps don't have the time in the near future. Doing this and reviewing it once a month will also mean that I can just forget about my backlog until I have cleared everything from my master list.

This morning I was curious about the amout of money I was spending every month on subscriptions for products and services on the internet. It turns out that I don’t spend huge amounts of money on products and services. Here’s where my money is going on a monthly basis:

• Instapaper
• App.net
• Dropbox
• Ruby Tapas
• The Changelog
• Github
• Pinboard

All in they come to just under £30 per month. The amount I am paying out each month is less than I thought, which means I have a few slots left for additional products and services. I’m already looking at taking out subscriptions to Treehouse to improve my iOS development skils, Instacast to sync my podcasts between devices and a Railscasts pro subscription.

What apps, services and products are you subscribed to on a monthly basis, and is there anything you are considering taking a subscription out on in the future?

I would love to sit down and teach my sons how to code, but I think it's more important to teach them about applying thinking to problem solving.

Scott Hanselman rounds it up nicely:

We need to teach kids to think and to be excited about thinking.

— Programming's Not For You by Scott Hanselman

... with Nicholas Bate.

Cultural Offering takes it a step further with his advice about connecting:

Go to them. When you are not happy with a business experience, don't tweet your disdain, go to them and explain the problem. Then ask for a resolution. Not happy with your grade on that paper? Skip the snarky Facebook status and go to them.

— Go to them by Cultural Offering

Another thought from episode 95 of the Ruby Rogues podcast had me thinking about just exactly what I do as a programmer. Yes, most of my time is probably spent writing code, but there’s one big aspect of being a programmer that is often over looked. Problem solving.

Most programmers write code that will end up solving a problem. Whether it’s a small web product or a large ERP platform, the code that we write as programmers usually has a single aim. To solve a problem. Solving problems doesn’t start with code though.

First you must understand the problem you are facing. You must be familiar with the domain language of the problem and understand why the problem is occuring. I like to visualise the problem I am facing. Sketching out the problem in a mind map or even as a flow chart for is always a first step to understanding the problem. With a visual aid of the problem you might recognise solutions that you have previously implemented or even gaps in the problem that require further knowledge.

With the problem now understood, you then set about providing possible solutions to the problem. One solution isn’t enough though. It’s highly unlikely that the first solution you think of will always be the best fit for the problem. I always like to try and come up with at least three solutions to a problem if I can. If I am stuck for solutions then it I like to implement the easiest solution to the problem that will work. Okay it might not be the best solution, but it is a solution. In time, a better solution will present itself, but I think it’s best to at least start with some kind of solution.

Problem solving is just one part of a programmer’s day, but it is an important one.

via Pedal Consumption

Episode 95 of the Ruby Rogues podcast got me thinking about my previous roles as a developer and how I interacted with my team.

It’s interesting that of all the roles I have had in the last 10 years, I can only count one of them as being a true eye opener in terms of team interaction. My role in an recent team, although short, was the most positive experience I have had.

At the start of each day the team would gather for a daily stand-up where we would go over yesterday’s progress and do a quick overview of what’s in store for today. There was some chat at the start about the latest designs on Qwertree and football results from the previous night. Just enough of an ice breaker for everyone to get comfortable and then commence the stand-up meeting.

At the end of it, everyone knew what they were doing for the day and what everyone else in the team was doing. There was no negative comments on anyone’s part, and if anyone one member of the team had a problem, the rest of the team tried to provide quick suggestions as solutions.

Positive team interaction didn’t stop there.

During the day, we would frequently pair up with another developer to work on a task until it was complete. During this time a high amount of interaction took place between the different pairs on the team for that day. Sharing ideas for problems, learning from one another's coding styles and of course the odd jibe at your preferred text editor.

Team interaction was always high during this time. It was great to see developers sit down together, regardless of level of experience, and move the development team’s project forward by quickly completely the task they were assigned at the start of the day.

I only worked with this team for a short period of time, but it was the most positive example I have seen of a team enforcing positive team interaction. Those readers who are aware of agile practices will immediately see that the team I am praising is in fact a team that uses agile practices.

The amazing thing is that they aren’t doing anything that isn’t achievable by many other teams who have poor interaction and communication amongst their members. All it takes is a change of attitude.

I'm in the market for a new iPhone case. There are hundreds to choose from. I mean hundreds. There's too many to decide from. Competition is nice in business but as a consumer, sometimes I want less of a choice. Less choice means I can make a decision faster.

Software developers love their text editors. Those developers that invest a significant amount of time in one particular text editor are able to wield it with the proficiency a level 20 warrior. They’ll slice and dice the code with the mininal number of gestures needed. They have all the commands they need memorised right down to the last keystroke combination. Text editors are the primary weapon of software developers and so they need to know how to this tool with great effect if they want to make their day a productive one.

I chose Sublime Text 2 as my main text editor a couple of years ago. I just find it easy to work with. I know the commands that I need, I spent a fair amount of time getting the right plugins and setting them up so that they work well for me and of course I’ve tried hundreds of themes before getting the one that just feels right. So if I’m so happy with my chosen text editor, why the hell do I keep wanting to try another tool?The other tool I am referring to is Vim. It’s a text editor that is used by thousands of people and is over 20 years old. Every year, I ask myself, “Did I give Vim enough of a chance?”

I’ve tried Vim a few times as a replacement for Sublime but every time I try it, I find something that I don’t like and go back to Sublime. Fast forward a few months and I do the same thing again. For the last three years, I think I’ve tried Vim about five times. I’m not talking about a couple of days, I’m talking about a full on month of use. However, at the end of each month I simply switch back to Sublime. Is it a comfort thing? It might be.

Vim is a great text editor but I just don’t feel that comfortable using it.​