Stuart Ainsworth

#NeverStopLearning: 10 Minutes of code

Today, I spent 10 minutes working on PowerShell. I’ve never really spent much time in PowerShell before. I’ve had a few classes a few years ago, but like most things, if you don’t use it, you lose it.  I was going to do a Pluralsight course, but frankly, I haven’t been great about following up on these sorts of things, so I figured I’d start with the completely free (no trial expiration) knowledge at the MS Docs site

I knew most of this stuff, but the point of this exercise is to force myself to start using again.  I spent a few minutes running the ISE, using Get-Help (and updating the help files), and then thought I’d try a quick script.  Like most coders, I stole this from the web:

Get-ChildItem | Where-Object {$_.LastWriteTime -gt (Get-Date).AddDays(-180)}

This simple script helped me find the files and folders in my user directory (the current context) that were modified within the last 180 days.  To limit the results to files only, I added an additional clause to the filter:

Get-ChildItem | Where-Object {$_.LastWriteTime -gt (Get-Date).AddDays(-180) -and ! $_.PsIsContainer }

I think I can do this.  More to come.

Fix More, Whine Less

I get paralyzed by the thought of NOT doing something correct, so I end up doing nothing. I’ve got to work on that. A three sentence blog post is better than no blog post. Fixing one tiny recurring error is better than just watching the logs fill up. It may be a lost cause, or it may be a moment of hope; whatever.

Just fix something. Something small. A lot of small somethings can make a big something.

My one true #DevOps statement…

After my last post, Brent Ozar offered the following suggestion on kickstarting my thoughts on “People First”

” Come up with the one true sentence, and the inspiration flows out of that. Sometimes you hang the entire post on that one sentence, and sometimes the sentence just ends up slipped in somewhere almost as an aside. “

I mulled over it over the weekend (in between basketball games, date nights, and family technical support), and below is the best I could come up with. I think it’s a useful exercise, and I’m going to focus my energy today on expanding this thought:

The primary purpose of software development is to add value to humanity; however, most software development processes dehumanize the creators.

More to come. And, thanks, Brent! I owe you yet another beer.

Writing is hard…

I’ve recently started working on a book, and have rediscovered that if you don’t exercise on a regular basis, it sucks to start. I need to think of this blog as an opportunity to get my regular writing “steps in”, so that when the time comes to actually start running, I’m ready.

One of the challenges I’m having is articulating my thoughts on the concept of “people first” in DevOps. It’s the first element in Donovan Brown’s definition, and embedded in the first value of the agile manifesto, but yet, people don’t get it. I was recently involved in a Facebook conversation on the evolution of graph databases, and was saddened by the fact that many people who I know and respect still see an ongoing war between developers and DBA’s (and often make assumptions about the other camp).

I may be naive, but I’m trying to find the good in people, and trying to build value to customers. Different roles and skills are necessary, but allowing those roles to foster tribalism to the detriment of the goal is a futile pursuit.

More to come.

To be a #DevOps Leader…

…you have to do less work, and do more to improve work.

I know, it’s been said 1000 different ways already, but it sunk in this week as I struggled to put out the bazillionth little forest fire that had crept up after our last deployment.  It’s so easy to get back in the rhythm of doing whatever it takes to keep the system stable, even if it means sacrificing time with family, projects you want to make headway, general health and well-being… IT work is built on the backs of heroes.

But it isn’t sustainable.  I look back over the last month and wonder what the hell it is I accomplished.  My team is worn out; I’m worn out.  We managed to squeak in a major project, but we had to drop the ball on 100 other little things to get it done.  And, to rub salt in the wound, the new project added new work to the backlog, which just means that we may have won the battle, but it’s an expensive win.

My job as a leader is to make sure people know how much wins like that cost; not to discourage them from trying to make a win, but to make better strategic decisions so that we don’t sacrifice something important in order to get some other important thing done.

Monday’s coming, and I’m going to start over. Again.  And i”m going to keep starting over until things get better.

#DOES18 – Wednesday Takeaways

Last day of the DevOps Enterprise Summit 2018, and I had a few aha! moments that really clicked for me.

  1. Jon Hall’s presentation on swarming was a great practical explanation on how to manage swarms.  My team needs to be more available to Tier 1 and Tier 2 to swarm on issues and resolve them.  It’s not quite the same model as the model Jon presented, but it’s a step.
  2. As an organization, we don’t need a plan so much as we need a set of common principles: commitment to communicate (make work visible to teams, management, customers… etc.), and commitment to best practices in development (SOA, Agile, product not project, etc.).  That’s the first step; once we’ve identified those principles, then there needs to be an establishment of processes that reflect those principles.
  3. Uncertainty is good.  We don’t need to stay in a particular mode in so much as we need to find the problem and solve quickly.

Keynotes are up, if you want to check them out.  Great stuff in there.

#DOES18 – Tuesday Takeaways

Thoughts from yesterday’s DevOps Enterprise Summit in Las Vegas

  1. Managing workflow is different than managing configuration changes or code.  It’s related, but you can have separate systems for individual team’s processes and procedures (i.e., Azure DevOps for developers, ServiceNow for ops), but you want to make work visible to all affected teams.
  2. Making work visible was a theme I heard over and over again; so much of the “throw it over the wall” mentality stems from the fact that ops does magic. 
  3. Processes are necessary, but they must be as light as possible or they won’t meet the need (they get in the way of rapid response).  People often adapt by ditching the process anyway.

#DOES18 – Monday Takeaways

