Category Archives: navel-gazing

To Do Journaling

IMG_3600

A co-worker noticed me taking some notes in my notebook the other day, and asked about my To Do journaling (yes I’m making that word up). There was genuine interest from a few other people, so I decided to make a blog post about it.

To Do journaling, to me, is writing down a list of things to accomplish for the day. This is a pretty common practice, and there is nothing really revelatory about the process, simply write the things you want to do down. I started doing this when I couldn’t keep track of the things I needed to do in my head any more, and I was letting things fall through the crack. There are many ways in which one could enumerate a to do list; there is a whole industry around tools to help one accomplish this. However, given how much of my life is ruled by electronic means and apps and tools, I have eschewed the “smart” tools, and instead have adopted a more traditional model. I find it helps keep me grounded.

For my journaling, I prefer to use pen and paper. A physical notebook I carry with me in which I can document my to dos for the day, and any sort of notes I need to write down. Writing things down by hand seems to trigger some bit of memory goo in my brain and helps me to remember it. If I type it out, it seems to slip through the synapses and fall out the other side, but writing it down gives it a bit of “stickiness”. Because I will spend a fair amount of time touching and feeling and writing in my notebook, I splurge on a high quality notebook. One that’s the right size, the right paper feel, and a nice cover. My current favorite is the Rhodia Webnotebook, in black. This notebook is hardcover, which helps me write on a variety of surfaces, but it covered in a very comfortable leatherette. The paper is very nice as well. A good notebook deserves a good pen too. I’ve gone through a multitude of pens in the past, with various favorites along the way. My current favorite is the Sharpie Grip Pen with a fine black point. These aren’t super fancy, but they write nicely (particularly on the Rhodia paper) and feel good in the hand. Additionally they’re so cheap that I don’t fret if I lose one. To keep my pen and my note pad together, I got a Quiver pen holder. This actually cost more than the notebook and pens combined, but unlike the notebook and pen which are consumables, the Quiver will transfer from note book to note book. This keeps my pen always with my notebook, and adds a nice touch of style to the setup.

Enough about the gear, lets talk about the process. Every day I create a new to do list. Every day is a fresh list, so that I don’t have to keep paging back through history to find the list of things to do. I make a To Do XX/XX header to indicate the date, and then start listing things prefixed with a dash.

IMG_3601

This is just a simple, unordered list. I typically leave room to the right of the list so that later, after taking various notes below it, if I need to add another item I have room. Having the items unordered also means I don’t stress if I have to add an item later, it can go wherever and not upset any ordering. As I start working on something, I’ll make a tilde mark next to the list item.

IMG_3602

Later, as I finish an item, I’ll check it off with a check mark. I do not cross the item out, because I want to be able to go back through my history to remember the things I’ve done. Crossing an item out makes it that much harder to read (my handwriting is challenging enough).

IMG_3603

If at the end of the day I haven’t accomplished everything on my list, I draw a square around the incomplete items. This square is a visual cue that lets me know I need to carry the item over into the next day’s list. In this way I don’t lost track of the things I want to accomplish, but I don’t have to flip back to previous days. I just carry over the unfinished items to the next day.

IMG_3604

This very simple process has kept me on top of the things I need to accomplish for the past few years. I’ve filled a number of notebooks this way, and that feels like a great accomplishment. Every time I feel like nothing is happening and my wheels are spinning I can page through them and realize that yes, I am actually getting things done. This process also helps come review time, looking back at past accomplishments. I haven’t done this yet, but I could star the items that would be good to highlight in any future self review scenario.

Thanks for reading, and feel free to share your own to do process in the comments, or on twitter.

On next chapters

I haven’t gotten a lot of sleep lately, I’ve had quite a lot on my mind.

I’ve been a “Racker” for almost two years now. I’ve helped build an amazing thing. The way we expand, deploy, upgrade, operate, and otherwise manipulate OpenStack andย  the other infrastructure behind the Rackspace Public Cloud is awesome, and getting better all the time. As much as I would love to stay on and continue to intensify the awesomeness, it was time to say good bye. While I’ve done a lot of the work, I wasn’t the only one, and I know that there are a lot of good people still plugged into the mission and it will go on.

What’s next? Well, I’ve been a working remotely for over 6 years now. It has been fantastic to be able to be home and around my family as we’ve grown. I’ve tried hard to strike a balance between work travels and home life, but sometimes that balance falls out of whack, particularly when the social side of me that craves in person interaction overrules the empathy side of me that keeps me in check when I’m putting too much on the shoulders of those I leave behind. With our boys growing older, spending quality time with them is more important than ever, which is making it harder and harder to make frequent visits to my Rackspace offices. At the same time, my boys are both now in full time school, which opens up my day time hours, which means it’s a great time to think about re-joining the “work from office” folks. I’ve also been working for large publicly traded companies for nearly 10 years, and I really felt like it was time to get back into the small startup game.

