personal

Affirmations

Recently, I’ve been thinking about the power of positive self-talk and motivational thinking. I’ve started reciting the following message in the morning to frame my thinking for the day ahead; thought I would post it here in case it helps someone else.

Today is a good day; today is my day.
I have all I need to be the best I can be.
I will overcome my fears, I will learn from my mistakes. I will enjoy today.
Today is a good day; today is my day.

Been a weird year….

And you’re probably going to see a ton of retrospective posts going live soon from a variety of authors. I’m struggling to write… well, anything…. That being said, I’ve had a few key successes over the last year.

  1. Presented several times virtually, particularly as a Friend of Red Gate. DevOps Enterprise Summit, PASS Summit, and DPS. I also presented for Georgia DAMA and for the Nashville SQL Saturday (my last in-person presentation).
  2. Job is good; learning lots of new stuff with Powershell and OCtopus Deploy, as well as Azure DevOps.
  3. We got an awesome dog. Meet Conway.

Of course, lots of other stuff happened too. COVID decimated travel plans, and as most of you are aware, it killed an organization that I’ve been a long-time member of (PASS). It also cancelled the SQLSaturday Atlanta for 2020, perhaps indefinitely.

Top it off with some health stuff, and frankly, I’m exhausted. However, I do have this urge to make the most out of the next year, and the only way I know how to do that, is to get back in the habit of writing.

More to come.

#FAIL

There’s been some great discussion in the #SQLFamily after Brent Ozar published a recent blog post: I Failed 13 College Courses. Lots of comments on Facebook about it, and other people soon came forward with their own brief tales of academic failure (and subsequent successes). I was particularly touched by Mike Walsh’s video (What Advice Should I Share on Career Day?), where he talked about dropping out of high school. Most of the conversations were about the struggles in academia, but there was real underlying thread: You can succeed and be happy after facing failure.

I’m friends with a lot of smart, successful people, and for those of us that are engaged in information industry, failing at an intellectual exercise (like college or high school) can be perceived as a mark of shame. I think what Brent, Mike, and others are showing is that recovering from failure is not only possible, but normal. We all fail at something, and that often puts on a new path to figuring out something else. Failure teaches us more than success.

My Story…

(Note: I just realized that my last blog post touched on this story briefly. Must be on my mind a lot lately.)

I didn’t fail in high school (WMHS, 1989).

I didn’t fail during my Bachelor’s degree (ULM, 1993 – B.A, RadioTVFilm Production).

I didn’t fail during my first Master’s degree (ULM, 1995 – M.A, Communication).

I didn’t fail on my coursework for my doctoral degree. (UGA, PhD coursework completed in 1999).

Nope. I waited until I was 28 years old (with a wife and two kids depending on me) to fail at my first academic exercise. I bombed my doctoral comprehensive exams not once, but twice over a 6 month period. In April of 2000, I was waiting outside my major advisor’s office to discuss my options for a third attempt. I waited for two hours, brooding over the shape of my life at the moment. She never came, so I walked out the door and didn’t go back (stopping at a bookstore on the way home to purchase two books on SQL). I didn’t hear from her until a few years ago when she friended me on Facebook, and we’ve never really discussed it. I’m happy, and she’s moved on to greater successes as well.

As an aside to this story, I had been working at the American Cancer Society while going to school; my official title on most publications was Research Assistant, but I was the shadow DBA for the Behavioral Research Center. I had been working with Microsoft Access to manage contact information for cancer registries as well as using SPSS with SQL to analyze data. I parlayed that interest in data management into a new job in August of 2000; I had decided that I wasn’t cut out for anything academic, and I wanted to move into IT full time.

I did go back in 2001 to finish a second Master’s degree in Education (UGA, 2002 – M.Ed. Instructional Technology). Yes, I have three college degrees, and none of them are in information Technology.

What I Learned…

Lots of lessons I picked up out of this.

