Comments (0)

By bkjones, November 1, 2011 11:13 pm

Today is November 1st, and there’s an event that takes place every November called National Novel Writing Month (NaNoWriMo). I don’t believe I have the ability to really write a novel, and have no reason to think anyone would read it if I did. But I would like to make an attempt to write a blog post every day this month, and this month’s post is about The Happy Idiot. Hope you enjoy it and leave comments.

Who is the happy idiot? It’s the person in class who shrugs off fears of looking dopy and raises their hand. It’s the person who, in an architecture meeting, isn’t afraid to be wrong in asserting that a new bottleneck is quickly emerging in the design. It’s the person who gives presentations on topics they’re really only 75% comfortable with, and announces as much to the audience, inviting corrections and more input. It’s the person who invites feedback and asks questions that seem trivial, even if it exposes their ignorance.

We need more happy idiots.

I wholeheartedly accept this role, even though there are circumstances where it might be easier to keep my mouth shut and keep up appearances or it might seem beneficial to not put a dent in some perceived reputation or something like that. The problem I have with doing that is that appearances are, in my experience, largely bullshit. Reputation, in my experience, comes from doing, not from merely being perceived as smart, or good, or whatever. Execute. The rest comes from that.

Furthermore, once you enter the realm of keeping up appearances, you wind up in this horrible vicious cycle where eventually you just always have to clam up to seem smart about everything. Purposefully keeping quiet when you have no idea what’s going on – indeed, *because* you have no idea what’s going on is a close relative to lying, and has the same consequences. Eventually you’ll be cornered to execute and you’ll have no idea what to do. The fear that this will happen will eventually take over your waking hours, causing stress, and it’s all downhill from there.

On the other hand, being the happy idiot means filling in the cracks in your knowledge. It means you’re conscious of your own ignorance. It means you’ll be able to execute more effectively. This starts a positive cycle: you learn more, you execute more effectively, you begin to be perceived as smart, good, whatever, and it’s not completely unwarranted, because you’ve actually asked questions that took guts to ask and as a result you executed in smart ways. Eventually, your dumb questions aren’t perceived as being dumb anymore. Eventually, when you ask a seemingly trivial question, people stop reflexively thinking ‘how does he not know that’ and start thinking about what your brain is about to do with that little tidbit of data.

Further, it means people will trust you more. Think about it. Would you rather give a critical project to someone who absolutely never asks questions and “seems smart”, or the person who asks intelligent questions and executes?

So, I say be the happy idiot. Put yourself out there. If you’re perceived as being dumb for taking steps to be less dumb, then the problem isn’t yours, and you shouldn’t make it yours.

Comments (1)

By bkjones, June 2, 2011 10:27 pm

I’ve been busy. Seriously. Here’s a short dump of what I’ve been up to with links and stuff. Hopefully it’ll do until I can get back to my regular blogging routine.

PICC ’11 Slides Posted

I gave a Python talk at PICC ’11. If you were there, then you have a suboptimal version of the slides, both because I caught a few bugs, and also because they’re in a flattened, lifeless PDF file, which sort of mangles anything even slightly fancy. I’m not sure how much value you’ll get out of these because my presentation slides tend to present code that I then explain, and you won’t have the explanation, but people are asking, so here they are in all their glory. Enjoy!

I Made a Webapp Designed To Fail

No really, I did. WebStatusCodes is the product of necessity. I’m writing a Python module that provides an easy way for people to talk to a web API. I test my code, and for some of the tests I want to make sure my code reacts properly to certain HTTP errors (or in some cases, to *any* HTTP status code that’s not 200). In unit tests this isn’t hard, but when you’re starting to test the network layers and beyond, you need something on the network to provide the errors. That’s what WebStatusCodes does. It’s also a simple-but-handy reference for HTTP status codes, though it is incomplete (418 I’m a teapot is not supported). Still, worth checking out.

Interesting to note, this is my first AppEngine application, and I believe it took me 20 minutes to download the SDK, get something working, and get it deployed. It was like one of those ‘build a blog in -15 minutes’ moments. Empowering the speed at which you can create things on AppEngine, though I’d be slow to consider it for anything much more complex.

