Category Archives: Me stuff

On Keeping A Journal and Journaling

I've kept a journal since I was 11. That was in the mid 80's. I hadn't heard the word “journaling” until about a year or so ago, and lately it appears that giving advice and howto information about journaling is a bit of a cottage industry. I had no idea so many people were in demand of this information, but in a world where you can subscribe to multiple very successful monthly magazines about running, I shouldn't be so shocked.

I should also not be shocked to learn that people have heard some of the benefits people tout about journaling and want those benefits for themselves. But maybe some are skeptical and wonder “is journaling really all it's cracked up to be?” For those folks, let me say this: I've read a few of the blogs myself, and while I'd say the authors are mostly 1 or 2-year “veterans” who don't really get it yet, the benefits they say you can get from journaling are not only possible, they're just the tip of the iceberg.

The key to getting started, though, is probably to completely ignore everything you've read, go get a Pilot v5 pen, and some kind of blank book, and just start doing as you please. Beyond encouraging words and listing the benefits, what the books and blogs are telling you to do is, quite honestly, bullshit. They're either trying to put arbitrary rules around it, or telling you about the process they themselves find useful… for them. Some things I read seemed utterly destructive to some of the benefits. Tread carefully around advice, from me or anyone else.

Journaling is ultimately a personal thing. All of it. Not just the process, but the goals or what you want to get out of it. Furthermore, most of the goals I've achieved over multiple decades of journaling (and they are both countless and priceless) happened not because I willed it to be so and structured my process or writing to meet them, but by happy accident. I was benefitting from journaling long before I even realized what journaling had brought to my life.

So the idea that you can learn to journal strikes me as pretty odd. But I do encourage you to do it. Just find some quiet time, a blank page, and a pen, and spill it. Even if it looks boring. In the meantime, if you have questions best answered by someone who has been doing this for more than a year or two, let me know and I'll be happy to help if I can.

What Geeks Could Learn From Working In Restaurants

I spent a long time in my teens and early 20′s working in restaurants. To be honest, I loved just about every minute of it. It’s exciting, you’re never idle, and it’s usually not boring: you either get immediate gratification from happy customers leaving a nice tip, or you’re on the defensive, thinking on your feet to save an experience after something has gone wrong. 

In contrast, technology, I’ve found, requires more of an investment to get to the gratification of a job well done. I’ve also always felt like certain aspects of technology, like coding, are somewhat therapeutic for me, whereas restaurant work mostly wasn’t. And, occasionally, technology work can be monotonous and boring.

