Bikes and Code

I read quite a bit. I read fiction, fantasy and sci-fi mostly, but I am not opposed to a good mind numbing blockbuster either. I read non-fiction, recently the works of Pierre Berton have caught my interest, though I tend to read a fair bit of political philosophy books as well. I read computer books, my desk and surrounding area is littered things I have read and occasionally need to reference or just read a chapter of to refresh my memory. Finally, like most regular Internet users, I read blogs.

It was directly due to the words of a couple of well respected bloggers that I started this one. There are multiple reasons. By writing, you exercise the communication part of the brain, which is always good. By putting up a public blog, it becomes easier to control your own Internet presence. As long as your writing is even passable, it is good marketing for yourself. These were just a few of the points that were made. I bought into it and am now going on a couple of months of roughly weekly posts. I believe I can keep this up rather easily.

So, one mission accomplished.

On more than one occasion, one of these people who are well respected in the software development field will mention something about a compiler. Specifically, that every serious programmer should write one at some point in time. This makes sense as a compiler tends to be one of those bits of software that does a good job of covering pretty much everything that a programmer needs to do somewhat regularly. Lots of string manipulation, lots of recursion, lots of knowledge about how a computer actually works, memory management, the list goes on.

I have not yet written a compiler. It is something that I have wanted to do more than once, but never actually sat down and started working on it. I’ve seen enough mentions in passing recently that I feel it is time for me to complete this particular rite of passage and actually write a compiler. I am capable of it, but I needed the push down the right path to do it.

So it is not going to be a huge project and I’m not going to sink huge amounts of time into it, but I do have goals for it that should be completed by the end of 2009. I need to define my own language, it should have ifs and whiles, it should evaluate mathmatical expressions correctly. I think I will compile to JVM compatible byte code, though I have not decided on that yet either. That would theoretically allow me to use Java libraries as well, which is appealing. It’s not going to be object oriented, mainly as this is a learning experience and I don’t want to bite off more than I can chew so to speak.

I’m leaning towards Ruby for the project, but am stronger with Java which will make some things significantly easier. I will likely make the final decision once I’ve read some of the Dragon book and know more about what I am getting into. My intention is to write it all at this point. I don’t think I will use a parser generator or anything like that, simply as the point of this is to learn how to write a parser/lexer/etc.

So that’s the plan for 2009, dedicate a couple of hours a week to this project and hopefully be able to run some of my own code in my own language by the end of the year. Who knows if that’s reasonable, but it should be… illuminating.

As I race cyclocross, my riding season ends up being quite long. My last race of the year is generally in late November or early December depending on the exact schedule. I like to take some time off at the end of the season, I find it’s great mentally and helps with getting the focus back for the next year of riding. The downside of this is that while lots of riders are starting up with the base training for the next year, I am happily sitting on my hiney enjoying winter treats.

But by the time January rolls around, I am itching to get back on the bike, which is a great situation to be in. In the wintertime in Canada, this means a large number of hours indoors on the trainer which is far from the most exciting way to get into shape. Fortunately, it is offset somewhat by the better part of a month of fairly sedentary lifestyle so I can approach it with some enthusiasm. So January is my month to ramp up some volume and get some hours in, followed by starting to ride a bit harder in February and March.

I’ve got a few goals and things that I want to do this year. I want to do more road racing this year than I did last year. An injury took me out of commission for a month or so in June which kind of did a number on my 2008 road season. Fortunately, it appears I have tons of choice for grassroots level racing in Vancouver. I’ll start the season off by doing a couple of the Team Escape Velocity Spring Series races. Later in the year, Escape Velocity also holds a series of Tuesday night races, which sounds awesome. I haven’t yet found out about any sort of regular time trial series, but I would expect that there is one somewhere in Vancouver.

I will also be doing a couple of endurance mountain bike races this year. I intend on racing the BC Bike Race in 2010, which means I have to get back into the mountain biking somewhat seriously. So far, I’m likely going to be riding the Salty Dog, but beyond that I have not made too many plans.

Cyclocross is a long ways away, but there is a series in Vancouver and thus I will be racing it.

Of course, this is all theoretical at this point. All I really know is that I intend to continue to get faster and hopefully actually be competitive within the next, oh, decade.

I’m back. Took a bit of a break over the Christmas season and enjoyed not working on software, programming and business for a few days. I did have a few interviews, which is always stressful, so I tried a bit harder to actually enjoy the downtime that I did have.

During one of the interviews a comment was made in passing about programmers not wanting to talk to clients. This is a popular topic for developers to joke about, but I had always treated that as a joke. When it came down to the business of doing business, well, talking to your clients is just to be expected. Ultimately, they are the reason you have a job, so there is something very serious to be said for treating your clients with respect.

This particular ramble is going to go down a couple of paths, I’m going for breadth more than depth here.

Generally a software developer is writing code for one of two different reasons. You are writing software for a new product that may or may not have clients yet, you may be trying to carve a niche into an existing market or creating a new one. The second and by far the most common reason is that you are contracted to write software that accomplishes some task for another person/organization/demographic/etc.

So what does that make our job as developers? Our clients or employers have problems that they have decided for whatever reason are best solved by computers. We are to analyze that problem and develop a solution. Hopefully that solution makes our clients more money or saves them money by making existing processes more efficient. If the post-mortem shows that the cost/benefit ratio is less than 1, then we have failed. It really is that simple.

Solving a client’s problem is our job. One of the aspects that makes software development so much fun is that many times our client does not know exactly what they want. This may be a source of entertainment for us, but is a very important thing to keep in mind. The world of programming is one of absolutes, the computer does exactly what we tell it to in a nice and ordered fashion. (Defects being the times when we tell the computer to do the wrong thing) The real world is much less black and white. What this means is that we have to listen to our clients and understand what they are trying to accomplish. If the request is vague, we have to figure this out by asking the proper questions to build a better picture of their business.

This is challenging.

Worse, they may know exactly what they want, but are wrong. I have personally been asked to implement things with very little more than a vague bit of hand waving and comments to the effect of “We think having something that does x would be nice.” In this particular case, x was fairly obviously, to a developer of the system who had detailed usage statistics, not what our users needed. They actually needed y. Through some discussion with our clients, our team was able to make the case that x would only help less than 1% of our users, and a particular subset of users who did not and would not spend any money. That probably helped our case somewhat. We ended up implementing a modified y and our customer service requests for a certain class of problem dropped significantly.

What was interesting to me from a personal standpoint was that the same people who were arguing to just implement x were the same ones who did not want to talk to the client. Now, I should clarify, I don’t mean, the grudging, “Oh no, small talk and meetings with people I don’t know”, the typical introvert response where you know that you will come out of the meeting drained, though hopefully with the problem solved. In this case I mean attempting to make the case that it was not our job to talk to the client to figure out what they needed.

This did not sit well with me. There is a reason that the principles of the Agile Manifesto have several points which specifically reference and talk about dealing with the customer. These points all touch on dealing with the customer with respect and understanding as they are the experts in their own business. We are experts in software development.

As software developers, our job is to learn from our clients to build systems that improve their business. To do that, we will always need to interact with our clients to determine their needs and meet them.