Working to be a professional in the new year

Published on January 01, 2010 by Toran Billups

As we start the new year I thought it might be valuable to set some goals like many of us do. And if I get these goals in writing, I will feel truly committed.

Now if I step back and look at this list it all sounds so interesting, but how will I find the time to actually do these things? Usually when you need time for something new you have to cut something else out. Like others I respect, that thing will be watching TV. I honestly have zero interest in much that is on these days anyway so I hope to avoid the time suck.

Read a few of the great books about software construction

The first bullet point is one that I have already started on. I received Clean Code by Robert C. Martin for Christmas this year and it's by far the most refreshing read I have come across to date. It speaks to the core of anyone interested in the craft of software development.

Another great book I've started reading this year is C# in depth by the great Jon Skeet. This was in part because I started writing c# professionally this year and wanted to learn about the language. What I have found is that the language itself has really grown since the initial release and as I subscribed to the MEAP program I will be learning about c# 4.0 before the next edition is published.

But in addition to these new books I also plan to go back and read both the pragmatic programmer and Code Complete again, but this time with a new perspective. When I first read both of these books I hadn't yet heard of TDD or any of the other concepts that I spent the last 2 years learning. I also found these to be some of the best books at the time and it never hurts to go back and read a great book for a second time.

Work to be a true professional in the software industry

If you read this and thought 'you haven't been a professional up to this point?'. I would actually agree with that statement as much as it kills me inside. The truth is that I didn't actually know what it meant to be a true professional until 6 months ago. It was then I learned that we write software test first and don't apologize for it.

I found it was time to start acting like someone who is an expert in this subject and take responsibility. When the business asks for something and it's flawed we should work with them to correct or clarify the specification. We are as much a part of the success as anyone else working for the company. The days when a software developer was a simple cog in the machine are over.

With this responsibility comes great power so when someone asks us to knock something out quick n' dirty, we say no. We are the experts in maintainable software and know more about how to achieve this than anyone else. So when another developer or manager tells you 'we don't have time to write a test for feature x', say 'actually, we don't have time not to test'.

This doesn't give you the ability to be the jerk on your team, but rather the advocate to help others understand that making a mess will eventually hurt them and at that point it will be too late. And as I found out this past year, if you can't be a professional at your current job then maybe it's time to change jobs.

Build a real software project on another platform

I always talk about this but it's time I get serious about it. My current employer doesn't limit anyone to a particular platform and I find this refreshing because it helps us grow and learn from other approaches.

I did a small ruby project in 2007 but with the latest release of rails, I wanted to rewrite this with the hopes that I will learn how to write test first with rspec. But I also wanted to write some code in a dynamic language again!

Blog more about how I've grown as a software developer

One of the goals I had last year was to start blogging. I'm glad I did, but looking back I focused on writing about things closer to a tutorial of sorts. This year I want to change that focus and talk more about myself. Specifically how I got started and what I have learned along the way.

I think there is some real value here because it allows me to reflect on each decision I made along the journey. I can't tell you how lucky I am to be here, but it was driven by my passion for software and being a true professional in this industry. I hope to share my story and maybe laugh a little about some of the crazy stuff I did just a few years ago.

Continue learning how to write tests that assert behavior

In my career I always found something new to learn and within a few months I was implementing it like a pro (or so I thought). This was the case until 2007 when I decided to play around with these 'unit tests' and 'test driven development'. I have since tried to write testable software, understand why test first is useful, grok the concept of mock and stub, understand how to test at a higher level with context specification, etc.

Yet after 2+ years I still don't feel that I am writing good tests. I wish I could point to one thing that always trips me up, but I feel like each time I write a test in a real production environment I take one step closer to really getting this BDD/TDD stuff right. Until then I will keep working to write great tests that actually provide value to the software I'm working on.

Speak at a few local events and evangelize good software practices

I gave a few presentations this past year on NHibernate, jQuery and Software Maintainability. Most of these were internal to my employer at the time, but this year I want to get out and present at a local user group and maybe the next Iowa code camp. I find that each time I get up in front of an audience and speak about something it helps me grow as a presenter. I also learn a great deal about the topic I'm presenting on.

So the more I can speak the easier it will get and the more I will learn myself along the way. These are both great things so I will try my best to get out and speak about something interesting this year.

Learn more about lean / agile / scrum / kanban

Until a month ago I never worked in a true agile shop, yet I always felt that BDUF focused on the things that added no value to a software project. So this year I will be learning firsthand how these methodologies produce better software.

Get real world experience working with a nasty codebase

Almost 100% of my career had me working on green field software projects. Although this was fun at times, I never felt that I had done any 'actual' work because I didn't read code that I myself didn't write. But with my change in jobs this year I now have the opportunity to work with a large code base that I had nothing to do with. I think this will provide the chance to see what bad code really looks like and how to refactor it and get it under test.

We often spend more time reading code than writing it so this was another great way to help me grow as a developer over time. Without such experiences developers often feel they know it all (lord knows I did).

Work with brilliant mentors to really grow as a software craftsman

For some reason each time I take a new job I'm instantly one of the best developers on staff. Yet I know almost nothing about writing great software. This time around that wasn't the case. But that is cool with me because I have had to learn everything through trial and error on my own in the past. But now that I work with the people that blow my mind on a daily basis I will be sure to grow at a rapid pace.

In addition to learning how great software is constructed I also plan to learn a great deal about software craftsmanship. Everyone I work with respects a set of basic principles that help to produce great software. And if I ever start to act unprofessional I know they will call me on it. In my opinion, this is one of the signs that you work with a great software team.

Learn a few new technologies for fun

I'm working in software for one reason only - it's my hobby. I love this stuff. With that said I do plan to learn a few specific technologies for fun this year including: Fluent NHibernate, StructureMap, f# and anything new that can be found in c# 4.

Understand the total cost of ownership for a line of code

Although I think I understand this, I don't. I plan to spend the next year thinking about how the cost of software goes up with each line written. I also plan to learn how one can keep the software maintainable while still providing value for the business. These concerns are ongoing because without an emphasis on them I will be worthless to any software team.

Directly impact the careers of other software developers who aren't thinking about maintainability

I know a few young developers who have been writing software for a few years now but don't yet understand the idea of professionalism. I plan to initiate the conversation and get them involved with the community. I look to the mentors I have and how they reached out to help me over the last few years. I only want to return the favor.

With that said it looks like this will be a busy year ... wish me luck!