The Power of a Great Demo

I went to school at Western Washington University and got a degree in English, with a concentration in Creative Writing. In damn near every writing class, you’d hear the same 3 words. Show, don’t tell.

Independent of writing style, a scene inspires and communicates more. A quick example:

Version 1:
Bob was hurt and furious after Marie’s “I miss you.” text. “2 months and this shit?” he thought.
Version 2:
The phone buzzed. A text. Marie: “I miss you.” Bob’s eyes watered a bit as he tapped the 3 dots, and hit ‘Block.’

I bring “Show, don’t Tell” up because, although it’s been embedded in my brain for the past ~20 years, a recent beer-night conversation with a friend (Hi Branden!) reminded me of those words. He was talking about the power of a good demo. Having tech to show off is simply more compelling than a simple conversation.

If you want to try something new, or convince someone of your idea, remember Branden and his idea. Show, don’t tell.

A developer I’ve been coaching finally executed a great demo on Angular for our weekly developer meeting. She spent nearly 3 months learning Angular. Her demo contained a soup to nuts implementation of a site, including tests, test coverage, a CI / CD pipeline deploying the site all the way to an azure site. She did this demo over the course of 45 minutes.

I was thinking about what sort of conversation it would be if she didn’t have the full demo. Maybe 5 minutes? Maybe she’d have been overruled, or even redirected to another technology.

But a full demo? She had the whole group listening.

Power Through, Part 2

As I left you in part one, I was in a pretty poor state. I was 34, 320 pounds, and I had been diagnosed with an extreme blood pressure event and congestive heart failure. Since I was still up and mobile, the doctor decided to start with drug treatments to clear out my lungs and get my blood pressure to a reasonable state.

I remember him saying that if the fluid didn’t clear on the drugs, I’d have to go in to the hospital. The fluid cleared.

I don’t remember taking a day off of work.

Early December of 2017. I was picking up Heather from her CrossFit gym. While she finished up the last of her workout, the owner of the gym approached me about a “new years new goal” thing.

For $100 bucks, I’d get daily access to the gym and a meal plan to follow for 3 months.

That gym owner had sponsored my daughters’ softball team for 3 straight years. I knew I wasn’t in the greatest shape, but I figured I owed him. So what the hell.

First thing was a meal plan date. I sat in a room with about a dozen and a half other folks talking about meal planning. Some folks were hardcore athletes, basically looking to bulk up and grow muscles. The rest were normal ‘trying to get fit’ folks. Folks that weren’t out of shape at all, but wouldn’t mind looking for a bit more than your standard “New Years Resolution.”

Then there was me and two others. We were the Bigguns. I was still over 300lbs but the other guy made me look small. He was 6’8″, and probably 360lbs. His wife made up the last of our group. Topping out at 5’4″, she was near 225lbs at least.

We had a long road.

To be continued…

Awesome Sauvignon Blancs

I’m a fan of Sauv Blancs. I drink a lot of wine from Washington, but I’ve been recently opening up my palette to New Zealand Sauv Blancs. I love a bright acidic push. I love the cool mid palette rush of New Zealand, but the dull fruit of Washington has a wonderful place.

Here are the Sauv Blanc’s I’ve been happiest with this past year.

I haven’t found a California one worth the hype yet.

Heather sitting under the Pergola, last year at Tildio.

Fidelitas Tasting Notes – 7/31

I got an email the other day advertising Fidelitas’ Canyons Malbec. I had to head in for a tasting!

2019 Red Mountain Semillon – Honeysuckle and creamy. Just a hint of acidic fruit on the finish.

2019 Optu White Blend – Gourgous and perfect for a hot day. I would have opened the tasting with it if I could have. Light floral nose. Beautifully fruity mid palate, with a hint of strawberry and peaches. Delicate finish. Outstanding stuff.

2017 Red Mountain Merlot – A standard Big Red Merlot from Washington. Lovely, but not what I was looking for that day.

2017 Optu Red Mountain Red Blend – Dark. Minerals and chocolate. A hint of plum on the finish. I felt a bit silly sitting outside on an 85 degree day in Woodinville drinking it. This felt like a good November evening wine.

2017 The Canyons Malbec – This was what I came to try. Nose was all dark fruit and baking spices. Palate was blackberries and honey. Just enough tannins to take notice. Long long long finish.

Don’t Break The Streak!

Here’s a quick accountability trick that I’ve been using to help me some of my fitness goals. It’s called ‘Don’t Break the Streak’, and it goes like this.

