Category Archives: Uncategorized

Vacation, in times of COVID

Long Beach, Washington is my favorite place to be on the 4th of July. I’m a fireworks hound; I love them, and I will not apologize for it. However, my desire to do them safely makes me ADORE doing them on a wet sandy beach. We get all the boom-y fun without the risk of setting someone’s house on fire.

The family at Long Beach

After the holiday, I had to come back home. We had appointments at the house and the car needed some work, and the reality is, Long Beach isn’t (for me, anyway) the best location for me to expect to spend a lot of time working. I came back and largely spent my time working. My wife and kids stayed down there, and the plan is for her to remain there until the end of July, and potentially August, if COVID takes a larger toll on our August plans.

Short post, but this is where I am right now.

The Life Changing Magic of Tidying Up Your Calendar

In prior posts, I’ve talked about my obsession with focusing on the important things, and getting things done. As someone with a meetings-heavy calendar, it’s very easy to end up with a done pile that doesn’t include a lot of concretes.

But I’m a developer first, so no matter how many coaching sessions or conversations I have on the calendar, what I absolutely have to do is get something produced. Coding is not a spectator sport, you can lose the the muscle memory if you do not actually write any code, so getting the work on the calendar is precisely necessary.

Actually use your calendar.

Most folks minimize usage of their calendar to just the meetings. Block time off for stuff that you need to do. Put stuff on the calendar you need to do. If coding is your job, put ‘write code’ on your calendar. With a “busy” flag.

An example: My boss lives on a small farm. He has “Move the Sheep” as a calendar item. Because its blocked off, I know not to schedule my one-on-one during his sheep-moving.

Don’t auto-accept meetings. Mark them as tentative, or decline.

The problem with meeting Accept is it’s ease. It is MUCH easier to respond Accept to a meeting, than it is to respond “Tentative” with a reasonable answer. Here are a few simple canned responses you can use:

  1. Tentative: “I’ll try to make it, but my calendar is crazy.”
  2. Decline: “I’ll catch up via email.”
  3. Tentative: “Can we do this virtually instead? Like a Slack thread?”
  4. Decline: “I don’t have an educated opinion here. If you need something from me, let me know and I’ll get it to you ahead of this.”

The Harsh Truth: You don’t need to be present on most meetings. A LOT of them don’t directly involve you, and are really just time sucks because people don’t like having to read / write email.

Caveat: Show up to meetings appropriate for your Team Norms. If your team has a daily stand-up, be there. Planning every 3 weeks? Be there. But focus on the time and agenda at hand, and move on.

Be brutal clearing out your calendar.

OK, so your calendar is full of ‘tentative meetings’. Now it’s time to filter those out. Cleaning out the calendar is an exercise in willpower. The fear of missing out will be powerful here, so be strong.

Personal note: I love having my opinion asked about things. If I’m honest, probably 25% of my motivation to blog is precisely caused by this. The fear of missing out on a chance to expound on a topic is SO hard to pull from, precisely because it flatters my ego.

Target those things you MUST do on the day, and the things can deeply impact. Focusing on those few things will allow that impact to be felt more strongly.

It is your calendar. Own it.

Fidelitas : Magna Club!

I checked my email last night, and a 2-year wait was finally over. We have been members of the my favorite winery, Fidelitas Wines, for over 10 years. We started in 2009 as members of their 8-bottle club, then bumped to their 16-bottle club (‘OPTU’) in 2014. The bumped membership was a gift to my wife. As of this morning, we officially made it into the 24-bottle club, called ‘MAGNA’.

It feels a little silly to be so excited by this, but I absolutely cannot help it.

It also feels pretty darned fantastic to support the best winemakers in the state.

Our first foray into Fidelitas was in 2009. Heather’s father had won a silent auction for charity for a day-trip guided tasting in the Yakima Valley by Bob Woehler, a wine journalist in the Tri-Cities area of Washington State. Bob was in his late 70s, and his wife in her 80s, but still both active in the local charities and wine scene. Since Heather’s dad wasn’t much of a wine fan, he let Heather and I take the trip for him.

We met Bob and his wife, and they took us to 8 different wineries in the area, a good selection to be sure. His wife had packed a picnic lunch for us, and we went from place to place while Bob lauded over local winemakers. We had two favorites, Fidelitas and Chinook Wines. If Chinook had a wine club, we’d be members there too. Try her Cab Franc Rose, if you happen to go to a PCC and find it there.

Heather’s appreciation for a good Malbec was alive and well back in 2009, so after Bob gauged her tasting notes, we drove up to the Benton City tasting room. The wine hit us like a ton of bricks. Red Mountain is a well known AVA, but at the time, was still breaking out of the Yakima Valley mold. It was just so much more full and vibrant than so many wines we had tasted that day. We joined that day, and brought several bottles with us. I remember Bob’s wife winking at her “that’s a good choice for a first club, but a hard one to live up to.”