Systems and Devops People, Hack With Me!

I like systems-land, and a while back I was stuck writing some reporting code, which I really don’t like, so I started a side project to see just how much cool stuff I could do using the /proc filesystem and nothing but pure Python. I didn’t get too far because the reporting project ended and I jumped back into all kinds of other goodness, but there’s a github project called pyproc that’s just a single file with a few functions in it right now, and I’d like to see it grow, so fork it and send me pull requests. If you know Linux systems pretty well but are relatively new to Python, I’ll lend you a hand where I can, though time will be a little limited until the book is done (see further down).

The other projects I’m working on are sort of in pursuit of larger fish in the Devops waters, too, so be sure to check out the other projects I mention later in this post, and follow me on github.

Python Meetup Group in Princeton NJ

I started a Meetup group for Pythonistas that probably work in NYC or PA, but live in NJ. I work in PA, and before this group existed, the closest group was in Philly, an hour from home. I put my feelers out on Twitter, found some interest, put up a quick Meetup site, and we had 13 people at the first meetup (more than had RSVP’d). It’s a great group of folks, but more is always better, so check it out if you’re in the area. We hold meetings at the beautiful Princeton Public Library (who found us on twitter and now sponsors the group!), which is just a block or so from Triumph, the local microbrewery. I’m hoping to have a post-meeting impromptu happy hour there at some point.

Python Cookbook Progress

The Python Cookbook continues its march toward production. Lots of work has been done, lots of lessons have been learned, lots of teeth have been gnashed. The book is gonna rock, though. I had the great pleasure of porting all of the existing recipes that are likely to be kept over to Python 3. Great fun. It’s really amazing to see just how it happens that a 20-line recipe is completely obviated by the addition of a single, simple language feature. It’s happened in almost every chapter I’ve looked at so far.

If you have a recipe, or stumble upon a good example of some language feature, module, or other useful tidbit, whether it runs in Python 3 or not, let me know (see ‘Contact Me’). The book is 100% Python 3, but I’ve gotten fairly adept at porting things over by now Send me your links, your code, or whatever. If we use the recipe, the author will be credited in the book, of course.

PyRabbit is Coming

In the next few days I’ll be releasing a Python module on github that will let you easily work with RabbitMQ servers using that product’s HTTP management API. It’s not nearly complete, which is why I’m releasing it. It does some cool stuff already, but I need another helper or two to add new features and help do some research into how RabbitMQ broker configuration affects JSON responses from the API. Follow me on github if you want to be the first to know when I get it released. You probably also want to follow myYearbook on github since that’s where I work, and I might release it through the myYearbook github organization (where we also release lots of other cool open source stuff).

Python Asynchronous AMQP Consumer Module

I’m also about 1/3 of the way through a project that lets you write AMQP consumers using the same basic model as you’d write a Tornado application: write your handler, import the server, link the two (like, one line of code), and call consume(). In fact, it uses the Tornado IOLoop, as well as Pika, which is an asynchronous AMQP module in Python (maintained by none other than my boss and myYearbook CTO,  @crad), which also happens to support the Tornado IOLoop directly.

Comments (34)

By bkjones, January 18, 2010 8:39 am

I probably get more upset than is reasonable when I come across articles with no date on them. I scroll furiously for a few minutes, try to see if the date was put in some stupid place like the fine print written in almost-white-on-white at the bottom of the post surrounded by ads. Then I skim the article looking for references to software versions that might clue me in on how old this material is. Then I check the sidebars to see if there’s some kind of “About this Post” block. Finally, I make a mental note of the domain in a little mental list I use to further filter my Google searches in the future. Then I close the browser window in disgust. If it weren’t completely gross and socially unacceptable to do so, I would spit on the floor every time this happened.

Why would you NOT date your articles? In almost every single theme for every single content management solution written in any language and backed by any database, “Date” is a default element. Why would you remove it? It is almost guaranteed to be more work to remove it. Why would you go through actual work to make your own writing less useful to others?