There’s something you want to improve. For me, it’s push-ups.

  1. Print off a calendar, and hang it someplace conspicuous.
  2. Do SOMETHING every day to get yourself better, and once you do it, check off of that calendar.
  3. Your goal is to make the streak of ‘checked days’ as long as possible.

This gives you a quick visual indicator of your improvement. A steady streak of Xs through days that you can count.

Your job is keep the streak alive, and make the snake as long as possible!

Just like the game.

My Long-Term Goal: Be able to do 50 real push-ups in less than a minute. Given where I am in my fitness, that’s a LONG-term goal.

My Daily Habit: 3 sets of 12 hand release push-ups with between 30 seconds and 60 seconds rest between them. The whole thing takes about 5 minutes to do.

My streak: 6 days (so far).

Developers – Make Your Own Metrics

Writing software can have a bit of a pile of metrics to pay attention to. I especially hate being held toward measurements I cannot get control of. One of the worst offenders can be the ‘Story Point.’

The Problem of Story Points

The story point starts with the best intentions. It gives a way to for a team to build consensus about how big something ‘feels’ without the burden of a deadline. Project managers can get a general gauge of velocity, and an idea of how long a project will take to complete. But there are some glaring holes.

First, there is no baseline for a story point. What’s a 1? Without a definition of the base, what does it mean when a team estimates something at an 8? Is an ‘8’ in fact 8 times bigger than 1? If not, what’s the value of a velocity ‘sum’? If you can’t trust 1+1 to equal 2, the fact that your team got 35 points done in a sprint is meaningless.

Second, in my day-to-day developer role, I can only minimally impact the larger measure of velocity with story points. My largest impact is simply showing up for work. In effect, velocity largely measures who was on vacation for a given week.

Metrics I Care About

Things that get measured, get improved.

There are plenty of things I can demonstrably impact as a developer though. I can write more LOC, or less. I can measure test case counts and the code-coverage of those tests. I can measure the complexity of functions and classes. I can measure the depth of dependency usage, and the number of interface implementations. I can count external dependencies, or compiler warnings. I can do stupidly easy stuff and count the number of ‘.Result’ calls on async methods. (Quick tip, your target is 0.)

It comes down to a issue of my own design though. The trick is to decide what that design is, and how to measure it. For my own aesthetic, I prefer the following:

  • Small code, thoroughly-tested, released often.
  • Code which is apparent in purpose and function.
  • Code with minimal external dependencies, which can be quickly replaced when warranted.

These are my design preferences, and having them help lead me towards the metrics I care about.

Small code, thoroughly-tested, released often = Cyclomatic complexity + Unit Test Coverage * Count of the number of deployments. These are simple numbers I can get out of build tools, and can ‘fiddle with’ right there in my editor. I can target small commits that are easily released to boot. I might not be directly able to control the release schedule, but I can target code that CAN be released often.

Code which is apparent in purpose and function = Average function length / Average class size * Average length of time commits are in code review. Again, I can fiddle with function length and class size directly in my editor, and I can make smaller commits / review sessions. I can do this every day to improve these numbers.

Code with minimal external dependencies = Count them. Did I install a Nuget package that came with 6 dependencies? Is there a comparable package that only has 2? If not, can I make one? If I don’t have time, can I minimize the surface area of that package? All of those items are directly under my control.

Communicate, Communicate, Communicate

Since I have my design aesthetics and metrics that show them, I can use them to communicate value and even push them further beyond story point as a measure of value. Some examples:

PM: We only completed 25 story points this sprint. Last sprint, we got 32. 😦
Me: We improved our test coverage by 28%, and last sprint, we had only gone up 4%. Our system is more robust against failure.
Me: We released 7 times this sprint! Last sprint, we released 5.
Me: Our average function length decreased by 8.5 lines, and our cyclomatic complexity stayed the same. That means our system is easier to work with for the next sprint!

Will my PM always understand these metrics? Probably not, but then my job is to get involved and communicate my values!

I might have to compromise. You don’t get to win everything, but having your principles backed with hard numbers is a much better way to win something and exercise some authority on some of your work.

I would rather be a stakeholder in what I am building than a cog in the machine.

Developers – Know Thyself

I am not suggesting that we change everything about story points or project management in a software project. There are better minds than mine on that. However, developers should do everything they can to decide how they want to write their code, and how to measure their improvement. Be regular, diligent, honest and thorough measuring your work. It is the best way to improve what you actually care about.

