Development

#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

2017-06-08 by Professional Development SQLServerPedia Syndication 1

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).
2017-01-11 by Book Reviews Professional Development SQLServerPedia Syndication 0

#DevDataBhm inaugural event

I’m presenting today at DevDataDay in Birmingham.  First time in a while for me, but I’m excited about the opportunity to go to sessions again and learn something (more on that in a bit).  I realize this blog has been a bit dusty for a while, but I’m gonna try to do better about that.

TOPIC:   Theory of Cloud Database Administration
SPEAKER: Stuart Ainsworth
ABSTRACT: The cloud is more than just a marketing term; it’s a model for designing scalable, distributed systems and assigning ownership to various components of those systems.  Data is a crucial part of that model, and there are lots of challenges ahead.  This presentation will explore the history of cloud computing, the current state of data in the cloud (using SQL Server 2016), and the impact on career choices for data people.

2016-08-20 by Conferences SQL 0

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…

 

 

 

2015-10-08 by Code Good Habits Professional Development SQLServerPedia Syndication 3

Agile Perspectives: Fixed or Variable Length Iterations

Got into a deep discussion with a colleague tonight over different approaches to Agile development (yes, I’m a geek; why do you ask?).  I’m a Fixed Length Iteration kind of guy, particularly since I’ve spent most of time on the Operational side of the house recently.  He’s a Variable Length Iteration fan, and I thought the arguments on both sides of the fence were compelling enough that I wanted to blog about them.

Really, I’m doing this for my adoring fans.

Actually, I’m doing this because I feel guilty about not blogging, and thought this was at least SOMETHING to warrant paying for a domain year after year.

Anyway, here’s the breakdown of the two arguments; let me start by spelling out some common assumptions.  I’m assuming that you’re reading this because you have some interest in development, and more specifically, some interest in agile development.  If you have those interests, then I’m also assuming that you know what an iteration is.  If not, the hyperlinks in the previous statements should help educate you and steer you clear away from this blog to more fascinating subjects.

The Argument for a Fixed Length Iteration

There’s a couple different versions of the Fixed Length Iteration, based on either a calendar (January, February, etc.) or a cycle (every four weeks); the goal is to commit to a ship date, and stick to it time after time.  I’m more of a fan of a calendar-based Fixed Length Iteration; the actual length of the iteration varies (February is short), but development is consistently wrapping up every month, and every month code is being shipped out the door.  My reasons for supporting this model are as follows:

  1. People are cyclical creatures. We live from paycheck to paycheck; we hate Mondays and work for the weekend.  Having a fixed length cycle (with some minor variation if you based that cycle on a calendar) helps in estimating and planning what gets done and when.
  2. A fixed cycle forces developers to think in terms of components. If you’re expected to ship working code at the end of each month, you start writing code that is bite-size, so that you can leave out pieces that aren’t finished (rather than waiting until the whole thing is done).  Bite-sized code is easier to test and deploy with reduced risk.
  3. A fixed cycle means that it’s easy to change directions without stopping development efforts. Sometimes business priorities change; a fixed length cycle allows developers to continue moving forward until the end of the iteration and change gears there.  The start of a new iteration is never far away, so most businesses can wait until the next month rather than waiting till an unknown end of a sprint.

The Argument for a Variable Length Iteration

I’m trying to give this perspective a fair shake, even though I don’t subscribe to it; in a variable length iteration model allows business and development to scope out work at the beginning of an iteration and estimate a ship date regardless of the cycle or the calendar; the goal is to allow code to mature and be more stable.  My friend subscribes to this model because:

  1. Variable length iterations resemble traditional projects. There’s a scope estimate, requirements gathering, and work estimates (and traditional slippage).  Most agile purists immediately scream “WATERFALL”, and there’s some truth to that, but a variable length iteration is comfortable to business.  It’s like Mr. Roger’s house shoes.
  2. They lend themselves to continual shipment of code. If the iterations are variable, developers can focus on one task from start to end, and begin to operate on separate iterative cycles; if you have a development staff of 5, you could theoretically have up to 5 separate iterations going on at the same time; when a developer finishes, they ship their contribution without waiting on the sprint to end.
  3. This fragmentation of the iteration allows for sudden, non-disruptive change. If there are multiple iterations occurring for each independent block of code, and business needs change for one line, then only that line has to shift gears.  There’s no impetus to wait; you stop where you are on the one piece, and move on to the next piece.

Your Choice?

I’d love feedback on this; as I’ve stated from the outset, I’m a fixed length iteration guy.  What did I miss?  Are there other benefits to the Variable Length model that I’m missing?

2015-08-11 by Blogging is FUN! Development SQLServerPedia Syndication 5

#SQLServer – Where does my index live?