What happens when you don’t date your articles?

1. People have no idea whether your article has anything to do with what they’re working on.  If you wrote an article about the Linux kernel in 1996, it’s of no use to me *now*, even if it was pretty hardcore at the time.
2. Readers are forced to skim your article looking for references to software versions to see if your article is actually meaningful to them or not. Why make it hard for people to know whether your article is useful? The only reason I can think of is that you already know your articles are old, so not dating them insures that people at least skim enough to see some of the ads on your site. You are irreversibly lame if you do this.
3. It causes near seizures in people like me who really hate when you don’t date your work, as well as all of your past teachers, who no doubt demanded that you sign and date your work.
4. Every time you don’t date an article online, a seal pup is clubbed to death in the arctic, and a polar bear gets stranded on a piece of ice.

At some point, I will make an actual list of web sites that regularly do not date their work. A sort of hall of shame for sites that fail to link their writing to some kind of time-based context. If you have sites you’d like to add, let me know in the comments.

Comments (0)

By bkjones, November 1, 2009 3:32 pm

The information superhighway’s construction has benefited me in ways I’ve only been made conscious of this weekend.

I’ve had a lot of time to myself this weekend, and decided to spend a few solid 1-hour blocks playing guitar. Oh, I still play around the house here and there, but usually if I can get in 20 minutes I feel privileged. Learning more kids songs is helping

But this weekend I wanted to learn a couple of songs in particular. I wanted to learn “Why Georgia” and “My Stupid Mouth” from John Mayer’s “Room for Squares” album. Although since that album’s release Mr. Mayer has gone on to do more produced and (to a guitarist) less interesting things on his commercial albums, Room for Squares contained really wonderful textures and sounds while somehow keeping the guitar front-and-center.

John also uses a lot of cool chords and fingerpicking techniques that I knew I’d have fun with if I ever had the time to sit down with the songs and my guitar at the same time. I’ve been playing for almost 25 years, and knew a lot of the chords and techniques, but it’d be great to be able to use them in songs that people under 30 recognize rather than having to explain (for example) who James Taylor is.

How I Learn Songs: First Phase

I learn songs by first listening to them either with headphones on, or at a relatively high volume, about 20 times. I want to become intimate, at a subconscious level, with every detail of the song. I want to feel the tension build, recognize cues from all of the instruments, and understand how they’re playing off each other. This is wildly important to a one-man musician, because often I try to embellish the final piece to try to put hints of the entire song into the final piece — not just the guitar part.

Of course, I *start* with the guitar part, because it’s a bridge to the rest of the song. I learn it as close to note-for-note as possible (where there are solos, the same goes for the solo. I’m sick that way).

Once I can play the song through along with the recording and not hear anything going awry, I practice it that way several times. Maybe 10 times.

Then the fun begins.

Having Fun Learning: Second Phase

When I was a kid, my mom and her sisters liked to go to flea markets. I was not a big fan of these huge collections of what looked like garage sales, until I came across a group of tables with what must’ve been 1000 cassette tapes (that was the popular audio medium of the day). When I scanned the collection, I noticed an unusually large collection of Jimi Hendrix tapes. I figured they were compilations, but after picking one up, I realized it was actually a random collection of live and unreleased recordings.

Over the course of months I collected as many of these as I could, because Hendrix was an artist that always sent me running to the guitar. All told I had about 6-8 versions of Red House, a classic 12-bar blues jam. I had 3-4 versions of Foxy Lady, another 3 of Purple Haze, and lots more. Going through and picking out differences between the live and recorded versions was a great primer on how you can alter and embellish while staying within the same basic framework of a song without totally destroying it.

From then on, whenever I learned new songs or started studying a particular guitarist, I tried to get as many different versions of different songs as I could, to see how the guitarist thought about the piece. Guitarists on the road forced to play the same songs night after night get bored, and often try to make things interesting by altering different parts of the song, or even by changing the guitar’s role in different parts of the song. Fascinating stuff.

Making it Your Own: Third Phase