In spite of the quite dramatic differences between the two working environments, I sometimes find myself thinking about restaurants when I’m working on software or systems. It turns out that some of the tenets of restauranteurism, or just waitering or bartending, can be applied to work in the tech sector. Allow me a bit of license to riff on some of them here:

  • Treat your station as a single table. If one table needs a refill on a drink, chances are so do one of the other 4 tables that are all within 10 feet of that one. Save yourself some running by checking with all of the tables when one asks for something. In geek terms, this maps to looking for wins across multiple projects in your environment. Does your app need user authentication or a mail transport service? Chances are other projects do too. Looking for these kinds of wins can also help distribute the load of creating the requirements, and foster a sense of shared ownership in the result. 
  • Anticipate the need. Your customers shouldn’t have to ask for everything they need. Ideally they wouldn’t need to ask for anything they need, because you’d keep an eye on their drinks, you’d notice that someone wasn’t eating their salad and suspect something is wrong, you’d know that having kids means the first thing to the table is a huge stack of napkins, etc. The point is, there’s what’s happening now, and what is, in your professional opinion, likely to screw that all up. Your experience will likely guide you to solutions that are likely to keep that from happening. If not, you’re about to get more experience. Just like in technology ;-)  
  • Presentation counts. All restaurants fiddle with the light levels, the music rotation, how food is placed on the plate, the garnishes added to drinks, and any restaurant you’d want to eat in is fastidious about tiny, tiny details from sweeping the entry foyer, to replacing tablecloths, to tossing old-looking napkins, to replacing chairs with tiny pinhole tears in the leather. Why? Because a restaurant is, in the process of serving you, also constantly selling you through your experience there. Of course, your software should do this, but you can get deeper than that: all of those ideas you have that nobody listens to, or you can’t get approval for? You’re missing some details. You don’t have any metrics, or you’re giving a geeky experience to a business-y audience, or you’re not presenting your idea in the form of an experience, or you’re creating a vision of a present instead of a product in the mind of the person with the checkbook.
  • Presentation can’t save poor quality. You can put all kinds of shiny AJAX-y Bootstrap-y stuff all over your site. It could be the nicest UI in existence. If the service doesn’t work, you’re toast. And those ideas you’re trying to sell internally? You’d better be confident they’ll work and have a solid execution plan, because a couple of bombs and no amount of presentation goodness is going to get you to “yes” again.
  • Consistency! Food quality, presentation, service… the entire dining experience, from the moment you set foot on the property to the moment you leave, should ideally be completely 100% consistent. Completely predictable. Zero surprises. It makes the restaurant easy to get to know, because if you’ve seen one, you’ve basically seen them all. Now think about the naming of your variables. Do you abbreviate here and write it out there? Think about how you package your software. Do you sometimes provide an XML config file and sometimes INI format? Think about your code layout. Do you sometimes use inheritance and sometimes composition, when either will do? Do you sometimes test? Do you sometimes… anything? Small inconsistencies add up. I believe we’re pretty much all guilty of them sometimes, but we should all strive to minimize them. 
  • Minimize Complexity. Very little inside of a restaurant is complicated or complex. Inevitably, the friction points where small complications live are where problems arise. A huge number of issues within a restaurant are human error: mistaken orders, mismatching food to table when the tray is assembled, food under- or overcooked, drinks made wrong or sent to the wrong table, miscalculated bills, forgotten requests for drink refills or side orders, the list goes on for an eternity. Ironically, computers are employed to help with some of it, and the food service world is better for it on the whole. In technology, and I’m sure in most jobs, most of the issues are more with the people than the technology. From forgotten feature details to overlooked metrics, from miscommunicated load projections to undocumented security policies, the clumsy inner workings, and inter-workings of human beings gets us every time. 
  • Mise en place! This is a French term, and I don’t speak much French, but in a kitchen it means “have your shit together and easy to reach, kid”. Chefs on a line will have a shelf or some other space that’s within arm’s reach where they put bowls and bottles of things they need all the time. The pre-meal time for a chef is spent double-checking that this small area is picture perfect, double-checking that refills and extras will be easy to grab during the shift, and making sure there’s no excuse for failure. I see teams fail at this quite a lot, actually. The mise en place for a technology worker are all of those things that need to be in place in order for a service to go to production. Metrics and monitoring. Hardware allocations. Infrastructure service dependencies. Security concerns. Power! I cannot count how many times a service has gotten to the week of deployment before a request to allocate storage in production was created, or the number of times hardware arrived before anyone thought about where it would be plugged in, or what that would do to the uptime provided by the UPS during an outage. 
Overall, I’d say it’s been for my progress in the technology industry to have grown and learned lessons from experiences in other industries, even if those experiences sometimes came from rather menial roles. Also, as my great grandmother used to say, all of that sweaty, smelly work was also good for me: “It builds character!” 

What I’ve Been Up To

Historically, I post fairly regularly on this blog, but I haven’t been lately. It’s not for lack of anything to write about, but rather a lack of time to devote to blogging. I want to post at greater length about some of the stuff I’ve been doing, and I have several draft posts, but I wanted to list what I’ve been up to for two reasons:

  1. I use my blog as a sort of informal record of what I accomplished over the course of the year, hurdles I ran into, etc. I also sometimes use it to start a dialog about something, or to ‘think out loud’ about ideas. So it’s partially for my own reference.
  2. Someone might actually be interested in something I’m doing and want to pitch in, fork a repo, point me at an existing tool I’m reinventing, give me advice, or actually make use of something I’ve done or something I’ve learned and can share.

