I’m not in a management position, myself, but lately I’ve been taking the lead in more and more initiatives. Nearly all of my existing experience being from the perspective of an individual contributor, so I had never really given much thought to what’s actually involved when moving beyond that stage.

With that in mind, I found the following three books to be quite helpful:

• Managing Humans: Biting and Humorous Tales of a Software Engineering Manager by Michael Lopp
• Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams by Mickey W. Mantle and Ron Lichty
• The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change by Camille Fournier

Managing Humans touched on a lot of topics I found quite good, especially about the importance of one-on-one’s and giving useful feedback. It grazed the surface of a lot of topics and was a tad repetitive at times, but I overlooked a lot of that once I realized (about a third of the way through) that the author was actually the author of the Rands In Repose blog, which I was a big fan of early in my career.

The Manager’s Path seems better suited for those higher up the ladder, so a lot of the content was a bit dense and way too out of scope for me… Once you reach the stage of being a manager who manage other managers, that’s just way too meta for me….

Managing the Unmanageable felt like it was somewhere between the two, as far as content and style. It didn’t feel as personalized as Lopp’s book but the writing was less distance than the one by Fournier.

Once I was done with all three, they had all sort of blended together for me. I am very glad that all of my bookmarked pages and highlighted text were saved on my Kindle for later browsing!

At this point, I still not sure being a ‘Manager’ is really my thing… but at least now I do have a bit more respect for people who do take on those roles and what they have to deal with.

One topic I did really like seeing come up in my reading was how important it is for a technical lead to continue contributing. Leads should contribute a lot less than before, but it’s still necessary. It helps keep them in touch with the code base, so it’s easier to understand the pain-points in the code. Not to mention while the lead focuses on provide an extra helping hand for squashing gnarly bugs or tackling mundane changes, the core contributors on the team can stay focused on implementing all of those new shiny features that keep them interested and engaged… I dig it.

Even though I’ve read plenty of great books centered around Agile, eXtreme Programming, etc. over the years, it’s always been difficult to view them as anything other than idealized pie-in-the-sky philosophies… something used at some magical startups or whatever, but not really anything us ‘mere mortal’ developers would ever get involved with. Even when I talk with developers at companies who publicly declare themselves as using Scrum, Agile, etc., a lot of the time the people down in the trenches mention it being a bit different…

Lately I’ve been learning a lot more about Scrum. Not so much because Scrum is inherently better than Agile… more like that’s what some projects in VSTS were already using as a template, so I figured that I had might as well make another attempt at delving into the details on it.

As much as I had expected early on to find a reason to dismiss it, there’s actually a lot in it that I love. Using the sprints to make minimum-viable products at a fairly predictable cadence sounds awesome to me and many of the features in VSTS make that very easy to do.

I was kind of surprised that the default Scrum template didn’t have a field for how long a task took (or even how long you thought it would take…) and just had a field for how much work remains. That was a bit odd. I’m a MASSIVE fan of Joel Spolsky in general, but I especially liked a post he did over a decade ago called Evidence Based Scheduling. (If you aren’t familiar with it, check it out!) While I don’t even want to consider how much time I’d need to spend on creating a similar Monte Carlo simulator for possible ship dates based on historical velocities, I do see value in tracking that information for if/when I’m ever actually able to do that sort of analysis…

I don’t work on any projects right now that actively adhere to Scrum, so a lot of this still feels a bit academic… but I think any changes I’m able to implement within existing projects that can benefit from a Scrum-like or Scrum-ish approach, it’s at least a step in the right direction. And, maybe one day I’ll get certified as a Scrum Master (though, to be honest, it strikes me a bit too much ‘fluff’ for something I’d be into).

There’s an episode of The Simpsons where Homer is being lectured about regrets he will have later down the road. Homer responds with, “That’s a problem for future Homer. Man, I don’t envy that guy!”

As odd at it may sound, I’ve found that to be a rather liberating perspective at times.

Rather than getting bogged down with analysis-paralysis, unknown-unknowns, and trying to plan every last detail before moving forward, sometimes it’s actually a lot more effective to just start moving forward and deal with those pesky ‘implementation details’ later…

Aside from occasionally needing to adjust my approach as I go, nothing is a better motivator than knowing the point of no return is long gone and just needing reach the goal…

It’s a very Zen experience — accepting the present moment’s situation and working with the current tools and knowledge available to move forward.

Maybe I just have a high risk-tolerance level, but it seems to work for me!

Over the years, I’ve really developed a love for breaking stuff…

Whether it’s a code review or blackbox testing of a third-party application, I go into it expecting there to be problems… I might not always know where they are, but I am confident they exist.

In the world of infosec, the mantra is “assume breach”. Well, I apply a similar mindset to testing — “assume bug”.

If all of the tests are pretty green “PASS” messages, I assume it’s only because the tests aren’t extensive enough or missed some edge-case scenario.

I’ll do some more posts in the future about it, but I’m going to start playing with some different testing harnesses and frameworks in the upcoming months and try to see how much I can get out of them. Until then, though, I guess I’ll just stick with my manual testing.

Another year over… and a new one on the way…

This year I was able to take a more active lead in the hiring process — everything from creating a job description from scratch all the way to creating and implementing interview questions and tests. It was a lot of fun.

There was more C# development this year, but still quite a lot of work being done in VB.NET. I’m at the point where I don’t have a huge concern whether I’m working on VB.NET or C#. It’s not the language that makes the code good or bad. I’m generally happy just as long as things seem understandable, maintainable, and don’t have the stink of being a rushed hack just to get stuff out the door.

In the upcoming year, I’d like to get more involved in the local dev community. I used to go to the various SQL Saturday events and stuff, but kind of got burnt out on them. I found a pretty nice Tampa development group on Slack that does local meetups, so I might give that a try. Always good to have others available to bounce ideas off of, swap stories with, etc.

See ya’ll in 2018!