Improvement Through Iteration

After reading Jeff Attwood's post "We Are Typists First, Programmers Second" and hearing my co-workers ask me how fast I typed for the umpteenth time, I decided to take one of those typing tests and found out I average around 100 words per minute (wpm). Not bad.

The last time I took a typing test like that was 15 years ago, and I was typing around 50 wpm. Back then, my keyboarding experience was only about 2 years. Before that, I only had keyboard access if I was lucky.

Baseball When I was 23 years old, I was drafted by the Cleveland Indians to play professional baseball. 19 years prior, I had my first at-bat in T-ball and was tagged out after reaching first because I didn't know the rules – you know, the one that says you have to stay on the base.

Besides bragging rights, I do have a point: persistence, practice, and repetition are a few of the key ingredients to successful skill improvement.

There are other ingredients of course, but I don't know anything that refines our skills as much as those three. Genetics and talent play a role, of course, but without repetition and practice we get what's called "rough around the edges". This means your talent is only good if you polish it.

Of course this applies to software skills as well. Coding, designing, managing – they all require repetition to get better. Or put another, probably more relative way, they all require iteration to get better.

Read more »

Is the Economy Hurting the Software Industry?

Over the last few weeks I've talked with several software engineer/business types about the economy and whether or not the software industry is feeling any effects from it. The consensus seems to be that it's not (yet) but my small sample size may be skewed regionally to the Central Florida area.

For the most part and at least in this area, jobs in the software industry are plentiful, companies have plans to hire more, and contracts are not drying up. But when I see articles like this, I start to wonder if the software industry really is doing okay.

At the same time, there are some noticeable changes due to the economy – much less shopping in stores, much less dining in restaurants, and – being in Central Florida – much less tourism. So something is going on out there, but perhaps the software industry isn't feeling it yet. Maybe? It's too difficult to tell with my small sample size.

So, any readers willing to help expand my little survey and let me know where you're located and what you're seeing in regards to the economy and software? Are companies still hiring? Is there still a demand in your area for software? Does anyone anticipate a downturn or is it all good times?

Notes from SD Best Practices Joel Spolsky Keynote

My notes from the SD Best Practices Conference aren't written in prose or anything, but they're still handy so I thought I'd post my notes taken during the keynote given by Joel Spolsky entitled 'Building Better Software". Enjoy:

There’s a big difference between #1 and #2. Compare David Beckham vs. Landon Donovan; Hey Jude (#1 hit 1968) vs. Love is Blue (#2 hit 1968); iPod vs. Zune. Oftentimes the #2 is functionally superior, but for some reason #1 still wins. According to Spolsky, it comes down to three elements:

 

  1. They make people happy.
  2. They obsess over aesthetics.
  3. They observe the culture code.

On “make people happy”, Joel talked about how helplessness is actually a form of depression (“learned helplessness”). Humans by nature want what’s called agency – a feeling that we can make things happen. So when things don’t happen, we get frustrated, depressed, and give up. There have actually been studies on this.

 

Read more »

SD Best Practices Day Four

There was a Day Four that I attended at the SD Best Practices Conference, even though I'm posting this a week later. As mentioned in the previous post, I wasn't entirely sure which sessions I would be attending that day, but these are the ones that made the cut:

Read more »

SD Best Practices Day Three

Day 3 was about Financial Engineering, Quantitative Testing, and Agile Metrics. And as I get ready for Day 4 I realize that burnout is setting in. If you've been to the GDC, then you know it's a bad idea to go to a class every single session – by the end of the week you'll be burned out. So usually at the GDC you take breaks and go to the expo.

The only problem with the SD Best Practices show is that the expo is very small. There's maybe 10 vendors? I suppose it makes some sense – SD Best Practices seems to be about the equivalent of the gaming industry's Austin Game Conference relative to GDC (the software industry has their big SD West conference). But the problem is that it's easy to get burned out if you go to every single class session, which I have tried to do – and failed due to burnout.

In any case, these were the classes from Day 3:

Read more »

SD Best Practices Day Two