I would learn lots of this stuff, again, note-for-note to the best of my ability. I was blessed with a fantastic ear and good sense of rhythm, and that along with practice and constant exercising of those talents made me able to pick out and play even some rather complex stuff in no time. By the time I was 14, I was able to play simple things like Led Zeppelin’s “The Lemon Song” in about an hour (not counting the solo), and most of the stuff on the radio I could begin playing along with accurately before the song was even over.

Even better, there were plenty of “solo acoustic” variants of songs, or songs where the live recording happened to pick up the guitar and drums more than the bass and keyboards, or it emphasized the bass and drums more than the guitar. These imperfections are absolute gems for learning more about what’s going in the song… or what *could* be going on when you play it!

Once I learn a song and work in some of the original artist’s own embellishments, some of my own embellishments, and some of my musical personality and influences, it more or less becomes “my own”. I can still play a variant faithful to the recording, but it seems boring when you’ve heard all that can be done with it.

What’s Better Now?

Well, it’s not like I used to pick a song, spend a weekend with it, and all of a sudden it was my own. While I could easily learn decently solid renditions of songs in a weekend, it would take me months to find different recordings of a particular song, to read magazine articles and sometimes books about guitarists, scouring the words for descriptions of how they played things and thought about them. It would be an ongoing process that sometimes also involved figuring out the players’ influences and tracking down *their* recordings… ugh.

Today?

*Literally* today, I decided to learn “Why Georgia” by John Mayer (I learned a decently solid version of “My Stupid Mouth” yesterday). While I was listening to the song in iTunes, I also checked out YouTube and searched for the song there. Boom! 5000 hits. In about an hour, I had heard (AND SEEN!!!) about 10 different performances by John Mayer himself, and I spent about another 20 minutes browsing videos others have posted either covering the song, or providing a tutorial on how to play the song!

Of course, some of the covers and tutorials are horribly wrong, but it’s easier to pick out stuff that’s not going to help you on YouTube than it is actually having to play through badly written tablature to figure out it’s wrong (and the internet, I promise you, is absolutely flooded with bad tablature).

The point is, I was able to learn this song, and work in Mayer’s embellishments as I went. Watching him play it in live performances, I was able to rely in visual cues and his body language to help me figure out how he thought about the song as he was playing it. Seeing him play in solo acoustic settings vs. live with a whole band was enlightening. In the end, I have learned a version of the piece, in one day, that would probably have taken me months to put together in the 80′s.

Thanks, Internet!

Comments (0)

By bkjones, June 12, 2009 2:23 pm

So, I’ve taught the Linux Boot Process as part of a couple of different training courses now, and I thought I’d share it with the world in the form of a screencast (it’s hosted at my co.’s site). This is also a test to help me figure out how to “do screencasts”, generally.

The material in the screencast is slightly adjusted, because different training clients want to see different things, and some just can’t afford to spend a lot of time on the boot process in their training classes.

I welcome any feedback anyone might have on it.

Comments (2)

By bkjones, May 26, 2009 10:01 pm

So, I’ve been freelancing now for 9 months. I did a post a while back about what was working and what wasn’t, and I still stand by those recommendations. But that was over 6 months ago. Since then a lot of things have happened. I’m happy to report that, so far, things are going great. My clients are happy, I’m happy, and I’m taking to the business end of things pretty well.

However, I’m learning more about the business, and myself, so I thought I’d share s’more thoughts on my freelancing experience to help those in the same boat, or who are thinking of making the leap:

You only *think* you’re organized

I thought I was pretty organized before I became a freelancer. I was always punctual, never missed appointments or meetings, didn’t miss deadlines — I was on top of things. I’m still doing all of that, but I’m finding that I have to organize things very differently from when I was a 9-to-5 employee.

This might not apply to you. You might already organize things in a way that would be easy to apply to a freelancing schedule. It wasn’t that way for me. I typically used to think of my life in terms of projects. I had projects I was working on, usually more than one at a time. Every week, I had a meeting with my boss to go over the status of the projects, if I had hit any roadblocks, etc. In retrospect, it was pretty nice.