PyCon 2013

I’m participating again for the third year in the Program Committee and anywhere else I can help out (time permitting) with the organization of PyCon. It’s historically been a fantastic and really rewarding experience that I highly (and sometimes loudly) recommend to anyone who will listen. Some day I want to post at greater length about some actual instances where being really engaged in the community has been a win in real, practical ways. For now, you’ll have to take my word for it. It’s awesome.

I also hope to submit a talk for PyCon 2013. Anyone considering doing this should know a couple of things about it:

  1. Even though I participate in the Program Committee, which is a completely volunteer committee that takes on the somewhat grueling process of selecting the talks, tutorials, and poster sessions, it’s pretty much unrelated to my chances of having my talk accepted. In other words, submitting a talk is as daunting for me as it is for anyone. Maybe more so.
  2. Giving a talk was a really rewarding experience, and I recommend to anyone to give it a shot.

I just published a really long post about submitting a talk to PyCon. It’s full of completely unsolicited advice and subjective opinions about the do’s and don’ts of talk submission, based on my experiences as both a submitter of proposals and a member of the Program Committee, which is the committee that selects the talks.

Python Cookbook

Dave Beazley and I are really rolling with the next edition of the Python Cookbook, which will cover Python 3 *only*. We had some initial drama with it, but the good news is that I feel that Dave and I have shared a common vision for the book since just about day one, and that shared vision hasn’t changed, and O’Reilly hasn’t forced our hand to change it, which means the book should be a really good reflection of that vision when it’s actually released. I should note, however, that the next edition will represent a pretty dramatic departure from the form and function of previous versions. I’m excited for everyone to see it, but that’s going to have to wait for a bit. It’s still early to talk about an exact release date – I won’t know that for sure until the fall, but I would expect it to be at PyCon 2013.

PyRabbit

I’ve blogged a bit about pyrabbit before: it’s a Python client for talking to RabbitMQ’s RESTful HTTP Management API. So, it’s not for building applications that do message passing with AMQP — it’d be more for monitoring, polling queue depths, etc., or if you wanted to build your own version of the browser-based management interface to RabbitMQ.

Pyrabbit is actually being used. Last I looked, kombu was actually using it, and if memory serves, kombu is used in Celery, so pyrabbit is probably installed on more machines than I’m aware of at this point. I also created a little command shell program called bunnyq that will let you poke at RabbitMQ remotely without having to write any code. You can create & destroy most resources, fire off a message, retrieve messages, etc. It’s rudimentary, but it’s fine for quick, simple tests or to validate your understanding of the system given certain binding types, etc.

I have a branch wherein I port the unit tests for Pyrabbit to use a bit of a different approach, but I also need to flesh out more parts of the API and test it on more versions of RabbitMQ. If you use Pyrabbit, you should know that I also accept pull requests if they come with tests.

Stealth Mode

Well, ‘stealth’ is a strong word. I actually don’t believe much in stealth mode, so if you want to know just ask me in person. Anyway, between 2008 and 2012 I’ve been involved in startups (both bought out, by the way! East Coast FTW!) that were very product driven and very focused on execution. I was lucky enough to answer directly to the CEO of one of those companies (AddThis) and directly to the CTO of the other (myYearbook, now meetme.com), which gave me a lot of access and insight into the mechanics, process, and thinking behind how a product actually comes to be. It turns out I really love certain aspects of it that aren’t even necessarily technical. I also really find the execution phase really exciting, and the rollout phase really almost overwhelmingly exciting.

I’ve found myself now with an idea that is really small and simple, but just won’t go away. It’s kind of gnawing at me, and the more I think about it, the more I think that, given what I’ve learned about product development, business-side product metrics, transforming some stories into an execution plan, etc., on top of my experience with software development, architecting for scalability, cloud services, tools/technologies for building distributed systems, etc., I could actually do this. It’s small and simple enough for me to get a prototype working on my own, and awesome enough to be an actual, viable product. So I’m doing it. I’m doing it too slowly, but I’m doing it.