Bob’s wife was entirely right. We had only joined a second club almost eight years later, after our palettes learned to appreciate the variety.

Coaching Moment – Why Won’t They Give Me Permission?

I had an impromptu conversation this afternoon with a system engineer. He wasn’t looking for ‘coaching’, in the same vein that my developers are inclined to do, but a conversation about how to integrate a new technology into the credit union’s mechanisms. I am a poor network engineer. My understanding of network sophistication is pretty slim, and my ignorance was exposed, repeatedly, throughout this conversation.

However, as we discussed the problem, and came to a series of potential solutions, a common thread came up in my colleague’s responses to a solution.

“Yeah, that probably could work, but it will be nearly impossible to get this through…”

“This would work, and would be kinda fun. But moving the CU toward this is like turning a ship around…”

I checked in here. There wasn’t a technical reason these solutions weren’t reasonable. They were just too ‘new’. I queried further, and it became very clear a lot these ideas were things my peer had thought of. He just never got permission to move forward.

And just like that, it became a coaching moment.

Aside: One of my old managers used to hate complaints. Hated them. His personal stake in what we had built attached a personal note to anything technical complained about. If you came to him with a complaint, and an expectation that he would ‘fix it’ for you, you came away rebuffed, and in no unclear terms. But if you came to him with a complaint, and a well-thought out fix for it?

That nearly always ended up differently.

I coached this particular engineer about feeling welcome to take that next step, and propose a ‘fix.’ This is common to the Pull-Request model of open source software. An lone issue and complaint is reasonably ignored, but an issue with a well-thought-out pull request, correcting the flaw? That is something worth paying attention to. Even if the correction is inaccurate, it is worth paying more attention to someone willing to put in the work to correct it. In your own life and work, put some skin in the game.

Avoid being a complainer that is not willing to own the problem or the solution. Get in there, find out what’s hard about the problem, and take the chance to own the solution. Will it always work? Of course not, but the effort you take learning about the problem will likely lead to a better solution down the line.

Pay Yourself First : The Dirty Secret of a Morning Person

One thing I have learned about myself is that I am, without apology, a morning person. I get a walk in with the dogs, a cup of coffee or two, and a protein-rich breakfast (greek yogurt with berries and egg whites) everyday, and still have an hour or two before work. There are others who try a different tack, as described by the following tweet:

Tweet with text, "Learned a very relatable term today: “報復性熬夜” (revenge bedtime procrastination), a phenomenon in which people who don’t have much control over their daytime life refuse to sleep early in order to regain some sense of freedom during late night hours."
A tweet describing exactly the opposite approach.

I would like to tell you about an easy way to get up in the morning and how much better, but the dirty little secret is this ‘revenge bedtime procrastination’ is precisely what I’m doing.

I just do it in the morning.

Knowing I am at my most chipper and best in the morning gives me license to enjoy my morning first. I choose not to wake up to immediately work, but to wake up to spend a few moments for myself. I don’t feel too bad about playing 20 minutes of Pinball Action at 5:30 in the morning.

A screenshot from a pinball video game.
Yay Pinball!

I take a great deal of pride in my work, and what I do every day, but spending 2-3 hours every morning taking care of me, the dogs, and my family first make it exactly worth that effort. If you feel like you are ‘stealing back’ time for yourself in the middle of the night, only to wake up miserable, you might do better taking that time first thing in the morning.

Pay yourself first. Especially with your time.

Presentation: Introducing F#

Alright, you are like me, so you you’ve talked up F# in your office, and folks are interested! You need to introduce F#, and quick! Well, I have got some help for you!

I have a slide deck for you to use, and a YouTube video for ya to share if you aren’t the presenting sort. Feel free to clone the repository and use as you need to.

My Three Everyday “Must Dos”

If you wrote down everything you did, every day, what do you think it would tell you about your priorities? Would you be happy with how you spent your life?

The daily must-dos become the habits that help us get good at what we’re doing. I have mentioned my mechanism for getting things done in this blog before. Go check it out, if you haven’t read it already!

Here are the top three daily things that always end up in my “Must Do” column.

Check The Budget

Photo by Karolina Grabowska on Pexels.com

I did not grow up with an over-abundance of money. My family did not really talk about money all that much either, viewing it as a constant sort of stress. It has always been a weird point of pride and identity too, where someone “from money” was someone to look down your nose at.

After a life changing event in the mid-2010s, I decided to change that, focusing on taking the mystery away from money. Now, every day I go through my budget and make sure my dollars are going to where I prioritize them to go. I use a tool called You Need A Budget to do so.