This is a quick post; I meant to get this pulled together last night, but hey, I’m in Vegas.  There were things to do, so I’m hammering it out before the morning sessions start.  As always, this is a fantastic conference; it really shifts the focus away from specific technological solutions to understanding why technology is important to delivering business value.  In no specific order, here are my key takeaways from yesterday:

  1. I need to do a better job of articulating my vision, and asking my boss (and his boss) to do the same.  What’s the message we want to send to our employees?  To our clients?  To our competition?
  2. Minimum Viable Compliance – we are so process-heavy; how do we convince governance to help us do the right thing, but do it in such a way that it reduces the strain on the system?  Governance as a Service.
  3. Return to our roots- build a service catalog, and use it to describe architecture.  Every single component of the value stream (ideally) should be captured, and used like Lego blocks to define service delivery.
  4. Reliability Engineering needs to be visible.  Keep measurement and reporting simple; start with a rubric, and a pass/fail mentality.  Dedicate time to toil reduction as a team, not as individuals.

Lots more to come, but wanted to get these notes out the door.

TIL from Atlanta #AzureDataFest

AZURE DATAFEST

I’ve been meaning to write this post since we wrapped up the event, but life, as usual, gets in the way.  Overall, I was very pleased with the whole event; things (for the most part) ran very smoothly.  However, in the spirit of continuous learning, here’s a few lessons (in no particular order) for anyone considering hosting an Azure DataFest in the future. 

Event Management

We used Sessionize and EventBrite to handle speaker submissions, schedule building, and attendee management.  Both tools worked great, but both are a little pricey (Sessionize charges $250 for the event, and EventBrite added a $3.54 fee to every ticket sold).  The benefit is that it was very easy to generate a professional looking schedule, review abstracts, and manage attendees (from fee collection to attendance rosters).  The one downside is that the tools don’t integrate (no way to easily export speakers into Eventbrite), and we really need a central website for people to hit rather than each individual tool.  I also had a small issue where some attendee badges didn’t print; that was probably user error.

Sponsor Expectations

  • I should have added company names to each attendee badge to make it easier for them to see what company attendees were from when talking.
  • I need to explain the email\contact information privacy policies better.  Some sponsors wanted to get more contacts to add to their mailing list.  May need to borrow a page from the SQLSaturday playbook and encourage raffles to get information directly from the attendees.
  • Microsoft SSP’s were on site, and that was a very valuable contribution.  Saw lots of hallway conversations with clients and Microsoft; that’s rare for SQLSaturdays.
  • Need to charge more for sponsorships in general; we had a flat rate of $500, which doesn’t go a long way toward building a community.  Also, I need to provide more structure over what’s included in a sponsorship; we had a couple of sponsors which had 5 or 6 team members show up.  Since food was included in their sponsorship, that literally ate up most of the profit from their sponsorship.
  • Need to find ways to encourage relationships between speakers and sponsors; speaker dinners or vendor parties?

Attendee Management

  • Generally, went well.  Food portions were about right, fee was right for a two day affair, and we had very few snacks and\or drinks left over.
  • Would love to go as paperless as possible; however, I think people like having SWAG bags.  Maybe provide them with an empty bag, and tell them SWAG is available at sponsor tables?
  • Stickers were a HIT!
  • Very different crowd than a SQLSaturday.  In fact, during opening session, only a few people had heard of SQLSaturday or AtlantaMDF.  Need to do a better job of evangelizing both of those, while recognizing that this is a crowd that may not want to give up their weekend.
  • Pretty sizable fall-off on Friday (the second day).  May need to do Monday-Tuesday to see if we do a better job of retaining folks.

Speaker Management

  • As noted above, Sessionize worked great for speaker management.  Abstracts were easy to receive and review, and building a schedule was a snap.
  • Need to be more up-front about the volunteer nature of this conference.  We had a few people that misunderstood, and submitted from abroad, and then inquired about travel reimbursement.  It was cleared up over a few emails, but I should have headed that conversation off earlier.
  • I had a speaker withdraw because we charged $50 to attend the two-day conference;  they felt that didn’t fit as a “community” event, since most community events should be free to the consumer (or offer an optional lunch, like SQLSaturday does).  I get the point, but in practical terms, that’s tough to do with a new event.  No event is free; just different people (sponsors) pick up the tab.  We’ll continue to work on this, but ADF may always have a small fee associated with it.
  • Most sessions had speakers sitting in the audience.  I haven’t seen that happen at SQLSaturday’s in a long time, so I’m hoping that people learned as much as they gave.

Logistics

  • Facility was great, but room capacity != seating arrangement.  I had to steal chairs from sponsors, and actually order more chairs on the first day to eliminate standing room only.
  • I loved having the plenary (everybody in one room) sessions at the start; really need to do one at the end, and then do a wrapup.
  • I could have saved some funds on table linens.  The caterer brought their own, and they weren’t really necessary for the check in tables.
  • We had a few technical glitches, so we need to make sure we keep the facility staff around next year.  They went to lunch and weren’t back in time for the afternoon session, so those were a little rough (maybe promise them free lunch next year?).

Look Mom, I’m famous….

Well, moderately well-known 😛

I had the pleasure of being a guest on Andy Leonard and Frank LaVigne‘s podcast, Data Driven.  I was originally going to talk about #SQLFamily, Azure DataFest, and community life in general, but the topic quickly changed in light of the Azure outage on the day we recorded it (9/4/2018).  So we rambled on, joked a lot, threw in some 80’s pop culture references, and generally had a good time. Give it a listen on your favorite podcasting app.

Hopefully this will inspire me to find time to write more.  We touched on a lot of ideas, but didn’t really dive very deeply into any of them.  I need to stop DOING, and WRITE IT DOWN (that’s a variant of the advice I give my team).