Today, I got asked by one of my DBA’s about a recently deployed database that seemed to have a lot of filegroups with only a few tables.  He wanted to verify that one of the tables was correctly partition-aligned, as well as learn where all of the indexes for these tables were stored.  After a quick search of the Internets, I was able to fashion the following script to help.  The script below will find every index on every user table in a database, and then determine if it’s partitioned or not.  If it’s partitioned, the scheme name is returned; if not, the filegroup name.  The final column provides an XML list of filegroups (because schemes can span multiple filegroups) and file locations (because filegroups can span multiple files).

 WITH C AS ( SELECT ps.data_space_id
, f.name
, d.physical_name
FROM sys.filegroups f
JOIN sys.database_files d ON d.data_space_id = f.data_space_id
JOIN sys.destination_data_spaces dds ON dds.data_space_id = f.data_space_id
JOIN sys.partition_schemes ps ON ps.data_space_id = dds.partition_scheme_id
UNION
SELECT f.data_space_id
, f.name
, d.physical_name
FROM sys.filegroups f
JOIN sys.database_files d ON d.data_space_id = f.data_space_id
)
SELECT [ObjectName] = OBJECT_NAME(i.[object_id])
, [IndexID] = i.[index_id]
, [IndexName] = i.[name]
, [IndexType] = i.[type_desc]
, [Partitioned] = CASE WHEN ps.data_space_id IS NULL THEN 'No'
ELSE 'Yes'
END
, [StorageName] = ISNULL(ps.name, f.name)
, [FileGroupPaths] = CAST(( SELECT name AS "FileGroup"
, physical_name AS "DatabaseFile"
FROM C
WHERE i.data_space_id = c.data_space_id
FOR
XML PATH('')
) AS XML)
FROM [sys].[indexes] i
LEFT JOIN sys.partition_schemes ps ON ps.data_space_id = i.data_space_id
LEFT JOIN sys.filegroups f ON f.data_space_id = i.data_space_id
WHERE OBJECTPROPERTY(i.[object_id], 'IsUserTable') = 1
ORDER BY [ObjectName], [IndexName]
2014-08-14 by Code SQL SQL Server SQLServerPedia Syndication XML 0

Managing a Technical Team: Act Like a Good Developer

This is one of my favorite pieces of advice from my Managing a Technical Team presentation that I’ve been doing at several SQLSaturdays and other conferences: act like a good developer, with a different focus.  Most new managers, especially if they’ve been promoted from within (the Best Operator) model don’t know how to improve their management skills.  However, if you were to ask managers what makes a good developer, you’ll probably get a series of answers that are similar to the following broad categories:

Good Developers have:

  • a desire to learn,
  • a desire to collaborate, and
  • a desire for efficiency.

I could probably say that this is true for all good employees, but as a former developer, I know that the culture in software development places a lot of focus on these traits; system administrators usually have different focus points.  However, all technical managers SHOULD emulate these three traits in order to be effective.  Let me explain.

Desire to Learn

Let’s imagine Stacy, a C# developer in your company; by most accounts, she’s successful at her job.  She always seems to be up on the latest technology, has great ideas, and always seems to have a new tool in her toolkit.  If you ask her how she got started programming, she’d tell you that she picked it up as hobby while in college, and then figured out how to make a career out of it.  She’s an active member of her user group, and frequently spends her weekends reading and polishing her craft; while not a workaholic, she does spend a great deal of her personal time improving her skills.  She’s on a fast track to managing a team, in part because of her desire to learn.

One day, she gets promoted, and is now managing the development team; she struggles with the corporate culture, the paperwork, laying out a vision, and can’t seem to figure out how to motivate her team to the same level of success that she was achieving as a developer.  The problem is that her desire to learn no longer syncs up with her career objectives;  Stacy needs to invest her educational energies into learning about management.

Ask a new IT manager what books they’re reading, and typically the response will be either none at all, or a book on the latest technology.  We tend to cling to that which is familiar, and if you’ve got a technical background, it’s easy and interesting to try and keep focusing on that background.  However, if you’re serious about being a manager, you need to commit to applying the same desire to learn that you had as an employee to learning more about management.  Sure, pick up a book on Big Data, but balance it out with a book on Relationship Development.  Podcasts?  There’s management ones out there that are just as fun as the development ones.  Webinars? Boom.

Desire to Collaborate

Bob’s a data architect.  Everybody loves Bob, because he really listens to your concerns, and tries to design solutions that meet those concerns; if he’s wrong about something, he’s quick to own up to the mistake, and moves on.  He works well with others, acknowledging their contributions and adapting to them.  In short, Bob is NOT a jerk; nobody wants to work with a jerk.

Bob gets promoted to a management position, and he too struggles; he’s still hanging out with his former teammates, and is still going to the same conferences.  Everybody still likes Bob, but he’s having trouble guiding his team in an effective manner.  He hasn’t really built relationships with his new peers (other managers that report to his director), and hasn’t found ways to manage more effectively.  He’s collaborating, but with the wrong people.

As a new manager, you should continue to maintain relationships with your directs, but you need to build a relationship with your new team of peers.  Understand their visions, and find ways to make your team valuable resources to them. Reach out to other managers at user groups and conferences; build a buddy system of people based on your management path, not just your technical one.

Desire for Efficiency

If you sat down and had a conversation with any development team that was effective and producing results and asked them about their methodology, it wouldn’t be long before they started talking about frameworks.  Efficiency in development is derived from reusable patterns and approaches to problems; they’re tough to implement at first, but the long term gain is enormous.

As you’ve probably guessed, there’s management frameworks that can be very effective in a technical environment; investing time in implementing them can yield great efficiencies when faced with making decisions.  In my current environment, I use three:

  1. MARS – my own self-rolled approach to system operations; it’s not perfect, but it helps focus efforts.
  2. Kanban – allows me to see what our WIP (Work In Progress) is, and helps queue up items for work
  3. ITIL – we’re just starting to adopt this, but we’re working on isolating Incident Management from root cause analysis, as well as implementing robust change control processes.

The challenge with management frameworks is similar to that of development frameworks: bloat.  It’s too easy to get bound up in process and procedures when lighter touches can be used, but in most cases, the efficiency gained by having a repeatable approach to decisions allows you to respond quickly to a changing environment.

Summary

Management is tough, but it’s especially tough if you continue to focus on your technical chops as opposed to your leadership abilities.  Act like a good developer, and apply those same basic principles to your team.

2014-08-04 by Professional Development SQLServerPedia Syndication 0