First, I learned that the fear of failure often motivates me to pick the easier path. Looking back over my academic career, I’ve always been smart enough to know what my limitations are, and lazy enough to not challenge them. I got a degree in Radio Production, not just because I enjoyed the theatrical end musical elements but also because I knew I didn’t have to take harder courses (like Chemistry, Physics or Calculus; all of I which I had managed to avoid in High School). I used to think it was working smarter, not harder; in hindsight, I just didn’t want to fail.

Second, a fear of failure often blinds me from looking at the bigger picture. When I’m scared that something is going off the rails, my instinct is to drive forward at full speed and force it to succeed. Over time, I’ve learned to be sensitive to those warning signs, and try to put the brakes on and redirect. At several points in my graduate career, I knew that I was in the wrong field. But I had a job in academic research, and I had never failed before, so I was going to see this through and will it to be. That obviously didn’t work.

Third, fail early, because failing late in the game is expensive. I racked up over $120,000 in student loans in my doctoral program; if I had recognized early on that I wasn’t going to be happy, I could have avoided that. If I had challenged myself earlier with smaller risks, I might have predicted that academia wasn’t for me. Hindsight is amazingly clear; in the thick of it, however, I’ve learned that it’s best to take small risks when possible, and fail often. Failing at something gives you two choices: you challenge yourself to try something different and succeed in the future, or you curl up in a ball and “accept your limitations”. It’s easier to bounce back when the consequences of the failure are small.

Summary

I’m no guru; I’m just a guy trying to figure it all out just like you. I’ve gone on to have other epic failures, as well as some incredible successes. I will say that my own personal journey has resonated with my perspectives on software and service development recently. Below are some great reads about failure.

Successful Failure

Fail Fast and Fail Hard

Blameless post mortems – strategies for success

5 #DevOps Books I plan to finish this year

New Year.  Resolutions, etc. 🙂

I’m notoriously bad about starting a book and never finishing it, particularly when it’s a technical book.  My goal this year is to finish the following 5 books:

The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations

Gene Kim is perhaps best known for his novel “The Phoenix Project”, which lays out the fundamental precepts for DevOps.  The Handbook (by Kim, Patrick Debois, John Willis, and Jez Humble) gets great reviews, and I think it does a good job of translating theory into practice.  I’ve only finished about a third of it, so I’ve still got a lot of reading left to do, but I hope to finish it soon.

Site Reliability Engineering: How Google Runs Production Systems

This one might be a little easier to cheat on my goal; I’ve already read most of it.  It’s a collection of papers written by various SRE’s within Google, and gives some great insights into their vision of applying developmental principles to operation problems.  While it could be argued that the SRE model is distinct from DevOps, there’s enough overlap that it makes sense to apply these techniques to my DevOps study.

Level Up Your Life: How to Unlock Adventure and Happiness by Becoming the Hero of Your Own Story

This one’s a bit of a stretch for most DevOps folks, but if you think of it an approach to personal continual improvements, then it makes sense why this book belongs in a DevOps collection.  I started reading this one last year, and quickly off the bandwagon.  My goal is to try and finish it by the middle of the year, and hopefully begin to apply some of the principles to my personal and professional challenges.

The Art of Capacity Planning: Scaling Web Resources in the Cloud

I heard John Willis at DevOpsDays Nashville this year, and he recommended following and reading John Allspaw (among other people); the second edition of this book is coming out this year, so I’ll probably wait till it arrives.  While I don’t do much with either web or cloud development, the principles of scaling is relevant to all kinds of applications.

Team of Teams: New Rules of Engagement for a Complex World

Damon Edwards actually recommended this book during a webcast I saw a couple of months ago, and while it’s not a technical book, it speaks to the art of transforming a large, complex organization with entrenched policies into a nimble, responsive team.  Brownfield to greenfield (with military references).

Where’s your slack?