I’m very excited to be joining the Blue Box team as an OpenStack Engineer. I get to keep working on OpenStack stuff, and Ansible stuff, and other fun open source things. They’re in Seattle, which gives me an excuse to get on my bike a few days a week and multi-modal commute in, and still strike a good balance with my home life. I also get to plug more firmly into the Seattle tech scene, which exploded with awesomeness since I was last a part of it.

Parting ways is never easy, but the relationships I’ve built feel strong enough to survive. We’ll still see each other at various conferences and meet ups, and we’ll all keep working to make OpenStack even better.

Breaking the cycle – It’s okay to say “I don’t know”.

While listening to a recent Freakonomics podcast, I learned that from childhood on there is programming to teach us that it is better to have an answer, even if it is wrong, than to not have an answer at all. Why this happens is not fully understood, but the consequences are becoming more apparent. Maybe my upbringing was different, but I’ve never seemed to have a problem with stating that “I don’t know”. But I have ran into people who always seem to have the answer, even if it is wrong.

People in the business world are no exception. There often can be an expectation set, particularly for people in more senior positions, to be experts in our fields, which to some means always having an answer.

Far too often though, we don’t have an answer. Our skill isn’t in knowing all the answers, our skill is in being able to discover the answer. It’s knowing when to ask for help, where to get that help, and how to sort through data to find a solution.

Stating that “I don’t know” is not an admittance of failure. Instead it is an invitation for collaboration and discovery. It is the very nature of science and the Scientific Method; starting with an unknown, research to form a hypothesis, test that hypothesis by experimentation, analyze the data and form a conclusion, then communicate the results. Science works when we start with the unknown and journey to the known. The door is open for others to provide ideas and research to the table. Differing opinions are welcome and debated.

When we skip passed the “I don’t know” stage and jump straight to an answer, particularly when practicing “fake it until you make it”, any differing opinion is viewed as adversarial. This creates conflict rather than collaboration. More effort will be spent to entrench on the wrong answer just to hold up the illusion that one has all the answers. Any evidence that does not support the already chosen answer will be ignored or discounted.

In these situations, a wrong answer asserted with authority, is far more expensive than the answer of “I don’t know” and the subsequent period of discovery. Good money and time will be thrown after bad, just to make the wrong answer work, or to find ways to blame other things from preventing the wrong answer from working. This creates a very hostile work environment and does not foster collaboration.

Speaking of discovery, the only method to to learn new things is through feedback. Feedback often comes from the process of trail and error, or experimentation. When it is okay to be wrong, it is also okay to make mistakes and errors. This leads to much clearer data and better understanding of the problem at hand. The ability and encouragement to try new things, even if (and especially if) they fail is a fantastic tool for learning, and ultimately for discovering the best answers to a given question.

In many ways, the ability to admit not knowing the answer to something is a valuable trait, one that should be celebrated, encouraged, and cultivated. An environment should be created and maintained that fosters this behavior. Encourage trail and error. Celebrate failures as data about what doesn’t work and use it as data to measure what does work against. The rewards will be many.

I won’t claim that this is the best way, I just don’t know. What I do know is that organizations I’ve been a part of that have embraced the culture of discovery have been more successful and more pleasant to be a part of than those which haven’t. I encourage those I work with to not be afraid to state “I don’t know”. It’s impossible to know everything about everything. Together we work to find answers to the unknown and the journey is just as important as the solution.

Hosting my own blog

Many moons ago I had a LiveJournal blog. At the time I just didn’t want to be bothered with hosting my own stuff, and there was a LiveJournal community. Many of my peers also used LiveJournal, so I followed the herd.

Fast forward a few years and I blogged less and less, as I joined social media and participated in things like Facebook more and more. My LiveJournal basically stopped in 2010.

In April of 2012, I moved to the Anaconda team at Red Hat to be a full time developer on the installer software, and I decided to start blogging about that. LiveJournal felt clunky so I wanted something new and cool, and I was terrified of running my own blog software, so I got a blogspot.com account and started publishing. Shortly after that I left Red Hat and joined Rackspace, and gave the blog a new title.

Now that I’m at Rackspace working on our Public Cloud, it seems really silly to keep hosting a blog on blogspot. So I’ve bit the bullet as it were and created a wordpress site to keep my blogging going. I don’t know what I’ll post about, or how often I’ll do it, or if anybody will care, but it will be therapeutic to me at least, and that’s all that really matters.

