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.
or
Me: We released 7 times this sprint! Last sprint, we released 5.
or
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. Folks with ten years experience in their chosen field happily pull in the high 70s, when 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 , 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 entirely.

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.”

Coaching Moment – Sharpen the Axe

Yesterday I was in a career planning meeting with a developer, who complained she didn’t have enough free time to learn all the stuff she needed to learn to move forward. She had too many meetings during the week, and too many too many tasks assigned to her on her project team. Even worse, the tasks she was getting that they all were the same ‘kind’ of tasks. She said “I’m not getting better. I’m stuck. <<Another developer on her team>> has already started working on <<a new technology>>, and I don’t have time to even look at it.”

That comment was an absolute heart-breaker for me.

I despise being stagnant. I am also distinctly competitive. That feeling of being stuck on a team and watching everyone else do bigger and newer things is one I have a lot of empathy for.

One of the telling moments of our conversation was how this particular developer was filling her time. In her mind, work hours meant she was working on her project, full stop. She had forty hours a week planned towards project work, and even basic administrative stuff like email, meetings, was designed to fit in to that time.


A long time ago, I heard this quote attributed to Abraham Lincoln.

“If I had six hours to chop down a tree, and I’d spend the first four sharpening the axe.”

Lincoln, maybe? I have no idea…

“We have tons of training options. What are you doing to train yourself?”

She mentioned a Pluralsight course she had started in her off-hours, but not finished. I told her I wanted her to add learning time to her week, and I wanted a bi-weekly status report on what she had done. She asked about fitting in her project work.

“Sharpening the axe IS project work, when the project is chopping down a tree.”


As someone in technology, maintaining a continual pattern of learning and training is a personal responsibility. Google made themselves well known with their advent of ‘20% time for personal projects’. Having never been a Googler, I couldn’t tell you if that’s true, but I do know staying up on the developments in the industry is crucial for personal fulfillment and job growth.

Take the time, and sharpen your axe.

Is Twitter Bullshit?

After reading Digital Minimalism and Get Your Sh*t Together, I pulled all my social media apps off my phone. I did not delete accounts or anything (except for Facebook, which I did delete.) I just removed the apps from my phone, figuring I would check Insta and Twitter from my computer directly, when I wanted to. The idea here was just to minimize the time not focused on doing something particularly.

My power usage on my phone went down drastically. I never thought of myself as a ‘power user’ of those applications, particularly, I just occasionally scrolled through and read while I sat on the (well, you know.) My Galaxy S10 would typically start at 5am at 99%, and make to 1 or 2pm, ending at around 20% when I would plug it in. With those applications removed, my phone would be around 55% battery at 430pm, when I would stop working for the day. By the end of the day I would recharge, with my phone sitting at or around 15%. I am not one of those ‘big brother’ folks, thinking that those applications are monitoring me terribly, but it is an interesting data point.

Fundamentally, my usage of those services hasn’t changed as much as I would like. My usage of Instagram is MUCH less than it used to be, but Twitter is still regular, I just use the browser to do so. Twitter pisses me off 90% of the time and it seems decidedly like its designed to do so. It’s always so rant-y and rage-inducing, and so short-term in terms of content to be meaningless in the long term. I do value the ability to navigate the social zeitgeist, but I have to wonder, is Twitter the right medium for me? I wish I had a good answer here, because I want to direct myself to deeper conversations, rather than quick hot takes on something that makes me feel a fleeting connection to a social peer group.

That’s the tricky thing of Twitter and social media. It democratizes minutiae. What do YOU think of Ivanka posting an advertisement for Goya black beans? What do YOU think of the Washington football team changing their name? What do YOU think about companies that say “Black Lives Matter” on their homepages but contribute to PAC’s that support candidates that don’t support it. And this goes on, and on, ad nauseum.

There is literally nothing I can do about Ivanka posting an advert for Goya. I have an opinion on it. One I actually spent time forming. I googled a little about laws about public officials, endorsements, and quid pro quo. Yet I repeat: There is NOTHING I can do about this, at all. But I can feel my feelings about it.

Since uninstalling had an interesting side effect on my phone battery, I wonder if the same effect can be had on my own. I’m going to try to recharge my batteries less often. It is time to drop the bullshit. Twitter, you have a target on you.

4 Simple Principles of Source Control

Different models for source control have many camps. I would rather have my software teams focus on principles of usage before worrying about the specifics or the ‘right way’ to do something. The principles I suggest below should be easy to follow, and share with new team members.

1. Prefer distributed to centralized source control.

Git is so ubiquitous now, that this is nearly a non-issue, but if your team is still using a centralized repository (SVN, or TFS), you should SERIOUSLY consider resetting that model, if for no other reason because it will become impossible to find modern developers with experience in the centralized model.

2. The main branch represents the latest version in ‘production’ at all times.

Invariably, a product will have features in flight when something immediate (a bug, a feature request, a security update) takes over priority. Maintaining a ‘hotfixable’ version of production code at all times is crucial element of product ownership. Teams should updating the main branch with the updated code immediately after a release to production.

3. Work must be visible from a distance.

Developers not embedded on the product team should be able to look at a source repository, and quickly assess what work is being done, by whom, and according to what priority. This is typically done through consistent branch naming. Consistent branch naming makes it easy for team members to quickly onboard, and for larger CI / CD processes to be built off of those processes.

4. Leave nothing behind.

Keeping a tidy repository will avoid confusion, and ensure that only what is current and open is worked on. Branches left open can be committed and pushed to accidentally, leading to work missed, and potential breaks in CI and CD processes.

Vacation in times of COVID, part 2

My wife and children have been at the beach house in Long Beach for over a week now, while I go down on the weekends. This last weekend proved wonderful. Bright and sunny, but cool, as only a Washington Beach can be.

Walking on Friday night before sunset.

Nothing like a bright sunny day on the beach that requires a light jacket.

Are there really teenagers if they aren’t fighting for no goddamn reason?

The funny thing about a beach town like Long Beach is the quirky weirdness that exists in that place. I have never, ever, seen a kite store in my life before visiting Long Beach. A store, wholly dedicated to kites and kiting enthusiasts.

Sunset behind a few clouds.

Yet, I still had to come back to the house. We have furniture deliveries, and homeowners-association installs of safety equipment that someone has to be here for. That, and my desire to work is literally nil when I’m down at the beach. I instead re-read Jack London’s Call of the Wild in the course of 3 hours, while my shih-tzu and terrier ran all over the beach, barking at gulls, digging holes in the sand and rubbing the scent of molted Dungeness Crabs into themselves.

A message to my work brain: Locust tests hosted through to Azure Containers will get done, I promise. Maybe a little later than I planned.