I’ve been rereading the book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency recently.  As I alluded to in my last post, my life has been rough for the last few months.  My nephew’s passing took the wind out of an already saggy sail; I’ve spent a great deal of time just trying to balance work, family, and life in general.  Some people turn to counselors; I turn to project management books.

The premise of the book is that change requires free time, and that free time (slack) is the natural enemy of efficiency.  This is a good thing; if you are 100% efficient, you have no room to affect change.  Zero change means zero growth.  I’ve been a proponent of slack for a while (less successfully than I’d like); it makes sense to allow people some down time to grow.  Just to be clear, slack isn’t wasted time; it’s an investment in growth.  Slack tasks include:

  • Research into interesting projects.  Lab work allows you to experience the unexpected, which gives you time to prepare for the unexpected in production
  • Building relationships. Teams are built on trust, and trust is earned through building relationships.  Teams that like each other are more likely to be successful when it comes to problem solving.
  • Shadow training.  Allow team members to work in other teams for a while; learn how the rest of the company operates.

In short, slack is necessary in order to promote growth; if you want your organization to stay ahead of it’s competition, cutting resources in the name of efficiency is sure-fire plan for losing.  The best advice for slack time is the 80/20 rule; run your team at 80% capacity, and leave 20% for slack.  In the case of emergency, slack time can be temporarily alleviated, but it’s the responsibility of management to return to normal work levels as soon as possible.

So what does this mean for me personally?  In the name of efficiency, I let slack time go.  I work a full time job, a couple of different consulting gigs, act as a chapter leader for AtlantaMDF, and am an active father.  I have no hobbies, and suck at exercise.  I love to travel, but trips are planning exercises in and of themselves.  In short, I have zero slack to deal with emergencies.  When something goes wrong and time gets compromised, I immediately feel guilty because I’ve robbed Peter to pay Paul in terms of time.  That’s not living,

I’m done with that.

Change is incremental, so I’m not planning on upsetting the apple cart just yet, but I am trying to figure out ways to make my slack time more of a recharge time.  Don’t get me wrong; I waste time.  I sit and stare at Facebook like the rest of the modern world; I binge on Netflix when new series drop.  That’s not slack, and it doesn’t recharge me. Slack is using free time to grow, to change.  My goal is to find an hour a week for growth-promoting free time.  I’ll let you know how I’m doing.

 

R.I.P. Cristian Charles Hammons – 1/12/1994 – 12/1/2015

12509403_10153830404628104_6803017885983941827_n

I’ve been reluctant to write this post for a couple of months now, in part because I don’t usually use this forum for posting personal stuff, and in part because I didn’t know what to say.  I’ve got another post in mind, however, and I felt like I needed to give this topic the respect it needed before I could pick up where I left off.  Bear with me.

On December 1, 2015, my nephew took his own life.

No matter how many ways I tried to write that previous sentence, none of them seemed to adequately capture what I’m thinking or want to say, so I’ll leave it alone and try to finish this post.  Cris was a smart, funny, kind young man with whom I didn’t spend near enough time as he grew up; I really only got to know him over Facebook as an adult, and I loved him.

He had battled depression for years, and he lost the war.  He left behind a grieving fiance, a set of in-laws who loved him very much, his mother (my sister),  grandparents, great-aunts, great-uncles; all of us were shocked, and I didn’t realize how much I would miss him.

Family is important, y’all.  Don’t miss out, and don’t let anything keep you from loving yours.

Me and Cris, circa 1995

Me and Cris, circa 1995

Coding naked.

Me, circa 1992. This is not the most embarrassing picture of that time period.

Me, circa 1992. This is not the most embarrassing picture of me from that time period.

True story: when I was in college, I was the lead singer (if you can call it that) for a goth rock Christian rave band called Sandi’s Nightmare.  I had zero musical talent, and relied solely on the strengths of my band-mate (Brad; you still rock); however, while my singing ability was dubious at best, I was pretty theatrical.  We had a total of 3 awesome shows before we moved on to other things, but it was a lot of fun while it lasted.  Our biggest hit was a cover of Lust Control’s Dancing Naked, a fantastic little number about David’s celebration of the ark returning; his passion and excitement overwhelmed his embarrassment.

