Monday, April 28, 2008

Ruby, don't take your love to town.

I'm on the road to learning the ruby language. I've been reading several different resources on the basics, and I'm starting to get a grasp on how the syntax is working. There are a lot of things that make this a bit difficult for me to learn, but I like the way it looks. Once I have a good grasp on it, I think I'll really like it a lot, I just have to keep looking for places where Ruby is the answer, instead of making Ruby the answer even when it's not.

I've been readying Why's (Poignant) Guide to Ruby, which could be called Why's acid trip to understanding ruby. It's the best metaphors and explanations about the syntax that I've found, but it's also got crazy bizarre things in there that I think, what was he smoking?

I've also started looking at Programming Ruby, which is known as the pickaxe book. I've been looking at this one, because it's installed with the one-click installer for Ruby, so it's already on my computer, but you can also read it online.

There's also a neat interactive ruby tutorial that makes you type the code and read about why at the same time, there is some of the same bizarre things in this as the Poignant guide above because it is also written by Why the Lucky stiff.

So far I'm just learning to do the basics, and I haven't created anything new or solved any fun problems, but I'm enjoying learning the new language.

Monday, April 14, 2008

It's good to have someone you can trust

Sometimes as developers we lose sight of what is right in front of us. A quick change to a piece of code and WHAM, something breaks.

It's times like this that it's good to have someone we trust. We can ask that person to look at our change and help us find the fix, which is often just something extremely stupid that we did.

Too often when we've done something stupid, we look right at the mistake and see it for what it was supposed to do, not what it is doing. A 2nd person can usually find this bug within a few seconds.

This is one of the biggest benefits for paired programming. In those cases there is a lot less chasing your own tail around, because the feedback is immediate. That's why paired programming teams have higher quality and stay focused better.

Thursday, April 03, 2008

The practice of boring

Software Development is boring. I'm a software engineer, Software development is my tool. Software development is the practice of boring.

The practice of boring is doing the same things over and over and over. That's what software development is. I am constantly connecting to a data store, pulling back data, displaying it in an application. Something can then happen to the data and it will be saved back to the database. I have just described practically every piece of software ever. Essentially Blogger is the same thing.

Blogs are saved somewhere, they are then displayed for editing by the author or viewing by anyone else.

Amazon is that way. A list of things for sale, their reviews, their price are all saved somewhere and displayed when you log in. Even your preferences based on a history of your purchases from Amazon are stored and pulled to display suggestions.

Online newspapers display their stories into their web page layout.

Software developers write the software to get data and display it, sometimes with editing. Software development is the practice of boring.

It's a good thing I'm not a software developer. I would go completely bonkers with a redundant mundane job like that. I'm a problem solver. My job is not to just write software, I need to be able to understand a specific problem, decide if there is an existing solution that can be re-used or if a new one has to be developed. I need to understand what needs to be tracked to make the project a success and to make the work done on it legal. I need to understand laws and how they relate to the potential solution I develop. I need to stay aware of different development methodologies because one of the new ones may be a faster way to provide my solution.

I need to be great at the practice of boring, in order to really focus my ability and skills into problem solving. The better I am at the boring task of writing software, the more prepared I am to write the software needed to solve that next problem. I embrace the repetitive task of getting data from somewhere and displaying it, because all of the in-between steps where the process and business rules lie are what makes each application unique.

There is a lot of tools, tutorials, books, and training available to improve your software development skills, the only way to get better at solving problems is to solve more of them. Experience is the key. Be the best developer you can be, learn to code the highest quality code the fastest, in order to get on to that next problem. Keep your job interesting, with the practice of boring.