Nowadays, I still have projects, but they all belong to different clients, and all of the clients need their own status, and they all have different personalities, different lingo, different businesses, and different priorities. Some client projects are heavily focused on a completion date. Others are heavily focused on a feature set. Still others are focused on a budget number. I have to interact with them all separately, and I have to think about how to present the status to each one to meet their expectations. So, I actually budget time to think about these things.

What’s more, since I do all of my work remotely on an hourly basis, if a client has to complete a task so that I can move forward, and it takes them three days, I may well have nothing I can work on and get paid for for that period of time. With some clients, this isn’t a very big deal: I offer them a discounted rate if they prepay for “bulk hours”, so they get a cheaper rate, and I’m not out of luck if there are delays. I also try to work in other smaller projects and do business development work for my company during these times.

So, the lesson is not to bother trying to come up with crazy Gantt charts and precise time lines. Your clients’ businesses don’t work that way, so yours will need to be flexible as well.

Nowadays I create more loosely defined, high-level project definitions with less detailed tasks and time lines. I still don’t lose sight of what needs to be done, and I’m still able to meet my clients’ needs.

I’m more paranoid than I thought

I’ve grown used to people asking me “How’s business?” I used to hate that question, because I didn’t really have a metric to go by that I thought was sufficient. Now I have several metrics, but I feel like I need to evaluate where I am with respect to those metrics almost daily. I guess it’s part of being a young business.

When you’re fully employed, “business”, to some degree, is always good, because you’re always employed, and always have a paycheck coming in. My stepfather worked for Exxon during the Valdez oil spill. Business for Exxon was horrible. But my stepfather’s job (i.e. “business”) was relatively unaffected.

My business has two services: consulting and training. I try to maintain training appointments for at least the next three months, and consulting projects for the next 4-5 months. If I look at my calendar and see lots of empty spots any time in the next three months, I have work to do. This methodology works for me, and makes me less stressed out than the method I used to use.

I used to just say “if at any time I have less than 6 months of expenses in the bank, I have work to do”, but looking at dollar figures every day is stressful, and I think in terms of the business it’s kinda like taking your eye off the ball. The ball isn’t money — the ball is your client list. Much like the ball brings with it the potential for a base hit or home run, your client list has the potential to pay your bills and grow your business.

More to Come

I can get a little long-winded, so I’ll stop here for now. I’m interested in your input, whether you’re a freelancer, or considering becoming one. Share your thoughts!

Comments (1)

By bkjones, March 30, 2009 8:35 pm

To all my geek/nerd friends in the blogosphere: I’ll be posting updates on Fedora Directory Server, my Linux training courses, and more in the coming weeks, but I wanted to let you know that I’ve recently been stricken with… umm… Twitter. I’m @bkjones on twitter, so if you’re into beer, brewing, billiards, cooking, guitar/music, linux, system administration, perl, shell, python, php, databases, sql, or anything like that, lemme know, or follow me!

Comments (0)

By bkjones, March 5, 2009 8:25 am

Last night I discovered likaholix.com and was able to get an account during their beta phase testing. You can see my likaholix page here, but I thought I’d take a few minutes to jot down some initial thoughts about it, because I do think it’s interesting.

Likaholix makes it Mind Numbingly Easy™ to quickly “like” something. To do that, all you do is type in a title for the thing you like, and then type a short description telling people why you like it. Then, add a couple of tags so the site can easily categorize your likes, making them easier for visitors to find.

Why is this cool? Well, a few reasons:

1. The huge masses of internet users happen to really like reading reviews. This is pretty easy to prove. Go to technorati.com and you’ll see that sites like Engadget and Gizmodo and other sites that do reviews are among the most highly trafficked sites. Other sites that aren’t blogs, like CNET, are also enormously popular. And what’s your favorite feature of Amazon? I know what mine is: customer reviews!!
2. The huge masses of internet users don’t really write thorough reviews, because they’re long and take time and more effort than you might think. However, just about anyone can tell you in 5 seconds or less why they like something, and are usually happy to do so.
3. The huge masses of internet users don’t really read thorough reviews, because they’re just too damn long. I mean, sure, if you’re making a major purchase in your life, you might read every letter you can find about a product, but for many things, people just want the bullet points. I’m not aware of a limit on the number of characters you can use in your descriptions on likaholics, but it certainly doesn’t encourage you to ramble on, like, say, this WordPress interface does
4. The huge masses of internet users love the idea of being a trend setter, which likaholix facilitates. Perhaps even more, they tend to follow and respond to trends, and likaholix facilitates that, too, by making it really easy to connect with other people, assigning credibility points to users making them “tastemakers” in certain areas, and making it really easy to find recommendations for whatever you’re interested in.
5. It’s appealing to huge masses of internet users, because it is, by definition, not specialized. You can like anything, and so this becomes sort of the internet equivalent to the “show about nothing”, Seinfeld, which if you remember, was hugely popular.

Of course, with the good comes the bad. There’s nothing really bad about likaholix, and the product is still in beta, so it’s very likely that it’ll change, but here are some quirks I noted:

1. There’s no feedback link! Why have people sign up for a beta if they have no interface to tell you what’s going on, why they like/don’t like, etc? That’s goes beyond bad into this really bizarro world of… bizarreness.
2. When you put in a title for your new like, likaholix tries to find a URL for what you’re about to describe. If you pick one of those URL’s, it changes your title to whatever the page title is of the URL you chose. That’s bad, because a) I would say most sites don’t pay proper attention to what their page titles should look like, and b) I typed in my title for a reason. Please don’t subvert my attempt to communicate through the use of an effective title.
3. Also, when you type in a title, while you’re typing, there’s a drop down that’ll appear with suggested completions. This is, unfortunately, too clunky and slow to be effective. Several times something would appear, and the right choice would barely have time to catch my eye before disappearing again. This is probably due to lag between results being generated and my typing. This means I’m sitting there pushing the back button, maybe a few times, then typing letter by letter very slowly until it comes back. At least the results are cached; I was usually able to get back to the right set of results and pick what I intended.
4. You can only be a tastemaker in two categories, and that kinda sucks, but I think I understand why that is: they’d probably like you to focus on one or two areas and “own the topic”, which is a big catch-phrase in the blogosphere. I think it’s kind of lame, but it’s not a big deal, and it’ll probably change anyway.
5. likaholix will post your likes to twitter, but with no link back to the site, and no indication that the tweet came from likaholix whatsoever! What’s the point? I’m sure this will change. I’ve disabled the feature on my account for the time being, and opted to post my likes to facebook, where people are less likely to have a real-time interface spamming them with my likes all day.

In the end, I think likaholix is a hit. I’ve never used a single site to get product reviews and recommendations, but now I might. I understand that this site only shows good reviews, but bad reviews are so easy to find that I don’t really care, and if the masses tend not to like something, then the fact that a site with (someday) millions of users mentions a product a mere 3 times will be indication enough. “If you have nothing nice to say…” and all that.

Also, if I want to know if some gadget, we’ll call it ‘foo’, sucks, Googling for “foo sucks” still works like a charm.

Comments (1)

By bkjones, February 20, 2009 10:53 pm

Marc Andreessen was on Charlie Rose last night, and I missed it. A buddy told me about it, and I wanted to watch, but things just got in the way. So here it is.

So, this is the very first time I’ve ever embedded video into a blog post. I couldn’t help myself.

Why?

I’ve never even heard Marc Andreessen talk until tonight, to be honest. I’ve been a huge fan of his actual technical work, and I’ve read some of his writings, and you almost can’t help but follow his career if you work with internet-related things directly, but I’ve somehow missed him at all of the conferences, never seen an interview… until now. And you know, it turns out that in this interview, he validates several posts that have been lying around on this blog for some time.

He talks about the evolution of web commerce and cloud computing and how it lowers the bar for startups.

He talks about news, newspapers and how they absolutely must kill the print edition, now.

He talks about social media, where it came from, where it’s going, “viral”, etc.