I promise, I’m not making this stuff up; it was pretty edgy for the Bible belt of  Northeast Louisiana in the early 90’s.  I mean, I had an earring and everything.   The point of this post (besides reveling in my musical abilities and tastes of 25 years ago) is that sometimes we just need to be naked.

Let me explain; I made choices that in hindsight are difficult to defend (like my haircut). However, there was a reason for the choice at the time, and even though it may not have been the greatest idea, I’ve learned something from every experience I had.  While there are things that I would do differently if given the choice and knowledge I have today, I don’t regret many things.  That’s what the metaphor of nakedness is all about; being open and honest about not only your successes, but your choices along the way.  You can’t change the past, but you can learn from it.

Becoming a Naked Developer

I’ve spent most of my professional career as a SQL developer working for one company (13 years in November);  I was the first developer hired by that company, and my job was to build an integration platform transforming syslog data into reports, all on a shoestring budget.  I strung something together in a couple of weeks, and in the first month, I took a process that normally took two weeks to do by hand down to a day; my boss threatened to kiss me (I was flattered, but declined).

Was it pretty (the code, not the boss)?  No.  Was it successful?  Yes.

Fast forward a couple of years to 2004: I’m a member of small team building a solution to analyze more data than I’ve ever seen in my life (terabytes of data from firewalls and Windows machines); we had to import and semantically normalize data in near-real-time.  We built a solution using DTS, and then moved it to .NET and MSMQ.

Was it pretty? No.  Was it successful?  Yes.  Part of that code is still being used today, and my company has thrived off of it.  We were acquired by a larger company 8 years ago, and we’ve kept moving forward.

Every few years, we’d talk about doing a rewrite, and we’d bring in some outside expertise to evaluate what we’ve done and help us come up with a migration plan.  Some consultant would come in, look at what we did, and shake their heads at us.  Each time, we (the remaining original developers) would attend meeting after meeting as our code was dissected and judged; we sat naked (metaphorically) in front of a team of experts who told us everything that was wrong with the choices that we made.  At the end of each visit, we’d regroup and complain about the agony of judgement. In all honesty, we would have done things differently, given our current experience (and modern technology).  However, the simple truth is: we won the day.  We continue to win the day.

During some of these initial code reviews, the consultants were jerks.  They’d spend a lot of time bemoaning how horrid everything was; I’d be embarrassed and try to explain what I would have done differently if only I had the time.  The consultants would eventually propose some complex solution that would cost hundreds of thousands of dollars to implement.  Our company would consider the offer, stick it in a file somewhere, and we’d keep on keeping on.   Clunky code that works is better than expensive code with the same outcome.

Over time, I learned to live with the embarrassment (as you can tell from this post); I started listening to what the consultants would say and could quickly figure out which ones had good advice, and which ones were there to just be seagulls.  People that focused on solving the immediate problems were much easier to talk to than the people who wanted to rip out everything and start over.  Don’t get me wrong; sometimes you need to start over, but there is  a cost associated with that decision.  It’s usually much easier to start where you are, rather than trying to reinvent the wheel.

What’s my point?

First and foremost, don’t dwell on your past mistakes.  If you can honestly say that you built something that worked within the constraints of the time period, no matter how clunky or silly it seems now, then it was the right decision.  Working software works.  Laugh at it, learn from it, and let it go; repair what you can, when you can, but keep moving forward.

Second, learn to code naked.  Whatever it is that you’re trying to do at the moment, share it.  Open yourself up to code review, to criticism; exposure brings experience.  Granted, you’ll meet some seagulls along the way, but eventually, you’ll figure out who’s there to help you grow as a developer.  Foster those relationships.