Day 2 of the SD Best Practices conference kicked off with the 1.5 hour sessions, which make for a more engaging day in my opinion than an all-day tutorial session. My Day 2 was focused more on the design and process side, as I went to three agile-related classes and one user interface design related class.

With Agile, I have researched and studied it extensively, including implementing pieces of it at the workplace, so with these classes I'm looking for the little nuggets that help further refine my understanding. For the UI design, I recognize that while I've come up with my own approaches to building better interfaces, hearing an expert speak on the topic will only help.

These are the classes I attended:

Read more »

SD Best Practices Day One

Today was Tutorial day at the SD Best Practices conference. I attended an all-day session held by Dan Saks and Stephen Dewhurst called "Sooner Rather than Later: Static Coding Techniques for C++".

The major topics covered involved how to use templates, explicit partialization, and partial specialization to make C++ code more secure so that errors are found at compile-time instead of run-time. A lot of the discussion revolved around ideas discussed in the book Modern C++ Design by Andrei Alexandrescu and focuses on more examples of how to use generic programming to solve problems and tighten code.

In the near future I may post a few things I learned or had "aha!" moments about. As for now, I'm tired and need to get ready for tomorrow.

Civ IV: Colonization

Recently I picked up a copy of Civilization IV: Colonization, a remake of the classic 1994 Sid Meier game of exploration, conquest, and revolution that I spent many, many hours playing as a teenager. It's part of the reason for my lack of posts here lately.

I'm not one to give game reviews, especially since my tastes tend to differ from many other people, but this is a great game. I've been surprised at the depth, as it's near impossible to just skirt by to win, even at a lower difficulty. This adds another level to the game that wasn't required in the original: resources must be managed, not just from production within your cities but also through trade routes between your cities.

Back in the original, I remember I could mostly ignore the wagon trains, which handle resource transport between cities. I could win by focusing on city production alone, which led me to build massive armies and destroy everything, including the Redcoats (nothing against the British).

But this game is different, and as a result of repeating my old strategy my first play ended in crushing defeat. I like that. It's challenging, it's different. It's not just a remake - it's an entirely new, well-designed strategy game.

If you haven't played it yet and have any interest in good strategy games, then do yourself a favor and get a copy. It's relatively inexpensive ($29.99 USD) and doesn't even require that you own Civilization IV.

Everything’s a System

I got a laugh out of bbraithwaite's post at Applied Game Design on the parallels between a Lead Game Designer and a college's Department Chair:

One ships games, the other ships students and a designs a sandbox game (termed “a curriculum”) in which players (termed “students”) can build the right collection of assets and resources (termed “courses” and “a portfolio”) to take them toward their goals of entering the game industry.

The funny part to me is that you could say the same thing for a Lead Software Engineer. Or an Artist. Or a Director. Or a Construction Worker. Or a CEO. It's all the same.

Everything in our human world is a system that follows one very basic pattern of all systems: input-process-output.

Read more »

Life, project, cycle

I don’t know the origins of the phrase “project lifecycle”, but whoever decided to tie the two words together must have been very insightful. Yes, I’m about to go zen.


Recently a lightbulb went off in my head that the project lifecycle closely mirrors that of life in general. I don’t necessarily mean that in the literal sense, especially since some projects never seem to die, but there is a certain causality in a project that is reflective of life in general.


What do I mean? Well, the decisions we make the first week of a project can have an impact on us during the last week, just as in life the decisions we make as a child can have an impact on us forty years later.


For example, in a project, no planning typically leads to some level of chaos and potentially a lot of crunch. In life, no education as a child typically leads to a worse job, worse social status, and overall more difficult life.


In a project, poor communication can lead to ineffecient execution, infighting, and a lack of direction. In life, poor communication can lead to stunted personal growth, isolation, and perhaps divorce.


And so, the pattern is similar.


Everything we do and every choice we make drives us down a path, and it’s either driving us where we want to go or it’s driving us away. This holds true for any journey, whether it’s life, a project, or a roadtrip. Every decision counts.