This is not to compare myself to Andreessen in any way — that’s ludicrous. But it’s nice to get some validation from on high for some of the thoughts and ideas I’ve had. Now if only I could write a tool that will lay the foundation for the next generation of human interaction, I’ll be all set

It should go without saying that I learned some things, but the biggest thing I learned came from just a tiny little quip buried in the middle of the video somewhere. He says, while talking about the iPhone, that it was “beamed in from 5 years in the future”. I think problems should be thought about that way in general. I’ve adopted a new way of thinking about products and services from pondering on this for all of 5 minutes. Find a service that solves a problem now, or find a problem that exists now — either one. Now think about how that problem will be solved in 5 years. Now set a deadline for solving that problem in 1 year.

Sounds impossible? Not a chance. Impossible is just another excuse to get creative, change your perspective, rethink the problem, and produce a solution. Listening to really smart people talk can be inadvertently inspiring. Thanks Marc!

Comments (1)

By bkjones, January 28, 2009 9:17 pm

I’ve seen the inside of lots and lots of businesses over the past decade or so. Though the technology has changed somewhat dramatically in many areas of the data center, the general, high-level methodologies for building a sane environment can still be applied. While the implementation is typically done by system administrators, it also helps if their managers and people who hire systems administrators are at least moderately clueful.

While it’s true that the high-level methodologies haven’t changed, likewise, the ways in which people abuse or neglect them hasn’t really changed much either. Here’s a list of things to avoid, and things to jump on, when building and growing your environment.

1. Don’t hire systems administrators: I have to say, that this is a problem I only used to see in very small businesses who couldn’t afford them, and perhaps didn’t warrant having one full-time, and this is changing it seems. I have now spoken with perhaps 4 managers in as many months that should really have at least one full-time sysadmin, and instead are just assigning systems tasks to volunteers from the engineering team. The results are disastrous, and get worse as time passes and the environment grows.At least develop an ongoing relationship with a systems guru and bring them in for projects as they arise — that’s worlds better than the results you get from doling out the tasks to people who don’t really have a systems background.The problem isn’t that any given task is “hard”. Most aren’t. The problem is actually multi-faceted: First, if something goes wrong, developers typically don’t have the background to understand the implications and impact of that. He also probably doesn’t have the experience to quickly fix the problem. Further, he may not know of a resource to get authoritative information on the topic (hint: online forums are not typically the best source of authoritative information for complex systems issues.)
2. Don’t automate: I’m an advocate of investing in automation very early and very often. If you’re just starting your business, and it relies heavily on technology, the first wave of systems you buy should include a machine to facilitate automated installation in some form. The reasons for this are many, but a couple of big ones are:
   • Consistency: if your system builds are easily repeatable, you can typically set up an automated install regime to make base installs identical, and alter only those parts of the install that support some unique service the system provides. You can then be sure that, to a very large degree, all of your machines are identical in terms of the packages installed, the base service configurations, the user environment, etc.
   • Server-to-Sysadmin ratio: automating just about anything in your system environment results in less overhead in terms of man hours devoted to that task. Automating the installation, backups, monitoring, log rotation, etc., means that each system administrator you hire can manage a larger number of machines.