There are plenty of YouTube videos are available out there about the YNAB product, but if you watch the ones from Nick True, you’ll get a good idea on how the product works.

Crossfit, or other workout

Photo by Victor Freitas on Pexels.com

Is Crossfit problematic right now? Yeah, very much so. They have some corporate housecleaning to do, because there is no room for racism and sexism in the gym. Taking care of yourself and your body is for everyone.

That said, there has never been anything I’d consider even remotely negative about my local box. When I was 320 pounds, they were kind, supportive, and helpful. They did not try to sell me a bucket of supplements. They challenged me, and made those challenges doable for someone in my shape and size.

They are people that are striving to be active, kind, and full of life. That is precisely the sort of person I want to be.

So despite how much I hate Burpees, I hit up my Crossfit WOD everyday. If you live in the Kenmore area, come visit us at Crossfit Kenmore.

Write for 45 Minutes

Photo by Retha Ferguson on Pexels.com

I graduated with an English degree, so you’d think this would be something I could do easily, but like anything else, it has to be maintained. I use OneNote for my note-taking, falling in love with it when I used my old Windows Phone in 2009. I remembered being able to speak into my phone, even back then, and have it transcribe my language with an accuracy of about 90%.

I was amazed. I was also a nerd, so I started nearly every transcription with “Captains Log, stardate… “

Most recently, I have been taking up the task of blogging for 45 minutes every day. Fleshing out my thoughts onto a screen isn’t exactly the same as paper, but it does let me combine with other creative work. For example, my blog post about learning a new programming language is the basis for a talk I will be doing on soon to a new Python User’s Group.

Consider what these top three things tell you about my priorities. Everyday I prioritize writing, taking care of myself, and the family finances. These are not all of my priorities, of course, but they are the “must dos” every day. When you look at your day, what are your “must dos?”

Coaching Session – Is Everything Broken, or Is It Just Me?

Today’s coaching session revolved around a young developer recently moved into an established team. The developer had experience in Agile teams with specific practices, and this team’s practices were VERY different, and almost non-existent. As opposed to a product team with a defined backlog process, this new team is catch-as-catch can, and largely individualized. This developer was concerned, greatly.

“Where is the product owner? Why isn’t she engaged here? Where are the stories? Where is task breakdown?” And on and on, indicating worries great and small. He was half-convinced the entire structure was broken, and needed to be rebuilt from the ground up.

Man oh man, could I empathize with that.

There were a lot of complexities to unpack in this developers complaint, but I called out his newness to the team. He was joining an extremely stable team, with established norms and structures. It is entirely possible that the Agile mindset and culture of the team needs to change, but for an engineer, the first thing to do is get competent on the platform.

This team is a bunch of individuals working. That is a problem. Fixing the process needs to happen, for sure. That isn’t the purview of a brand-new-to-the-team engineer. Nobody is going to listen to someone who comes into an organization and immediately vents about how everything is broken.

Process absolutely matters, but for this engineer, engineering has to count first. That’s what I coached him to do. I recommended he get good at the tech FIRST, and then talk about process improvements.

After that conversation ended, I setup a meeting with the product owner. I wanted to see what sort of issues she was seeing, and if there was anything this principal software dev could help with.

Four Best Practices of CI Builds

Continuous integration builds (also called CI builds) are an absolute process game-changer, turning a local ‘works on my box’ coding and deployment strategy into an automatic and reliable process. Once a team gets a taste of an automated and reliable build process, it is easy to fall into a trap of adding all of the things to your CI build. Integration tests, security scans, performance tests, etc, until eventually, the CI build has lost the features that make a CI build implicitly valuable. The best development teams keep continuous integration builds simple.

Best Practice: With no changes to code or steps, the result of CI builds should be the same.

Responsibilities of the CI Build

A CI build’s job is to collect all developer changes, and create a releasable artifact, ensuring changes from all developers on a project are included in the product, and don’t cause conflicts with each other. A CI build must be fast, so that changes that break a build can be immediately corrected; a quick feedback loop is essential to the CI process. A CI build should perform the following steps:

  1. Collect all source code and changes.
  2. Restore dependencies.
  3. Compile / construct the build.
  4. Run unit tests and build verification tests.
  5. Create the artifact.

Assuming the same code input from step one, and no changes to any of the steps, a CI build’s result should be the same, every time.

A new CI build should be executed if the state of any of the five items above are modified. If there’s a code change anywhere, step one has changed. If any dependencies are updated, in the framework or libraries the product uses, step two has changed. If a build setting has changed, like going from 32 bit to 64 bit, or from ‘debug’ mode to ‘release’ mode, that is step three. Unit test changes typically are manifested as code changes, but any test settings changed would be an item for step four. If the artifact construction process changes at all, that’s step five.

Best Practice: Execute a new build on any individual change to those steps.

Tempting Steps You Should Avoid in CI Builds

  • Code Security Checks
  • Integration Tests

Code security checks are tempting items to add to a CI build, but fail the ‘no changes to code or steps’ rule. Most code security checks are rule-based in nature, getting updates when there is a new known vulnerability. The process is similar to a malware database updates. With no code change, and no change to steps, but an invisible-to-the-developer modification to the security changes, builds can succeed or fail seemingly randomly. Also, the scope of secure code changes can be larger than common unit / build verification failures. A security change can be very small, but more commonly is larger and design-related.

Best practice: Include code security checks on a regular schedule, not directly connected to the CI build, and have those check failures create backlog items the developers can research and correct.

Integration tests are tempting to add to a CI build, but fail the rule of failing fast. Any system large enough to have integration tests in the first place will be a fairly complex set of tests to run, which may take quite a while to execute fully. They also tend to rely on a lot of scripting and setup work.

Best practice: Include integration tests as a post-CI step in an automated pipeline separate from the CI build.

To recap: Continuous Integration builds should be quick, automated, and provide a fast feedback loop. They should contain the following steps.

  1. Collect all source code and changes from the repo.
  2. Restore any dependencies.
  3. Compile / construct the build.
  4. Execute Unit Tests and Build Verification tests.
  5. Create the artifact.

Remember the best practices of good CI builds:

  1. With no changes to code or steps, the result of CI builds should be the same.
  2. Execute a new CI Build on any changes to the five steps.
  3. Include code security checks on a regular schedule, not directly connected to the CI build, and have those check failures create backlog items the developers can research and correct.
  4. Include integration tests as a post-CI step in an automated pipeline separate from the CI build.

Happy building!

Six Questions You Need To Answer When Learning a New Programming Language

Are you someone who wants (or maybe is being forced) to learn a programming language? Learning to program isn’t just syntax and structure. Here are six questions you should answer about your programming language before writing your first program.

While learning the syntax, structure and tools, make sure you can answer the these questions.

1. What is latest version of your language?

By keeping yourself with the most up-to-date versions of your language, you minimize the risk associated with using old software with known security flaws. Building software can be risky, if not done carefully, so make sure you are using the most up to date version of your language.

Paying attention to the version information is also a great way to date the information and numerous resources you find out there in the wild. C# is in version 8 now. If you find a book about C# 2, it is NOT new, and can probably be recycled.

2. Who hosts the documentation, and where?

Programming languages will either have an organization, or a corporation which acts as the owner / maintainer of that language. C# is owned and maintained by Microsoft, and the C# documentation is hosted on their website. Python is hosted by the Python Software Foundation. Java, by Oracle.

Find the documentation website, and favorite it.

3. How do you manage dependencies and libraries?

Nowadays, nobody codes anything entirely by themselves. All languages start with a basic platform library that contains the very basic commands, keywords and structural expectations. C# has the .NET runtime. Java, the JDK. Often times open-source community provides the rest via a packaging system.

Learn your packaging platform, and how it works. Each package will often be just like the programming language itself, with versioning, docs, etc.

4. How do you test your code?

Unit testing has been a best practice for software development since the early 2000s. Unit tests are an extremely useful tool in your belt, enabling you to prove out functionality you are exploring or have written yourself. Every major language will have a library associated with writing unit tests. Using the packaging platform from step three, your next step should be finding out how to test your code. You, and your users, will be grateful that you did.

5. What risks are there? What should you watch out for?

In general, programming is a ‘high access’ activity on your computer, your networked environment, your data, etc. The convenience of doing things quickly or in bulk is precisely what a programming language can enable, so be careful. Make sure your SQL statements have WHERE clauses, and are guarded by a transaction that can be rolled back, if done in error. Make sure your loops have defined end states. Make sure you know precisely what your memory pointer is pointing to. Low-level compiled languages have more potential to damage computers directly by overwriting memory or restricted data. High-level interpreted languages tend to cause file or data related issues.

A computer does EXACTLY what it is told to do, and nothing more. Remember that, and be VERY sure it is doing what you intend.

6. How do you package and deploy the code you write?

Remember that code is just part of the story here, and is largely just a work product to the end result itself. Hosting a JavaScript site on a localhost isn’t enough, nor is a bunch of class files for a JAR file. When you write code, the goal is to ship an artifact of some kind. Don’t just start with Hello World, but start with Hello World deployed somewhere!

There are lots of resources out there for learning programming in a digital age. As you go through your learning, make sure you can answer these six questions while you’re learning the basics of the language. Happy coding!