Sysadmins vs. programmers

In a Slashdot thread on the topic of the Programmer’s Day, I came across this insightful comment, with which, having been both a sysadmin and a programmer, I have to somewhat agree. No disrespect to any programmers intended, but sysadmins have it tougher.  I wouldn’t go as far as to claim that Programmer’s Day is not deserved – we all work hard, but I agree that Sysadmin’s Day is deserved more.

Having been both a sysadmin and programmer, I have to honestly say that while sysadmin day is deserved, programming day isn’t. There’s just simply much more to sysadmins that are underappreciated when compared to programmers:

  • Sysadmins setup routine systems that are built by programmers (who usually get the credit).
  • Sysadmins only get (negative) attention when something goes awry.
  • There’s usually no mention of sysadmins anywhere.
  • Unless you are very technical, you probably don’t even know that sysadmins exist!

In contrast, programmers have it nice in the sense that when they do a good job, they are seen as the heroes who created the system. People go to programmers for feature requests in addition to bug reports. Their names are usually listed in an about dialog or readme file somewhere. Also, unless you are completely technically illiterate, you know that someone has to create the software.

The final bit: the infrastructure will crash and burn without sysadmins, but without programmers, it’ll just cease to advance.

Having a Programmer Day in addition to Sysadmin Day is like having an Executive Day in addition to Labor Day: unnecessary, unjustified. In both cases, the former already has the glory on a daily basis that the latter is hugely lacking.

 

Happy Programmer Day!

Today is the 256th day of the year, which means it’s Programmer Day once again.  I’d like to take this opportunity to congratulate all my colleagues around the world and wish them all quieter rooms, better tools, larger salaries, faster computers, and fewer bugs.  Let the source be with you! If you write code and 256 has a special meaning to you, I tip my hat to you and hope you’ll enjoy this little comic strip from Geek And Poke.

For those of you who are not programmers, but curious about a special meaning of 256, the explanation is really simple.  Bit a smallest unit of information, which can only take values of 0 or 1 in binary notation.  Bits are organized into bytes.  There are 8 bits in a byte.  Which means there are 2 to the power of 8 combinations of ones and zeros in a byte.  2 to the power of 8 is 256.  There are a few more meanings to the number, if you are still interested.

What people don’t get about my job : Programmer

I came across this rather lengthy, but definitely worth a read, article about different professions and misconceptions people have about them.  Some of the stories are surprising, some – less so.  Given that there is not one from a computer programmer, I decided to share here my view of it.

It’s too tough to choose a single misconception, so I’m going to limit myself to the top three.  These three are the ones I have to deal with most often.  They vary from person to person, of course.  But I’ve heard the same from a few of my colleagues.  So here it comes.

Continue reading What people don’t get about my job : Programmer

Why you should teach yourself WordPress taxonomies

Alex King has a blog post describing the major differences between using custom fields and taxonomies in WordPress.  If you are familiar with the WordPress database, and if you think about it for a couple of minutes, you’ll probably realize why taxonomies are a better choice than custom fields for those situations where you can use both.

The reason to favor a custom taxonomy in these situations has to do with the WordPress database structure. Queries by taxonomy are well optimized as this is a primary front-end presentation feature in WordPress core. Conversely, querying by custom field key and value is slow. The value column in the custom field table is not indexed – you are basically doing a search through data that is not intended for that purpose.

The problem is that too many people, even those who are very well familiar with WordPress database structure, never really think about it.  And since custom fields are an older way of solving problems, many go for them without proper consideration.

One more thing

Last year Matt Mullenweg wrote this post and I somehow missed it.

There is a dark time in WordPress development history, a lost year. Version 2.0 was released on December 31st, 2005, and version 2.1 came out on January 22nd, 2007. Now just from the dates, you might imagine that perhaps we had some sort of rift in the open source community, that all the volunteers left or that perhaps WordPress just slowed down. In fact it was just the opposite, 2006 was a breakthrough year for WP in many ways: WP was downloaded 1.5 million times that year, and we were starting to get some high-profile blogs switching over. The growing prominence had attracted scores of new developers to the project and we were committing new functionality and fixes faster than we ever had before.

What killed us was “one more thing.” We could have easily done three major releases that year if we had drawn a line in the sand, said “finished,” and shipped the darn thing. The problem is that the longer it’s been since your last release the more pressure and anticipation there is, so you’re more likely to try to slip in just one more thing or a fix that will make a feature really shine. For some projects, this literally goes on forever.