3. Make security an afterthought: Security should be a very well thought out component of everything you do. People have been preaching this for eons, and yet it’s pretty clear to me that plenty (I might even say a majority) of businesses don’t even practice the basics, like keeping on top of security updates to systems and applications, removing/archiving user accounts when people leave the company, and setting up a secure means of remote access.Security breaches are a nightmare, typically. There are a lot of questions to answer when it happens, and most of them take some time and manual drudgery to answer. In addition, machines need to be reimaged, data needs to be recovered, audits need to take place, and of course, the big one: everyone has to spend time in meetings to talk about all of this, and then, magically, projects are planned to immediately insure that it never happens again… until it does, because the only time those projects gain priority is when a breach occurs. Get on top of it now, and save yourself the headaches, and costs, and other potential (and way bigger) disasters.
4. Don’t plan for failure: “plan for failure” is presently a term bandied about in relation to building scalable, reliable services using large numbers of machines, but the phrase also applies to good old infrastructure services. For example, for some reason, there are managers out there who demand that DNS services be handled by in-house systems, and then they end up with only a single DNS server for their entire domain! I’m not kidding! I’ve seen that twice in the past year, and that’s too much. For every service you deploy, you should make a list of all of the interdependencies that arise from the use of that service. Then determine what your tolerance for downtime is for that particular service, taking into account services that might go away if this service is unavailable. Why? Because it’s going to fail. If the service itself doesn’t fail, something else will — like the hard drive — and your end users won’t know or care about the difference. They’ll just know the service is gone.
5. Don’t communicate: as environments grow and become more complex, changes, tweaks, and modifications will be required. No systems environment I’ve ever seen is static. You’re going to want to implement services a little differently to offer more security, more reliability, a better overall user experience, or whatever. Communicating with the people you serve about these changes should be a part of the planning for projects like this. Users should know that a change is happening, how and when it’s happening, how they’ll be affected during the time of the change, and, hopefully, how their lives will be better because of the change.In addition, you should be thinking about how you’ll communicate with your systems team, and your users, in the event of a catastrophe. Do you have an out-of-bound mechanism for communication that doesn’t depend on your network being alive? If, I dunno, you lost commercial power, say, causing your UPS to kick itself on and immediately blow up, leaving your entire data center completely black, and you were the only person in the building, how would you get in touch with people to help you through the disaster? Note that this implies that your email server, automated phone routing, etc., are down as well.
6. Don’t utilize metrics: “If you can’t measure it, you can’t manage it” holds true in systems management as well. How do you know when you’ll need more disk? How do you know when your database server will start to perform badly? How do you know when to think about that reverse proxy for your web servers? You need to monitor everything. Resource utilization metrics are a key to growing your environment in a cost-effective way while still giving services the resources they need.
7. Don’t utilize monitoring: not metrics in this case, but service and system availability monitoring. What’s the cost to you if your website is unavailable for 1 minute? One hour? One day? If your database server, which serves your web site, goes down at 10pm and nobody knows about it until 8am, how does that affect your business? In reality, you *always* have availability monitoring: your customers will be your alert mechanism in the absence of any other monitoring solution. And what’s the cost in terms of the perception of the service you provide as a result? Monitoring can be non-trivial, but it is absolutely essential in almost all environments.
8. Don’t use revision control: Revision control can get you and your team out of so many headaches that I can’t list them all here. I’m not even going to tell you which tools to consider, because if you’re running an environment without revision control, almost anything is better than what you have. Revision control can be used to save different versions of all of the configuration files on your systems, documentation for all of your systems, all of the code written in your environment (i.e. those scripts used for system automation, etc.), and your automated installation template files. It can also be utilized in the chain of tools used to perform rollouts of new applications in a sane way (it can also be used to do rollouts in insane ways, but that’s another post). Revision control is equal parts disaster recovery, convenience, accountability, consistency, and control. To the extent that activity can be measured, it also provides metrics.
9. Don’t use configuration management: Depending on the size of the environment, this can come down to something as simple as an NFS mount or a set of imaging templates, with maybe some rsync-ish scripts around (in a revision control system!), or it can get complex, involving things like Puppet or CFEngine, along with other tools depending on your platform and other restrictions. The idea, though, is to abstract away some of the low-level, manual drudgery that goes along with systems management, so that you can, to quote the Puppet website, “focus more on how things should be done and less on doing them.” This ties in nicely with things like revision control, recoverability, the goals of consistency, automation, and increasing your system-to-sysadmin ratio.
10. Don’t be a people person: All of IT, not just systems management, has historically had issues communicating with business unit personnel. Likewise, business personnel have no idea how to communicate with IT personnel. No matter which side of the fence you fall on, generally being good with people, communication, perceiving and predicting the needs of others, will be very beneficial in winning consensus and gaining support for your projects. If nothing else, your career benefits from having a reputation of having good interpersonal skills and being an “all around good guy.” I know this is a completely non-technical item, but my experience is that some very large problems in systems management are not related to technology, but rather people.