Ugh, when will this be over.

Burnout is a thing. Even without the regular commute, the gym being open, and my recent trips to Long Beach seeing the amazing summer sunsets, I’m tired and a bit sick of it all.

COVID19. My Pollyanna-esque brain wholly believes in humanity. We will overcome this, like we overcome everything else. Still, I can’t help recalling folks predicting a second wave, and it seems like we’re getting one in Washington.

Protests in the city. I have never distrusted police more than I do now. I will vote against their funding nearly every time from now on.

Teenagers. No, daughter-of-mine, a chore chart is not the same as misogyny.

The picture is of my middle kid when she was a baby. It showed up in my Google Photos, with a ‘remember this?’ message. It made me happy seeing her smile that much. I may be feeling a bit of burnout, but she’s too cute to not share.

Quick Tip : Learn by Testing

I have already talked about what to looking for when learning a new programming language. One of the points I brought there was “How do I test my code. Unit testing libraries are available in near every major programming language and are an important tool in the belt!

One way to use unit testing libraries effectively is to use them to give yourself a safe playground for learning other libraries or features of the language.

Say you’re working in the .NET space, and you are trying to learn AutoMapper. One of the easiest ways to try out that library is to spin up a simple unit test project, and test your way into understanding the new framework. Start with simple examples from the docs and assert the values you expect. Try out different functions! Be thorough, and try it all out in the safety of a unit testing project that will not negatively impact your current work.

This has a handy benefit of getting you muscle memory using the library as well.

You can do this for learning programming languages as well. Getting unit tests up and running is a great step in learning a new language, and can be inserted right after the ‘hello world’ step!

Even if you are not a TDD fan, consider starting from scratch with unit testing. Happy coding!

On Being Coachable

I have spent a few posts about my experiences coaching other folks. It is immensely satisfying to coach and mentor people in their careers, but not everyone is mentally ready to be coached by someone else. Pride is legit, and exposing yourself to the critical eye of others with the express purpose of having them break you down can be difficult. Many times the things we need the most coaching on are things we attach our sense of self to. Subsequently, we do not improve as fast as we could have, if we had that course correction.

Here are four tips for being coachable.

1. Remove the Personal Stake

Take a deep breath and start here: You are valuable. You matter. It is critical that you continue being who you are. Unfortunately, the things we need coaching on often are those same things that we use as a crutch to define our identity. Look very deeply and critically at your own crutches before you do anything else.

You do not need coaching on how to be a better you. Coaching is for skills, for empathy and awareness. A good coach pushes you towards a place where you can improve what you are doing, not who you are. If you attach your ego to a set of skills, you will buckle against guidance.

This is 2020. Most people will hold several careers over the course of their lives. There is no value in remaining static to a single set of skills, and just as so there little value attaching your identity to those skills. If you find yourself saying ‘but this is who I am’, step back, and ask ‘is this who I want to be?’

2. Make Yourself Conspicuous

A key element to being coachable is access, and making what you are doing open and visible. If your coach or mentor cannot see you what you do on a regular basis, you are limiting that person’s ability to help you. The key here is to make your coach aware of the specifics of what you are doing.

Examples: As a softball coach, I can talk in general terms about batting, but for an individual player, I can target her specific stance and swing when I see her swing. My CrossFit coaches address movement when they specifically see them, and the movement is still fresh in my mind. When pairing with a software developer, I can consistently nudge back to write tests before they write the implementation, as opposed to doing a simple code review, where I may not see that developer’s whole process.

3. Get a Regular Feedback Loop

Now that you have made what you do visible, you have to setup a regular feedback schedule. Look for feedback that is targeted, specific, and on a detail you are capable and interested in changing. Regularity of that feedback is the critical element here. Setup a scheduled time for that feedback and disconnect it from the immediacy of the moment.

This one sounds counter intuitive but coaching is done well during a time of introspection. During the moment, it is too easy to get emotionally attached to what it is you are doing, and so criticism hits buttons harder than they really are intended to. You need to pick the right time, when the moment is still fresh in your mind, but detached from those immediate emotional points connecting it to your sense of self.

4. Invest Your Time

The only way to get better at something is to put in the time, and it’s the most useful way to follow after a coaching session. You cannot watch a video on improving your short game, and just expect your handicap to drop three points. Spending time on Udemy watching guitar instruction videos is great, but you have to put in the work and practice what you’ve seen. Nobody learns to swim from a book about swimming.

