On My Bookshelf, August 2012

With the new semester rapidly approaching, I have moved back in to my apartment. During the move-in I reorganized my bookshelf, and I thought I’d share what it contains at the start of the Fall 2012 semester.

The shelf features a decent selection (mostly technical reference books, though). Any book that I recommend or that I am currently reading will be underlined with a link for your further investigation.

Read More

Tip #1 — Care About Your Craft

Having team members read a few technical books a year is a good idea in my opinion: it makes for a more knowledgeable, versatile group of developers. At my internship this summer we are reading and having weekly discussions on a book called The Pragmatic Programmer, and I’ve already picked up a few good tips from it.

One tip that struck a cord in me is, “Care About Your Craft — Why spend your life developing software unless you care about doing it well?” This tip, in my mind, shadows the rest of them. If you don’t truly care about the product you’re crafting then you will not have the determination to apply the others.

Not only does this simple tip apply to programming and developing the best piece of software possible, but it also applies to life’s ventures. Why ever half ass something? If you find that something in your life is not being given 100% of your effort then it is most likely not worth 100% of your effort.

Following this way of thinking, one could then cut out the activities that are not getting the full effort. The remaining effort could then be allocated to life’s other activities.

I am aware that not everyone thinks and operates the same way as this and that this tip may have multiple meanings to multiple people. The way I presented it was very “Type A” heavy, but that’s just how I think.

As this blog continues to develop, I plan on posting more of these software tips and how they apply to my life as a developer and a student.

Code from the Past

We all try to write the best, most elegant, most functional code we can. It’s our life: we get paid to write good code, plain and simple. We like to feel that the project that we’ve done our best work on is our current project at hand. That being said, what happens when you read code from that project after a few months or even a year?

Embarrassment. Or at least that is how I feel. “How did this code ever work?” or “Why did I do something this way?”

My friend who has been my roommate for two years at Iowa State is doing an internship this summer; his boss said that whenever an interviewer asks, “Tell me a time where you’ve failed.” he replies, “Every time I look at the code I wrote 2+ years before”.

I can directly relate to this. Looking back at old code, I feel like the code is a typed out failure. After discussing my mindset on this topic with a coworker of mine, my mindset has started to shift.

This new mindset holds that the code from a past project was right at the time so the product was deployed. The code was at least “good enough”; therefore it was not a failure. Another thing that I have worked on believing is that without writing those (now) “bad” lines of code, I wouldn’t have learned how to write the (currently) “good” lines of code.

A good programmer is constantly learning. This brings about changes in programming styles, techniques, design, and the list goes on.

In conclusion, this is how I am going to try to see it when looking at code of the past from now on: I desire to be a good programmer, one who is constantly learning. Because of the constant learning, it is unfair to judge myself on something that was written many lessons learned ago. The only thing I can do is reflect on what’s been built and apply the lessons that I learned in the projects of today and tomorrow.