Al Hoang

Tom has a great summary on why.

One challenge for the cowboy sys admin is on how to keep oneself engaged while making their job basically… a walk in the park.

One thing I have found helpful in creating lists is to be dogmatic about writing docs as you are doing something somewhere, anywhere and collect all of this later. (You are writing documentation as you do your job, aren’t you?)

Read More

After reading Game Developers and Porn Stars I started recollecting an earlier time in my life. At that point in time I was considering a life as a game developer. I had heard the rumors that life as a game developer was a meat grinder and had really long hours. I spent time reflecting on the choice I had. I really like video games and think they a great form of entertainment that has had a large influence on my life. But I still feel, at its core, video games are just entertainment. Sometimes, they can educate along with delight but that is all.

Ultimately, I took a different path than becoming a game developer. After reading Kill Ten Rat’s blog post on Game developers I am glad about my choices. I have pretty much erased almost any regrets on not taking that path in life. Although I AM sad to read such a story in 2009 because the decisions I made were over a decade ago and it is disappointing to hear the state of the game industry for a game programmer as a whole seems so soul crushing.

Seems someone else ran into issues while trying to deploy god.

While, I don’t think god sucks I definitely don’t endorse it. At this point I would only use it under the following conditions:

• Need for a process monitor tool with more dynamic configuration setups. This is where god really shines against monit’s simpler understanding of what process management is about.
• The host that needs monitoring can easily spare at least 16MB for a monitoring process. See below on why.
• I really want an all Ruby solution for all the tools in a system

In general, I am into the whole ‘It is Open Source. If you’re having issues, fix it’ deal so I am not nearly as angry sounding as Brad is about god. However, after having issues with god, I switched to monit for simple process monitoring and restarting. I had far less troubles and got on with other tasks that I considered more important than perfection in a process monitoring system.

For those that are curious here are the issues that I ran into with god:

• Daemonized Ruby took at least 8MB of RAM for the monitoring process. With RAM the way it is, this is not as big a deal. However, if you are trying to get by on a 128MB VPS host every kilobyte counts.
• God itself had issues just randomly dying after some time. Tom promptly fixed it after it was reported and that was great. However, it was a little disappointing that a monitoring process just died.
• Sparse documentation compared to monit’s. Then again this is typical from many Ruby projects and luckily Ruby code is readable enough
• Digging up known issues for god required noodling through groups, forums, and blog posts. Would have been nice to just have a friggin’ FAQ like other sys admin-targeted software I have seen.

I also DO agree as has been said in the comments on Brad’s post that it is the responsibility of the deployer of software to handle the issues with whatever they deploy and just deal with it. The reason I say this is because I fell for the hyped up description of god in the beginning and ultimately paid the price when it sucked up my time. I dealt with it but definitely am less impressed with overhyped marketing descriptions of software these days. Personally, I am not a fan of that type of marketing for software since it seems a little disingenuous to me. But that is just me.

I just read a blog post by Blaine Buxton describing the phenomenon of Forced Pairing. In a nutshell, pair programming has to take into consideration the human factor when programming. Some people need their own space to code well.

On reflection, this makes sense. When I have pair programmed, I have usually been supportive of the idea and want to share my thoughts and ideas with the person that I pair with. However, communication of thoughts and motives is at best an imprecise art. From what I have seen, pair programming can have issues at the ground level under the following circumstances:

• If one person in a pair is not willing to communicate with the other person
• If one person cannot express intentions well to the other person
• One person is moving too quickly and will not slow down enough for the other person to keep up (This is not fun at all)

I cannot imagine an environment where pair programming was taken so seriously that is has been codified as a law but if they do exist then Forced Pair Programming is definitely something to watch out for. However, I do believe that pair programming is an effective strategy for getting multiple developers up to speed on any codebase and avoids the Only One Developer Understands this Code syndrome.