Third, encourage people to grow; recognize that the same grace you desire for your coding mistakes is applicable to others as well.  Be kind, be gentle, but be honest; seek to understand why they made the design choices they did, and be sensitive to the fact that if it works, it works.  Sometimes we get caught up on trying to figure out the right way to do something, and ultimately end up doing nothing because it’s too difficult to implement it according to the textbook.

Life is too short to not enjoy what you do; try to share that joy without embarrassment.

THIS is the most embarrassing picture of me from that time period.  I thought being an actor was the best way to meet girls… Yes, those are tights I am wearing…

 

 

 

2014 Year In Review

Finally finding some time to sit down and write this post; of course I’m squeezing it in after work, and before my wife and son come home, so there’s no telling how far I’ll get. This post is probably best treated as a stream of consciousness effort, rather than my usual agonizing over every word. 2014 was a mixed bag of a year; lots of good stuff, and lots of not-so-good stuff; I’ll try to start with the good:

2014 Professional Highs

As I’ve mentioned before, I was promoted to management in my day job a few years ago; in October of 2014, my kingdom expanded. Instead of managing a team of SQL Server DBA’s, my department was consolidated with another small group, and I now manage the IT infrastructure for our Product Group. It’s not a huge jump, but it is an opportunity for me to get involved with more than just SQL Server and databases; I’m now managing a team of sysadmins as well, so I’m getting a crash course on virtualization, server administration, and networking. It’s been fun, but a bit challenging.

I haven’t neglected my SQL Server roots, however; I presented to over a dozen user groups & SQL Saturdays last year (which is a lot for full-time desk jockey). I ultimately delivered two killer presentations at Summit in November, which boosted my confidence tremendously after 2013’s less-than-stellar performance. Blogging was steady for me (23 posts on my blog), but I did have a chance to write a piece on Pinal Dave’s blog (Journey to SQL Authority); that was a great opportunity, and one I hope to explore more. In addition to blogging and community activity, I also finally passed the second test in the MCSA: SQL Server 2012 series (Administration; 70-462). I’m studying for the last test (Data Warehouse; 70-463), and then I need to start getting some virtualization certs under my belt.

Finally, a big professional step forward for me was that I became a Linchpin (part-time); I’ve had a great deal of respect for this team of SQL Server professionals over the years, and I was very blessed to be able to step in and help on a few projects this year. I’m hoping for more. It’s a great way to test the waters, even if I’m not ready to dive into full-time consulting yet.

2014 Professional Lows

I got nominated for Microsoft MVP (twice); I didn’t get it (twice).

 

2014 Personal Highs

Big year for travel for my wife and I; we went to Jamaica and Vancouver, as well as Nashville, Chattanooga, St. Louis, Charlotte, Seattle, Hilton Head, Myrtle Beach, and Ponte Vedra. We saw two killer shows: George Strait and Fleetwood Mac; I also got to see one of my favorite bands, The Old 97’s. Our son turned a year old, and it’s been a lot of fun watching him grown and discover new things. 2014 was a year of joy in a lot of ways….

2014 Personal Lows

2014 was also a year of sorrow for me; if you follow me on Facebook, you know how proud I am of my son. What became less well-known is that I have two teenage daughters from my previous marriage; they turned 17 and 15 this year. In September of 2013, my daughters decided that they didn’t want to spend as much time with me and their stepmother. Over the last year, I’ve had to come to terms with the fact that my daughters aren’t planning on changing that any time soon, and they have no desire to have a relationship with their brother. That’s a pain that I’ll never get over; I love all of my children, and all I can do is pray that someday things will change. The only reason I feel compelled to mention it publically is that I don’t want them to become invisible; I have three children, even if I don’t get to see two of them very often. I also feel like I’ve reached a turning point; I was VERY depressed last year because of this situation, and I’m ready to move forward in 2015.

 

Summary

