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.
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:
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.
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.
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
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
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
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?”
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.
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:
Collect all source code and changes.
Compile / construct the build.
Run unit tests and build verification tests.
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
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.
Collect all source code and changes from the repo.
Restore any dependencies.
Compile / construct the build.
Execute Unit Tests and Build Verification tests.
Create the artifact.
Remember the best practices of good CI builds:
With no changes to code or steps, the result of CI builds should be the same.
Execute a new CI Build on any changes to the five steps.
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.
Include integration tests as a post-CI step in an automated pipeline separate from the CI build.
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?
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!
One of our favorite local wineries had day 2 of their 3 year anniversary party today. Heather and I were lucky enough to get tickets to both days!
If you haven’t heard of Long Cellars, check out our Day 1 party post for a quick intro and write up. He is an amazing winemaker, and should get rich making wine.
So let’s break out the wine for the day!
Day 2 started with my wife’s favorite varietal Malbec. Again, we were sampling wines with tiny amounts available, so a chance to hit these early vintages was amazing.
We started with a 2014 from Glacier vineyard. Light, blue and dry, with a single bottle available for ~20 folks who made it to the party. 2015 had two samples available, a vintage from Scooteney Flats that had a savory nose, with a red fruit finish (twelve bottles), and a Boushey vineyard that was truly outstanding, with out of this world blue fruit (none left, just a sample available.) Classic Washington Malbec. The 2016 (seven bottles available) had the complexity I had come to expect from the year, and the 2017 (another seven bottles) was dark, and full, and super fruity. The Scooteney Flats was uniquely savory, I wondered if it had a touch of syrah in it.
Petit Verdot is a unique grape. When you read about it, it is normally just a blending grape. Something to make a blend fuller, and finish strongly. When Heather and I started tasting in Washington, you would find Petit Verdot in tiny percentages at the end of blends. 4% here, 2% there. Very light additions. Then in 2016, we started seeing producers push it our as a single varietal.
Jason had three versions of the Petit Verdot for us to try. A 2015 from Scooteney Flats, light and delicate, with 6 bottles left. A wonderful 2016 from Boushey that was brutal and fleshy; almost, for the life of me, toothsome. The 2017 was a bright powerfully ruby everyday drinkable fruit-bomb that finished with a screaming bit of pepper. There were 3 cases left of the ’17.
The Friendship Blends
A unique thing that Jason does every year is to create a blend with friends of his. They get together, test out various blends (he tells a grander story), and create a wine together. Each gets named in a unique way, usually with a letter of their first names or last names.
Jason Long should be famous for his blends. The single varietals are fabulous by themselves, but his ability to create a truly balanced Bordeaux is his strongest trait. The 2014/2015 FAIKEN, with 8 bottles left was our target for the evening. Heather and I first fell for FAIKEN in 2018 when we first found Long Cellars, and we fell hard. The FAIKEN is a Cabernet, Merlot, Malbec and Petit Verdot blend of grabby tannins, dark red fruit, perfect acid, and a delightful boozy burn. The 2016 NEKEL, a bawdy and pungent Cabernet-dominant blend was second up and with 4 bottles available for purchase, and I recall buying at least half-a-case of it when it was made first available. Finally, we had the 2017 PAJJAM. The PAJJAM is a winner, but was released about 6 months ago, and was the only wine I wasn’t worried about getting a hold of. We still have one bottle, and with 18 cases available, it was just a pleasant thing to enjoy. I do love Merlot, and a Merlot dominant blend makes for a wonderful finisher on the afternoon.
The End of the Party
Once again, to conclude the party Jason offered everyone the chance to purchase two bottles if they wanted to (via a raffle, to keep it fair). If anyone wanted more than two bottles then after all the other attendees else had a chance, they could do so.
We were able to grab two bottles of our favorite blend, the FAIKEN, and once everyone had their chance, I grabbed one more bottle of the 2016 Petit Verdot.
Two days with six wonderful hours of tasting, stories, food and conversation. I am so happy we were able to take six rare bottles home, and a celebrate a local winery. It was a great time and a great Father’s Day weekend.
One of our favorite local wineries had day 1 of their 3 year anniversary party today. Heather and I were lucky enough to get tickets to both days!
If you haven’t heard of Long Cellars, you are in good company. Jason Long is a very small producer. He is local to the Woodinville area, makes small batches, and has an experimental streak in him. His parties are legendary affairs, where you are likely to get an extra pour of Merlot while a burlesque dancer shakes her (or his) tassels at you. Long Cellars classics are his $25-bottle everyday drinkers. The Cab Frank, a Cabernet Franc dominant blend with a Frankenstein label, and the Screaming Baby, a delicious Merlot-fronting Bordeaux that most years has near everything but the kitchen sink thrown into it.
Jason Long has been making wine for upwards of 13 years, but has only had his own winery and label for 3 years now. The party had food, stories about the winery and the wines he had made, and of course, samples from vintages we have not seen in quite a while, or at all.
As a local wine snob, the party was an intriguing chance to sample the Long Cellars wine after it had some time to age. Being a smaller producer, it is significantly more costly to keep wine held back from his customers. Right now, Jason is releasing his 2018s (the 2018 Reserve Red Mountain Malbec is wonderful), so the opportunity to sample wine his early vintages was a unique treat.
To start out a wonderful party, and to show precisely the sort of host and winemaker he is, Jason started us with a Dry Riesling and a mineral-y yet sweet rosé made from Pinot Gris. Bone-dry and a tart finish, it had the full body of a Chardonnay. I thought it would make a wonderful desert, paired with a salted caramel. The rosé was sweet, lightly floral, but had a decided mineral finish that would not quit. I asked about them, noting he did not commonly release a Riesling.
“Yeah, I don’t have any really. It’s just something I’m playing with. I only have about a case. Did you like it?”
Worth the price of admission right there.
Day 1 started with a flight of 3 Merlots, from 2015, 2016, and 2017. These were so exclusive, Jason had sent us an inventory of ‘bottles available for purchase.’ Not cases. Bottles.
The 2015, bold and fruity, with a hint of acid. One bottle available for purchase. The 2016 was complex and full. Eighteen bottles. The 2017, fruit-forward and potent. Thirty-six bottles.
Merlot happens to be my favorite grape, mostly because it is delicious, but also due to that movie that every Merlot winemaker complains about.
Bottles of merlot ends up selling about 25% cheaper than they should be, mostly because stupid folks that do not like delicious things copy that movie. Tell ya what world, the smart money is on Merlot!
Jason had five cabs for us to try. A 2013 that was just for sampling, with literally no bottles left for sale. A 2014 from Fidelitas he had seven bottles of, and three different vintages from the Quintessence Vineyard (2014, three bottles, 2016, five bottles, and 2017 about ten cases.)
The 2013 was delicate and delicious. The 14s were a lovely contrast of the two vineyards, with a note of savory and jasmine on the Fidelitas, and a sweet and floral nose on the Quintessence. The dark 2016 was delicious, but the showstopper was the 2017. It was delicious, fruity, and delicate (and with ten cases, easier to get a hold of.)
The Cabernet Franc flight was next on the list. This was a unique flight, all from Boushey Vineyards, and one from each year from 2013 to 2017. The fascinating element here was the completely different wine you got from every year.
The 2013 was light and dry, and only available to taste. The 2014 (six available), full, friendly, but with a strong green pepper note. The 2015 (five left), almost pine-y with green pepper, and paired AMAZINGLY well with olive oil drizzled on a crusty piece of bread. The 2016 (six left) was broody, dark and complex. The 2017 (fifteen bottles), bold, fruit-forward with a hint of tannin.
To round out the tasting was a final bottle, the inaugural Sleeping Baby from 2014, which finished up the evening wonderfully. Again, it was the last of the vintage. Better keep an extra bottle of what you get.
The End of the Party
To conclude the party, Jason offered everyone the chance to purchase two bottles, if they wanted to (via a raffle, to keep it fair). If anyone wanted more than two bottles then after all the other attendees else had a chance, they could do so. Naturally, I was picked last in the raffle (grumbles). Fortunately, we got our prizes.
Heather picked out the last available bottle of the 2014 Cabernet Sauvignon from Fidelitas vineyard, and I went ahead and grabbed a bottle of the 2016 Cabernet Franc. After others had a chance, I snagged an extra bottle of my longtime favorite, the 2016 Merlot.
I had a conversation with a new dev lead today. This lead was recently installed into a project with an upcoming deadline that he was genuinely worried about. As we started the conversation, the worry sort of came out of him in piles. When he was finally able to take a breath, I collected from him that 1) he believes that the code-base is largely un-salvageable (he only recently joined the team) and 2) the deadline is completely rushing at him (about a week and a half before the first delivery.) I had spent a few minutes looking through his project and coached him toward doing the following.
1. Get a CI / CD Pipeline Setup
The first thing to do here is to get a Continuous Integration and Delivery pipeline setup, so you can quickly and reliably deploy in an automated fashion. The fact is, no software comes out as a 100% bug-free product the first time and this software will be no exception. By building up the CI pipeline you’ll be able to fix things quickly and consistently. Every commit should create an artifact, and assuming success that artifact is something can release. If the software isn’t good right now, the product can get good over time.
This was the bulk of the conversation, as it felt like to him that I was recommending that he throw sh*t at a wall and hope that it sticks. The big value comes from the ability to iterate.
2. Code Doesn’t Have to be Perfect.
The fact is, when you have a deadline you have already agreed to, you have to get over the fact that the code is crap, and likely will need a rewrite. Code is a tool used to create a product, nothing more, so worrying that it’s “not good enough” is contra-indicated.
The dirty truth about software is that no code is good enough. Ever. There is always something to do better and cleaner. That is not to disparage the craftsmen out there, but a craftsman does not back out of a commitment. When you make a commitment, you keep it.
3. Keep Your Campground Clean
This one was fairly specific to the project, but in development projects un-merged branches and directories all over the place that are largely empty do not help anyone, and make the project look bigger than it is. If you have a REST API and a daemon, you don’t need a ‘Tests\Python’ folder that has nothing in it. Things that look small, will feel small.
I will check in with him again after a few days to see what progress he has made on those items. If he can get the CI/CD pipeline down, and know HOW to get the code into production boxes quickly, we can move into things like refactoring into patterns that might smooth some sailing here.