New blog name, new focus

I’ve renamed this blog to “Adventures in The Cloud”.  My day job is now DevOps for Rackspace’s public cloud, and I’ll occasionally blog about those adventures.  This is where those blog posts will land.

Right now I’m still learning my way around things and finding places to help out, so not a lot to blog about yet.  My first big task is a cleanup of our cloud, finding VMs that are still running that should be deleted, VMs stuck in a delete action, or VMs that aren’t running any more but our DB thinks they are.  There are various other clean up items I’m finding along the way.  The software I’m writing to do this will likely be contributed to OpenStack upstream at some point (soon) as it’ll be useful to anybody running an OpenStack based cloud.  Nobody likes wasted resources!

That’s all for now, back again when I have something fun to talk about.

Hanging up the Hat

Seven years ago I put on a Red Hat.  I had been a part of the community for a few years prior to that as well, first as a newbie in #redhat looking for help, later as somebody providing help to others, then as an early cabal member in the newly formed Fedora project, later as a leader of Fedora Legacy.  Along the way I’ve made some very strong friendships that I hope will continue.

This is my last week as a Red Hatter.

I’d like to think that the Fedora project is a better place now than when I joined.  I hope my time here has made a positive difference.  My new role will leave me with less time to participate directly in Fedora, although I will likely continue maintaining a few packages here and there for my personal use.

I do plan on being at FUDCon in January, I hope to see many of you there.

I’ll likely be shutting down this particular blog this week, but a new one will start and I’ll link to it from here if you really like me and wish to keep tabs on what I’m doing ๐Ÿ™‚

Well I’ve been waiting for this moment for all my life…

I can feel it coming in the Air tonight…

Excuse me a moment whilst I rock out to a killer electronic drum riff.

still there?  Ok.

I’ve had a Macbook Air for a while now, not the original air, but the first redesign of it (sadly just before they did another redesign with a better chipset and backlit keyboard, oh well).  When I first got it, I went a little crazy, and setup a triple boot system, OS X, Windows (Vista), and Fedora.  Sadly, Fedora didn’t work so hot.  There were graphics issues, sound issues, touchpad issues, wireless issues, I mean, I think the issues had issues.

So instead of fighting all those issues, I did something even more silly.  I found a virt software set in OSX that would allow me to attach a real partition to the guest.  I setup a virtual disk image to do a minimal install of Fedora in, then edited the grub config so that it would actually load up the real disk partition as /.  This actually worked, surprisingly well.  I spent most the time in OSX with various X11 applications ran through ssh, and of course ssh’d into the guest to do all my command line work.  It still felt dirty though.  I would also let the guest boot up into graphical mode and make that go full screen in OSX Lion, which gave the illusion of using Linux native on the hardware.  The upside was that the touchpad worked pretty well, and there weren’t network issues.  Video still sucked, no gnome-shell for me.

When I picked out the Air, I was thinking that it would be nice to have some hardware that was not the normal around the water cooler, so that we had a broader set of systems being used every day.  I actually thought I could do something to fix issues that came up.  Ha, hah.  Turns out the most useful thing I could do was hand the system off to people who knew what they were doing.

Enter Super Hero mjg who decided (or got tasked with, I’m not sure which) that making Fedora work on Apple hardware like my Air was a thing he would do.  And he sure did!

So you can wipe off that grin, I know where you’ve been

That’s the Fedora 17 Final (RC3) Desktop Live image being installed to my Air.  It couldn’t have been easier.  dd the iso to a USB stick, boot holding down option, plug in the stick (because I forgot to do that first) and pick the Fedora Media.  Anaconda did all the right things (even when I didn’t) and I now have a simple dual booting macbook.

F17 looks awesome.  First time I’ve really used shell, and I like it.  Audio works, graphics work, webcam works, touch pad (mostly) works, even the brightness and volume buttons work.  I can’t wait to haul it down to my local Starbucks on my bike, then show it off to my hipster friends, because you see, I was using Fedora on my Air before it was cool.

Well I’ve been waiting for this moment for all my life….

It’s a Brand New World!

It has been a few years since I was last heavily interested in how Anaconda did it’s things.  Having recently gotten back into it for my new role, it’s kinda cool to see how much has changed.

Composing images:
  buildinstall is out, lorax is in
  mkintrd is out, dracut is in

Booting the installer
  Loader is out, dracut is in
  sysvinit/upstart is out, systemd is in

Installer Itself
  Too much really to list here, I’m still trying to get a grip on it, and it’s all changing again!