2014 was more good than bad, but I’m looking forward to 2015. I’ve always believed that you should play the hand you’re dealt, and make the most of it. Life is good, and it’s only getting better.

 

 

 

my amazing life

I don’t often talk about personal stuff on this blog (it’s CODEgumbo; not LIFEgumbo), but a lot’s happened in the last few weeks, so I thought I’d share a bit.  Besides, I was on a roll for blogging for a bit there, and then suddenly stopped; I figured I should at least attempt to explain what happened Smile.  So let me explain in chronological order (with a few flashbacks) what’s been going on with me lately.

I’m a dad, again….

Evan Stuart Ainsworth was born on June 25, 2013.  It’s been 14 years since I’ve had a baby in the house, so it’s a complete reboot.  I’ve been totally unprepared for the joys and trials of having a baby; I kept thinking it was going to be easy, but I guess I forgot how worn out you feel all the time, and I’m just the dad.  I don’t understand the sheer strength my wife has; the kid eats all the time.  And when he’s not eating, he’s either happy or mad; my nickname for him is the Hulk (“don’t make me angry”).

Before I go too much further with the story of Evan’s arrival, I should pause for a second and say how grateful I am for my two daughters (Isabel, 16, and Grace, 14); their world just got a little weirder, and they’ve stepped in and accepted it reasonably well.  Blended families are tough, and I appreciate them for trying to balance their relationship with me, their stepmother, and their new little brother, as well as building a relationship with their mom (and her new family).

Anyway, while the birth of any kid is big life change, Evan is special.  He was actually supposed to be an induced birth, so we were at the hospital when labor started.  Betsy (my wife) was all hooked up to monitors, and labor was progressing when things went awry; during some of the contractions, Betsy suffered a condition known as a placental abruption, and Evan went into shock in utero.  Within minutes, Betsy underwent an emergency C-section, and Evan was out within 15-30 minutes of the incident.

Betsy and I spent two weeks hanging out at the NICU, waiting on our little boy to get well; it wasn’t comfortable.  Lots of stress, nowhere to really go, and too little time in between feedings for either of us to leave.  Thankfully, Evan’s condition was relatively minor compared to many babies that spend time in the NICU, but it was still scary.  When I say my prayers, I give thanks for the doctors and midwives at the hospital; without them, I don’t think either Betsy or Evan would be home with me today.  After I give thanks, I then turn my thoughts toward the parents and families of children in the NICU.

I say all of this to explain that even while it’s tough coping to a new baby, I just laugh when I hear him cry.  Life is a blessing, even in the everyday struggles.

I survived another trip around the sun

As of July 5, 2013, I am now twice-21.  I’m a little slower, a little grayer, and happier than I’ve ever been.  42 is a lot more awesome than I thought it would be when I was 21.  Besides, kids are supposed to keep you young, and if I keep having them, I should live forever.

I celebrated a second year of marriage

While I don’t share a lot about my personal life on my blog, I REALLY don’t talk a lot about my wife.   As I pointed out above, this is my second marriage; my ex-wife and I separated in November 2009 after 14 years of marriage.  If you go back and search older posts on here, you’ll find a few references to my original marriage scattered about; I try not to dwell on them too much, because I don’t really want to revisit those feelings.  Let me just say that I spent a lot of my adult life trying to be happy and make someone love me, and I was only marginally successful.

After my divorce was final, I dated a few women and thought I would enjoy being single. And then I met Betsy.  My wife is an amazing woman, and I don’t think I tell her that often enough.  She loves me for being me, and its easy to love her.  I’m happy every day; love is easy with the right person.  At times it seems as though I just met her a week ago; at times, it seems as though life began when I met her.  Enough mushy stuff by me; sing along with the Proclaimers.  It’ll make you feel good.

And now back to our show

Hopefully, I’ll get back on track with technical blogging now that I’ve had some time to adjust to all the recent life events.  Thanks for reading.