By the way, the one thing I completely suck at is front end design/development. I can do it, but if I could bring on a technical co-founder of my own choosing, that person would be a front end developer who has pretty solid design chops. If you know someone, or are someone, get in touch – I’m @bkjones on Twitter, and bkjones at gmail. I’m jonesy on freenode. I’m not hard to find :)

In and Out of Love w/ NoSQL

I’ve recently added Riak to my toolbelt, next to CouchDB, MongoDB, and Redis (primarily). I was originally thinking that Riak would be a good fit for a project I’m working on, but have grown more uncomfortable with that notion as time has passed. The fact of the matter is that my data has relationships, and it turns out that relational databases are actually a really good fit in terms of the built-in feature set. The only place they really stink is on the operations side, but it also turns out that I have, like, several years of experience in doing that! Where I finally lost patience with NoSQL for this project was this huge contradiction that I never hear anyone ever talk about. You know the one — the one where the NoSQL crowd screams about how flexible everything is and how it really fits in with the “agile” mindset, and then in another doc in the same wiki strongly drives home the message that if you aren’t 100% sure what the needs of your app are, you should really make sure you have a grasp on that up front.

Uhh, excuse me, but if I’m iterating quickly on an app, testing in production, iterating on what works, failing fast, and designing in the direction of, and in direct response to, my customers, HOW THE HELL DO I KNOW WHAT MY APP’S NEEDS ARE?

So, what I’m starting with is what I know for sure: my data has relationships. I’m experienced enough with NoSQL solutions to understand my options for modeling them & enforcing the relationships, but when the relational aspect of the data is pretty much always staring you in the face and isn’t limited to a small subset of operations that rely on the relationships, it seems like a no-brainer to just use the relational database and spend my time writing code to implement actual features. If I find some aspect of the data that can benefit from a NoSQL solution later, well, then I’ll use it later!

Unit Testing Patterns

Most who know me know I’m kind of “into” unit testing. It’s almost like a craft unto itself, and one that I rather enjoy. I recently started a new job at AWeber Communications, where I’m working on a next-generation awesome platform to the stars 2.0 ++, and it’s all agile, TDD, kanban, and all that. It’s pretty cool. What I found in the unit tests they had when I got there were two main things:

First, the project used bare asserts, and used dingus in “mock it all!” mode. Combined, this led to tests that were mostly effective, but not very communicative in the event of failure, and they were somewhat difficult to reason about when you read them.

Second, they had a pretty cool pattern for structuring and naming that gave *running* the tests and viewing the output a more behavioral feel to them that I thought was pretty cool, and looked vaguely familiar. Later I realized it was familiar because it was similar to the very early “Introducing Behavioral Driven Development” post I saw a long time ago but never did anything with. If memory serves, that early introduction did not introduce a BDD framework like the ones popping up all over github over the past few years. It mostly relied on naming to relay the meaning, and used standard tools “behind the curtain”, and it was pretty effective.

So long story short, those tests have mostly been ported to use the mock module, and inherit from unittest2.TestCase (so, no more bare asserts). The failure output is much more useful, and I think the pattern that’s evolving around the tests now is unfinished but starting to look pretty cool! In the process, I also created a repository for unittest helpers that currently only contains a context manager that you feed a list of things to patch, and it’ll automatically patch and then unpatch things after the code under test is run. It has helped me start to think about building tests in a more consistent fashion, which means reading them is more predictable too, and hopefully we spend less time debugging them and less time introducing new developers to how they work.

The Happy Idiot

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.

 

Slides, an App, a Meetup, and More On the Way

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.

If You Don’t Date Your Work, It Sucks.

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.

It’s so much easier now

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!

My first screencast: The Linux Boot Process

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.

More Lessons in Freelancing

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!

Activity Lapse: I blame Twitter

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!