So I’ve had a fun few weeks getting used to the new way of doing things, stumbling around, mumbling about “In my day!” and waiving my cane.  The reality is that these are all really cool improvements, and it’s made working on changes quite a lot easier to manage.  I don’t like that feeling that the world has moved on while I wasn’t looking, but then again, that’s OK, that’s what the world should do.  I just get to be that New Guy again for a bit.

I’ve seen the Future, and it involves punch cards??

I’ve now been working for Red Hat for roughly 6.5 years.  That’s a long time!  I started out doing Release Engineering work for our internal Fedora project, somewhere around Fedora Core 5.  One of my first tasks was to script a mass rebuild of all our packages for a new compiler and point out to people when their software failed to build.  As an eager new employee I spend some time on the weekend sending out build failure reports (by hand) to one of our development mailing lists, and a funny thing happened.  The CEO of the company (at the time Matthew Szulik) replied to one of my reports directly to me, saying that he was pleased to see somebody else burning the weekend hours.  The C, E, Freaking, O!  How cool was that??

Fast forward a release or two and now I’m helping to move Fedora out of Red Hat and into the world at large as a “Community Driven” project.  Basically get our sources and build system to where more than just Red Hat employees can touch.  This required a lot of careful thought, planning, and political smooth talking but we made it happen.  A great group of engineers and managers all saw the greater potential for Fedora if we could just free it from the Mother Ship and worked very hard to convince other people and create software and infrastructure to make it happen.  My role changed a bit at that time from just another release engineer to more of a group leader, a group of volunteers who wanted to help out with the tasks related to getting a Fedora release made.

Fast forward again a larger number of releases and we’ll get to about 2 years ago.  A FUDCon was about to start in “Toronto” CA and a big group of folks were on a chartered bus riding from “Boston” to the FUDCon event.  As geeks do when stuck in a small space around other geeks, we talked about geeky things.  The geeky thing that had been on my mind for a while now was trying to get Fedora sources moved out of an aging CVS based setup with buildsystem integration by way of various data files and Makefiles onto something a bit more…. modern.  Anybody paying any sort of attention to source control systems in the past few years will have noticed a sharp uptick in the adoption of a new source control system called git.  We desperately wanted to use git to manage Fedora package sources, and I desperately wanted to use something other than Makefiles to interact with the system and so we spent a good part of that ride throwing ideas around.  Certainly not the first time we’ve done this, but something happened to click on that ride and half a plan was formed.  There certainly is something magical about getting a group of people together and then removing a lot of the outside distraction, just to see what kind of awesome can be cooked up.

For the next 2 years or so I worked on first getting Fedora moved into git and replacing Makefiles with a python library and application, followed by doing the same for a much more complicated internal setup at Red Hat for all of Red Hat’s products.  The work on the latter is now (mostly) done and I had to make a decision.  Did I want to keep working on Release Engineering type stuff, as I had for the previous 6.5~ years, or was I ready for something new?  I certainly felt ready for something new.  There is nothing wrong with releng work, I quite enjoyed it and I really liked the team I worked on, but 6 years is a long time for a geek to be focused on one type of work.  So I looked around Red Hat to see if anything else was interesting to me, and I found an opportunity within the Installer team.

The Installer team primarily develops and maintains Anaconda, the software used to install Fedora and Red Hat Enterprise Linux (and it’s many rebuilds) onto computers.  There is a variety of other software involved, all playing supporting roles, but Anaconda is certainly the star of the show.  As of Monday the 16th I’ve been the newest member on the Installer team.

What I’ll be doing there is still being worked out; It depends somewhat on what interests me and what needs are there.  Getting to the title of this entry, one of my first tasks is to get up to speed on IBM Z hardware (s390x).  The team needs more than one person to have knowledge of how our software (installer and the OS) is brought up on these systems.  I learned that even though IBM has been making new Z systems in recent years, they /still/ make use of a stack of virtual punch cards spooled into a virtual reader to allocate resources for an OS to come up.  That’s right, it’s 2012, I’m looking into the future of my work here at Red Hat and I’m learning about punch cards.  WAT?

I’ll still be involved a bit with source control management for Fedora/RHEL, and may make some new features and fix bugs in the software we use to interact with git and our build systems, at least until we find a new sucker^w engineer to take on those responsibilities.  But now instead of writing software that our developers make use of, I’ll be writing software that our /customers/ make use of and that’s both scary and very exciting!

I hope to blog a bit more often about my Adventures in Installer Land, thoughts and observations that are going to require more than 140 chars.  For now, back to the punch cards!