Once you’ve taken the time to remove the personal stake, make yourself conspicuous, and set a regular feedback loop, the final step is to exercise consistent and deliberate practice. Things won’t necessarily come immediately, but you’ll be able to push forward more quickly. Dedicate calendar space and some distraction free time to practice the deep work required to improve. Turn off the rest of the world, and build your skills.

On Passion

A debate recently rehashed on (of course) social media revisited the discussion about whether or not a developer is a ‘real’ developer if she/he were doing it ‘just for the money.’ Some folks argued that developers who were just in it for the money were selling out. Others argued that doing a job for money aren’t doing anything different than anyone else, and that just plain-old-engineering is a perfectly reasonable activity.

I was easily sucked into this debate. Working on teams with passionate people is an amazing and wonderful experience. Hours literally melt away, even when doing simple drudgery work. The work needs to get done, and you feel a carnal pull toward it. Who doesn’t love getting lost like that?

Passion glosses over a lot of flaws though. The constant hours eventually drag on and drain you. Following passions and jumping from the next thing to the next thing to the next thing ends up leaving holes everywhere. “Passionate for technology” rarely correlates to “thorough and detail oriented”, and people sacrifice professional behavior under the guise of ‘passion’ way too regularly to be ignored. At the end of the day, you’re left with the same old technical debt you have on every other project with the added burnout of dealing with all of the passionate eccentricities.

Tech pays very well. First year programmers leaving school with a comp-sci undergrad degrees get six-figures. That sort of incentive can attract a lot of people, regardless of where their passion lies. One of my ex interns once told me that if she could make the same money she would spend her time sewing clothes. She then told me about the similarities she saw in the nature of sewing, compared to programming: the detail and focus of the work. Would she rather be sewing than programming? Absolutely, but she was looking for a career, not a hobby.

I remember being a young kid hearing a news anchor on the TV describe someone as ‘middle-class.’ I remember asking my mom what class was and what class we were and she thought and said “something like a sort of upper lower class. We aren’t poor-poor, but we don’t really have any money.” I knew we weren’t ‘poor-poor’. Nobody in the house was starving. We were in good health, and lived in a house well big enough for everyone (my mom, stepdad, and the four kids.) We didn’t have a lot of the things other families had though, and I do remember being unduly aware of how much things cost, and how visibly bad it made my parents feel when we asked for more than they could afford. We had hand-me-down stuff. I started on a TRS-80, because that was available at a thrift store. We got an Apple IIe, when my dad, who worked procuring equipment for researching professors, was tasked to replace it. My mom bought a used 386, when 486s and Pentiums came out. The Apple wasn’t working for her schoolwork.

I grew up more and more fascinated by computers. I would describe it as a combination of passion, fascination, and an ability to create some control in a less than stable location. Starting from playing games written verbatim in Basic from books to connecting to bulletin boards for reasons I can no longer remember. I would fiddle with things just so, to the point where the computer would be unbootable an hour before my mom got home. My fear of her yelling (she was a prodigious yeller) prompted just enough ingenuity that I was able to restore the machine to a working state at the last minute. A unique first taste of just-in-time optimization.

From my beginnings, there is not a clean differentiation between passion for technology, or simple financial drive, and I am not sure the distinction is necessary. I will say plainly, as the breadwinner of a family of five, financial viability is the first thing that I look for. Passion for the work comes second. I am blessed to have found a position that met both criteria. I have a career that enables my passion for technology and service, and I make enough to support my family. But there is no doubt that the finances weren’t there, I would move towards a career that made that possible, regardless of my passion.

Does that fact make me less passionate about technology? I don’t think so. I find that my ‘passion’ changes with the wind. Example: I deeply dove into functional programming with F#. I still love the language, but I am not spending every day pining about it anymore. What will I be passionate about five years from now? Will it be F#? Coaching? Writing? CrossFit? Spanish-style guitar? They are all some pretty good candidates given what I do now, but it’s entirely possible that will be something else that I haven’t thought about.

There’s a good chance I’ll still be a programmer though. In five years, my oldest will be in college. My youngest will be in his second year of high school, and my middle will be in her senior year. I will still need the same income that I do now, if only to continue to support them. I will passionately do so with the skills I started building with writing Basic games. I expect my ex-intern to do the same thing, to passionately support herself and her family with the skills she’s built, both programming and sewing. I guess I land on the side of being a passionate sell-out. As a wise man once said, “Take care of your chicken.”