Strive to Work for a Bad Company

It’s approximately four O’clock in the morning in Cleveland, Ohio. My soul rises from my sleeping body and nudges me to wake up. Like Terminator, my body’s still at rest, but my eyelids lift abruptly. Analogous to clock-work, the program that I call my daily routine has just been activated.

I reach for my phone and begin my morning routine of surfing YouTube for another interesting topic for my mind to absorb. I declared a couple weeks ago that I would pick up F# as my next programming language. So I look for F# related topics. However, I soon realized that I’ve already consumed the majority of the videos pertaining to this language. I then scroll down the list of search results and immediately recognize a familiar face. But I noticed that this face is not even related to F#. Instead it’s one of my favorite thought leaders. It’s David Heinemeier Hansson (aka: DHH). The topic of the video he’s featured on is titled “Unlearn your MBA”.

I listened to the video and thoroughly enjoyed his presentation. But one thing really stuck out in the video that I found was very peculiar. At one point in the video, he mentioned that every college graduate that’s eager to join the workforce should work at a really bad company. His argument was that there’s so much to learn from people that are horrible at running a business or in my case, building software, that when we are ready to go full throttle into our career, we can do so off of the lessons learned from people that are bad at their jobs.

That video that I watched and that message that he relayed really made me think about a recent experience that I had in Miami. I was so disappointed with a shop that I was working with that I could no longer deliver value to their business based on my standards of professionalism. I just could not understand why senior developers at that shop were so adamant on building software without any type of controls in place to notify them of quality concerns.

Their last project was a complete failure. It was essentially a death march where the developers had to work mandatory weekends to drive down the bug count. Each time they would fix one bug, two more bugs would surface. Of course, this team downright refused to leverage unit tests as a quality control to assist them with their bug fixes. Thus, as you might’ve guessed, they programmed blindfolded. In addition, the team lead did not feel the need to include QA at the beginning of the project. In fact, QA didn’t touch the product until the development team declared software construction completed. And as you’ve might have guessed, the software reeked with bugs. Of course, the majority of these bugs could have been identified and exterminated early within the development phase if QA would’ve just ran in parallel with code construction. However, that idea was downright crazy-talk. The end result was this. The project failed and it failed miserably. But saying the project failed miserably is an understatement. This project was nothing short of an atrocity that destroyed trust and killed morale. The project lead quit and was soon followed by several more resignations from other developers on the project. Meanwhile, I observed all of this my first month on assignment and was deeply concerned about what I was getting myself into.

I now look at my software development skills as one of my businesses. Therefore, I must protect the reputation of my business at all cost. When I’m building software for a client, it must be in the act of continuous competence without conveying any negligence. And yet, that shop that I attempted to help wanted me to follow their framework which inevitably led to pain, suffering, and mass abandonment.

David Heinemeier Hansson was right. If it were not for that specific experience of working with poor developers, I probably would not have wrote the thought provoking article “Are you a Professional Debuggerer”. In addition, I probably would not have got on DotNetRocks.com or DeveloperOnFire.com. As a result, perhaps we should all target a really bad company to work for so that we can really experience the ramifications of bad business and development practices while we are still at the beginning of our career. Once we can actually experience this pain firsthand, then I think we can finally appreciate businesses that really do strive for continuous improvement and thus continue to push our industry in a forward direction versus in endless circles. In doing that, perhaps then we can seek comfort in recognizing that for every end is a new beginning.

Advertisements
1 comment
  1. Instead of suffering through a bad company, I just read Dilbert.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: