<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Posts on For my friendgineers</title>
    <link>https://friendgineers.rosenshein.org/posts/</link>
    <description>Recent content in Posts on For my friendgineers</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Fri, 24 Apr 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://friendgineers.rosenshein.org/posts/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>The Genie and the Damped System</title>
      <link>https://friendgineers.rosenshein.org/posts/2026/04/24/</link>
      <pubDate>Fri, 24 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2026/04/24/</guid>
      <description>While we’re all thinking about LLMs and Coding Genies, here’s something to think about. Taken as a whole, the process of software development is a system. Not just a system, but a system with feedback loops. Make a change, see what happens, react to the change. The OODA loop.&#xA;As an aerospace engineer who got started dealing with computer-controlled flight dynamics and keeping them stable despite dealing with human pilots who insisted on overcontrolling things and getting into Pilot Induced Oscillations (PIO), I’m very familiar with different kinds of damping modes.</description>
    </item>
    <item>
      <title>Your PRs Are Someone Else&#39;s Problem</title>
      <link>https://friendgineers.rosenshein.org/posts/2026/04/20/</link>
      <pubDate>Mon, 20 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2026/04/20/</guid>
      <description>I was staring at a PR the other day. It had been open for six days. The author had rebased it twice, resolved a merge conflict, and was about to need a re-approval because the conflict touched reviewed code. Six days. For a change that would take maybe twenty minutes to review.&#xA;We&amp;rsquo;ve all been there. And if you haven&amp;rsquo;t been on the waiting side, I promise you&amp;rsquo;ve been on the other side — the reviewer who meant to get to it tomorrow and then tomorrow turned into Thursday.</description>
    </item>
    <item>
      <title>Indirection Vs. Abstraction</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/08/15/</link>
      <pubDate>Fri, 15 Aug 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/08/15/</guid>
      <description>I’ve heard it said that there’s no problem in computer science that can’t be solved by another level of indirection. I’ve also heard that there’s no problem in computer science that can’t be solve by another level of abstraction. That’s the same thing, right? Wrong1.&#xA;Let’s start with some definitions.&#xA;Abstraction: In software engineering and computer science, abstraction is the process of generalizing concrete details, such as attributes … to focus attention on details of greater importance.</description>
    </item>
    <item>
      <title>Testing Is More Than Preventing Breakage</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/08/13/</link>
      <pubDate>Wed, 13 Aug 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/08/13/</guid>
      <description>Here’s something I ran across on the interwebs the other day. It’s about the reason for testing. I don’t fully agree with the first point, but I definitely agree with the rest.&#xA;If your tests only tell you when something breaks, you’re missing the point.&#xA;Great tests accelerate learning. They guide design, expose bad assumptions, and make change safe.&#xA;Testing isn’t cleanup. It’s engineering. Still shipping without fast feedback? That’s not speed.</description>
    </item>
    <item>
      <title>Stuttering</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/07/30/</link>
      <pubDate>Wed, 30 Jul 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/07/30/</guid>
      <description>There are two hard things in computer science: cache invalidation, naming things, and off-by-1 errors. Today&amp;rsquo;s post is about the middle one of the two.&#xA;Naming is hard. Noun clumps1 for data. Verbs2 for functions. Hungarian Notation3 for clarity? Everyone&amp;rsquo;s got an opinion on what&amp;rsquo;s right. Even languages have opinions on what&amp;rsquo;s allowed. Almost all languages allow almost all of the ASCII characters in identifier names. Some they have rules around what can be first in the identifier and how long it can be.</description>
    </item>
    <item>
      <title>Optimization</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/07/23/</link>
      <pubDate>Wed, 23 Jul 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/07/23/</guid>
      <description>I&amp;rsquo;m traveling on business this week. I&amp;rsquo;m staying in a hotel, as you do when traveling for work. As I spend time in the hotel, I&amp;rsquo;ve noticed some very interesting things and learned from them. Just like I&amp;rsquo;ve learned things from my dryer. One of the I&amp;rsquo;ve learned is about different kinds of optimization. Take a look at this photo.&#xA;Look at that bar of soap. It&amp;rsquo;s got three holes all the way through it.</description>
    </item>
    <item>
      <title>Writing Legacy Code</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/07/21/</link>
      <pubDate>Mon, 21 Jul 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/07/21/</guid>
      <description>One of the people I regularly ready is Tim Ottinger. His writing has either put into words things that I’ve felt but hadn’t figured out how to say, or said things that I’ve said, but in a much clearer/more powerful way than I have. His recent post is one of the former.&#xA;One of the dominant, less-disciplined, processes that programmers follow is:&#xA;Write a bunch of code (being very careful, of course) Edit it until it will compile.</description>
    </item>
    <item>
      <title>Who Do You Love?</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/07/16/</link>
      <pubDate>Wed, 16 Jul 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/07/16/</guid>
      <description>On the topic of leading with the why, emotions are important. Two of the strongest emotions are love, and it’s not opposite, hate1. Three of the biggest drivers of innovation are necessity, laziness, and love. If you want to a strong driver of innovation, love is a pretty good choice.&#xA;Like George Thorogood asked, the question is, Who Do You Love?. Answer that question and you’re on your way. Get the whole team loving the same thing and you’ll be amazed at what you create.</description>
    </item>
    <item>
      <title>Practice Makes Perfect?</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/07/14/</link>
      <pubDate>Mon, 14 Jul 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/07/14/</guid>
      <description>As I heard in marching band, don’t practice until you get it right, practice until you can’t get it wrong. It was certainly true there. It’s mostly true in Software Development too. Not that we’re doing the same thing, day in and day out, like a marching band, but there are a lot of process we practice every day, and getting better at those processes, learning them so well that we can’t get them wrong, is a good thing, right?</description>
    </item>
    <item>
      <title>Power Dynamics</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/07/11/</link>
      <pubDate>Fri, 11 Jul 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/07/11/</guid>
      <description>Positional power is an interesting thing. The HIPPO effect is real. When you’re in a position of power, by definition, you have that power. Whether you’re aware of it or not. Whether you use it intentionally or not.&#xA;Of course, with great power comes great responsibility. One of the hardest things to remember is that because of that power, people don’t always hear things the way they are intended. And as the person who’s trying to communicate something, it’s on you to make sure the message gets across.</description>
    </item>
    <item>
      <title>Exsqueeze Me?</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/07/07/</link>
      <pubDate>Mon, 07 Jul 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/07/07/</guid>
      <description>With all due respect to Mike Meyers as Wayne Campbell, I saw something on the internet and the only possible response was Exsqueeze Me?. The quote started out OK, not great, but OK, then, right there at the end, it took a sharp left into crazy town.&#xA;Good teams can and will delete tests that have high false positive rates – or that never fail.&#xA;Here’s the thing. If you’ve got a test with a high false positive rate, that’s bad.</description>
    </item>
    <item>
      <title>The Messy Middle</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/07/02/</link>
      <pubDate>Wed, 02 Jul 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/07/02/</guid>
      <description>I’ve talked about a messy middle before, but that’s not the only messy middle. That one was about the land of It Depends. Where you can’t know the answer until you have all of the context. But there are other messy middles.&#xA;Consider the space between products and platforms. The split between what customers bought, and what the company built internally so that they could then build the things that customers bought.</description>
    </item>
    <item>
      <title>Speed Vs. Quality</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/06/30/</link>
      <pubDate>Mon, 30 Jun 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/06/30/</guid>
      <description>As I’ve noted before, while I’ve worked all over the computing stack, from simulation for games and requirements analysis to 3D rendering to fleet management to tools, I’ve spent the last 15 years or so working down in the engine room. Working on internal platforms, tools, and infrastructure. And time and time again I’ve seen teams and entire organizations micro-optimize for immediate velocity only to run into a wall and find themselves stuck.</description>
    </item>
    <item>
      <title>Culture: Not Just For Yogurt</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/06/25/</link>
      <pubDate>Wed, 25 Jun 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/06/25/</guid>
      <description>Culture isn’t just for yogurt and sourdough. It’s also for teams. Or really, any organization, formal or informal. There’s a lot that goes into culture. What your goals are. How you incentivize. How you teach. How you do things, in good times, and in bad. And perhaps most importantly, how you handle uncertainty.&#xA;Overhead on the internet:&#xA;Your “Company Culture” is more about what happens when somebody on a team says “I don’t know” than what team building events you plan.</description>
    </item>
    <item>
      <title>Docs First And The Definition Of Done</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/06/23/</link>
      <pubDate>Mon, 23 Jun 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/06/23/</guid>
      <description>I’ve talked about doc culture before. About the importance of writing things down. About how you can use a narrative doc, that everyone reads before talking to make meetings more efficient. Most folks think of this as the Amazon approach.&#xA;Amazon does run on docs. Many meetings start with a document, not a slide deck, that people read in the meeting. They comment on it live. The authors provide direct feedback.</description>
    </item>
    <item>
      <title>System Goals</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/06/20/</link>
      <pubDate>Fri, 20 Jun 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/06/20/</guid>
      <description>As CEO and Co-Founder of Honeycomb, Charity Majors has a lot to say about observability. She also has a lot to say about software development in general. And software leadership. Over the years I’ve learned a lot from her stuff.&#xA;Recently she was on the How AI Is Built channel. It’s a pretty good overview of how to do observability and why it’s important. On top of that, the title of the episode really spoke to me.</description>
    </item>
    <item>
      <title>Superpowers And Optionality</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/06/18/</link>
      <pubDate>Wed, 18 Jun 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/06/18/</guid>
      <description>A long time ago I talked about distributed systems superpowers. Those are great things to have. When you’re building a distributed system, you really want your core functionality to have those superpowers. They make building the features your users want much easier. That&amp;rsquo;s your superpower&#xA;A quick recap. Here’s the 5 superpowers I listed.&#xA;Idempotency: The system should do the right thing if asked to do the same thing twice. Availability: The system should always work.</description>
    </item>
    <item>
      <title>Coding Genies and Code Review</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/06/13/</link>
      <pubDate>Fri, 13 Jun 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/06/13/</guid>
      <description>Speaking of writing for the maintainer, what about coding assistants? They write code too.&#xA;First, an axiom. Just like auto-complete in your IDE is your code, code that you ask an AI assistant to write and then share as your own is your code. There’s nothing wrong with that per-se, but it’s not an excuse to not care about the implementation details.&#xA;Second, a position. Kent Beck has taken to calling coding assistants Genies.</description>
    </item>
    <item>
      <title>Who Are You Writing To Anyway?</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/06/11/</link>
      <pubDate>Wed, 11 Jun 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/06/11/</guid>
      <description>I’ve written about this before. When you’re writing code, who are you talking to? The simplest answer is that you’re writing to the computer. To the assembler, compiler, or interpreter, depending on the language you’re using. And at some level, that that’s true.&#xA;However, there’s a lot more to it than that. As the great philosopher and programmer, Anonymous, once said&#xA;A programmer does not primarily write code; rather, he primarily writes to another programmer about his problem solution.</description>
    </item>
    <item>
      <title>AI Isn’t The Answer</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/06/09/</link>
      <pubDate>Mon, 09 Jun 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/06/09/</guid>
      <description>If AI isn’t the answer, what is? Before you can say what the answer is, you need to be clear what the question is. If the question is “How can I get more code written faster?”, then AI might be the right answer. On the other hand, if the question is “How can I provide more value to the user faster?”, then AI probably isn’t the answer. At least not in any meaningful way.</description>
    </item>
    <item>
      <title>But The Requirements Just Changed</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/06/06/</link>
      <pubDate>Fri, 06 Jun 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/06/06/</guid>
      <description>Or at least someone told you they did. But did they really change? Or do you just understand them better?&#xA;Here’s the thing. If you go to your user, not the stakeholder, not the purchasing agent, not the product owner, but the user, and get them to describe the problem they need to have solved, it won’t change much. They may come up with more problems as you talk, but problems rarely change or go away by themselves.</description>
    </item>
    <item>
      <title>New Code Vs. More Code</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/06/04/</link>
      <pubDate>Wed, 04 Jun 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/06/04/</guid>
      <description>I’ve said before that as developers we read more than we write. And that’s still true. Here’s something else we do more often than we probably think. We modify (extend) existing code way more often than we write brand new code.&#xA;Writing green-field code is fun. It’s easy. There are far fewer constraints. But how often are you really writing green-field code? If you want to be pedantic about it (and sometimes I do), everything after the first time you save you code is working on existing code.</description>
    </item>
    <item>
      <title>Listen to Your Data</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/06/02/</link>
      <pubDate>Mon, 02 Jun 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/06/02/</guid>
      <description>I’ve touched on the importance of listening to your data before, but I decided that the topic is worth revisiting. That time it was about the difference between 0, 1, and many. As a side note, I mentioned the relationship between data and Object Oriented Programming, and how your data can tell you what your objects are.&#xA;That’s still true. When people ask me to take a look at their design and architecture and wonder what the right answer is, my first answer is usually, of course, It Depends.</description>
    </item>
    <item>
      <title>What Is Performance Anyway?</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/05/30/</link>
      <pubDate>Fri, 30 May 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/05/30/</guid>
      <description>Performance is important. It’s also very context dependent. High performance can mean different things at different times to different people. And what your target audience is going to consider important is never fully known unit that audience actually gets your software in their hands.&#xA;That said, there are some areas that almost always go into what people consider high performing software. Things like responsiveness, latency, total run time, throughput, and resource efficiency.</description>
    </item>
    <item>
      <title>Time Passes</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/05/28/</link>
      <pubDate>Wed, 28 May 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/05/28/</guid>
      <description>Hot Take. Unit tests should pass, regardless of what day you run them. Time is hard. It has a way of passing when you’re not even thinking about it. When you’re writing simulations (or unit tests, which can be thought of as simulations of some small aspect of your code) one of the most important things to do is control time. As a general rule, unless you’re measuring performance or displaying/logging the current time, you probably shouldn’t be using your language’s equivalent of Time.</description>
    </item>
    <item>
      <title>Licensed Engineers</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/05/23/</link>
      <pubDate>Fri, 23 May 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/05/23/</guid>
      <description>Closing out this series1, the third most common reason I’ve seen thrown around for why software engineering isn’t real engineering is:&#xA;Real engineers have a license. Software engineers don’t&#xA;In the United States you can get become a Professional Engineer. Canada has licenses and the Iron Ring2, which acknowledges the responsibilities an Engineer takes on towards society. Other countries have similar systems.&#xA;To the best of my knowledge, the only place that has a Software Engineering specialty for Professional Engineers is Texas, and while that’s called Software Engineering, it’s really more about computer hardware engineering, and the number of licenses issued is vanishingly small.</description>
    </item>
    <item>
      <title>Engineers Estimate</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/05/21/</link>
      <pubDate>Wed, 21 May 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/05/21/</guid>
      <description>The other day I talked about the #1 excuse people use when they say software engineering isn’t engineering, that software has no constraints. If you think software engineers don’t have to deal with constraints, here’s the post. Or just go talk to a software engineer.&#xA;The second most common excuse I’ve seen is&#xA;Real engineers can and do estimate their work. Software engineers can’t (or won’t) accurately estimate.&#xA;First, let&amp;rsquo;s agree that if you&amp;rsquo;re trying to do something that isn&amp;rsquo;t even close to something that has been done before, the estimate is going to be wrong.</description>
    </item>
    <item>
      <title>Constraints</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/05/19/</link>
      <pubDate>Mon, 19 May 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/05/19/</guid>
      <description>Over the years I’ve seen many people say that software engineering isn’t real engineering. They tend to come up with the same reasons, even if they have different examples. In my mind I’ve grouped them into a few major reasons.&#xA;Real engineers work with things in the physical world. Things made of atoms, and they’re constrained by physics. Software engineers, on the other hand, work on “bits”, and bits aren’t real1.</description>
    </item>
    <item>
      <title>Slow is Smooth, Smooth is Fast</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/05/16/</link>
      <pubDate>Fri, 16 May 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/05/16/</guid>
      <description>Move fast and break things. That’s the tech mantra, right? Do something. Might be right, might be wrong. Just do something and see what happens. Things will break. That’s OK. Just fix it later. As the Dothraki say, It is known.&#xA;There’s another saying. Slow is Smooth, Smooth is Fast. This one is courtesy of the Navy Seals. It’s saying the opposite. Slow down. Think about what you’re doing. Make deliberate choices.</description>
    </item>
    <item>
      <title>Government Digital Services</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/05/14/</link>
      <pubDate>Wed, 14 May 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/05/14/</guid>
      <description>A long time ago, in a country far away from, the government released guidelines. Nothing unusual about this, It happens all the time. Usually, when I hear about that I think of things that are well known, well understood, generally accepted, and now written down in obtuse language with lots of buzz words and details. Enough fluff to make it largely incomprehensible. You know, standard bureaucratic language.&#xA;When I think about the government that did this, I think of powdered wigs, stiff upper lips, and traditions that date back hundreds, if not thousands of years.</description>
    </item>
    <item>
      <title>Best Simple System For Now</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/05/12/</link>
      <pubDate>Mon, 12 May 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/05/12/</guid>
      <description>When you’re writing code you have lots of choices. Even when working with 20-year-old legacy code, you have options. Not all of those options are equal though. Some are cheap and fast now, but may have a large cost later. Others are expensive and slow now, but might make things easier in the future. Your job as a software engineer is to choose the right one.&#xA;Which one is right? You can probably guess what my answer is.</description>
    </item>
    <item>
      <title>Respect The Problem</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/05/09/</link>
      <pubDate>Fri, 09 May 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/05/09/</guid>
      <description>The other day I ran across a really interesting quote.&#xA;The bottom line here is that you have to respect the problem. &amp;hellip; There’s no silver bullet solution to just linearise them and wish them away.&#xA;&amp;ndash; Dan Davies&#xA;Now that was in the context government regulation and the environment, but the quote can be applied just as well to many different environments.&#xA;Such as software development. When you’re trying to solve a user’s problem, you have to understand their problem.</description>
    </item>
    <item>
      <title>Dijkstra On Bugs</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/05/07/</link>
      <pubDate>Wed, 07 May 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/05/07/</guid>
      <description>Unsurprisingly, there are hundreds of quotes about computers and programming by Edsger Dijkstra, and almost all of them are worthy of a post (or two). His work is foundational to much of what we do as software engineers. He was also a prolific, excellent, and memorable communicator. After all, he was the one who came up with Goto Considered Harmful and that one is certainly well known, almost dogma.&#xA;Edgser W.</description>
    </item>
    <item>
      <title>Zero Bugs</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/05/05/</link>
      <pubDate>Mon, 05 May 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/05/05/</guid>
      <description>Back when I worked on boxed products at Microsoft, we had 2-year release cycles. And towards the end of each one was a milestone called Feature Complete. That was the point in the project where all features we expected when we did planning 18 months earlier were done. Or at least the ones that we hadn’t decided to cut because we ran out of time. You would think that after feature complete, we’d be ready to ship.</description>
    </item>
    <item>
      <title>Emergency Procedures</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/05/02/</link>
      <pubDate>Fri, 02 May 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/05/02/</guid>
      <description>The other day I ran into a quote on the internet about the problem with emergency procedures. I generally agree with it. The quote went like this:&#xA;If you wouldn&amp;rsquo;t use your emergency process to deliver normal changes because it&amp;rsquo;s too risky, why the hell would you use it in an emergency?&#xA;But, as always, It Depends. It’s about the risk/reward ratio. You want the ratio to be low. If the system is down, the risk of breaking the system is low.</description>
    </item>
    <item>
      <title>Careers are Non-Linear</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/04/30/</link>
      <pubDate>Wed, 30 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/04/30/</guid>
      <description>Hiring has been on my mind lately. I’ve been looking for an entry level developer. Someone just starting out in their career. I’ve described the arc of my career before. In fact, I came up with what I think is a pretty novel (and useful) way to describe the arc of a career. It’s also good for helping you visualize where you are at any given point compared to your company’s (or more specifically your managers) expectations.</description>
    </item>
    <item>
      <title>People Over Process</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/04/29/</link>
      <pubDate>Tue, 29 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/04/29/</guid>
      <description>As seen on the internet&#xA;People over process.&#xA;Why?&#xA;Because systems can&amp;rsquo;t fix problems with people, but people can fix problems with systems.&#xA;People Over Process is from the Agile Manifesto. There’s a lot to unpack there. It starts by acknowledging that the software development is a socio-technical endeavor. There are people (that’s the socio part). But there are also tools and rules and processes, which makes it technical.&#xA;Socio-Technical Theory</description>
    </item>
    <item>
      <title>The Power Of Examples</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/04/28/</link>
      <pubDate>Mon, 28 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/04/28/</guid>
      <description>I’ve subscribed to Kent Beck’s Tidy First substack, and there’s lots of useful info there. He just posted a piece on Why TDD doesn’t Lead to Dumb Code. As usual, it’s a really good entry.&#xA;But what really stood out to me in that post was not what he was saying, but how he was saying it. In particular, his use of an example. Beck is trying to answer why TDD doesn’t lead to overly specific code.</description>
    </item>
    <item>
      <title>Biases: The Tyranny Of Or</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/04/25/</link>
      <pubDate>Fri, 25 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/04/25/</guid>
      <description>I’ve mentioned the Tyranny of Or many times, I talked directly about it four years ago, and I stand by what I said. However, because OR is such a loaded word there’s more to say. And, I get to use the Agile Manifesto and how it’s often mistakenly applied as an example.&#xA;To recap, the Tyranny of Or is any time you are forced into, or have convinced yourself, that you are in a situation where you need to make a choice between two options.</description>
    </item>
    <item>
      <title>Simple or Easy?</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/04/24/</link>
      <pubDate>Thu, 24 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/04/24/</guid>
      <description>Here’s a question for you. What’s the difference between simple and easy? Are they different, are they the same, or is one a superset of the other? If you had to choose one, which would you choose? And why?&#xA;First, let’s see what Sir Merriam-Webster&amp;rsquo;s reliable book has to say.&#xA;SIMPLE&#xA;readily understood or performed&#xA;simple directions&#xA;the adjustment was simple to make&#xA;EASY&#xA;requiring or indicating little effort, thought, or reflection</description>
    </item>
    <item>
      <title>Governing the Commons</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/04/23/</link>
      <pubDate>Wed, 23 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/04/23/</guid>
      <description>Adding to my book reviews, consider Governing the Commons by Elinor Ostrom. You might wonder what a book about Turkish fisheries, Swiss grazing pastures, Japanese forests, and Spanish and Philippine water systems has to do with software development. It does seem to be a bit of a stretch.&#xA;Some background first. The common part is all about what the Commons actually are. In this case, it’s the same commons talked about in The Tragedy of the Commons.</description>
    </item>
    <item>
      <title>More Error Types</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/04/22/</link>
      <pubDate>Tue, 22 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/04/22/</guid>
      <description>I’ve talked about Type I (False Positive) and Type II (False Negative) errors before. While it would have been so much better if they just called them False Positive and False Negative cases, they only cover part of the problem. A more complete list would include the Type III (the right answer to the wrong problem) and Type IV (the right answer for the wrong reason) errors.&#xA;The Type III error ought to be innocuous.</description>
    </item>
    <item>
      <title>Strong Opinions, Loosely Held - Part 2</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/04/21/</link>
      <pubDate>Mon, 21 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/04/21/</guid>
      <description>A while ago I talked about Strong Opinions, Loosely Held. I talked about the problem with people with structural power (the HiPPO) having strong opinions and how those opinions often get too much weight.&#xA;The HiPPO Timo Elliott&#xA;As Jim Barksdale of Netscape once said,&#xA;&amp;ldquo;If we have data, let’s look at data. If all we have are opinions, let’s go with mine.&amp;rdquo;&#xA;Doing that can easily get you into trouble, because being a HiPPO doesn’t make it right.</description>
    </item>
    <item>
      <title>Virtuous tests</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/04/18/</link>
      <pubDate>Fri, 18 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/04/18/</guid>
      <description>I’ve talked about the different kinds of tests. I’ve talked about when to run the different kinds of tests. I’ve said that your tests need to be good tests. All of that is true. What I haven’t done is talk about what makes a good test.&#xA;Of course, the answer to the question of what makes a test good is, It Depends. Mostly it depends on what kind of test you’re writing and when you’re running it.</description>
    </item>
    <item>
      <title>Code Virtues</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/04/17/</link>
      <pubDate>Thu, 17 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/04/17/</guid>
      <description>I’ve talked about code smells before. Just the other day I talked about comments as a smell. What about the opposite? Are there code virtues?&#xA;Of course there are. Things that we want our code to have. In fact, the Pragmatic Programmers published a list back in 2011&#xA;Pragmatic Programmers&#xA;Because English is a slippery language and, as Humpty Dumpty said, words can mean what we choose them to mean, each virtue is given as not only what it is, but what it isn’t.</description>
    </item>
    <item>
      <title>Motivation</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/04/16/</link>
      <pubDate>Wed, 16 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/04/16/</guid>
      <description>Motivation is a funny thing. If there’s a lot of motivation, it can make us do certain things. It can make us not do certain things. It can make us try to do everything. It can make us do nothing. It can make us focus solely on one thing, It can blind us.&#xA;On the other hand, if there’s no motivation, nothing happens.&#xA;Motivation is funny in another way. There are two kinds of motivation.</description>
    </item>
    <item>
      <title>Comments Are A Smell</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/04/15/</link>
      <pubDate>Tue, 15 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/04/15/</guid>
      <description>I’ve talked about comments in the past. Comments are a code smell, right? Maybe, or maybe not. It depends. Like so many things in the software world, a recommendation phrased as a comparison has been turned into a binary flag.&#xA;Why that happens is understandable. Binary is easy. True/False. 1/0. So easy even a computer can understand it. It reduces cognitive load. On the other hand, comparisons and value statements are hard.</description>
    </item>
    <item>
      <title>Diffusion Of Responsibility</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/04/14/</link>
      <pubDate>Mon, 14 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/04/14/</guid>
      <description>I’ve talked about ownership before. I’ve even mentioned diffusion of responsibility a couple of times. But I haven’t really talked about it. It’s time to talk about it.&#xA;I’m a grandfather now. Have been for almost a year. It’s amazing watching my granddaughter grow and learn. It’s also mazing watching my daughter learn about being a parent, just like I did many years ago. Unsurprisingly, we have many of the same opinions on how to raise a child, but it’s about 30 years later, so we’ve all learned a few things and advice has changed.</description>
    </item>
    <item>
      <title>Code Coverage Is Not Enough</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/04/11/</link>
      <pubDate>Fri, 11 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/04/11/</guid>
      <description>Tales from the real word today. Code coverage is important. It can give you confidence. It can help you move faster. It can alert you to problems before they get exposed to your users. But it’s no guarantee of correctness.&#xA;Bad Tests The first problem is that 100% code coverage does not in any way guarantee that the tests you’re using to measure your coverage are valid tests. Writing good unit tests is hard.</description>
    </item>
    <item>
      <title>The Finish Line Is Just Another Milestone</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/04/10/</link>
      <pubDate>Wed, 09 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/04/10/</guid>
      <description>Speaking of remodeling updating your code, If you’re releasing a new version of your code, that means you’ve already released a version of your code. That means that at some time in the past, you finished your code. Or at least thought you did. But now, here you are releasing a new version. So I guess you weren’t done. Or to put it another way,&#xA;The finish line is just another milestone.</description>
    </item>
    <item>
      <title>Home Ownership and Software Updates</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/04/09/</link>
      <pubDate>Tue, 08 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/04/09/</guid>
      <description>Seen on Bluesky&#xA;Homeownership is a lifelong commitment to discovering what it takes to modernize a legacy system and the lengths to which you will go and compromises you will make in doing so.&#xA;It’s often been said that software development is like home construction. You have a site, some requirements, a plan, you start to build, then you adjust as needed. There’s some truth to that, and from far enough away, it’s accurate.</description>
    </item>
    <item>
      <title>Verification First Development</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/04/08/</link>
      <pubDate>Tue, 08 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/04/08/</guid>
      <description>From the “Listen to Hillel” file, an article on Verification First Development. I really like the idea of Test Driven Development, but I have to be honest. I don’t always do it. Sometimes I practice Test After Development. Meaning I write my tests to verify that the code I wrote does what I wanted it to do. But after reading Hillel’s article, I realized that even though I sometimes write my tests after, I almost always know how I’m going to verify it.</description>
    </item>
    <item>
      <title>Safety Nets and Guardrails</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/04/07/</link>
      <pubDate>Mon, 07 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/04/07/</guid>
      <description>Safety nets and guardrails sound like the same thing, but they’re not. They are very similar though. They both help prevent bad things from happening. Where they differ is in how and when they operate.&#xA;Safety nets help after something bad has happened. It’s what you do when things go wrong. Your traditional safety net catches something that has fallen. It could be a person off a roof, or a trapeze artist that missed a catch.</description>
    </item>
    <item>
      <title>With Apologies to Uncle Bob</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/04/04/</link>
      <pubDate>Fri, 04 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/04/04/</guid>
      <description>From the design by counter-example file, this might be the most practical definition of “unclean” code I’ve ever seen.&#xA;In the kitchen, the stuff I left on the counter is fine, I know why it&amp;rsquo;s there. Everything my family leaves on the counter is mess.&#xA;In our own software, we don&amp;rsquo;t trip over the rough edges, we can fix those later. For everyone else, our software is rough.&#xA;&amp;ndash; Jessica Joy Kerr</description>
    </item>
    <item>
      <title>Testing Schedules</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/04/03/</link>
      <pubDate>Thu, 03 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/04/03/</guid>
      <description>Yesterday I talked about different kinds of tests, unit, integration, and system. I mentioned that not only are there different kinds of tests, but those tests have different characteristics. In addition to the differences in what you can learn from tests by classification, there are also differences in execution times and execution costs.&#xA;NB: This is semi-orthogonal to test driven development. When you run the tests is not the same as when you write the tests.</description>
    </item>
    <item>
      <title>Test Classification</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/04/02/</link>
      <pubDate>Wed, 02 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/04/02/</guid>
      <description>Whether you are thinking about unit vs integration vs system tests, or build (or save) time vs check in time vs release time tests, what you’re really thinking about is test classification and test hierarchy. Or put another way, you’re thinking about why you’re running that test and what the goal of the test is.&#xA;Of course you want the test to pass. And you want that pass to mean something.</description>
    </item>
    <item>
      <title>I&#39;m Back</title>
      <link>https://friendgineers.rosenshein.org/posts/2025/04/01/</link>
      <pubDate>Tue, 01 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2025/04/01/</guid>
      <description>It’s been a while since I’ve published a new entry. Not because I haven’t thought of things, but because I got sidetracked with life and work for a bit, then I got out of the habit of writing. Which is a great topic to write about. So here I go. Talking about writing. And habits. And personal lessons.&#xA;We all have free will. We get to decide what we want to do.</description>
    </item>
    <item>
      <title>On Busyness</title>
      <link>https://friendgineers.rosenshein.org/posts/2024/07/16/</link>
      <pubDate>Tue, 16 Jul 2024 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2024/07/16/</guid>
      <description>As I’ve mentioned previously, Winnie the Pooh makes a great coach for folks interested in extreme programming. Things are the way they are and we have to live with what is. We can learn from it. We can change it. But we have to deal with the reality of what is.&#xA;There’s another part of the Tao Of Pooh we can learn from. It’s the Bisy Backson.&#xA;In the book, Rabbit is looking for Christopher Robin, but instead of finding him, Rabbit finds the note above.</description>
    </item>
    <item>
      <title>That&#39;s The Way It Is</title>
      <link>https://friendgineers.rosenshein.org/posts/2024/04/19/</link>
      <pubDate>Fri, 19 Apr 2024 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2024/04/19/</guid>
      <description>I’ve said before that It Depends is just E_INSUFFICIENT_CONTEXT written so humans can understand it. There’s another common phrase that often hides a much deeper meaning.&#xA;That’s Just How It Is The thing about that sentence is how passive and accepting it is. Particularly in the word just1. Without just it’s a description of the current state. Adding just adds another whole dimension. It changes the sentence for a description of what is to a comment on what is.</description>
    </item>
    <item>
      <title>The Power Of No</title>
      <link>https://friendgineers.rosenshein.org/posts/2024/04/16/</link>
      <pubDate>Tue, 16 Apr 2024 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2024/04/16/</guid>
      <description>A long time ago I read a story by Eric Frank Russell, And Then There Were None. On the surface it&amp;rsquo;s a typical re-contact story. There was a great diaspora during which hundreds or thousands of interstellar ships left Earth to start new colonies. Shortly afterward, something happened, and contact was lost with all of them. Now, four hundred years later, the people or Earth are trying to reconnect with those colonies.</description>
    </item>
    <item>
      <title>What Are You Waiting For?</title>
      <link>https://friendgineers.rosenshein.org/posts/2024/03/28/</link>
      <pubDate>Thu, 28 Mar 2024 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2024/03/28/</guid>
      <description>I’ve talked about the Eisenhower matrix before. Two orthogonal axes, importance, and urgency. It’s a good way to prioritize. The higher and further to the right, the higher the priority.&#xA;Another way to look at things is task priority, Leverage, Neutral, or Overhead. They all need to be done, but things with leverage are higher priority.&#xA;Or maybe you prefer the MoSCoW method. Must, Should, Could, and just as important, Won’t.</description>
    </item>
    <item>
      <title>You ARE Allowed To Think Before You Type</title>
      <link>https://friendgineers.rosenshein.org/posts/2024/03/26/</link>
      <pubDate>Tue, 26 Mar 2024 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2024/03/26/</guid>
      <description>I’m a big proponent of agile (lower case a) development practices and Test Driven Development (TDD) in particular. In my experience it conforms to the reality of changing understanding and moving requirements much better than BDUF. Like many things, there’s a spectrum ranging from BDUF to “Start typing and see what you come up with”. And in some specific scenarios, either one of those might be the right choice. But for the vast majority of us, in the vast majority of cases, the best choice is somewhere in the middle.</description>
    </item>
    <item>
      <title>10 Commandments of Code Review</title>
      <link>https://friendgineers.rosenshein.org/posts/2024/03/19/</link>
      <pubDate>Tue, 19 Mar 2024 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2024/03/19/</guid>
      <description>Programming is a social activity. We work with other people, not in a vacuum. We share code with other people. We share ownership of code with other people. We share responsibility for code with other people. The sharing goes the other way as well. Others share their use cases, their requirements, and their experiences. One of the places where all of that comes together is in a code review.&#xA;In some cases, such as pair or mob programming, code review is a synchronous, ongoing activity, but that’s not what I’m going to talk about now.</description>
    </item>
    <item>
      <title>Optionality</title>
      <link>https://friendgineers.rosenshein.org/posts/2024/03/15/</link>
      <pubDate>Fri, 15 Mar 2024 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2024/03/15/</guid>
      <description>There are lots of reasons to have high internal software quality (ISQ). Minimizing WTFs/min is only one of them. One of the biggest reasons is not what ISQ does for you today, but what it will do for you tomorrow. The optionality it gives you for the future.&#xA;So what is optionality, and why should we care?&#xA;optionality (countable and uncountable, plural optionalities)&#xA;(finance, business) The value of additional optional investment opportunities available only after having made an initial investment.</description>
    </item>
    <item>
      <title>Review Your Own Code Review</title>
      <link>https://friendgineers.rosenshein.org/posts/2024/03/04/</link>
      <pubDate>Mon, 04 Mar 2024 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2024/03/04/</guid>
      <description>I’ve talked about code reviews before. There’s are things you should do when you review code, and there are things you shouldn’t do. Most of those things are about what to do when reviewing someone else’s code. The rest are about what goes into preparing a good code review.&#xA;I stand by those ideas. But there’s on important thing that goes into preparing a good code review that I haven’t mentioned in the past.</description>
    </item>
    <item>
      <title>Demands ...</title>
      <link>https://friendgineers.rosenshein.org/posts/2024/02/29/</link>
      <pubDate>Thu, 29 Feb 2024 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2024/02/29/</guid>
      <description>What if I told you that your time was limited? That the number of things you could get done in any given period was limited? You’d probably say “I know that.” And you do. You know you can’t do everything, and you know you can’t do everything at once. However, you&amp;rsquo;re not in control of what you need to do. Hopefully you&amp;rsquo;re involved in the decision, but while the how is often fully on the development team, the what and the why usually aren&amp;rsquo;t.</description>
    </item>
    <item>
      <title>The Tao Of Pooh</title>
      <link>https://friendgineers.rosenshein.org/posts/2024/02/19/</link>
      <pubDate>Mon, 19 Feb 2024 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2024/02/19/</guid>
      <description>I’ve always liked Winnie the Pooh. He may say he’s a bear of very little brain, but I think he’s got a lot of deep understanding that we could all benefit from.&#xA;While I’m reasonably sure Pooh was not an extreme programmer, that’s not a bad paraphrase of what extreme programming and the agile manifesto are getting at. Do the work and the work will show you what needs to be done.</description>
    </item>
    <item>
      <title>Primitive Obsession and Boolean Blindness</title>
      <link>https://friendgineers.rosenshein.org/posts/2024/02/14/</link>
      <pubDate>Wed, 14 Feb 2024 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2024/02/14/</guid>
      <description>George Boole brought us Boolean algebra. There&amp;rsquo;s tremendous benefit in using it. Boolean algegra is one of the foundations of computer science and factors into a lot of what we do as developers. But sometimes, it can also blind you to a deeper truth.&#xA;I’ve talked about primitive obsession before. It’s where you use a base type to represent a specific domain type. Like storing a URI as a string, It works, and its faster at first, but it’s also very limiting.</description>
    </item>
    <item>
      <title>Deploying vs. Releasing</title>
      <link>https://friendgineers.rosenshein.org/posts/2024/02/09/</link>
      <pubDate>Fri, 09 Feb 2024 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2024/02/09/</guid>
      <description>Today’s thought is courtesy of the inimitable @mipsytipsy (Charity Majors).&#xA;Deploys and releases are two different things:&#xA;DEPLOY &amp;ndash; building, testing, and rolling out new code changes; hopefully small, incremental ones, very often&#xA;RELEASE &amp;ndash; changing user experience in some meaningful way (not just minor bug fixes)&#xA;Sounds simple, no? In reality we confuse the two all the time. Or at least conflate them. Every deployment changes how things behave. And the only way to change it is to deploy again.</description>
    </item>
    <item>
      <title>Let It Flow</title>
      <link>https://friendgineers.rosenshein.org/posts/2024/02/06/</link>
      <pubDate>Tue, 06 Feb 2024 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2024/02/06/</guid>
      <description>Like many things, I’ve talked about Flow and WIP before. The idea that what you want to optimize for is getting things done, not doing things. That’s a pretty subtle difference, but it’s an important one.&#xA;Or as it was said in Principle of Product Development Flow,&#xA;In product development, our problem is virtually never motionless engineers. It is almost always motionless work products.&#xA;&amp;ndash; Donald Reinertsen&#xA;So much of how we work is designed to keep us busy.</description>
    </item>
    <item>
      <title>K. I. S. S.</title>
      <link>https://friendgineers.rosenshein.org/posts/2024/02/02/</link>
      <pubDate>Fri, 02 Feb 2024 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2024/02/02/</guid>
      <description>This is something I keep coming back to. Whether it’s talking about The Unix Way or the difference between complicated and complex, we seem to like complexity.&#xA;Developers are drawn to complexity like moths to a flame, often with the same outcome&#xA;&amp;ndash; Neal Ford&#xA;It’s not surprising. It’s in the nature of the problems we’re trying to solve. We’re often dealing with large problems in real-world situations. People are involved, and people are complex.</description>
    </item>
    <item>
      <title>Adding Estimates</title>
      <link>https://friendgineers.rosenshein.org/posts/2024/01/30/</link>
      <pubDate>Tue, 30 Jan 2024 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2024/01/30/</guid>
      <description>I’ve talked about estimation many times before. I’ve talked about Kent Beck, and I’ve talked about Hillel Wayne. Today I’m going to talk about all three of them at once. I’m not sure how directly this applies to development, but I’m pretty sure there’s something there. Maybe I&amp;rsquo;ll have it by the end of the post.&#xA;Beck recently wrote about private estimates and public progress. What it basically came down to was that the entire team gets together on Monday and decides what they think they can get done that week, given all they know of the situation, the priorities, and the goals.</description>
    </item>
    <item>
      <title>You Broke What?</title>
      <link>https://friendgineers.rosenshein.org/posts/2024/01/24/</link>
      <pubDate>Wed, 24 Jan 2024 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2024/01/24/</guid>
      <description>They say with motorcycles there are riders that have laid their bike down at least once, and there are riders that will lay there bike down in the future. That there are no other kinds of riders. I’m not a motorcycle rider, so I can’t comment on the accuracy of that statement or not.&#xA;I am, however, a software developer, and I can say that there are 10 kinds of developers.</description>
    </item>
    <item>
      <title>The Dude Abides</title>
      <link>https://friendgineers.rosenshein.org/posts/2024/01/18/</link>
      <pubDate>Thu, 18 Jan 2024 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2024/01/18/</guid>
      <description>The Big Lebowski is a cult classic from the late 90s. It’s all about Jeff “The Dude” Lebowski and a series of events and (mis)adventures that happen to and around him. There are many quotable lines, but one of the most quoted, one that shows up on posters, shirts, memes everywhere, and is the last line The Dude says in the movie, is “The Dude abides.” It’s a paraphrase of a line in Ecclesiastes</description>
    </item>
    <item>
      <title>Skill Vs. Experience</title>
      <link>https://friendgineers.rosenshein.org/posts/2024/01/12/</link>
      <pubDate>Fri, 12 Jan 2024 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2024/01/12/</guid>
      <description>Skill and experience can have a lot in common. If you have a lot of experience doing something, you can become very skilled at doing it. Alternatively, you can be very skilled at doing something, and that can take the place of spending time gaining experience.&#xA;Consider this video of a technically skilled mountaineer and a monk walking up a mountain.&#xA;There should have been a video /video/skillvsexperience.mp4 Skills Vs Experience</description>
    </item>
    <item>
      <title>Time Periods</title>
      <link>https://friendgineers.rosenshein.org/posts/2024/01/08/</link>
      <pubDate>Mon, 08 Jan 2024 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2024/01/08/</guid>
      <description>From Star Trek to Hofstadter&amp;rsquo;s Law, estimates are always a conundrum. There are lots of articles about it on the web, but here’s Ron Jeffries about it and it’s a really good place to start.&#xA;To me, the problem is not the estimates themselves, or the idea that you’re trying to measure something that is neither precisely or accurately measurable, but in what happens to after you make the estimate.</description>
    </item>
    <item>
      <title>Doing It Well And Truly</title>
      <link>https://friendgineers.rosenshein.org/posts/2024/01/05/</link>
      <pubDate>Fri, 05 Jan 2024 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2024/01/05/</guid>
      <description>I’ve always been a reader of science fiction. In particular, the kind of science fiction where knowledge and competence make a difference. Stories like Andy Weir’s The Martian. Or Lucifer’s Hammer. There’s nothing magical or particularly special about the protagonists, they’re just competent. And lucky. And most importantly, they do the thing. They do it well and truly. But most importantly, they do it. The don’t (only) talk about doing it.</description>
    </item>
    <item>
      <title>A look at 2023</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/12/31/</link>
      <pubDate>Sun, 31 Dec 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/12/31/</guid>
      <description>Happy New Year! Time for my yearly retrospective. Big changes on the work front. I started the year working at Amazon on their Just Walk Out technology, but then got moved to a new initiative. The work was interesting, and from what I hear, going well, but Amazon and that project weren&amp;rsquo;t a good fit for me, so after a year at Amazon, I started looking around for something different.</description>
    </item>
    <item>
      <title>McDonald&#39;s</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/12/26/</link>
      <pubDate>Tue, 26 Dec 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/12/26/</guid>
      <description>I’ve been a subscriber of Kent Beck’s Tidy First? since almost it’s beginning. If you don’t have a copy of the book, consider picking one up. There’s a lot of good stuff in there. Not just things to do, but when and why to do them.&#xA;Since then, Kent’s been talking about his Thinkies, which are questions (or statements) designed to induce movement and provide you with more options and help you reach a decision.</description>
    </item>
    <item>
      <title>Strong opinions, Loosely Held</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/12/08/</link>
      <pubDate>Fri, 08 Dec 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/12/08/</guid>
      <description>Everyone’s got opinions. Some strong we feel strongly about, some not so much. Some we are willing to consider changing our minds on, others we aren’t. How you balance how strong your opinion is and how hard you hold on to it is the challenge. It’s easy to hold on to something too tightly or for too long.&#xA;That’s why companies have policies like Disagree and Commit, Meritocracy and Toe Stepping, No Jerks, or No A**holes.</description>
    </item>
    <item>
      <title>Stop Designing</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/12/06/</link>
      <pubDate>Wed, 06 Dec 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/12/06/</guid>
      <description>Stop designing up front the moment you start speculating.&#xA;&amp;ndash; Kent Beck&#xA;That’s a pretty bold statement. After all, how much do you really know about what you’re going to need to do at the beginning? At the beginning of a project (or feature, or task, or bug investigation) all you know is a rough idea of the problem to solve, not how you’re going to solve it.&#xA;To me, what Kent is saying isn’t that you should only do design on things that are known/fixed/unchangeable, but that the level of detail of the design should match the level of detail of what you know.</description>
    </item>
    <item>
      <title>Break It Down, Even At Small Scale</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/11/03/</link>
      <pubDate>Fri, 03 Nov 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/11/03/</guid>
      <description>I’ve talked about taking breaking things down many times. I think it’s a really good idea. I’ve talked about how it applies to commits, pull requests, and projects in general. It can help you move faster and be more responsive to both changing conditions and things you learn along the way.&#xA;It also applies at smaller scales. You can have one huge, long method, or you can break the method down into logical parts, with another method around it to manage data flow and decision making.</description>
    </item>
    <item>
      <title>It&#39;s A Trap</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/10/27/</link>
      <pubDate>Fri, 27 Oct 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/10/27/</guid>
      <description>Overheard:&#xA;… coming from another language and trying to find the library that makes it look like the language you came from is a trap&#xA;Pretty much all of the languages we write code in today are turing complete, meaning they can be used to write a program that does just about anything you want. That means all languages are equivalent, and the choice doesn’t matter, right?&#xA;Wrong And it’s wrong on many levels.</description>
    </item>
    <item>
      <title>Visibility</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/10/19/</link>
      <pubDate>Thu, 19 Oct 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/10/19/</guid>
      <description>I don’t often give career advice. Or rather, while I often talk about what good engineers and developers do, the importance of adding value, and the importance of managing your own career, I rarely talk about specific things you need to do to get a promotion. I’m of the opinion that if you grow and improve yourself, add value, and create and take advantage of opportunities along the way, your work will be recognized and valued.</description>
    </item>
    <item>
      <title>Radiating Information</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/10/12/</link>
      <pubDate>Thu, 12 Oct 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/10/12/</guid>
      <description>According to the Hacker Ethic, per Steven Levy in Hackers, all information should be free. Stewart Brand anthromophized it and noted the tension betweemm the cost of distributing information going down and the value of having the right information at the right time going up. He said&#xA;It seems like there’s a couple of interesting paradoxes we’re working with here. That’s why I’m especially interested in what Bob Wallace has done with PC-WRITE and what Andrew Flugelman did before that with PC-TALK.</description>
    </item>
    <item>
      <title>Perspective</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/10/06/</link>
      <pubDate>Fri, 06 Oct 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/10/06/</guid>
      <description>Perspective is important. Where you see things from changes what you see. Some things are visible from one perspective, but not visible from another. This applies not just to your physical location, but also to your mental location. Your experiences, your history, your expectations, and your biases all have a huge impact on not just what you see, but how you interpret what you see.&#xA;Consider this video of Saturn&amp;rsquo;s small army of moons moving around it.</description>
    </item>
    <item>
      <title>Three More Tells</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/09/29/</link>
      <pubDate>Fri, 29 Sep 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/09/29/</guid>
      <description>A while back I talked about The Three Tells. They weren’t poker tells. Instead, it was tell them what you’re going to tell them, tell it to them, then tell them what you told them. I thought it was a good way to approach a presentation then, and I still think it is today. But that’s old news. Today I’m going to tell you about three different tells. The three tells of Test Driven Development (TDD).</description>
    </item>
    <item>
      <title>Games And Agency</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/09/13/</link>
      <pubDate>Wed, 13 Sep 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/09/13/</guid>
      <description>I recently finished listening to the first chapter of Worlds Beyond Number. It’s a podcast that uses D&amp;amp;D rules to help define a world built for storytelling. Brennan Mulligan is the Dungeon Master (DM) and world builder. He’s responsible for (almost) all of the backstory, pacing, and events. He does an amazing job of not just building a world and making it feel alive, he also provides the context that the three live characters act within.</description>
    </item>
    <item>
      <title>Shallow Hurry</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/09/11/</link>
      <pubDate>Mon, 11 Sep 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/09/11/</guid>
      <description>I ran across the term shallow hurry the other day and it resonated deeply (no pun intended) with me. Shallow hurry means doing just what you’ve been doing, only doing it faster. The expectation is that you’ll get done sooner. And that might even be true. In the short term.&#xA;Typing faster will get your code written a little bit sooner, but there’s a natural limit on that. While there may be times when we’re actually limited by typing speed, that’s not usually the case.</description>
    </item>
    <item>
      <title>Lead With the Why, Not the Way</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/08/02/</link>
      <pubDate>Wed, 02 Aug 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/08/02/</guid>
      <description>Taking a break from the book reviews, but sticking with the theme of software development being a social endeavor, there are many ways to get teams working on things together and doing them in a similar fashion. Some work better than others.&#xA;One of the best ways to make sure that everyone is working together and in a similar fashion is to work ensemble style. If the team is sitting together talking about and editing the same code at the same time then, by definition they’re working together and in a similar fashion.</description>
    </item>
    <item>
      <title>How Buildings Learn</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/07/31/</link>
      <pubDate>Mon, 31 Jul 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/07/31/</guid>
      <description>Now that I’ve written about Seeing Like A State, I want to talk about How Buildings Learn. How Buildings Learn is, in many ways, a counterpoint to Seeing Like a State. It also has a lot of relevance to software design.&#xA;How Buildings Learn starts from the premise that over-architecting is bad. That the best way ensure longevity is to architect not only for the now, but also for the future.</description>
    </item>
    <item>
      <title>Seeing Like a State</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/07/28/</link>
      <pubDate>Fri, 28 Jul 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/07/28/</guid>
      <description>I was going to compare and contrast Scott’s Seeing Like A State with Brand’s How Buildings Learn, but when I went to find the link to what I wrote, I realized that How Buildings Learn is going to have to wait, because, somehow, I haven’t directly talked about Seeing Like A State. I have mentioned legibility though, which is directionally similar.&#xA;In Seeing Like a State, Scott talks about the tendency of the state, really any large organization, to want to be able to measure, record, and control a system.</description>
    </item>
    <item>
      <title>Code Coverage Is NOT useless</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/07/27/</link>
      <pubDate>Thu, 27 Jul 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/07/27/</guid>
      <description>Mini rant today. There are lots of teams across the software industry that are called some variation of “Software Quality”. That’s a lovely term. It means different things to different people. There are (at least) two kinds of quality at play here. Internal software quality (ISQ) and external software quality (ESQ). ESQ is about correctness and suitability for the task at hand. ISQ is about the code itself, not whether or not it works as specified.</description>
    </item>
    <item>
      <title>Fly Like An Eagle</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/07/24/</link>
      <pubDate>Mon, 24 Jul 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/07/24/</guid>
      <description>I’ve talked about time before. It passes, and there’s not much you can do about that. Even in a simulator, time passes. That adds a lot of complexity. Especially in keeping track of things. And when they happened. And when you found out about them. And when someone asks you about it.&#xA;I’ve talked about time and dates being hard to deal with before. Then there’s the winter solstice, which merges time, dates, durations, and the English language.</description>
    </item>
    <item>
      <title>Milestones Vs. Steppingstones</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/06/27/</link>
      <pubDate>Tue, 27 Jun 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/06/27/</guid>
      <description>In software, we’re very familiar with the idea of a milestone, but not steppingstones. Which is odd, because the two terms are very similar. Where does the terms come from? Like many things in the western world, the term milestoone comes from the Roman Empire. The Roman Empire did lots of things throughout Europe and Asia. Some good, some bad. One thing they did really well was build roads. Good, solid roads that you could count on to get you from here to there, regardless of the season or weather.</description>
    </item>
    <item>
      <title>Complexity And Congitive Load</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/06/16/</link>
      <pubDate>Fri, 16 Jun 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/06/16/</guid>
      <description>Software design is not about minimizing design complexity, but rather spending our complexity budget where it can do the most good. — Kent Beck&#xA;Let’s face it. Very often the systems we build are complex. And they’re complex in many different ways. Ways you just need to deal with. And it’s got nothing to do with how easy (or hard) it is to explain the task in English.&#xA;Sometimes the complexity is in the domain.</description>
    </item>
    <item>
      <title>Monolith Is A Deployment Strategy, Not An Architecture</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/06/14/</link>
      <pubDate>Wed, 14 Jun 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/06/14/</guid>
      <description>There was an article a few weeks ago about how the Amazon video team switched one of their tools from a distributed microservice architecture to a monolith that runs/scales on EC2. Does this mark the beginning of the end for microservices? Were we wrong to decompose all those monoliths into microservices? Should we recombine all of our microservices and serverless systems back into monoliths?&#xA;Or, is this just another case of It Depends?</description>
    </item>
    <item>
      <title>0, 1, Many</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/06/12/</link>
      <pubDate>Mon, 12 Jun 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/06/12/</guid>
      <description>Continuing on with looking at numbers, think about counting. We all know how to count. Or we think we do. But do we really think about how we should be counting. Consider the following quote.&#xA;&amp;ldquo;Common programmer thought pattern: there are only three numbers: 0, 1, and n.&amp;rdquo; – Joel Spolsky&#xA;There’s more than a little truth to that statement. After all, from a linguistic standpoint there’s lots of precedent for it.</description>
    </item>
    <item>
      <title>1 &gt; 2 &gt; 0</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/06/09/</link>
      <pubDate>Fri, 09 Jun 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/06/09/</guid>
      <description>I&amp;rsquo;m pretty sure this story is true, because I&amp;rsquo;ve heard it too many times, sometimes from people who could have been there. The people involved and timeline match up. Also, even if it&amp;rsquo;s not true, there&amp;rsquo;s still something to learn.&#xA;Amazon has always been about 2-pizza teams. You should be able to feed an entire team lunch with 2 pizzas. The idea is to keep them agile and innovative. To minimize communications delays and bottlenecks.</description>
    </item>
    <item>
      <title>What You Do Next</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/06/07/</link>
      <pubDate>Wed, 07 Jun 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/06/07/</guid>
      <description>&amp;ldquo;If you hit a wrong note, it&amp;rsquo;s the next note that you play that determines if it&amp;rsquo;s good or bad.&amp;rdquo; –Miles Davis&#xA;That&amp;rsquo;s pretty deep. And it applies to things very far removed from jazz. Things that are very structured and precise. Things like code. Or, maybe, software isn&amp;rsquo;t as structured, precise, and linear as we think.&#xA;Before you get upset and tell me I&amp;rsquo;m nuts (which may be true, but doesn&amp;rsquo;t matter here), I want to be clear.</description>
    </item>
    <item>
      <title>What Are You Testing? II</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/06/05/</link>
      <pubDate>Mon, 05 Jun 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/06/05/</guid>
      <description>I’ve written about what you’re testing before. That article was about writing tests in a way that you could look at the test and understand what it was and wasn’t testing. It’s about writing readable and understandable code, and I stand by that article.&#xA;However, there are other ways to think about what you’re testing. The first, and most obvious way to think about it is thinking about what functionality the test is validating.</description>
    </item>
    <item>
      <title>Release Stabilization</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/06/02/</link>
      <pubDate>Fri, 02 Jun 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/06/02/</guid>
      <description>Release stabilization is traditionally the period at the end of a development cycle where the team minimizes change and spends time fixing things and making sure the result is stable. That sounds like a good thing, doesn&amp;rsquo;t it? And compared to its most obvious opposite, release de-stabilization, it&amp;rsquo;s definitely a good thing. Before you release any software, executable, library, website, whatever, you want to know that its good and that it&amp;rsquo;s stable and resilient to whatever the real world will throw at it, When thought of that way, it&amp;rsquo;s something we should always do.</description>
    </item>
    <item>
      <title>Average Practice</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/05/31/</link>
      <pubDate>Wed, 31 May 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/05/31/</guid>
      <description>I’ve talked about best practices a bunch of times. Generally, in praise of them, with the caveat that context is important. What was the best practice for one team, in one specific situation, might not be the best practice for you in your situation.&#xA;Over time, best practices get diluted. As they get described, and implemented, with less and less connection to the original context which they came out of, the less specific and focused they get.</description>
    </item>
    <item>
      <title>Green Fields And Platforms</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/05/26/</link>
      <pubDate>Fri, 26 May 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/05/26/</guid>
      <description>I recently had the opportunity to work on a greenfield project. You know, the kind of project were you recognize a common problem a set of users have and you have an idea of how to solve the problem for them. It can be a great space to operate in. You have a green field to build your castle in. Sure, you’ve got the eternal constraints of time and resources, but other than that you’re free to innovate.</description>
    </item>
    <item>
      <title>What Is Done?</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/05/24/</link>
      <pubDate>Wed, 24 May 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/05/24/</guid>
      <description>The Definition of Done is an important part of the software development process. I’ve talked about being Done Done and Telling You What I Want before. I’ve also talked about the difference between Stories and Tasks. All of those things tell you about the importance of knowing what done means. There’s also some guidance in there on how to define done.&#xA;What those posts don’t do though, is point out any of the potential hazards along the way.</description>
    </item>
    <item>
      <title>High Quality Quality</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/05/22/</link>
      <pubDate>Mon, 22 May 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/05/22/</guid>
      <description>Before today’s topic, a little housekeeping. After a little over 14 months, I’m back at Aurora. I’ve taken on a Tech Lead Manager role, responsible for measuring and helping to improve software quality in support of Aurora’s mission to deliver self-driving, safely, quickly, and broadly.&#xA;Of course, before you can measure (or improve) something, you need to define what it is. In this case it’s software quality. There are lots of ways to measure software quality.</description>
    </item>
    <item>
      <title>A Problem Vs. The Problem</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/05/11/</link>
      <pubDate>Thu, 11 May 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/05/11/</guid>
      <description>If you&amp;rsquo;re looking for the All Models Are Wrong that was here by mistake, just follow this link.&#xA;I’ve talked about Root Cause Analysis (RCA) before. Otherwise known as “Why did this really happen?” It’s an important tool in deciding if you’re fixing a problem or alleviating a symptom. Both are very doable, and both can be appropriate. The question you need to ask yourself is “What impact do you want the solution you’re coming up with to have?</description>
    </item>
    <item>
      <title>All Models Are Wrong, But Some Are Useful</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/04/11/</link>
      <pubDate>Tue, 11 Apr 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/04/11/</guid>
      <description>As I’ve mentioned before, I’m a mechanical/aerospace engineer by training. My first job out of school was doing simulations to do trade off analysis on different aircraft configurations. Some were studies around mission effectiveness in different combat environments, and others were aerodynamic simulations to see what effect changing flight control software would have. In all of those cases we were using code to represent the various real-world systems and their interactions to predict what the results would be in the field.</description>
    </item>
    <item>
      <title>Mea Culpa, Mea Maxima Culpa</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/03/29/</link>
      <pubDate>Wed, 29 Mar 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/03/29/</guid>
      <description>I goofed. One of the first things to do when you make a mistake is to acknowledge you were wrong. Back in September of 2021 I wrote a piece called Measurement where I listed a bunch of management quotes and said that it&amp;rsquo;s important to use the whole quote, not take part of the quote out of context. I believed that when I said it then, and I still feel that way now.</description>
    </item>
    <item>
      <title>Permission, Approval, and Feedback</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/03/28/</link>
      <pubDate>Tue, 28 Mar 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/03/28/</guid>
      <description>There are endless debates online about the relative merits of code reviews/pull requests vs Ensemble/Mob/Pair programming. I&amp;rsquo;m not going to talk about any of that. You can read about it at one of more of those links.&#xA;I&amp;rsquo;m going to talk about the world that many (most?) developers live in. Requirements are identified. Designs are done. Work is discovered. The work is turned into tasks. Tasks are prioritized. Tasks are selected by / assigned to an individual.</description>
    </item>
    <item>
      <title>Any fool can write code the computer understands.</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/03/24/</link>
      <pubDate>Fri, 24 Mar 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/03/24/</guid>
      <description>Any fool can write code that a computer can understand. Good programmers write code that humans can understand.&#xA;&amp;ndash; Martin Fowler&#xA;I&amp;rsquo;ve talked about that quote, and coding for the maintainer before. I&amp;rsquo;ve mentioned Martin Fowler even more often. However, almost all of those have been more than a year ago, and it&amp;rsquo;s an evergreen topic.&#xA;Over the last 40+ years I&amp;rsquo;ve written code in lots of languages. Various flavors of Ada, assembly, Bash, Basic, C/C++, Cobol, C#, Forth, Fortran, Java, JavaScript, F#, Pascal, Perl, PHP, PL/1, and Python, to name a few.</description>
    </item>
    <item>
      <title>Enter The Conversation</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/03/21/</link>
      <pubDate>Tue, 21 Mar 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/03/21/</guid>
      <description>&amp;ldquo;Always enter the conversation already taking place in the customer’s mind.&amp;rdquo; ~Robert Collier&#xA;Interesting quote. It comes from the sales and marketing world. Basically, it says that your message will be heard better/clearer if what you’re saying fits into what your customer is already thinking than if it’s disconnected.&#xA;That makes sense. Sure, sometimes a cold call really does pique your interest and get you to follow up. The more common response to a cold call, however, is to just say &amp;ldquo;Thanks.</description>
    </item>
    <item>
      <title>Let Me Tell You What I Want</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/03/13/</link>
      <pubDate>Mon, 13 Mar 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/03/13/</guid>
      <description>I&amp;rsquo;ve talked about user stories and ISBAT before. The idea that a user story should be focused on something the user wants to accomplish. The acceptance criteria (AC) should show how the result adds value to the user. While the AC&amp;rsquo;s are about the definition of done, they&amp;rsquo;re not about the steps along the way.&#xA;Very often however, user stories, especially on backlogs and on teams that work as groups of individuals, turn into tasks.</description>
    </item>
    <item>
      <title>The Audience Is Listening</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/03/01/</link>
      <pubDate>Wed, 01 Mar 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/03/01/</guid>
      <description>There are lots of ways to present information. When you’ve got some information you want to share it’s your responsibility share it well. There are lots of things to think about. Of course, you need to make sure the information you want to share is presented clearly, but that’s only the most basic, obvious, part.&#xA;Another thing to keep in mind is context. The context that you share with the people you’re talking to.</description>
    </item>
    <item>
      <title>Incident Response</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/02/24/</link>
      <pubDate>Fri, 24 Feb 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/02/24/</guid>
      <description>As I’ve mentioned before, I’m a Mechanical/Aerospace Engineer by training, and plane geek. One thing I’ve noticed is that there’s a lot that software engineers can learn from aerospace engineers and aviation in general. One of those things is incident response.&#xA;A few days ago a couple of Alaska Airlines jets headed for Hawaii had tail strikes, within 6 minutes of each other.&#xA;Now tail strikes happen occasionally. There’s a procedure for it.</description>
    </item>
    <item>
      <title>Done Done</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/02/20/</link>
      <pubDate>Mon, 20 Feb 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/02/20/</guid>
      <description>One of the questions that gets asked a lot when you’re working on somethings is “When will it be done?” Lots of people want to know, for lots of good reasons. Leaving aside all of the questions around how to estimate (story points, blink estimation, bduf, etc), or if you should not even estimate at all, there’s still the question of what Done means.&#xA;This is where it gets interesting. According to Scrum, the definition of done is</description>
    </item>
    <item>
      <title>Engineering Project Risks</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/02/17/</link>
      <pubDate>Fri, 17 Feb 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/02/17/</guid>
      <description>I’ve mentioned Gergely Orosz before. He currently writes the Pragmatic Engineer Newsletter and has worked at Uber, Skype, and other places before deciding to write his newsletter full time. He’s written about lots of interesting things, so check out his newsletter if you get a chance.&#xA;For those who haven’t subscribed to his newsletter, he also posts teasers and summaries on Twitter. One of them is about Engineering Project Risks. 7 types of risks and how to manage them.</description>
    </item>
    <item>
      <title>E_INSUFFICIENT_CONTEXT</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/02/15/</link>
      <pubDate>Wed, 15 Feb 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/02/15/</guid>
      <description>As I mentioned the other day, I say “It depends” a lot. Then I go on to describe why it depends in that particular case. Yesterday I ran into a very short Mastodon Toot that is the underlying reason it depends.&#xA;“It depends” is human for E_INSUFFICIENT_CONTEXT_PROVIDED&#xA;The more I thought about it, the more true it became. It’s just that simple. At least the reason “it depends” is that simple.</description>
    </item>
    <item>
      <title>Don&#39;t Be Too DRY</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/02/10/</link>
      <pubDate>Fri, 10 Feb 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/02/10/</guid>
      <description>DRY, or Don&amp;rsquo;t Repeat Yourself is a good rule of thumb. Like all other rules of thumb though, if you were to ask me if you should remove some specific bit of duplication, my answer would be &amp;ldquo;It depends&amp;rdquo;.&#xA;On the other hand, one of the Go Proverbs is, as Rob Pike tells us,&#xA;A little copying is better than a little dependency&#xA;So, when should you stay dry, and when should repeat yourself?</description>
    </item>
    <item>
      <title>Lies, Damn Lies, And Statistics</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/02/09/</link>
      <pubDate>Thu, 09 Feb 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/02/09/</guid>
      <description>When you&amp;rsquo;re running code in production, metrics are important. You need to know that things are working correctly. You need to know when things are starting to go in the wrong direction before any of your users or customers notice. Metrics can tell you that.&#xA;The problem with metrics at scale is that, in order to make sense of them, they&amp;rsquo;re often aggregates. Mean, median, mode, p90, and p95. All ways to turn lots of numbers into a single representative number.</description>
    </item>
    <item>
      <title>Pass or Fail?</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/02/06/</link>
      <pubDate>Mon, 06 Feb 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/02/06/</guid>
      <description>We say a test passes when the results are as expected and that it fails when one or more of them is not. When one or more asserts fails. That makes sense. When you take a test in school and get the right answers you pass. If you don’t, you fail.&#xA;When you took that test in school and got the right answers who passed? You, or the test? It’s been a long time, but the last time I took a test in school I got enough correct answers.</description>
    </item>
    <item>
      <title>Autonomy, Alignment, Purpose, and Urgency</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/01/31/</link>
      <pubDate>Tue, 31 Jan 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/01/31/</guid>
      <description>I&amp;rsquo;ve talked about Autonomy, Alignment, Purpose, and Urgency before. What I haven&amp;rsquo;t done much of is compare and relate them. Particularly the Autonomy/Alignment and Purpose/Urgency pairs.&#xA;Autonomy is great. You get to decide what you (and/or your team) do. You decide what you think is important and you go do it. You expect the work to be impactful, and you get to have fun doing it. Ask for forgiveness instead of permission.</description>
    </item>
    <item>
      <title>The Immutable Past</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/01/25/</link>
      <pubDate>Wed, 25 Jan 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/01/25/</guid>
      <description>Comments are important. I’ve written about them a bunch of times. Comments in docs. Comments in code. Comments in git commits and PRs. As an aside, git commit messages and Pull Request messages are often very different things with different intents.&#xA;All the old things still apply. Comment about why you did something, not what. Comment about what you decided to not do. Comment about when you might revisit the decision.</description>
    </item>
    <item>
      <title>The Law Of Instruments</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/01/23/</link>
      <pubDate>Mon, 23 Jan 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/01/23/</guid>
      <description>if all you have is a hammer, all you see are nails.&#xA;&amp;ndash; Kaplan, Maslow, et al.&#xA;That’s not exactly what Maslow and the others said, but that’s a pretty common paraphrase. And it’s true. If the only tool you have is a hammer, you tend to treat every problem as a nail and pound on it until the problem is gone. Not necessarily solved, but at least it’s gone.</description>
    </item>
    <item>
      <title>Effective Software Engineers</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/01/19/</link>
      <pubDate>Thu, 19 Jan 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/01/19/</guid>
      <description>What do you think of when you think of effective software engineers? Do you think of things like knowledge of frameworks, libraries, and technologies, an understanding of Big O notation and data structures, or maybe the ability to write code fast? I know a lot of people go in that direction when they think of effective engineers. While I agree that those things are important to being a good programmer, I think being a good engineer, software or otherwise, requires an entirely different set of skills.</description>
    </item>
    <item>
      <title>Breaker Breaker Rubber Duck</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/01/13/</link>
      <pubDate>Fri, 13 Jan 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/01/13/</guid>
      <description>When I think about rubber ducks I think of two things. I think about Ernie singing in his bathtub and I think about the old C. W. McCall song, Convoy. And they&amp;rsquo;re both relevant here. Ernie is talking to his rubber duck. talking through his thoughts and plans. In Convoy, anti-establishment as it was, Rubber Duck, the lead driver in the convoy, recognizes that driving, as solitary as you are in the cab of your truck traveling down the interstate, is something you do with others.</description>
    </item>
    <item>
      <title>Forward Compatability</title>
      <link>https://friendgineers.rosenshein.org/posts/2023/01/03/</link>
      <pubDate>Tue, 03 Jan 2023 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2023/01/03/</guid>
      <description>Before I get into today’s topic, a little flashback. Since December 29th, we’ve had 4 days with measurable snow. The first one, over 2 days was a wet, heavy (for Colorado) foot of snow, the other two were more typical front range snows, 2 inches of light powder. But it never got that warm and sunny, so it’s been building up. It’s also been melting and refreezing. Which reminded me of this post abut YAGNI.</description>
    </item>
    <item>
      <title>Another Year In Review</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/12/30/</link>
      <pubDate>Fri, 30 Dec 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/12/30/</guid>
      <description>It’s the last day of the year and time for my annual look back. It’s been a busy year. At home, at work, and on the blog. On the work front, at the beginning of the year I had just started working from home again because of the Marshal Fire. A few weeks later cleaning was finished and I started working from the office again. There weren’t many people there, but it was good to not work alone.</description>
    </item>
    <item>
      <title>Beware Of Bugs</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/12/27/</link>
      <pubDate>Tue, 27 Dec 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/12/27/</guid>
      <description>&amp;ldquo;Beware of bugs in the above code; I have only proved it correct, not tried it.&amp;rdquo; – Donald Knuth&#xA;What does that statement even mean? Assuming the proof is correct, and I have no reason to doubt it, how can something be proven correct and still have bugs? There&amp;rsquo;s a lot to unpack in that statement.&#xA;First of all, how do you prove something is correct? There are formal/logical proofs that start with axioms and then prove a statement based on those axioms.</description>
    </item>
    <item>
      <title>Happy Winter Solstice</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/12/21/</link>
      <pubDate>Wed, 21 Dec 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/12/21/</guid>
      <description>Today is the Winter Solstice in the northern hemisphere. The shortest day of the year. And here in Colorado, if the weather prognosticators can be trusted, both a warm and pretty cold day. The high is listed as 51°F and the low as -10°F. Last year on this day it was warmer (63°F), but it hasn’t been that cold since 1998, when it was -17°F. That’s also the biggest swing between high and low temps I could find in the records, which go back to 1928.</description>
    </item>
    <item>
      <title>Latkes</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/12/19/</link>
      <pubDate>Mon, 19 Dec 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/12/19/</guid>
      <description>Yesterday was our 14th annual Latke Fry. Not just any latkes, but vegan, gluten free, Rosenshein latkes. 30+ hours after the cooking began, and I still smell a little like the short order cook I was one summer many years ago.&#xA;After last year’s disappointing 25 pounds of potatoes, this year’s 9 hours of cooking and 40 pounds of potatoes helped me realize something. The limiting factor in how many latkes get eaten and how many pounds of potatoes get used isn’t how hungry folks are, the number of guests, how hard I work, or how pipelined the latke assembly line is.</description>
    </item>
    <item>
      <title>What Are You Testing?</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/12/16/</link>
      <pubDate>Fri, 16 Dec 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/12/16/</guid>
      <description>When writing tests, whether they’re TDD test, Unit tests, Integration tests, or Canary tests, the first thing you need to be sure of is what you’re testing. If you don’t know what you’re testing then how can you know if your test has succeeded? The next thing to do is make sure that what you’re testing is really the thing you want to test. I’ve seen way to many tests that say they’re testing some business logic, but what they really end up testing is either the storage system or some cache along the way.</description>
    </item>
    <item>
      <title>FFS</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/12/12/</link>
      <pubDate>Mon, 12 Dec 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/12/12/</guid>
      <description>Once upon a time, in the before times, when people worked in offices and went to conferences in person, there was a conference called FFS Tech Conference. The format was simple. Every talk title started with FFS, and started with a 15 minute rant by the speaker followed by 15 minutes of questions/discussion. Unfortunately, the conference series never took off, but there are some real gems in that first one.</description>
    </item>
    <item>
      <title>Hello Mother</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/12/09/</link>
      <pubDate>Fri, 09 Dec 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/12/09/</guid>
      <description>Speaking of change and staying the same, today is the anniversary of the mother of all demos.&#xA;54 years ago Douglas Engelbart got on stage at the ACM/IEEE Fall Joint Computer Conference and defined the environment we’re living in today.&#xA;In 90 minutes he showed, on one system, things that had never been seen together before. Things like graphical interfaces, windows, real-time collaboration, hypertext, mice, version control, video conferencing and more.</description>
    </item>
    <item>
      <title>Properties</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/12/07/</link>
      <pubDate>Wed, 07 Dec 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/12/07/</guid>
      <description>Properties are more than squares on a Monopoly™ board. According to dictionary.com, a property is&#xA;that which a person owns; the possession or possessions of a particular owner: goods, land, etc., considered as possessions: a piece of land or real estate: ownership; right of possession, enjoyment, or disposal of anything, especially of something tangible: something at the disposal of a person, a group of persons, or the community or public: an essential or distinctive attribute or quality of a thing: Monopoly uses the first 5 definitions, but I&amp;rsquo;ve been thinking about the sixth version.</description>
    </item>
    <item>
      <title>The More Things Change</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/12/05/</link>
      <pubDate>Mon, 05 Dec 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/12/05/</guid>
      <description>November seems to have slipped away, but I&amp;rsquo;m back now. This peice has been brewing for a while and it&amp;rsquo;s time to share.&#xA;Things sure have changed for developers. The first piece of software I got paid to develop was written in Fortran77 on an Apollo DN4000. The development environment was anything but integrated. I used vim to edit the code, f77 to compile the individual source files into object files, then f77 again, this time with all of the object files, to generate an actual executable file.</description>
    </item>
    <item>
      <title>Omission vs Commission</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/10/10/</link>
      <pubDate>Mon, 10 Oct 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/10/10/</guid>
      <description>Some bugs are bugs of commission. In my experience, it’s most of them. You get an equation wrong. You compare against the wrong, but similarly named, field. Or maybe as simple as flipping a sign in a test. The nice thing about bugs like that is that they’re usually easy to spot. Ideally with your test suite, but even if not, the response is generally wrong, so you notice, and then you fix it.</description>
    </item>
    <item>
      <title>Strange Loop</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/10/07/</link>
      <pubDate>Fri, 07 Oct 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/10/07/</guid>
      <description>Strange Loop Strange is, according to its own website, a multi-disciplinary conference that brings together the developers and thinkers building tomorrow&amp;rsquo;s technology in fields such as emerging languages, alternative databases, concurrency, distributed systems, security, and the web. I’ve had it on my list of things to do one of these years for a while. I’ve heard a rumor that next year is going to be the last one, so I guess I know what I’ll be doing in late September next year.</description>
    </item>
    <item>
      <title>Tensegrity</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/10/04/</link>
      <pubDate>Tue, 04 Oct 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/10/04/</guid>
      <description>It’s been a while since I posted anything. Sometimes life intrudes on posting, but I’m back to posting again. Today’s question is, can you push something with a rope? Sure, you can do it if the rope is short enough that it effectively can’t bend, but what about a longer rope? You can’t. But you can make it look like you’re pushing with a rope. You do it with tensegrity. Tensigrity is not new.</description>
    </item>
    <item>
      <title>More Broken Windows</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/09/14/</link>
      <pubDate>Wed, 14 Sep 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/09/14/</guid>
      <description>I’ve talked about the Broken Windows theory before. The idea that visible signs of problems in a community, like persistent broken windows, is a leading indicator of further problems in a community. And I said that in software development problems, like frequent pages, technical debt, and failing to code for the maintainter, set precedents and lead to more of the same.&#xA;Since then, I’ve seen multiple cases where, anecdotally, that has proved true.</description>
    </item>
    <item>
      <title>Readability vs Idioms</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/09/12/</link>
      <pubDate>Mon, 12 Sep 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/09/12/</guid>
      <description>We’re all here trying to add value. Trying to solve the problems we’ve seen. The problems that keep us up at night. Coming up with solutions that make a difference to something that’s important to us.&#xA;The question though, is not how to add the most value in the next instant, but how to add the most value over time. That’s and important distinction. Because what adds the most value right now might be different from what will add the most cumulative value tomorrow, next week, or next year.</description>
    </item>
    <item>
      <title>The Developer&#39;s Journey</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/09/08/</link>
      <pubDate>Thu, 08 Sep 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/09/08/</guid>
      <description>I’ve been a developer for a long time now. I’ve seen others start down the path. I’ve seen people make mistakes and picked them up and helped them continue on their journey. I’ve seen their trials and tribulations. I’ve seen their highs and lows. And everyone’s journey is different. But there are some pretty common things I’ve seen along the way, especially amongst the most successfull.&#xA;Starting Out In which the person sees an opportunity.</description>
    </item>
    <item>
      <title>One Thing At A Time</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/09/06/</link>
      <pubDate>Tue, 06 Sep 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/09/06/</guid>
      <description>Doing one thing and doing it well is The Unix Way. As I said in that article, tools should do one thing and do it well. If you need to do two things with two tools then connect them with a data pipe. It’s a great tenet for tools and applies to any number of systems that I’ve worked on. From text extraction to image processing to 3D model generation to an entire micro-service network.</description>
    </item>
    <item>
      <title>What&#39;s an Internal Customer?</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/08/31/</link>
      <pubDate>Wed, 31 Aug 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/08/31/</guid>
      <description>I’m a platform and tool builder. I’ve spent most of my career building platforms and tools. Tools that others, inside and outside the company, use to do whatever it is they do to add value to their respective businesses. Even when the “tool” is something like Flight Simulator, built as a game to provide entertainment. Many, probably most, people who used Flight Sim used it as shipped. They might buy a airplane or some scenery, but basically they used it as shipped.</description>
    </item>
    <item>
      <title>WIP and Queuing Theory</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/08/26/</link>
      <pubDate>Fri, 26 Aug 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/08/26/</guid>
      <description>You never know where things will back up. I’ve talked about [flow] a few times now. It’s a great state to be in and you can be very productive. On the other hand, having too much WIP inhibits flow and slows you down. And it slows you down by more than the context switching time (although that is a big issue itself). A common refrain I hear though goes something like “I need to be working on so many things at the same time otherwise I’m sitting around doing nothing while I wait for someone else.</description>
    </item>
    <item>
      <title>Built-In Functionality</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/08/23/</link>
      <pubDate>Tue, 23 Aug 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/08/23/</guid>
      <description>You can use all the tools, not just the large blade. Most languages have a way to start an external process. It’s usually called some version of exec, as in execute this processes for me please. There are generally lots of ways to call it. Synchronous and Asynchronous. Capturing the output,stdout and stderr. Passing arguments or not, or even piping data in viastdin. Capturing the exit code.&#xA;All those options are needed when you’re running external applications/executables.</description>
    </item>
    <item>
      <title>Consensus vs. Consent</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/08/19/</link>
      <pubDate>Fri, 19 Aug 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/08/19/</guid>
      <description>Consent and Consensus. Two very similar words. The first 6 letters are the same. The levenshtein distance is only 3. In general terms they both mean the same thing. If you have consensus you also have consent. The converse, however, is not true. In detail, they’re very different.&#xA;Consensus:&#xA;general agreement : UNANIMITY Consent:&#xA;compliance in or approval of what is done or proposed by another : ACQUIESCENCE It’s that last word in each definition that drives the difference.</description>
    </item>
    <item>
      <title>Hey, That&#39;s Pretty Clever</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/08/18/</link>
      <pubDate>Thu, 18 Aug 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/08/18/</guid>
      <description>The Dungeon Master of Engineering has been on Twitter for just over 4 years now. There have been lots of snarky (but accurate) tweets about life as a developer. Recently there was a whole thread contrasting the viewpoint of someone new to tech with a tech veteran. Some are whimsical, some are political, and some are learnings about things developers deal with every day. There are lots of really good learnings in there when you look at them.</description>
    </item>
    <item>
      <title>Thinking Rocks, Magic, Intent, and TDD</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/08/15/</link>
      <pubDate>Mon, 15 Aug 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/08/15/</guid>
      <description>Can this rock really think? Who let the magic blue smoke out? Some have said that computers are just rocks we’ve taught to think. Others think computers run on magic blue smoke, and once you let the magic smoke out they’ll never work again. The truth, as usual, is somewhere between the two extremes. It’s not magic, and while arcing 120 VAC to ground across a chip will make a cloud of blue smoke and the chip will ever work again, it’s not magic.</description>
    </item>
    <item>
      <title>Something Smells ... Primitive</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/08/12/</link>
      <pubDate>Fri, 12 Aug 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/08/12/</guid>
      <description>I like types. I like typed languages. I find they prevent me from making some simple mistakes. The simplest example is that if you have something like int cookiesAvailableToSell you can’t do cookiesAvailableToSell = 2.5. You either have 2 or 3 cookies to sell. If you can sell the half cookie as a whole one you have 3. If you can’t then you have 2 cookies to sell and a little snack.</description>
    </item>
    <item>
      <title>What Is Technical Debt Anyway?</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/08/10/</link>
      <pubDate>Wed, 10 Aug 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/08/10/</guid>
      <description>Technical debt has been on my mind a bunch the last few weeks. The system I’m working on has been around for a few years. It works, and it works successfully. However, since Day 1 we’ve learned a lot about what we want the system to do, what we don’t want it to do, and the environment it will be operating in. Some of those things fit into the original design, some didn’t.</description>
    </item>
    <item>
      <title>Starting vs. Finishing</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/08/03/</link>
      <pubDate>Wed, 03 Aug 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/08/03/</guid>
      <description>image source&#xA;What’s more important, starting or finishing? Being done is great, but you can’t finish something you haven’t started. To me, finishing is more important. Because if you don’t finish all you’ve done is waste your time (modulo any learning along the way). Of course, to finish you need to define what “finishing” means. This is critical because, especially in development, while finishing does NOT always mean delivered, it usually does, and that’s a place to start with the definition.</description>
    </item>
    <item>
      <title>What happens when you can&#39;t even Tidy First?</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/07/29/</link>
      <pubDate>Fri, 29 Jul 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/07/29/</guid>
      <description>image source&#xA;I had a different topic on my mind for today but life and the internet have conspired to change my mind. Today seems to be about refactoring instead. I’m trying to upgrade a docker image to use some newer libraries and the definition of which versions of libraries are used/depended upon are scattered hither and yon. Where they’re defined at all and not just picked by a happy accident at the time things were set up.</description>
    </item>
    <item>
      <title>Customers vs. Partners</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/07/28/</link>
      <pubDate>Thu, 28 Jul 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/07/28/</guid>
      <description>Customers are and partners are different. According to the dictionary, it’s like this.&#xA;Customer: a person or organization that buys goods or services from a store or business.&#xA;Partner: any of a number of individuals with interests and investments in a business or enterprise, among whom expenses, profits, and losses are shared.&#xA;Or to put it more succinctly, you work for a customer, and with a partner. And that’s a huge difference.</description>
    </item>
    <item>
      <title>Best Practices and Cargo Cults</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/07/20/</link>
      <pubDate>Wed, 20 Jul 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/07/20/</guid>
      <description>A best practice is a “method or technique” that often produces superior results. A cargo cult, on the other hand, is slavishly following the forms of something that you’ve seen work (or at least think works). The problem is that from the outside, and often from the inside, they look awfully similar. The question is, how can you tell the difference?&#xA;Actually, the difference is pretty straightforward. What makes seeing the difference hard is that it’s not in what you’re doing.</description>
    </item>
    <item>
      <title>Applesauce, Names, and Refactoring</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/07/18/</link>
      <pubDate>Mon, 18 Jul 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/07/18/</guid>
      <description>Did you know that applesauce can be an important part of refactoring, understanding code, and honest function naming? It’s true, and here’s how it works.&#xA;First and foremost, I’m not talking about mashed apples. As much as I enjoy applesauce on my latkes, that’s not what I mean. I’m talking about using applesauce as an honest name for something.&#xA;Naming is hard. It’s one of the two big problems in computer science.</description>
    </item>
    <item>
      <title>Policies</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/07/15/</link>
      <pubDate>Fri, 15 Jul 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/07/15/</guid>
      <description>I’ve talked about Chesterton’s Fence before. It’s the idea that you have to understand why something was done in the first place before you decide to undo it. You buy a vacation house with a fence and a gate across the driveway and all you ever do is stop, open the gate, drive through, and then close the gate behind you. To save time and trouble, you remove the gate because all it does is slow you down.</description>
    </item>
    <item>
      <title>This Is The Way</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/07/14/</link>
      <pubDate>Thu, 14 Jul 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/07/14/</guid>
      <description>I’ve talked about The Unix Way before. I recently came across a really good description of it. It doesn’t matter if you’re writing a tool or deciding what goes into your commit. It shows up in architecture, in Domain Driven Design and Bounded Contexts. It shows up in non-code places as well. Reducing Work In Progress is just another way of implementing the Unix way.&#xA;The best definition of the Unix way I’ve ever seen is:</description>
    </item>
    <item>
      <title>TDD Anti-patterns</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/07/11/</link>
      <pubDate>Mon, 11 Jul 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/07/11/</guid>
      <description>I&amp;rsquo;ve talked about the difference between Test After Design and Test Driven Design before. I&amp;rsquo;m a big proponent of writing tests that prove your design before you write code. Not all the tests, because as your knowledge of what the design should be improves, you&amp;rsquo;ll learn about new tests that need to be written as well. So, as you learn you write more tests to drive the design.&#xA;Regardless of when you write the tests, before or after the code, there are a bunch of test anti-patterns to watch out for.</description>
    </item>
    <item>
      <title>Monitoring vs. Observability</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/07/08/</link>
      <pubDate>Fri, 08 Jul 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/07/08/</guid>
      <description>Pop quiz. What&amp;rsquo;s the difference between monitoring and observability? First of all, Monitoring is a verb. It&amp;rsquo;s something you do. You monitor a system. On the other hand, Observability is an adverb. It&amp;rsquo;s one of the -ilities. Observability describes a capability of a system.&#xA;Monitoring is collecting logs and metrics. Metrics like throughput, latency, failure rates, and system usage. Monitoring is going over logs and looking for issues, patterns, and keywords among other things.</description>
    </item>
    <item>
      <title>Traditions</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/07/06/</link>
      <pubDate>Wed, 06 Jul 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/07/06/</guid>
      <description>Just what is a tradition? More importantly, what do we get of traditions? According to Merriam-Webster, tradition is&#xA;a: An inherited, established, or customary pattern of thought, action, or behavior (such as a religious practice or a social custom) b: A belief or story or a body of beliefs or stories relating to the past that are commonly accepted as historical though not verifiable The handing down of information, beliefs, and customs by word of mouth or by example from one generation to another without written instruction Cultural continuity in social attitudes, customs, and institutions Characteristic manner, method, or style Lots of words that describe what a tradition is.</description>
    </item>
    <item>
      <title>Design Is Iterative</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/06/23/</link>
      <pubDate>Thu, 23 Jun 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/06/23/</guid>
      <description>I’ve talked about rework avoidance and the advantage of taking smaller steps. I’ve talked about how it’s different from the older BDUF process. How a sea chart gives you a better chance of getting a successful result.&#xA;Given that, and, the fact that the Agile Manifesto, was written in 2001, you would think that the concept of iterative design is a new one.&#xA;However, you’d be wrong.&#xA;Way back in 1968, in the Software Engineering Report by the NATO Science Committee, you’ll find this quote by H.</description>
    </item>
    <item>
      <title>Good Habits</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/06/20/</link>
      <pubDate>Mon, 20 Jun 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/06/20/</guid>
      <description>In the past I’ve talked about Why We Test. We test to increase our stakeholder’s confidence. So let’s add all the confidence we can. If a little confidence is good, more confidence is better, right?&#xA;Maybe, but maybe not. Because Speed is also important. We want to get things done Sooner, not Faster. It’s not confidence at any cost. It’s enough confidence to move forward.&#xA;I think Charity Majors said it really well.</description>
    </item>
    <item>
      <title>Continuous Delivery</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/06/17/</link>
      <pubDate>Fri, 17 Jun 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/06/17/</guid>
      <description>Continuous delivery is the idea that every change, or at least every change a developer thinks is done, gets built into the product and into customers hands. It&amp;rsquo;s a great goal. Reducing latency between a change and getting feedback on the change means you can make smaller changes and be more confident that changes you&amp;rsquo;re seeing are due to the specific change you&amp;rsquo;ve made.&#xA;Over the course of my career I&amp;rsquo;ve seen a lot of deployment frequencies.</description>
    </item>
    <item>
      <title>Scream Tests</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/06/15/</link>
      <pubDate>Wed, 15 Jun 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/06/15/</guid>
      <description>The other day I mentioned to someone that we had a scream test scheduled for a few weeks from now and they gave me a very confused look. Since I know that it&amp;rsquo;s my responsibility to make sure my messages are received properly I asked if they knew what a scream test was. Turns out they didn&amp;rsquo;t. That day they were one of the lucky 10,000. If you don&amp;rsquo;t know, today&amp;rsquo;s your day.</description>
    </item>
    <item>
      <title>Automation</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/06/13/</link>
      <pubDate>Mon, 13 Jun 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/06/13/</guid>
      <description>If you need to do something millions of times a day it needs to be repeatable and, ideally, idempotent. While it’s technically possible to get enough people in your system in a Mechanical Turk mechanism, in most cases what you want to do is truly automate the task.&#xA;The trick though, as, @Kelsey Hightower said the other day on the art of agile development book club is that &amp;ldquo;automation is a byproduct of understanding.</description>
    </item>
    <item>
      <title>TAD vs. TDD</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/06/06/</link>
      <pubDate>Mon, 06 Jun 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/06/06/</guid>
      <description>Test After Development (TAD) or Test Driven Development (TDD)? What’s the difference? They sound pretty similar, and the Levenshtein distance between them is only 5, but the difference is pretty profound.&#xA;In TAD you write some code, try it out with some test cases, and write some tests to cover the complicated or confusing parts. You want to make sure that you have some confidence that the code does what you want it to so you write some tests.</description>
    </item>
    <item>
      <title>Lint Filters And Testing</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/06/03/</link>
      <pubDate>Fri, 03 Jun 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/06/03/</guid>
      <description>I don’t know about the lint filter on your dryer, but our current dryer, and every dryer I’ve used before this, had a message on or near the lint filter something like this.&#xA;CLEAN BEFORE EACH LOAD&#xA;That’s pretty good advice. Sure, you should clean the filter after you use it. It’s polite and you want to be helpful to the next person who uses the dryer, but that doesn’t always happen.</description>
    </item>
    <item>
      <title>Measuring and Managing</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/06/01/</link>
      <pubDate>Wed, 01 Jun 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/06/01/</guid>
      <description>You’ve probably heard the quote from W. Edwards Deming that&#xA;if you can’t measure it, you can’t manage it&#xA;Which is an accurate quote. It comes right out of The New Economics. And on the surface, it makes sense. Whether you call it OODA, Plan-Do-Check-Act, or just a feedback loop, how can you control (manage) something if you don’t know what’s going on? And the more accurately you know, the better you can control it.</description>
    </item>
    <item>
      <title>Software Development Is A Social Activity</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/05/27/</link>
      <pubDate>Fri, 27 May 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/05/27/</guid>
      <description>I’ve had a bunch of discussions lately around the nature of software development. Silos. Boundaries. Contexts. Cognitive load. Team Topologies. And how things flow and work together. Wheels withing wheels. Loops withing loops. Patterns within patterns.&#xA;Those discussions were all around how teams can and should work together. Where does one team’s responsibility stop and another’s begin. What’s the difference between a customer and a partner? How does value flow through the system?</description>
    </item>
    <item>
      <title>Where do defects come from?</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/05/25/</link>
      <pubDate>Wed, 25 May 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/05/25/</guid>
      <description>For those that know me, it’s no secret that while I like a lot of Uncle Bob’s specific advice (clean code, unit tests, I have some problems with his overall approach. Consider his response to the question “Where do defects come from?”.&#xA;According to him, the cause is:&#xA;Too many programmers take sloppy short-cuts under schedule pressure. Too many other programmers think it’s fine, and provide cover. And the obvious solution is</description>
    </item>
    <item>
      <title>A little housekeeping</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/05/24/</link>
      <pubDate>Tue, 24 May 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/05/24/</guid>
      <description>It turns out, unsurprisingly, that having 500+ blog posts in a single directory isn&amp;rsquo;t a great way to run things. To that end, I&amp;rsquo;m moving a bunch of stuff around. To you the user there isn&amp;rsquo;t much change. The new links are of the form /posts/&amp;lt;year&amp;gt;/&amp;lt;month&amp;gt;/&amp;lt;day&amp;gt; instead of /posts/&amp;lt;year&amp;gt;-&amp;lt;month&amp;gt;-&amp;lt;day&amp;gt;. If you&amp;rsquo;re following a link with the old format it should still work, but if it doesn&amp;rsquo;t, you&amp;rsquo;ll get a message saying it&amp;rsquo;s unavailable and a link to the new format.</description>
    </item>
    <item>
      <title>Elevator Pitch</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/05/23/</link>
      <pubDate>Mon, 23 May 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/05/23/</guid>
      <description>I’ve talked about vision and mission statements before. I’ve talked about strategy and charters too. Visions, charters, and strategies are big things. They can take a page or more to write down, a long time to describe, and even longer to really understand. Mission statements are often just as bug.&#xA;But there’s one kind of mission statement that isn’t big. It doesn’t take that long to explain or understand. When you hear it, you know exactly what the mission is, and if you are part of that mission, you also know exactly what your role in achieving that mission is.</description>
    </item>
    <item>
      <title>Why We Test</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/05/19/</link>
      <pubDate>Thu, 19 May 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/05/19/</guid>
      <description>We test to find bugs, or at least make sure there aren’t any, right? Wrong. Or at least it’s not just about finding bugs. Finding/eliminating bugs is one of the specific things we do as part of testing, but that’s not the goal. It&amp;rsquo;s not about lines or branches covered. It’s not about having tests pass or dogfooding. All of those are things we should do along the way, but they’re not the reason we test.</description>
    </item>
    <item>
      <title>Careers Pt 3 - Visualizing Progressions</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/05/06/</link>
      <pubDate>Fri, 06 May 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/05/06/</guid>
      <description>In part 1 I talked about how your “level” or title was just a way to describe the scope of influence you had. Just a measure of how much your work, and how you worked, impacted others. Part 2 explained more about what I meant by “scope”. What the parts of scope were and how scope could grow.&#xA;Being able to describe how that works is crucial to managing your career.</description>
    </item>
    <item>
      <title>Action vs. Reaction</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/05/04/</link>
      <pubDate>Wed, 04 May 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/05/04/</guid>
      <description>Bias for Action is one of Amazon’s Leadership Principles. Bias for Reaction is not. They sound very similar. And from the outside they look very similar. But from the inside they’re very different.&#xA;Bias for action is about making decisions. It’s about being thoughtful and using the information you have at hand to make a good decision. It’s about understanding the options and then deciding amongst them.&#xA;Bias for reaction, on the other hand, is about doing something, anything, instead of taking the time to think and make a decision.</description>
    </item>
    <item>
      <title>Story Splitting</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/05/02/</link>
      <pubDate>Mon, 02 May 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/05/02/</guid>
      <description>The typical user story starts something like&#xA;As a &amp;lt;persona&amp;gt;, I should be able to &amp;lt;task to complete&amp;gt;&#xA;That’s a decent format, or at least it’s a minimum bar. Without identifying the kind of user and the task to complete it’s really hard to compare tasks to identify which has the highest value. However, it is by no means a guarantee.&#xA;There are 2 really common reasons that this template doesn’t guarantee that you end up with a quality user story that you can implement.</description>
    </item>
    <item>
      <title>Careers Pt 2 – Breaking Down Scope</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/04/29/</link>
      <pubDate>Fri, 29 Apr 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/04/29/</guid>
      <description>In Part 1 I described how your level is a proxy for scope of influence. Knowing that gives you a framework to understand where you think you are. What it doesn’t give you a way to break scope of influence down into a series of areas that you can measure.&#xA;One way to do that is break down scope into categories. Different companies call them different things. Some call them competencies, proficiencies, or areas, others might call the capabilities or skills, It doesn’t really matter what they’re called, as long as everyone is talking about the same thing.</description>
    </item>
    <item>
      <title>Scheduling Time For Maintenance</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/04/27/</link>
      <pubDate>Wed, 27 Apr 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/04/27/</guid>
      <description>This is a real thing you can buy.&#xA;Brady is all about labeling for the workplace. They’re primarily aimed at the manufacturing/processing space. They’ve got a product line directed at lean manufacturing techniques, such as those that come out of the Toyota Production System (TPS), which I’ve talked about before. Since a lot of today’s agile and lean software development processes are derived from TPS and lean manufacturing some of them make a lot of sense in the software world as well.</description>
    </item>
    <item>
      <title>Error Based Development</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/04/25/</link>
      <pubDate>Mon, 25 Apr 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/04/25/</guid>
      <description>I’ve often (usually? almost always?) found it easier to write code than it is to debug it. Even code I recently wrote. If nothing else, when I’m writing code I have all the context in my head and I know how all of the API calls are going to respond. Even if I’m wrong, I know what I’m expecting and I write the code accordingly. Of course, that’s not always the case, which leads to debugging.</description>
    </item>
    <item>
      <title>The Importance Of (down) Time</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/04/22/</link>
      <pubDate>Fri, 22 Apr 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/04/22/</guid>
      <description>Time passes. Even if nothing else changes, time passes. That’s the same for everyone and you have no control over it. What you do have control over is what you do with your time.&#xA;How you use your time has a huge impact on your impact. At one of the highest levels there’s work-life balance and how getting that wrong leads to burnout and having no impact. One level deeper on the work side is managing work in progress (WIP).</description>
    </item>
    <item>
      <title>Careers Pt 1 - Levels</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/04/20/</link>
      <pubDate>Wed, 20 Apr 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/04/20/</guid>
      <description>I’ve been doing this for a while. And like the Farmers Insurance guys says, I know a thing or two because I’ve seen a thing or two. I’ve written a little about it before, but I figured it’s time to add a little more detail to how I think about things and what I’ve learned. About what levels are and aren&amp;rsquo;t, and what they&amp;rsquo;re a proxy for (hint: it&amp;rsquo;s influence, not ability).</description>
    </item>
    <item>
      <title>Faster or Slower?</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/04/18/</link>
      <pubDate>Mon, 18 Apr 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/04/18/</guid>
      <description>Speed kills. Measure twice, cut once. Rework Avoidance Theory. We&amp;rsquo;re trained from an early age to slow down when faced with uncertainty. To be cautious. To not drive faster than we can see. And often it’s true. Especially when operating heavy equipment. Simple physics tells us that mass * velocity equals inertia. And as Newton said, an object in motion stays in motion. Changing directions or stopping means working against that inertia.</description>
    </item>
    <item>
      <title>Planning vs Scheduling</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/04/06/</link>
      <pubDate>Wed, 06 Apr 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/04/06/</guid>
      <description>Q1 is done in most places, so Q2 planning is mostly done as well. Or at least what passes for planning. The list of expected (required?) work has been identified, ordered, and scheduled. Names have been assigned to each one. The “planner” now knows who’s doing what and when it will start and finish. How could anything possibly be more planned than that?&#xA;In theory, that is planning. But as they say, in theory, there’s no different between theory and practice.</description>
    </item>
    <item>
      <title>QWAN</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/04/04/</link>
      <pubDate>Mon, 04 Apr 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/04/04/</guid>
      <description>You’ve probably heard of the Gang of Four and their book, Design Patterns. You might even have a copy on your shelf. I know I do. There’s a lot of good stuff in there. Reusable concepts (patterns) that can be used whenever the situation calls for one of them. I’ve talked about some of them before, like the builder pattern, or the difference between adapters, facades, and decorators. They’re best practices, but as I’ve said, they’re only best if used at the right time.</description>
    </item>
    <item>
      <title>Do You See What I See?</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/04/01/</link>
      <pubDate>Fri, 01 Apr 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/04/01/</guid>
      <description>Context is a concept that comes up here a lot. Usually though, when I talk about context I’m talking about having enough context to understand what you’re doing and why. Or how the different parts of the code you’re working on fit together to provide value. But there’s a whole different kind of context. The shared kind of context. The kind of context that gets used when you’re trying to share information.</description>
    </item>
    <item>
      <title>Don&#39;t just take notes</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/03/30/</link>
      <pubDate>Wed, 30 Mar 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/03/30/</guid>
      <description>I’ve got a Remarkable 2 next-gen paper tablet. I got tired of grabbing a new tablet for every meeting and having piles of notebooks with 5 or 10 used pages around my office. Since I’ve had it I’ve been using it for meetings instead of grabbing the nearest piece of paper. Since then I’ve discovered a few things.&#xA;First, I haven’t lost any notes since I started using it. I only have to keep track of one thing and it’s always with me.</description>
    </item>
    <item>
      <title>Hangers and Optimization</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/03/28/</link>
      <pubDate>Mon, 28 Mar 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/03/28/</guid>
      <description>I’ve talked about context before. I know context is important. Even so, I still get reminded of its importance by the smallest of things. After just over 2 years I’m on a business trip again and something happened last night that reminded me again how important context is.&#xA;When I got to my room I went to hang up my shirts because I don’t want to have to iron them. When I went to hang them up some of the hangers were hung hook in and some were hung hook out.</description>
    </item>
    <item>
      <title>Loops and Ratios</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/03/25/</link>
      <pubDate>Fri, 25 Mar 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/03/25/</guid>
      <description>Test Driven Development, as I’ve said before, is really design by example. But it’s also a systems thinking approach to the problem. Loops withing loops. Feedback and feed forward. Change something (a requirement or a result) in one loop and it impacts the other.&#xA;What that image doesn’t capture though is the impact of time spent on various parts of the loop. It doesn’t touch on how the ratios of those times form incentives.</description>
    </item>
    <item>
      <title>Weird Person #2 or First Joiner?</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/03/22/</link>
      <pubDate>Tue, 22 Mar 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/03/22/</guid>
      <description>Who’s more important, the person who comes up with a weird idea, or the person who validates it? Sure, if no one comes up with the idea then it won’t come to fruition. But if you someone comes up with the idea and no one joins in then it probably won’t happen then either.&#xA;According to legend Steve Wozniak was happily building technology demonstrators for himself, but probably would have stayed at his HP day job if it wasn’t for that other Steve.</description>
    </item>
    <item>
      <title>Remediation Surprise</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/03/21/</link>
      <pubDate>Mon, 21 Mar 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/03/21/</guid>
      <description>Some call them Postmortems, Post-Incident Reviews (PIR), or Root Cause Analysis. Some call them something else entirely. Regardless of what you call them, taking the time to figure out why something bad happened and what you’re going to do to make sure it doesn’t happen again is a crucial part of a stable, performant, flexible systems. Unfortunately they also lead to remediation surprise.&#xA;A key part of the PIR is the list of action items.</description>
    </item>
    <item>
      <title>Poka-Yoke</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/03/18/</link>
      <pubDate>Fri, 18 Mar 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/03/18/</guid>
      <description>I’ve talked about guardrails and Root Cause Analysis before. And one of the questions I often ask candidates during an interview is what they (or their team) did to prevent a recurrence of a mistake with significant impact. These are all ways to make things safer in the future.&#xA;A general term for building that kind of safety into a system is poka-yoke. The idea that you can, by design, put special steps or checkpoints into a system so that mistakes are hard to miss.</description>
    </item>
    <item>
      <title>Raspberry vs. Strawberry Jam</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/03/16/</link>
      <pubDate>Wed, 16 Mar 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/03/16/</guid>
      <description>&amp;ldquo;The wider you spread it, the thinner it gets.&amp;rdquo;&#xA;&amp;ndash; Gerald M. Weinberg&#xA;Otherwise known as the Law of Raspberry Jam. You take some raspberry jam and spread it over so many slices of toast that it just add as little bit of color and a hint of sweetness. None of the wonderful flavor or texture of the raspberries you were trying to add. I’ve called it peanut buttering things before.</description>
    </item>
    <item>
      <title>Planning and Time Sinks</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/03/14/</link>
      <pubDate>Mon, 14 Mar 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/03/14/</guid>
      <description>Paraphrasing Eisenhower and von Moltke, planning is important, plans, not so much. The biggest reason for that is that no matter how much or how well you plan, things don’t always go the way you expect. Some things go faster, some go slower, and some just don’t work. Which leads to Hofstadter&amp;rsquo;s Law. Of course, Hofstadter’s Law is self-referential, so you can’t just plan it away.&#xA;What you can do, though, is understand why things take longer.</description>
    </item>
    <item>
      <title>Are Your KRs Really Tasks?</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/03/11/</link>
      <pubDate>Fri, 11 Mar 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/03/11/</guid>
      <description>OKRs. Objectives and Key Results. The Objective comes from your vision, and the Key Results define what success looks like on your KPIs (Key Performance Indicators). One nice things about Objectives is that they can be decomposed into smaller, more focused objectives as you got down the org hierarchy. That works great at the company, SVP/VP, and director level, and can work for managers of managers.&#xA;When the org is using OKRs every level is expected to have their objectives support one of the OKRs at the level above.</description>
    </item>
    <item>
      <title>Heros</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/03/09/</link>
      <pubDate>Wed, 09 Mar 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/03/09/</guid>
      <description>I’ve spent the last 10 years or so down in the metaphorical engine room. Working on developer experience, infrastructure, platforms, and tools. The things you often don’t notice or talk about unless there’s a problem. Then folks complain about it. Then, when it’s better they thank the person who told them about the fix. And I think that’s a problem.&#xA;Because it leads to things like this comic.&#xA;Two people each see a small problem.</description>
    </item>
    <item>
      <title>Are we there yet?</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/03/07/</link>
      <pubDate>Mon, 07 Mar 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/03/07/</guid>
      <description>No, I’m not channeling my kids on a 20 hour car ride (although that has happened multiple times). If you’ve ever made the drive from New York to Miami you know what I’m talking about. You drive for hours. All day in fact. A long day. A very long day. You finally get to Florida. Yay. We&amp;rsquo;re almost there. Then you realize you still have 6 hours to go. You’re only 2/3 of the way there.</description>
    </item>
    <item>
      <title>Tasking</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/03/04/</link>
      <pubDate>Fri, 04 Mar 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/03/04/</guid>
      <description>As a general and President, Eisenhower had a big impact on the US. One of the more relevant to development is the Eisenhower Matrix. It breaks tasks down into 4 types and helps you prioritize which ones you should work on when. It also tells you which ones to ignore.&#xA;But what if 4 categories is too many for you? Shreyas breaks it down into 3 categories, giving you one less thing to remember.</description>
    </item>
    <item>
      <title>All Aboard</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/02/28/</link>
      <pubDate>Mon, 28 Feb 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/02/28/</guid>
      <description>Today I started the latest chapter in my life. Just started my new job with Amazon, working on Just Walk Out technology. This is a big job change for me. It’s the first time in almost 25 years that I had to interview for a new job. It’s also the first time in almost that long that I made the transition alone.&#xA;Prior to Amazon I was at Aurora Innovation. I got there as part of an acquisition.</description>
    </item>
    <item>
      <title>Chesterton&#39;s Fence</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/02/25/</link>
      <pubDate>Fri, 25 Feb 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/02/25/</guid>
      <description>I’ve mentioned Chesterton’s Fence in a couple of previous blogs, but I never did define it. Chesterton’s Fence is a parable about how lacking context can be dangerous. In his 1929 book, The Thing, Chesterton wrote:&#xA;In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road.</description>
    </item>
    <item>
      <title>Moving On</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/02/23/</link>
      <pubDate>Wed, 23 Feb 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/02/23/</guid>
      <description>Today was my last day at Aurora. Some of you I’ve worked with for 15+ years across 3 ½ companies, others only for a few months at one company. Regardless, to all of you, a big thank you. You’ve all helped me learn and grow. As a developer, an architect, a mentor, and as a person.&#xA;Even though it’s been just over a year, I look back at all that’s been accomplished and it’s truly impressive.</description>
    </item>
    <item>
      <title>Exit Criteria</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/02/22/</link>
      <pubDate>Tue, 22 Feb 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/02/22/</guid>
      <description>Over my career I’ve written plenty of documents. Requirements docs, design docs, project specifications, white papers, and vision docs. They all have a few things in common. A definition of the current state, the problem with the current state, how the thing being written about will solve the problem (goals), and what issues it won’t address (non-goals). After that the different docs have different focuses and levels of detail appropriate for the role the doc was supposed to fill.</description>
    </item>
    <item>
      <title>Reading Roadmaps</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/02/18/</link>
      <pubDate>Fri, 18 Feb 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/02/18/</guid>
      <description>Roadmaps are important. Having an idea about how to get where you&amp;quot;re going is pretty important to getting there. You know what&amp;rsquo;s more important than a roadmap though? A destination. Because if you don&amp;rsquo;t have a destination, you don&amp;rsquo;t know if your roadmap is going to get you to the right place. But even with a destination, you need to know how to read (or write) a roadmap.&#xA;Inevitably though, you end up presenting them to someone.</description>
    </item>
    <item>
      <title>Kinds of Costs</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/02/16/</link>
      <pubDate>Wed, 16 Feb 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/02/16/</guid>
      <description>Costs are costs, right? You pays your money and you takes your choice. Simple, right? Not really. There are all kinds of costs. Up front, back end, hidden, and delayed for example. All of those are relevant to development. Besides those, there are two major ones to be aware of because they often turn into biases&#xA;Opportunity Cost: The time &amp;amp; money you spend on X means you can&amp;rsquo;t do Y.</description>
    </item>
    <item>
      <title>Cupid</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/02/14/</link>
      <pubDate>Mon, 14 Feb 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/02/14/</guid>
      <description>In honor of Valentine&amp;rsquo;s Day, a new acronym. SOLID has been around for a while, and there are lots of good things about SOLID. Applying the SOLID principles (almost) always leads to better code. But, as @tastapod wrote, SOLID is about principles, and with principles, like rules, you&amp;rsquo;re either in compliance with the principles or not. Now you just have to decide how compliant you want to be. The answer to that of course, is it depends.</description>
    </item>
    <item>
      <title>More Perspective</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/02/11/</link>
      <pubDate>Fri, 11 Feb 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/02/11/</guid>
      <description>​​I&amp;rsquo;ve talked about perspective before. Your point of view is a huge component of how you look at a situation. Let&amp;rsquo;s say you&amp;rsquo;re a fish. And let&amp;rsquo;s say you needed to navigate from Portland, Maine to Portland, Oregon. A map would be a good thing. It would really help you get from Portland to Portland. But for a fish the map wouldn&amp;rsquo;t look like most of the maps you&amp;rsquo;re used to seeing.</description>
    </item>
    <item>
      <title>Beware Of Just</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/02/08/</link>
      <pubDate>Tue, 08 Feb 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/02/08/</guid>
      <description>This comes up in lots of different contexts&#xA;but it boils down to &amp;ldquo;I know you&amp;rsquo;re busy, but here&amp;rsquo;s a simple and obvious (according to my cocktail party understanding) solution to the problem I&amp;rsquo;m having. I need it working tomorrow.&amp;rdquo;&amp;nbsp;&#xA;After all, how hard can it be to write a script to automate it? You already know how to do it. Response times for your web query are slow. Just add a cache.</description>
    </item>
    <item>
      <title>Perspective 2</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/02/04/</link>
      <pubDate>Fri, 04 Feb 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/02/04/</guid>
      <description>Consider this&#xA;&amp;nbsp;&#xA;&amp;quot;Everyone has this problem so clearly we can tolerate it&amp;quot;&#xA;Vs&#xA;&amp;quot;Everyone has this problem so clearly we should solve it&amp;quot;&#xA;Start with the exact same situation and come up with the opposite result. How is that possible? Is one right and one wrong?&#xA;As usual, my answer is, It Depends. It depends on what the problem is. It depends on the impact of the problem. It depends on your goal.</description>
    </item>
    <item>
      <title>Write Your Unit Tests FIRST</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/02/02/</link>
      <pubDate>Wed, 02 Feb 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/02/02/</guid>
      <description>There are at least a couple of ways to take that. There&amp;rsquo;s the temporal definition of first, meaning you should write your unit tests before you write the code that makes the tests pass. That&amp;rsquo;s pretty straightforward. Write a set of tests that verify the functionality you&amp;rsquo;re about to build. Write some more tests that verify failure modes. When all your tests pass you&amp;rsquo;re (almost) done. That&amp;rsquo;s classic test driven development, or as I like to call it, design by example.</description>
    </item>
    <item>
      <title>Sooner, not Faster</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/01/31/</link>
      <pubDate>Mon, 31 Jan 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/01/31/</guid>
      <description>What&amp;rsquo;s better, faster or sooner? More to the point, what&amp;rsquo;s the difference between them, and why should you care?&#xA;Let&amp;rsquo;s start with some definitions:&#xA;Fast:&#xA;Moving or able to move quickly&#xA;She&amp;rsquo;s a very fast runner.&#xA;a fast car&#xA;Happening quickly : taking a short amount of time&#xA;a fast race&#xA;We&amp;rsquo;re off to a fast start.&#xA;Operating quickly a fast computer&#xA;Soon:&#xA;Without undue time lapse : BEFORE LONG</description>
    </item>
    <item>
      <title>Decisions 2 (if ... elseif ... elseif ... elseif ...)</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/01/26/</link>
      <pubDate>Wed, 26 Jan 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/01/26/</guid>
      <description>Speaking of the difference between a choice and a decision, the number of choices you have to pick from can deeply influence the decisions you make about the code you write. Because the number of choices you have can sometimes drive the implementation of the decision of how to do something far from where you actually make the decision.&#xA;You could do it up-front, with a set of micro-decisions, but you better know what the options are and make all the right choices then.</description>
    </item>
    <item>
      <title>Is That a Choice or a Decision</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/01/25/</link>
      <pubDate>Tue, 25 Jan 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/01/25/</guid>
      <description>I&amp;rsquo;ve talked about evaluating your decision based on what you knew at the time instead of the outcome of the decision before. That&amp;rsquo;s as true now as it ever was. Unfortunately, that&amp;rsquo;s a retrospective approach to understanding the quality of your decision. It doesn&amp;rsquo;t help much while you&amp;rsquo;re trying to make the decision.&#xA;As much as it would make my job easier, I don&amp;rsquo;t have a time machine that will let me evaluate my decisions based on what I find out later.</description>
    </item>
    <item>
      <title>Flow</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/01/21/</link>
      <pubDate>Fri, 21 Jan 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/01/21/</guid>
      <description>You&amp;rsquo;ve probably heard of flow. That perfect balance of concentration, energy, attention, and understanding that leads to progress. You&amp;rsquo;ve probably been in a flow state a few times. It seems magical. You get more done than you expected and when you&amp;rsquo;re done the result feels right. Everything seems to click and the code is something you&amp;rsquo;re proud of.&#xA;And it&amp;rsquo;s by no means restricted to development, or just creative endeavors, but also in repetitive, assembly line, types as well.</description>
    </item>
    <item>
      <title>Roller Coasters</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/01/18/</link>
      <pubDate>Tue, 18 Jan 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/01/18/</guid>
      <description>Roller Coasters can be fun. Big drops. High speeds. Adrenaline rushes. And most of our offices have them relatively close. There&amp;rsquo;s the Steel Curtain at Kennywood, the Demon at Great America, and the Mind Eraser at Elitch Gardens. There&amp;rsquo;s even Roller Coaster Trail outside Bozeman.&#xA;From the outside it&amp;rsquo;s big and scary looking. You have some glimpses, but no understanding. You&amp;rsquo;re in line waiting to in and give it a try.</description>
    </item>
    <item>
      <title>Getting Feedback</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/01/13/</link>
      <pubDate>Thu, 13 Jan 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/01/13/</guid>
      <description>It&amp;rsquo;s feedback season again. There&amp;rsquo;s lots of advice on how and when to give feedback. The internet is full of it. What you don&amp;rsquo;t see so much of, and what&amp;rsquo;s about to become very relevant, is how to receive feedback. Like any other communication, regardless of how the message is sent, if it&#39;s not received there&amp;rsquo;s no information transfer.&#xA;So what can you do as the receiver of feedback? What is your role in the process?</description>
    </item>
    <item>
      <title>Efficiency</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/01/11/</link>
      <pubDate>Tue, 11 Jan 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/01/11/</guid>
      <description>What is efficiency? According to Merriam Webster, efficiency is:&#xA;Efficiency (noun):&#xA;the ability to do something or produce something without wasting materials, time, or energy : the quality or degree of being efficient&#xA;Ex: Because of her efficiency, we got all the work done in a few hours.&#xA;Ex: The factory was operating at peak efficiency.&#xA;But what does that really mean? And how does it change depending on what you&amp;rsquo;re doing/producing?</description>
    </item>
    <item>
      <title>SPOFs</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/01/05/</link>
      <pubDate>Wed, 05 Jan 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/01/05/</guid>
      <description>A SPOF is a single point of failure. It&amp;rsquo;s that one little thing that everything else depends on and doesn&amp;rsquo;t have redundancy. Like building an entire electric grid to make sure you have power available, adding an external generator and battery backup in case the grid fails, and building your house with multiple circuits to each room, then having a single line going from the battery/generator/grid multiplexer to the house. If that single line fails you&amp;rsquo;re out of power.</description>
    </item>
    <item>
      <title>Back It Up There</title>
      <link>https://friendgineers.rosenshein.org/posts/2022/01/04/</link>
      <pubDate>Tue, 04 Jan 2022 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2022/01/04/</guid>
      <description>Back in the house now and mostly back to normal. Heat and electricity are on, but we still need to boil our water. Turns out most of our processes and preparations worked, but not all of them. The biggest failure appears to be the emergency alert system. The city/county uses Everbridge to share alerts. That&amp;rsquo;s fine and dandy, and they&amp;rsquo;re highly available and distributed. The problem is, they&amp;rsquo;re OPT IN, so if you don&amp;rsquo;t register for alerts you don&amp;rsquo;t get them.</description>
    </item>
    <item>
      <title>2021 In Review</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/12/30/</link>
      <pubDate>Thu, 30 Dec 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/12/30/</guid>
      <description>And what a year it&amp;rsquo;s been. Just some personal reflections. I worked from home for 11 1/2 months. 1 business trip, which was the first in ~19 months (and that hasn&amp;rsquo;t happened in about 12 years). 1 vacation. Became empty nesters as our youngest moved out. Restarted our latke fry. 1 office evacuation. 1 company change. 2 role changes. 3 different managers. And 153 blog posts.&#xA;Which was the biggest? That&amp;rsquo;s easy.</description>
    </item>
    <item>
      <title>Language Matters</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/12/22/</link>
      <pubDate>Wed, 22 Dec 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/12/22/</guid>
      <description>Hyrum Wright, of Hyrum&amp;rsquo;s Law posted a, in my view, valid, reasonable, and realistic question. Where do the responsibilities lie when a change to a core library/service/tool that is demonstrably good for many breaks tests for some? Is it with the person/team that made the fix? The person/team that wrote the test? The person/team that set things up so that nothing can be released with a failing test? And what should the next steps, immediate and long term, be anyway?</description>
    </item>
    <item>
      <title>Core Services</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/12/20/</link>
      <pubDate>Mon, 20 Dec 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/12/20/</guid>
      <description>Ran across an article that says core services are a bad idea. Given my background in infrastructure and things like BatchAPI I got a little upset at the title. But I&amp;rsquo;m a tolerant person and open to learning, so I decided to read the article.&#xA;Turns out I don&amp;rsquo;t disagree with the article, but I&amp;rsquo;d probably give it a different title. What the author is calling Core Services is what I&amp;rsquo;d call shared global data.</description>
    </item>
    <item>
      <title>Constraints and Creativity</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/12/17/</link>
      <pubDate>Fri, 17 Dec 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/12/17/</guid>
      <description>A puzzle is a problem we usually cannot solve because we make an incorrect assumption or self-imposed constraint that precludes a solution&#xA;&amp;ldquo;Creativity is the ability to identify self-imposed constraints, remove them, and explore the consequences of their removal.&amp;rdquo;&#xA;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;-- Russell Ackoff&#xA;Speaking of systems and systems thinking, what you don&amp;rsquo;t think about is just as important as what you do think about. Sometimes more so. Our experience puts lots of constraints on our thinking and in most cases it makes things simpler.</description>
    </item>
    <item>
      <title>Beware the RAT</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/12/16/</link>
      <pubDate>Thu, 16 Dec 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/12/16/</guid>
      <description>Not rodentia, although Pizza Rat should be avoided, but Rework Avoidance Theory (RAT). Back in the before times you shipped a product in a box, marketed the hell out of it, and hoped people bought it. What was in the box was it. There was never going to be more to it. If enough people liked it you might make a new version in a couple of years and try the same thing.</description>
    </item>
    <item>
      <title>OODA and Systems Thinking</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/12/14/</link>
      <pubDate>Tue, 14 Dec 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/12/14/</guid>
      <description>Lately I&amp;rsquo;ve been thinking about systems thinking a lot. The difference between complicated systems and complex systems. How you approach them and how you work with them. You can control a complicated system. It might take a while to find the right lever to pull or knob to turn, but once you figure it out you can control it pretty tightly with a feedback loop. Because a complicated system&amp;rsquo;s responses are (generally) linear and predictable.</description>
    </item>
    <item>
      <title>Scrape To Taste</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/12/13/</link>
      <pubDate>Mon, 13 Dec 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/12/13/</guid>
      <description>our system of make-and-inspect, which if applied to making toast would be expressed: &amp;ldquo;You burn, I&amp;rsquo;ll scrape.&amp;rdquo;&#xA;-- W. Edwards Deming&#xA;After 2 weeks at sea, just a quick thought on testing and quality. You can&amp;rsquo;t test quality into a product or system. I think testing is critical. Unit tests, integration tests, exploratory tests, visual tests, and sometimes, fun-ness tests. But as important as they are, all you can do with after the fact testing is make sure that you don&amp;rsquo;t inflict known defects on your users.</description>
    </item>
    <item>
      <title>Better Code</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/11/24/</link>
      <pubDate>Wed, 24 Nov 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/11/24/</guid>
      <description>Ran into a really interesting video the other day by Woody Zuill (of Mob Programming) and Llewellyn Falco. Lots of good things to learn there. I&amp;rsquo;ll leave it to you to watch for yourself. It&amp;rsquo;s the meta point that I find really interesting.&#xA;The meta point is that you don&amp;rsquo;t need to understand code to refactor it, and that by refactoring you gain understanding. Then, with understanding, it&amp;rsquo;s easier, and overall faster, to do the thing you want to do.</description>
    </item>
    <item>
      <title>Walking Through The Code</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/11/23/</link>
      <pubDate>Tue, 23 Nov 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/11/23/</guid>
      <description>I&amp;rsquo;ve been thinking about code quality a bunch lately and the kinds of metrics that exist for how &amp;ldquo;clean&amp;rdquo; code is. Things like cyclomatic complexity, maintainability index, nesting depth, method length, and Halstead volume. They all provide some info, but they&amp;rsquo;ve also got issues. While the source code is the ultimate source of truth for what is, it&amp;rsquo;s by no means the full story. It can&amp;rsquo;t tell you what problem it&amp;rsquo;s solving, why it is the way it is, why it isn&amp;rsquo;t some other way, or what the foreseen but not yet handled problems are.</description>
    </item>
    <item>
      <title>Ignorance As A Service</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/11/22/</link>
      <pubDate>Mon, 22 Nov 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/11/22/</guid>
      <description>Extreme Programming has been around for a while. It brought with it the concept of pair programming. 2 (or more) developers working together on one keyboard to complete a single task. Sounds crazy, no? In practice it turns out not to be. Which leads to the next question. How long should a pair program together?&#xA;I came across this paper from 2005 that describes one company&amp;rsquo;s results from experimenting with how much time there should be between pair changes.</description>
    </item>
    <item>
      <title>More WAT?</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/11/16/</link>
      <pubDate>Tue, 16 Nov 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/11/16/</guid>
      <description>Avoiding the Wat is important. It&amp;rsquo;s especially important when you&amp;rsquo;re designing APIs. APIs are for life. People will be using them long after you&amp;rsquo;ve stopped thinking about them and using them in ways you didn&amp;rsquo;t originally intend. When it comes to language design the stakes are even higher.&#xA;Consider the JavasScript language. It&amp;rsquo;s pretty widely used, so choices in the language design there are pretty impactful. JS has a lot of built in functionality.</description>
    </item>
    <item>
      <title>ADRs and You</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/11/15/</link>
      <pubDate>Mon, 15 Nov 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/11/15/</guid>
      <description>I&amp;rsquo;ve talked about Architectural Decision Records before. Today is the 10th anniversary of Michael Nygard&amp;rsquo;s original article on them so I wanted to mention them again. Not just to remind folks that we need to record our decisions (which we do), but also as a segue to what, and more importantly, who an architect is.&#xA;According to Martin Fowler, &amp;ldquo;Architecture is about the important stuff. Whatever that is.&amp;rdquo;. While not terribly specific, it&amp;rsquo;s a pretty good heuristic.</description>
    </item>
    <item>
      <title>PR Comments</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/11/12/</link>
      <pubDate>Fri, 12 Nov 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/11/12/</guid>
      <description>I&amp;rsquo;ve talked about what makes a good commit message. They&amp;rsquo;re important markers left for future developers to understand what changed and why as they look back to understand why things are the way they are. They&amp;rsquo;re also important in the moment to the people who are reviewing the code. They explain the purpose, expected changes and interactions, and potentially, what won&amp;rsquo;t change.&#xA;That&amp;rsquo;s important information when you&amp;rsquo;re reviewing a PR for a bunch of reasons.</description>
    </item>
    <item>
      <title>Plans and Planning</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/11/10/</link>
      <pubDate>Wed, 10 Nov 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/11/10/</guid>
      <description>We&amp;rsquo;re in the thick of planning season again, and at times like this it&#39;s helpful to remember something else Eisenhower said back in 1950, &amp;ldquo;Plans are worthless, but planning is essential.&amp;rdquo; That sounds paradoxical on the surface, but it&amp;rsquo;s a generalization of a line from von Moltke the Elder&amp;rsquo;s On Strategy, &amp;ldquo;no plan of operations extends with any certainty beyond the first contact with the main hostile force.&amp;rdquo; And given Eisenhower&amp;rsquo;s background, that&amp;rsquo;s not an unsuprising source.</description>
    </item>
    <item>
      <title>Cloth or Die</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/11/08/</link>
      <pubDate>Mon, 08 Nov 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/11/08/</guid>
      <description>You&amp;rsquo;ve probably heard of Adam Savage, of Mythbusters and tested.com fame. Lots of fun stuff there. And lots to learn as well. Every once and a while he&amp;rsquo;ll need to cut something. Depending on what it is, he&amp;rsquo;ll reach for a different tool. Plasma cutter for steel plate, Pipe cutter for pipe. Scissors for paper, cloth, aluminum and sheet metal.&amp;nbsp;&#xA;Unsurprisingly, he doesn&amp;rsquo;t use the same scissors for all of them.</description>
    </item>
    <item>
      <title>Continuous Education</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/11/05/</link>
      <pubDate>Fri, 05 Nov 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/11/05/</guid>
      <description>One of the things that I think is important for developers is continuous learning. There&amp;rsquo;s always something. From new fields to new techniques in an old field to new tools to really understanding the toolsets that are already in use.&#xA;Consider MS Word (or Google Docs). It took me a surprisingly long time to really internalize how to handle simple layout in those tools. Using page and section breaks instead of just hitting enter a bunch.</description>
    </item>
    <item>
      <title>Like A Baby</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/11/03/</link>
      <pubDate>Wed, 03 Nov 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/11/03/</guid>
      <description>Slept like a baby&#xA;Taking candy from a baby&#xA;Taking baby steps&#xA;What do those phrases mean to you? The generally accepted meaning is something like&#xA;Slept like a baby&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; -&amp;gt; Slept soundly and deeply Taking candy from a baby -&amp;gt; Easy&#xA;Taking baby steps&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; -&amp;gt; small tentative steps I&amp;rsquo;ve got 4 kids, and let me tell you, in my experience, reality doesn&amp;rsquo;t match that.</description>
    </item>
    <item>
      <title>Realms</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/11/01/</link>
      <pubDate>Mon, 01 Nov 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/11/01/</guid>
      <description>&amp;ldquo;Bounded Contexts&amp;rdquo; sounds stuffy and arcane, the sort of term whiteboard warriors would cook up so henceforth I&amp;rsquo;ll refer to them as &amp;ldquo;Realms&amp;rdquo; because Realms have boundaries and Context is King.&#xA;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;-- Dan Bara&#xA;As I&amp;rsquo;ve mentioned, I think context is important. And I like bounded contexts because boundaries are important too. They help in knowing what you need to worry about and what you don&amp;rsquo;t.&#xA;But as Dan points out, the term bounded contexts is pretty abstract.</description>
    </item>
    <item>
      <title>More Comments</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/10/21/</link>
      <pubDate>Thu, 21 Oct 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/10/21/</guid>
      <description>Code should be self documenting. That sounds good, but what does it mean? It&amp;rsquo;s about making your code legible. Names of things, variable, method, class, package, library, executable, etc should mean something. What the code is doing should be obvious from reading. Encapsulation and decomposition helps a lot here.&#xA;Writing the code itself is a conversation between you and the compiler/interpreter. It has to be very precise in what it does.</description>
    </item>
    <item>
      <title>The Tyranny of Or</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/10/20/</link>
      <pubDate>Wed, 20 Oct 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/10/20/</guid>
      <description>&amp;ldquo;The test of a first-rate intelligence is the ability to hold two opposed ideas in the mind at the same time, and still retain the ability to function.&#xA;One should, for example, be able to see that things are hopeless and yet be determined to make them otherwise.&amp;rdquo;&#xA;― F. Scott Fitzgerald, The Crack-Up&#xA;A or B? Pick one. Many problems are answered that way. And maybe they&amp;rsquo;ve even been posed that way.</description>
    </item>
    <item>
      <title>Legibility</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/10/19/</link>
      <pubDate>Tue, 19 Oct 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/10/19/</guid>
      <description>Definition of legible&#xA;1: capable of being read or deciphered&#xA;legible handwriting&#xA;2: capable of being discovered or understood&#xA;murder sweltered in his heart and was legible upon his face&#xA;-- Merriam Webster&#xA;The first one you know. UI/UX/Design stuff. Being easy to read. But the impact, positive and negative, of making things legible, especially the second definition, runs way deeper than choice of font size and foreground/background color.&#xA;Code can be readable and completely illegible.</description>
    </item>
    <item>
      <title>Prioritization vs. Categorization</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/10/15/</link>
      <pubDate>Fri, 15 Oct 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/10/15/</guid>
      <description>MoSCoW. The method, not the capital of Russia (or any other city) or the mule.&#xA;Must: The system must meet these requirements or is considered a failure&#xA;o&#xA;Should: The system should meet these requirements, but if it doesn&#39;t we can do it later&#xA;Could: The system could meet these requirements. No one will object, unless there are must and should requirements that are unmet&#xA;o&#xA;Won&#39;t: The system won&#39;t do this.</description>
    </item>
    <item>
      <title>Problem Solving</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/10/14/</link>
      <pubDate>Thu, 14 Oct 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/10/14/</guid>
      <description>A puzzle is a problem we usually cannot solve because we make an incorrect assumption or self-imposed constraint that precludes a solution&#xA;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;-- Russell Ackoff&#xA;Similar to the XY Problem and my favorite question, &amp;ldquo;What are you really trying to do here?&amp;rdquo;, when you get stuck on a problem, make sure you understand the space you&amp;rsquo;re working in.&#xA;In development those constraints often come from the existing systems. The data structures and flow that are in use to solve the problem as it was understood last week.</description>
    </item>
    <item>
      <title>(Work) Spaces</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/10/12/</link>
      <pubDate>Tue, 12 Oct 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/10/12/</guid>
      <description>&amp;quot;Multitasking&amp;quot; is probably too crude a category. When I first heard of XP, I thought pair programming was the *second* stupidest idea I&#39;d ever heard. The stupidest was everyone working in the same team room (*not* an &amp;quot;open office&amp;quot;). But&amp;hellip;&#xA;&amp;nbsp;&amp;nbsp;&amp;nbsp;-- Brian Marick&#xA;That&amp;rsquo;s something that resonates with me. And also a big part of what I miss about going to the office. I&amp;rsquo;ve been doing this programming thing for a while now, and I&amp;rsquo;ve done it in a lot of different environments.</description>
    </item>
    <item>
      <title>Inversion</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/10/07/</link>
      <pubDate>Thu, 07 Oct 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/10/07/</guid>
      <description>Goals are important. Knowing what you&amp;rsquo;re doing and why can help clarify things when you need to make a decision. Turning that around helps. Knowing what you&amp;rsquo;re not going to do is just as important.&#xA;Sometimes questions are like that too. Ask a question one way and it can be hard to answer. Invert the question and it can be a lot easier. Consider the following question:&#xA;Which one of the following does not have an integer cube root?</description>
    </item>
    <item>
      <title>It Happens</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/10/06/</link>
      <pubDate>Wed, 06 Oct 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/10/06/</guid>
      <description>&amp;quot;That hardly ever happens is another way of saying &#39;it happens&#39;.&amp;quot;&#xA;&amp;nbsp;&amp;nbsp;-- Douglas Crockford&#xA;When someone says &amp;ldquo;That hardly ever happens.&#39;&#39; there are two ways to approach the situation. The first is to take it at face value and put just enough effort into the rare case to ensure the system continues to operate, even if that little part fails. Like adding timeouts and retries to network requests. Something might be delayed or a user might have to click a button again, but things still happen.</description>
    </item>
    <item>
      <title>Slacking Off</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/10/05/</link>
      <pubDate>Tue, 05 Oct 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/10/05/</guid>
      <description>Firefighters, especially professional ones, have buckets of slack time. According to one study firefighters should have less than 25% utilization (time responding to incidents) to avoid burnout. 75% slack time. Built into the fabric of the system. If they don&amp;rsquo;t have that much slack time they scale up. Cities build more firehouses, buy more engines, and hire more firefighters to get that slack time back.&#xA;That&amp;rsquo;s probably a reasonable goal for your on-call person.</description>
    </item>
    <item>
      <title>Experience -&gt; Expertise -&gt; Wisdom</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/10/04/</link>
      <pubDate>Mon, 04 Oct 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/10/04/</guid>
      <description>ex&amp;middot;pe&amp;middot;ri&amp;middot;ence&#xA;practical contact with and observation of facts or events.&#xA;&amp;quot;he had already learned his lesson by painful experience&amp;quot;&#xA;ex&amp;middot;per&amp;middot;tise&#xA;expert skill or knowledge in a particular field.&#xA;&amp;quot;technical expertise&amp;quot;&#xA;wis&amp;middot;dom&#xA;the quality of having experience, knowledge, and good judgment; the quality of being wise.&#xA;&amp;quot;listen to his words of wisdom&amp;quot;&#xA;That&amp;rsquo;s the typical progression, right? You have experience(s). You gain expertise. You turn that into wisdom. That&amp;rsquo;s certainly the progression we all want, but is it typical?</description>
    </item>
    <item>
      <title>Is That An Error?</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/10/01/</link>
      <pubDate>Fri, 01 Oct 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/10/01/</guid>
      <description>&amp;ldquo;. . . the errors are errors now, but they weren&amp;rsquo;t errors then.&amp;rdquo;&#xA;&amp;nbsp; &amp;nbsp; -- Marianne A. Paget, The Unity of Mistakes: A Phenomenological Interpretation of Medical Work.&#xA;I&amp;rsquo;ve talked about tech debt and agility before. It&amp;rsquo;s the choices you make to get value sooner by pushing work out to the future. And it&amp;rsquo;s absolutely a good idea. When done in moderation and at the right time. Just like Taking on any other debt.</description>
    </item>
    <item>
      <title>Empowered?</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/09/29/</link>
      <pubDate>Wed, 29 Sep 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/09/29/</guid>
      <description>That&amp;rsquo;s what we all want, right? Managers should empower their teams. Individual contributors should be empowered to design the things they&amp;rsquo;re responsible for. That sounds right, but is it? When I hear about people being &amp;ldquo;empowered&amp;rdquo; I start to wonder. Before you think I&amp;rsquo;m going full-on Taylorism on you, think about the word empower.&#xA;Empower:&#xA;to give power or authority to; authorize, especially by legal or official means:&#xA;I empowered my agent to make the deal for me.</description>
    </item>
    <item>
      <title>Cost Of Time</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/09/28/</link>
      <pubDate>Tue, 28 Sep 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/09/28/</guid>
      <description>&amp;ldquo;I have only made this code more complex because I have not had the time to make it simpler.&amp;rdquo;&#xA;&amp;nbsp;&amp;nbsp;&amp;nbsp;-- Grady Booch&#xA;Getting things right takes time. Making things simple takes more time. The question is, how much time do you have, and when do you have it? Expediency says make it work and move on. But that leaves you with the complexity. And complexity leads to drag.&#xA;The question is, how do you deal with the drag?</description>
    </item>
    <item>
      <title>Engineering Excellence</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/09/27/</link>
      <pubDate>Mon, 27 Sep 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/09/27/</guid>
      <description>I maintain that we are engineers, and I&amp;rsquo;m not the only one. And of course, we all want to be excellent to each other. But what is engineering excellence, really?&#xA;It&amp;rsquo;s not doing code reviews or design docs or outage post mortems, but those are all part of it. It&amp;rsquo;s not SOLID or DRY or KISS, but those are part of it too. And it&amp;rsquo;s not staging environments, release processes, or alerting.</description>
    </item>
    <item>
      <title>Context Matters</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/09/23/</link>
      <pubDate>Thu, 23 Sep 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/09/23/</guid>
      <description>I&amp;rsquo;ve talked about contexts before. The contexts of what you and your audience know. The ubiquitous language of bounded contexts. And the shared context of experience. There&amp;rsquo;s another kind of context that I haven&amp;rsquo;t talked about. The kind of context that comes with size and environment.&#xA;Because size and environment change things. In a company of 10 people it&amp;rsquo;s possible for everyone to know everyone else. And for everyone to know as much (or as little) as they want about everything else.</description>
    </item>
    <item>
      <title>Measurement</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/09/22/</link>
      <pubDate>Wed, 22 Sep 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/09/22/</guid>
      <description>&amp;quot;What gets measured gets managed - even when it&amp;rsquo;s pointless to measure and manage it, and even if it harms the purpose of the organization to do so.&amp;quot;&#xA;&amp;mdash; Peter Drucker &amp;quot;It is wrong to suppose that if you can&amp;rsquo;t measure it, you can&amp;rsquo;t manage it &amp;ndash; a costly myth.&amp;rdquo;&#xA;&amp;mdash; W. Edwards Deming&#xA;&amp;ldquo;Managers who don&amp;rsquo;t know how to measure what they want settle for wanting what they can measure.</description>
    </item>
    <item>
      <title>Broken Windows</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/09/21/</link>
      <pubDate>Tue, 21 Sep 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/09/21/</guid>
      <description>A system that breaks randomly but frequently&amp;hellip;and requires very short bursts of work to resolve the issue&amp;hellip; will sap the morale of a team far out of proportion to the &amp;ldquo;size&amp;rdquo; of any ticket&#xA;-- John Cutler&#xA;When you overload a database and it falls over no-one is surprised that things stop. When that happens the team(s) involved dig in, pick it back up, and get things going again. Next they figure out the series of unfortunate events that caused the outage and do something to make sure it doesn&amp;rsquo;t happen again, or at least warn them before it does.</description>
    </item>
    <item>
      <title>Drive</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/09/20/</link>
      <pubDate>Mon, 20 Sep 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/09/20/</guid>
      <description>You&amp;rsquo;ve probably heard of Maslow&amp;rsquo;s Hierarchy of Needs. Especially the first four levels. What Maslow called the D-Needs. The basic life and safety needs. If those aren&amp;rsquo;t met, nothing else matters. Things like air, food, and shelter. And that makes sense. Without those, nothing else really matters. And for a long time That was motivational theory. In life and at work. People are motivated to have their D-Needs met, and a steady paycheck ensured that you could meet those needs.</description>
    </item>
    <item>
      <title>DNS Linkage</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/09/14/</link>
      <pubDate>Tue, 14 Sep 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/09/14/</guid>
      <description>Question: How dynamic is your linker? Or put another way, can DNS be considered a really late binding, dynamic linker? Or put a third way, is the only difference between a monolith and a gRPC microservice ecosystem when the binding occurs?&#xA;Of course DNS isn&amp;rsquo;t a linker. A static linker pre-calculates the memory address of a function call. Then it sets the value that will be set into the instruction pointer.</description>
    </item>
    <item>
      <title>That&#39;s a Drag</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/09/10/</link>
      <pubDate>Fri, 10 Sep 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/09/10/</guid>
      <description>Speaking of flow and WIP, the reason to reduce WIP is to increase flow. The reason for increasing flow is to reduce time to value. To add value sooner. So obviously, if you want to add value sooner, you need to go faster.&#xA;But what do you need to go faster at? Increasing to speed can help, but not as much as you think. What you really want to increase is your average speed.</description>
    </item>
    <item>
      <title>Flow and WIP</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/09/09/</link>
      <pubDate>Thu, 09 Sep 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/09/09/</guid>
      <description>Way back in 1975 Fred Brooks told us about the mythical man month and that adding people to a project that&amp;rsquo;s late will just make it later. There are lots of reasons for that. One of the biggest, according to Brooks, is that the number of communications channels between all of the people involved goes up roughly with the square of the number of people involved (actually n(n-1)/2), and all that communication at best slows things down, but more likely creates bottlenecks, which really limit things.</description>
    </item>
    <item>
      <title>GetXXX()?</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/09/05/</link>
      <pubDate>Sun, 05 Sep 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/09/05/</guid>
      <description>Language is important. The ubiquitous language of your domain. The metaphors you choose to use. The names you give things. Even the words that go into the name of a method are important.&#xA;Consider the word &#34;get&#34;. It gets stuck on the beginning of a lot of functions to indicate that a value is being returned. But what is it really telling you?&amp;nbsp;&#xA;According to the folks at Oxford, there are multiple uses of &#34;</description>
    </item>
    <item>
      <title>&#43;&#43; / --</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/09/03/</link>
      <pubDate>Fri, 03 Sep 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/09/03/</guid>
      <description>History Lesson&#xA;The ++ (and &amp;ndash;) operator has been around for a long time. Like 50+ years. They&amp;rsquo;re functions with side effects. Prefix (increment the variable and return the new value) and postfix (return the value, then increment) versions. You see them in loops a lot. They&amp;rsquo;re syntactic sugar created so that programmers could write code with fewer keystrokes. But what&amp;rsquo;s that got to do with strings?&#xA;They&amp;rsquo;re syntactic sugar because back in the day, when the only data type you had was the WORD, and the only data structure you had was the VECTOR, you ended up with lots of code that looked something like</description>
    </item>
    <item>
      <title>Speed</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/09/02/</link>
      <pubDate>Thu, 02 Sep 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/09/02/</guid>
      <description>It&#39;s a truism that going too fast is dangerous. It&#39;s human nature to slow down in the face of danger or uncertainty. When you walk into a dark room for the first time you don&#39;t run. You walk in slowly, possibly feeling around for obstacles. There&#39;s even a Facebook group telling our local community to stfdlouisville.&#xA;On the other hand, when I talk to my fighter pilot friends I get a different answer.</description>
    </item>
    <item>
      <title>Exploitation</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/08/17/</link>
      <pubDate>Tue, 17 Aug 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/08/17/</guid>
      <description>Internet Explorer 3.0 had its 25th birthday the other day. In honor of that one of the original devs posted about his experience on Twitter. He tells the story of 2 AM foosball games and having all meals at the office. I joined Microsoft a few years later, and while not every team was working late and having dinner delivered, the number of days that there wasn&amp;rsquo;t a team nearby that had dinner brought in, with enough leftovers for folks on other teams without dinner to get some, was vanishingly small.</description>
    </item>
    <item>
      <title>Architecture Isn&#39;t Everything</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/08/16/</link>
      <pubDate>Mon, 16 Aug 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/08/16/</guid>
      <description>Architecture is important. It&amp;rsquo;s about the user/customer. About adding value for that person. Engineering, on the other hand, is often the art of the possible. How can we build this in a feasible way? What do we need to do now, not directly for the user today, but so that we can do better for the user in the future. Which is another way to say that it&amp;rsquo;s a question of balance.</description>
    </item>
    <item>
      <title>Intro to TDD</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/08/12/</link>
      <pubDate>Thu, 12 Aug 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/08/12/</guid>
      <description>Test Driven Development (TDD) is an interesting concept. In many places the primary artifact of TDD, the unit test, has been used as an excuse to not have a test group/department. After all, if the unit tests pass, then the system has to work right?&#xA;Maybe. For a simple program or library that might be the case. But as systems get more complex that is less and less true. Because the behavior of the system is more than the behavior of the parts, and you can&amp;rsquo;t test system behavior by testing the parts.</description>
    </item>
    <item>
      <title>Prioritization</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/08/11/</link>
      <pubDate>Wed, 11 Aug 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/08/11/</guid>
      <description>I&amp;rsquo;ve talked about priority before. And how priorities inflate. Even the opposite of priority. Lots of different ways to keep track of what&amp;rsquo;s important and how the importance of one relates to another. There&amp;rsquo;s a little bit about how you prioritize, and some about how you track priority, but nothing about the cultural context you make priority decisions on.&#xA;Consider these two approaches to the exact same problem:&#xA;&amp;quot;In a world of abundant opportunities we need to pick the best one to pursue next.</description>
    </item>
    <item>
      <title>Architecture vs. Engineering</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/08/10/</link>
      <pubDate>Tue, 10 Aug 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/08/10/</guid>
      <description>Architecture must include engineering considerations, so that the design will be economically feasible; but the emphasis in architecture is upon the needs of the user, whereas in engineering the emphasis is upon the needs of the fabricator&#xA;-- Fred Brooks&#xA;How&amp;rsquo;s that for nuanced? Architecture emphasizes&amp;nbsp;the user, engineering emphasizes&amp;nbsp;the fabricator. Seems reasonable. Of course sometimes the &amp;ldquo;user&amp;rdquo; of the component is the next fabricator down the line. Or is the &amp;ldquo;user&amp;rdquo; the user of the system?</description>
    </item>
    <item>
      <title>Missing Tests</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/08/04/</link>
      <pubDate>Wed, 04 Aug 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/08/04/</guid>
      <description>Unit tests can do a lot of different things. Of course, they make sure things work the way you want them to at the beginning. They can provide documentation (and sample code) for your users. Your happy path tests are written the way the code should be used by customers, right? They can just look at the examples.&#xA;Unit tests are also great for debugging. If you&amp;rsquo;re going to be debugging you&amp;rsquo;re going to need a simple repro case so you can inspect the situation.</description>
    </item>
    <item>
      <title>On Decisions</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/08/03/</link>
      <pubDate>Tue, 03 Aug 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/08/03/</guid>
      <description>We make decisions all the time. Some with lots of degrees of freedom, some with only a few, or even one. Sometimes we make decisions with lots of empirical evidence and experience, other times, not so much. And sometimes, we choose to not choose, but as Neil Peart said,&#xA;If you choose not to decide, you still have made a choice&#xA;And assuming free will, choices have consequences. The question is, how do you know if you made a good decision or not?</description>
    </item>
    <item>
      <title>Mutators and Accessors</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/07/26/</link>
      <pubDate>Mon, 26 Jul 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/07/26/</guid>
      <description>That&amp;rsquo;s often how they&amp;rsquo;re taught, but really, they&amp;rsquo;re just another name for getters and setters. They&amp;rsquo;re a great way to encapsulate things. After all, you don&amp;rsquo;t want folks depending on the internal implementation of things. You want high coherence and low coupling, right?&amp;nbsp;&#xA;Or, are they a code smell, otherwise known as Accessors are Evil? Consider the lowly Rectangle class. Does a getter really give you isolation? Instead of declaring a public member Foo of type int you have a private foo and a public method Foo.</description>
    </item>
    <item>
      <title>Another 4 Questions</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/07/09/</link>
      <pubDate>Fri, 09 Jul 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/07/09/</guid>
      <description>Not those 4 questions, but the 4 variations of one very specific question, Why are we building this?&#xA;Why are we building this?&#xA;Why are we building this?&#xA;Why are we building this?&#xA;Why are we building this?&#xA;Because until you answer the 4 variants, you haven&amp;rsquo;t answered the question. There are lots of things we can/should build. Assuming there are some form of constraints, we can&amp;rsquo;t build them all. So which one(s) should we build?</description>
    </item>
    <item>
      <title>Simple Fixes</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/07/08/</link>
      <pubDate>Thu, 08 Jul 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/07/08/</guid>
      <description>So I&amp;rsquo;ll need you to replace the cat-3 cable from port AA-825 with a new cat-5 cable to desktop SPA-251. And I need it for a demo in 10 minutes. What do you do? And for context, here&amp;rsquo;s the current status If you really need to do it in 10 minutes what you&amp;rsquo;re probably going to do is unplug the cable in port AA-825 and run a new cable around that lump and route it to SPA-251.</description>
    </item>
    <item>
      <title>Synergy</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/07/07/</link>
      <pubDate>Wed, 07 Jul 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/07/07/</guid>
      <description>Synergy -&amp;nbsp;&#xA;the interaction of elements that when combined produce a total effect that is greater than the sum of the individual elements, contributions, etc.; synergism.&#xA;Or, put another way, emergent behavior. Put a bunch of simple things or rules together and see what happens. DNA is only 4 base pairs, and the combinations are limited, but somehow, when they combine in the right ways you get people. Or viruses. And everything in between.</description>
    </item>
    <item>
      <title>Tenure</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/07/02/</link>
      <pubDate>Fri, 02 Jul 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/07/02/</guid>
      <description>Today&amp;rsquo;s rant. How do you stay in the same job for more than 2 years?. According to the article, the answer is, you shouldn&amp;rsquo;t. That&amp;rsquo;s definitely an answer. And depending on your goal, it might work for you. But the cynicism and self-centered nature of it rubs me the wrong way.&#xA;I mean, objectively the statements are mostly true, but it&amp;rsquo;s the intent behind them I don&amp;rsquo;t like. Especially #4.&amp;nbsp;</description>
    </item>
    <item>
      <title>Autonomy != Anarchy</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/07/01/</link>
      <pubDate>Thu, 01 Jul 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/07/01/</guid>
      <description>Autonomy is more than a car or truck driving itself. According to dictionary.com it&amp;rsquo;s&#xA;independence or freedom, as of the will or one&#39;s actions&#xA;But what does it really mean? Especially to a team, working with other teams?&#xA;Autonomy is power. The power to decide, for yourself or your team, what the right answer is. The power to decide how to achieve that result, The power to decide how to present and share that result,</description>
    </item>
    <item>
      <title>Perspective</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/06/30/</link>
      <pubDate>Wed, 30 Jun 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/06/30/</guid>
      <description>You&amp;rsquo;ve probably seen this before, maybe you&amp;rsquo;re one of today&amp;rsquo;s lucky 10000.&#xA;What&amp;rsquo;s the number of the covered parking spot in this image?&#xA;When I first saw this I had no idea. Eventually I decided it had to be 128. Because pairwise, 16 - 6 = 10, 68 - 88 = -20, so x - 98 = 30. That&amp;rsquo;s a stretch, but it made some sense.&#xA;Of course, for parking spot numbers that makes no sense.</description>
    </item>
    <item>
      <title>Inspect And Adapt</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/06/29/</link>
      <pubDate>Tue, 29 Jun 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/06/29/</guid>
      <description>Agile. XP, Scrum, SAFe. Software development methods. Agile software development methods. They all have their trademarks. Processes and artifacts that you should do and produce that will lead you to high performance. Just follow the rules and it will happen for you.&#xA;There&amp;rsquo;s a basic assumption in there that may or may not be correct though. As Tolstoy put it,&amp;nbsp;&#xA;All happy (high performing) families (teams) are alike; each unhappy (low performing) family (team) is unhappy (low performing) in it&amp;rsquo;s own way.</description>
    </item>
    <item>
      <title>Obligations</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/06/28/</link>
      <pubDate>Mon, 28 Jun 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/06/28/</guid>
      <description>When we talk about incident management there are lots of things to keep in mind, and priority is important. My formative years were in aviation so to keep the priorities in order I always think of it as aviate, navigate, communicate.&#xA;Something bad happened. First and foremost, keep the airplane flying, don&amp;rsquo;t make or let it get worse. Find someplace safe to land. Figure out how to mitigate the problem. Call ATC and declare an emergency and keep them informed.</description>
    </item>
    <item>
      <title>Keeping Your Balance</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/06/25/</link>
      <pubDate>Fri, 25 Jun 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/06/25/</guid>
      <description>Macro vs Micro. Explicit vs Implicit. Small functions vs Big Functions. Up front design vs YAGNI. Like many things software, It Depends. It&amp;rsquo;s a question of balance.&#xA;But what are you balancing? In most cases, when you get down to it, what you&amp;rsquo;re balancing are the perceived/expected needs of the future against the needs of the moment. In conjunction with the known cost now compared to the potential cost later.</description>
    </item>
    <item>
      <title>Testing And Failure</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/06/24/</link>
      <pubDate>Thu, 24 Jun 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/06/24/</guid>
      <description>&amp;quot;Testing leads to failure, and failure leads to understanding.&amp;quot; - Burt Rutan&#xA;I&amp;rsquo;m an airplane guy. As such, I&amp;rsquo;ve been aware of Burt Rutan for 40+ years. I even once helped a friend build a VariEze. Way back before there was a Mark Zuckerberg, let alone Facebook, Rutan was experimenting and failing forward. Lots of iterative development. On paper, in wind tunnels, in the air, and in space.&#xA;As impressive as SpaceShipOne was, I think Voyager was even more impressive.</description>
    </item>
    <item>
      <title>Rocket Science</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/06/23/</link>
      <pubDate>Wed, 23 Jun 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/06/23/</guid>
      <description>Almost 120 years ago Konstantin Tsiolkovsky published his rocket equation:&#xA;&amp;nbsp;&#xA;That&amp;rsquo;s rocket science. Really. That&amp;rsquo;s all there is to it. One equation. For any given rocket the change in velocity (speed in a direction) is equal to the rocket exhaust velocity multiplied by the natural log of the ratio of the initial mass to the final mass.&#xA;Sure there are a lot of nuances, and any good physics teacher will tell you at the end of class that it isn&amp;rsquo;t quite as simple as it&amp;rsquo;s made out to be, but to a first (and probably second and third) approximation, that&amp;rsquo;s all there is to the science behind rockets.</description>
    </item>
    <item>
      <title>Global Data(base)</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/06/22/</link>
      <pubDate>Tue, 22 Jun 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/06/22/</guid>
      <description>A database is a giant global variable that pervades your code. How, exactly, is that a good thing?&#xA;&amp;nbsp;&amp;nbsp;-- Allen Holub&#xA;Well. That&amp;rsquo;s a pretty bold statement. Let&amp;rsquo;s break it down and see how true it is.&#xA;A database is certainly a &amp;ldquo;global&amp;rdquo; variable. Or at least it is in the sense that any code with the correct permissions/connection string can connect to it and read/write data. That does make it global.</description>
    </item>
    <item>
      <title>Lone Wolf - Hard Nope</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/06/17/</link>
      <pubDate>Thu, 17 Jun 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/06/17/</guid>
      <description>Sometimes I read something and wonder if I&amp;rsquo;m living in the same universe as the author. Then I think about it some more and realize I&amp;rsquo;m not. Consider this article about How a Single Freelancer Outperforms a Whole Team. At first glance it makes sense. From the Mythical Man-Month to convoy speeds, a single person can be shown to be individually efficient than a team.&#xA;But, as I have been known to say, &amp;ldquo;What are you really trying to do here?</description>
    </item>
    <item>
      <title>Design By Example</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/06/16/</link>
      <pubDate>Wed, 16 Jun 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/06/16/</guid>
      <description>Yesterday I talked about Design by Counter-Example. What about the opposite? You know what you want to do (the user story), but you don&amp;rsquo;t know how to do it, or what the API and internals should look like. How might that work?&#xA;You&amp;rsquo;d start with a real world problem. A user story that describes a way to make the user&amp;rsquo;s world better. Better by adding some value. It might be by eliminating manual work, reducing the number of steps, or some whole new way of approaching the problem that solves a user&amp;rsquo;s problem.</description>
    </item>
    <item>
      <title>Design By Counter-Example</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/06/15/</link>
      <pubDate>Tue, 15 Jun 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/06/15/</guid>
      <description>Every once in a while I come across a coworker who knows exactly what they don&amp;rsquo;t want. Whether it&amp;rsquo;s a design doc, slide deck, email, error message, icon, or whatever you&amp;rsquo;ve come up with isn&amp;rsquo;t it. They could tell you that you were close, but it&#39;s not what they&#39;re looking for. The level of detail wasn&#39;t right. or the constraints were at the wrong level. That the color or saturation was off.</description>
    </item>
    <item>
      <title>Complex Vs. Complicated</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/06/14/</link>
      <pubDate>Mon, 14 Jun 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/06/14/</guid>
      <description>According to dictionary.com, complex is:&#xA;adjective&#xA;composed of many interconnected parts; compound; composite:&#xA;a complex highway system. characterized by a very complicated or involved arrangement of parts, units, etc.:&#xA;complex machinery. so complicated or intricate as to be hard to understand or deal with:&#xA;a complex problem. While&amp;nbsp; complicated is:&#xA;adjective&#xA;composed of elaborately interconnected parts; complex:&#xA;complicated apparatus for measuring brain functions. difficult to analyze, understand, explain, etc.:&#xA;a complicated problem.</description>
    </item>
    <item>
      <title>More Than Cruft</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/06/10/</link>
      <pubDate>Thu, 10 Jun 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/06/10/</guid>
      <description>I&amp;rsquo;ve talked about Tech Debt before. The idea that, like with earnings, you can trade future work and understanding for earlier delivery of a product, then pay it back later. It made sense when I first heard about it, and it makes sense now.&#xA;What&amp;rsquo;s important though, is to do both parts. Not just pushing work or learning into the future to speed up delivery. But what does that really mean?</description>
    </item>
    <item>
      <title>Blink Estimation</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/06/09/</link>
      <pubDate>Wed, 09 Jun 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/06/09/</guid>
      <description>Speaking of Tacit Knowledge, have you heard of Blink Estimation? Take a medium sized group of people with significant tacit knowledge in a domain. Explain a problem/opportunity and give them some time to ask questions and explore the shape of the problem. Then, ask them for a rough order of magnitude of the level of effort required to implement the solution. If your group comes up with similar answers then you&amp;rsquo;ve got your estimate.</description>
    </item>
    <item>
      <title>Tacit Knowledge</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/06/08/</link>
      <pubDate>Tue, 08 Jun 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/06/08/</guid>
      <description>When I first heard about tacit knowledge and started looking into it, I thought it was the same thing as tribal knowledge. You know, those things that aren&amp;rsquo;t written down, never get explained, and you just need to know to be successful. Turns out that&amp;rsquo;s not the case. On the surface they seem similar in that in both cases you aren&amp;rsquo;t told the knowledge you&amp;rsquo;re looking for. The difference is that tacit knowledge is the kind of knowledge that can&amp;rsquo;t be explained with words (at least in an amount of time that is useful), not just something that hasn&amp;rsquo;t been explained.</description>
    </item>
    <item>
      <title>Multiple Projects</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/06/07/</link>
      <pubDate>Mon, 07 Jun 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/06/07/</guid>
      <description>Work in progress and I have an interesting relationship. I understand, both intellectual and viscerally, that regularly working on multiple things at once takes longer than doing the first things first. Motion is not the same as progress, and just because you&amp;rsquo;re busy doesn&amp;rsquo;t mean you&amp;rsquo;re adding value. On the other hand, sometimes there are external events you need to wait for. Doing nothing in those cases doesn&amp;rsquo;t help anyone. While not all motion is progress, lack of motion is lack of progress.</description>
    </item>
    <item>
      <title>Gift Giving</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/06/04/</link>
      <pubDate>Fri, 04 Jun 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/06/04/</guid>
      <description>I&amp;rsquo;ve talked about the gift of feedback before. How important it is, and how useful it is. One thing I didn&amp;rsquo;t talk about then though is what kind of feedback you give when. Gifts should match the occasion. You wouldn&amp;rsquo;t give a housewarming gift for a 75th anniversary, and feedback is just the same.&#xA;Let&amp;rsquo;s say you want your house painted, so you look around at newly painted houses and find that the ones you like have the same painter.</description>
    </item>
    <item>
      <title>Things We Know (or think we know)</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/06/03/</link>
      <pubDate>Thu, 03 Jun 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/06/03/</guid>
      <description>There are lots of things we know. Or at least assume to be true. But how many of them really are? Consider RFC 1925, which lays out a set of &amp;ldquo;truths&amp;rdquo; for the internet. And since it can be found on the Internet, it must be true.&#xA;Of course, sometimes the easiest way to define truth is to define what it isn&amp;rsquo;t. That&amp;rsquo;s where the Fallacies of distributed computing come in.</description>
    </item>
    <item>
      <title>Eliza</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/06/02/</link>
      <pubDate>Wed, 02 Jun 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/06/02/</guid>
      <description>And I don&amp;rsquo;t mean Eliza Doolittle. No, in this case I&amp;rsquo;m talking about one of, if not the first, natural language processing artificial intelligence agents. I&amp;rsquo;m talking about the Eliza that came out of MIT&amp;rsquo;s AI lab in the mid 60s.&#xA;Eliza and I are about the same age, and I first ran into it in my early teens. And like any typical teen, I spent a bunch of time getting Eliza wrapped up in knots and saying things that made no sense at all.</description>
    </item>
    <item>
      <title>Proverbially Speaking</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/06/01/</link>
      <pubDate>Tue, 01 Jun 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/06/01/</guid>
      <description>Go is a pretty minimalist language. When you get down to it, there&amp;rsquo;s not much there. There are only 25 keywords. Types come in 3 flavors, simple types, aggregate types, and reference types, and the magic interface. Simple types are numbers (int/uint/float with precisions), strings and booleans. Aggregates include arrays and structs, while reference types are slices, pointers, funcs, and a go-ism, channels. That&amp;rsquo;s it.&#xA;Any yet, you can, and people have, written significant system/back-end/control-plane tools and systems with it.</description>
    </item>
    <item>
      <title>When You Have A Hammer</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/05/28/</link>
      <pubDate>Fri, 28 May 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/05/28/</guid>
      <description>You haven&amp;rsquo;t mastered a tool until you understand when it should not be used.&#xA;&amp;ndash; Kelsey Hightower&#xA;I&amp;rsquo;ve talked about patterns and best practices before. They&amp;rsquo;re great. They give you a starting point. But they&amp;rsquo;re no substitute for thinking about your situation.&#xA;Consider the hammer, screwdriver, and pliers. In theory, there&amp;rsquo;s very little you can&amp;rsquo;t do with that set of tools. You use the hammer to put screws in. You use the pliers to take screws out.</description>
    </item>
    <item>
      <title>Wat</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/05/21/</link>
      <pubDate>Fri, 21 May 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/05/21/</guid>
      <description>Heading into the weekend, a little programming humor for you. All languages have their oddities, but some are a little odder than others. For instance, Javascript can lead to watman.&#xA;And if that&amp;rsquo;s not enough oddness, here are some more weird languages. Take a look, one of them might be just the thing for your next project, but probably not.&amp;nbsp;</description>
    </item>
    <item>
      <title>OOP at Scale</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/05/20/</link>
      <pubDate>Thu, 20 May 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/05/20/</guid>
      <description>Quick, what&amp;rsquo;s the defining item of object oriented programming? Classes? Hierarchy? Inheritance? Enterprise Java Factories?&amp;nbsp;&#xA;According to Alan Kay, who came up with the term over 50 years ago, the 3 defining parts of OOP are:&#xA;Message passing Encapsulation Dynamic binding Nothing about objects, classes, or inheritance. More about isolation and clear boundaries. You can (and should) do that with your code as well. Use function calls (message passing) instead of doing things yourself.</description>
    </item>
    <item>
      <title>Empirical Software Engineering</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/05/17/</link>
      <pubDate>Mon, 17 May 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/05/17/</guid>
      <description>What is software engineering? What is important to software engineering? What do we know about software engineering? How do we know what we know about software engineering?&#xA;Perhaps more importantly, what do we know we don&amp;rsquo;t know about software engineering? According to Hillel Wayne,&amp;nbsp;&#xA;Empirical Software Engineering is the study of what actually works in programming. Instead of trusting our instincts we collect data, run studies, and peer-review our results.</description>
    </item>
    <item>
      <title>Rice and Garlic</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/05/12/</link>
      <pubDate>Wed, 12 May 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/05/12/</guid>
      <description>Here&amp;rsquo;s another one from GeePaw Hill, all about rice and garlic. Actually, it&amp;rsquo;s not about rice and garlic. It&amp;rsquo;s about generic advice. As GeePaw tells it, he knows a chef who has a standard answer to the context-less question, &amp;ldquo;How can I make my cooking better?&amp;rdquo;. The blind answer is &amp;ldquo;That&amp;rsquo;s too much rice, and not enough garlic.&amp;rdquo; And you know, that&amp;rsquo;s pretty good advice when you don&amp;rsquo;t know what&amp;rsquo;s being cooked.</description>
    </item>
    <item>
      <title>Discipline</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/05/11/</link>
      <pubDate>Tue, 11 May 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/05/11/</guid>
      <description>I cannot emphasize too much that architecture is as much about programmer discipline as any technical consideration. Without programmer discipline, all systems, no matter how well designed, degrade quickly into gray goo at the hands of people who don&amp;rsquo;t understand the &amp;quot;why.&amp;quot; -- Allen Holub Back in the stone age (actually the late 80s/early 90s) I was working for a 3rd tier aerospace company in southern California. One of the things we built was a tool we called ARENA.</description>
    </item>
    <item>
      <title>NFRs and You</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/05/10/</link>
      <pubDate>Mon, 10 May 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/05/10/</guid>
      <description>NFRs are non-functional requirements. I&amp;rsquo;ve talked about them before, but lately the name has been bothering me. It&amp;rsquo;s that non in the name. Unlike non-goals, which are the things you&amp;rsquo;re not going to do or worry about, Your NFRs are not things that your project won&amp;rsquo;t do, and they&amp;rsquo;re not requirements you can ignore. NFRs are things you do need to worry about.&amp;nbsp;&#xA;I mean, look at the phrase non-functional requirement.</description>
    </item>
    <item>
      <title>Toasters</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/05/06/</link>
      <pubDate>Thu, 06 May 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/05/06/</guid>
      <description>Toasters are pretty simple. Put in a slice of bread. Push a knob/lever and a few minutes later your toast pops up, with some approximation of the level of doneness you want. If you&amp;rsquo;ve got a commercial toaster with a conveyor belt you don&amp;rsquo;t even need to push the knob.&#xA;But it&amp;rsquo;s only an approximation of the level of doneness you want. And it seems to drift over time. And with different breads and slice thicknesses.</description>
    </item>
    <item>
      <title>Pointers and Errors</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/05/05/</link>
      <pubDate>Wed, 05 May 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/05/05/</guid>
      <description>Go is pass by value. But it has pointers. And multiple return values. So here&amp;rsquo;s a question. Let&amp;rsquo;s say you&amp;rsquo;ve got a Builder of some kind, but there are combinations of parameters that are invalid, so your builder returns a struct and an error. Simple enough. The caller just checks the returned error, and if it&amp;rsquo;s non-nil does whatever is needed. If it is nil, just continue on and use the struct.</description>
    </item>
    <item>
      <title>Understanding</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/05/03/</link>
      <pubDate>Mon, 03 May 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/05/03/</guid>
      <description>Quick. What happens when someone passes a poorly formatted string to your interface? The interface notices and responds with the correct error code. Great. What if they set the colorize_output and the no_ouput flags? Do you colorize nothing? Arguably correct, but also arguably wrong, and probably indicative of a confused user. You can, and should, be testing all those cases, and others, and having well defined answers. Unit testing can help you avoid lots of customer issues.</description>
    </item>
    <item>
      <title>Best Practices?</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/05/01/</link>
      <pubDate>Sat, 01 May 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/05/01/</guid>
      <description>Design patterns are best practices. Best practices are, by definition, the best way to do things. It&amp;rsquo;s right there in the name. Therefore we should use design patterns for everything. Taken to its logical conclusion, you end up turning the interview FizzBuzz question into the Fizz Buzz Enterprise Edition. That&amp;rsquo;s perfect, right? It&amp;rsquo;s got, among other things, frameworks, abstractions, factories, strategies, Travis for CI, and it&amp;rsquo;s even got an implementation. Which means if you need a scalable, enterprise-ready version of FizzBuzz, you&amp;rsquo;re set.</description>
    </item>
    <item>
      <title>Leading Vs. Trailing</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/04/30/</link>
      <pubDate>Fri, 30 Apr 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/04/30/</guid>
      <description>Indicators and metrics, that is. Or maybe we should call them drivers and outcomes. Leading indicators are predictors. Done right they help you know what&amp;rsquo;s going to happen in the future. Trailing indicators, on the other hand, are all about what happened. Consider a car without a fuel gauge. From experience you know you&amp;rsquo;ve got 6 hours of fuel. After 5 hours driving down the highway you can predict that you&amp;rsquo;re low on fuel.</description>
    </item>
    <item>
      <title>Dogma</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/04/28/</link>
      <pubDate>Wed, 28 Apr 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/04/28/</guid>
      <description>Dogma (n): a principle or set of principles laid down by an authority as incontrovertibly true.&#xA;&amp;ndash; Oxford Languages&#xA;That&amp;rsquo;s one definition of dogma. The problem I have with dogma is the incontrovertible part. Because even if something was absolutely true once, that doesn&amp;rsquo;t mean it&amp;rsquo;s true now. Or will be in the future.&#xA;And what happens when your dogma disagrees with itself? It&amp;rsquo;s not usually existence ending, but it can be confusing.</description>
    </item>
    <item>
      <title>Flow vs. Utilization</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/04/27/</link>
      <pubDate>Tue, 27 Apr 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/04/27/</guid>
      <description>What should you optimize, utilization (how busy everyone is) or flow (how tasks are moving through the system)? How do you measure those things? What does it even mean if they&amp;rsquo;re high or low?&#xA;What does utilization mean for a developer? What does it include? Of course, time spent typing in code counts. And time spent writing tests. But what about time building/running code and tests? Or time documenting the design decisions made?</description>
    </item>
    <item>
      <title>We Like Ike</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/04/19/</link>
      <pubDate>Mon, 19 Apr 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/04/19/</guid>
      <description>Dwight David Eisenhower. 34th president of the United States. Supreme Commander of the Allied Forces in Europe. Brought the term military-industrial complex into the vocabulary. All in all, a pretty busy guy for much of his career. He did a lot of things and made a lot of decisions. And regardless of if you agree with those things or his decisions, one of the other things he gave us was a framework for deciding what needs to get done when.</description>
    </item>
    <item>
      <title>While You&#39;re In There ...</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/04/16/</link>
      <pubDate>Fri, 16 Apr 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/04/16/</guid>
      <description>When you&amp;rsquo;re in the middle of a complicated change and you come across something isn&amp;rsquo;t quite right, but doesn&amp;rsquo;t impact the work you&amp;rsquo;re doing, what do you do? What about if you&amp;rsquo;re adding a new capability and you spot the cause of your personal annoyance? It could be a simple misspelling, incorrect documentation, or something more substantial, like common code that everyone agrees should be refactored out, but no-one has done.</description>
    </item>
    <item>
      <title>Additive Vs. Subtractive</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/04/15/</link>
      <pubDate>Thu, 15 Apr 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/04/15/</guid>
      <description>There are two basic ways to make colors, additive and subtractive. Then there&amp;rsquo;s positive and negative space. M.C. Escher loved to play with positive and negative space, and you&amp;rsquo;ve probably seen the vase/face image. Michelangelo is said to have said that the sculpture is already inside the marble, he just removes the superfluous stuff.&#xA;But what has this got to do with software? We write software, we don&amp;rsquo;t carve it. We don&amp;rsquo;t start with a wall of text and release the program hidden within it.</description>
    </item>
    <item>
      <title>Monolith to Microservice</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/04/14/</link>
      <pubDate>Wed, 14 Apr 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/04/14/</guid>
      <description>Who knew Arthur C. Clarke and Stanley Kubrick were software architects? I certainly didn&#39;t. And yet, in 1968 they came up with&amp;nbsp;2001: A Space Odyssey, which&amp;nbsp;includes a great metaphor for what happens when a new team encounters an existing monolith.&#xA;There it is, in all its glory. It works. It does something. It also has what appears to be a featureless, impenetrable surface. We&amp;rsquo;re not sure how or why it works, and we certainly don&amp;rsquo;t know where to start digging in.</description>
    </item>
    <item>
      <title>Technical Debt and Agility</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/04/13/</link>
      <pubDate>Tue, 13 Apr 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/04/13/</guid>
      <description>How much technical debt can/should you accrue? How agile can you be? What&amp;rsquo;s the connection?&#xA;I&amp;rsquo;ve written about tech debt before. The important thing to remember about it is that the metaphor only holds if you understand that it&amp;rsquo;s about opportunity cost and future value of money. It&amp;rsquo;s not a license to write crappy code and expect that the software elves will magically fix it later. Used correctly it&amp;rsquo;s building what you need now instead of what you think you&amp;rsquo;ll need in 12 months.</description>
    </item>
    <item>
      <title>A &#39;Making&#39; App</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/04/12/</link>
      <pubDate>Mon, 12 Apr 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/04/12/</guid>
      <description>Some of us are building very complicated systems that run in multiple processes across multiple machines with a pub/sub model. Others are building large scale embarrassingly parallel systems, while others are building microservice based systems that take user input and modify persistent data stores.&#xA;In production those systems have lots of discrete physical components talking with each other over systems with varying latencies. And as you&amp;rsquo;ve probably experienced, you don&amp;rsquo;t really have a working system until you&amp;rsquo;ve properly handled the issues that come from having multiple components.</description>
    </item>
    <item>
      <title>Humor</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/04/09/</link>
      <pubDate>Fri, 09 Apr 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/04/09/</guid>
      <description>Every once and a while I wander back to defprogramming.com to see what comes up. Today I got&#xA;Code is like humor. When you have to explain it, it&amp;rsquo;s bad.&#xA;&amp;nbsp; &amp;nbsp; -- CORY HOUSE&#xA;Which I really like. Because code should be obvious when you read it. That doesn&amp;rsquo;t mean what to write is obvious. Far from it. The problem you&amp;rsquo;re trying to solve is nuanced. It&amp;rsquo;s complex. There are lots of corner cases to odel with.</description>
    </item>
    <item>
      <title>Naked Returns</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/04/08/</link>
      <pubDate>Thu, 08 Apr 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/04/08/</guid>
      <description>TIL that you don&amp;rsquo;t actually need to list the things you return from a method when you use the return keyword. That&amp;rsquo;s called a naked return. At first I thought of Scala&amp;rsquo;s return and how you generally shouldn&amp;rsquo;t use it, but it&amp;rsquo;s clearly not that. It&amp;rsquo;s not (basically) returning the last thing calculated when you exit a function. That has lots of potential issues by itself and has led to some odd looking code, but that&amp;rsquo;s a different story.</description>
    </item>
    <item>
      <title>Not Just About Crows</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/04/07/</link>
      <pubDate>Wed, 07 Apr 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/04/07/</guid>
      <description>I didn&amp;rsquo;t know this, but apparently the twitter user known as @tef_ebooks is all about the crows. Or at least posts lots of pictures about crows. I ran across them for something different.&#xA;thinking about that time i was in a meeting with amazon engineers, and my co-workers asked &amp;quot;what&#39;s serverless&amp;quot;&#xA;i said &amp;quot;per-request, not per-instance billing&amp;quot; and there was an awkward silence like all the hype had been let out of the room</description>
    </item>
    <item>
      <title>README.md</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/04/06/</link>
      <pubDate>Tue, 06 Apr 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/04/06/</guid>
      <description>Markdown is pretty simple. A few `#`&amp;rsquo;s, `*`&amp;rsquo;s, and `-`&amp;rsquo;s and you&amp;rsquo;ve got a formatted document. Unless you don&amp;rsquo;t.&#xA;But you know where markdown files really shine? As the lowly README.md. Not to be confused with Reamde, which is excellent, but something completely different.&#xA;That README file is amazing for a whole slew of reasons. Not the least of which is that, since by convention almost all files have lower case names, it&amp;rsquo;s right there at the front of your directory listing, right next to your Build(.</description>
    </item>
    <item>
      <title>OKRs and You</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/04/05/</link>
      <pubDate>Mon, 05 Apr 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/04/05/</guid>
      <description>What is a vision? What about a mission?&amp;nbsp; What do Key Performance Indicators (KPIs) and Objectives and Key Results (OKRs) have to do with either of them? When and where can you use them?&#xA;A vision statement is a picture of the future. It defines the end goal. The future the company wants to achieve.&#xA;A mission statement, on the other hand, says what you&amp;rsquo;re going to do to enable that vision.</description>
    </item>
    <item>
      <title>Hyrum&#39;s Law</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/04/02/</link>
      <pubDate>Fri, 02 Apr 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/04/02/</guid>
      <description>With a sufficient number of users of an API, it does not matter what you promise in the contract:&#xA;All observable behaviors of your system will be depended on by somebody.&#xA;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;-- Hyrum&amp;rsquo;s Law&#xA;Or, what&amp;rsquo;s old is new again. The earliest reference to Hyrum&amp;rsquo;s Law I could find was in late 2016, but that&amp;rsquo;s hardly the first time I ran across the idea. That&amp;rsquo;s just the name with the weight of Google behind it.</description>
    </item>
    <item>
      <title>Managing Expectations</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/03/31/</link>
      <pubDate>Wed, 31 Mar 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/03/31/</guid>
      <description>A suggestion by a general to a private is an order. An order from a 2nd Lieutenant to a Master Sergeant is a suggestion.&#xA;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;mdash; Unknown&#xA;I cannae change the laws of physics! I&#39;ve got to have thirty minutes!&#xA;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;mdash; Scotty (eight minutes before the Enterprise might be destroyed) Although they come at it from different directions, both of those are about expectation management. Whether you&amp;rsquo;re asking/demanding something, or being asked/told to do something, the expectations, on both sides, are defined not just by the words, but by the situation.</description>
    </item>
    <item>
      <title>Katas</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/03/30/</link>
      <pubDate>Tue, 30 Mar 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/03/30/</guid>
      <description>How do we get great designers? Great designers design, of course.&#xA;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;-- Fred Brooks&#xA;So how are we supposed to get great architects, if they only get the chance&amp;nbsp; to architect fewer than a half-dozen times in their career?&#xA;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;-- Ted Neward&#xA;If you don&amp;rsquo;t know what an architectural kata is, think of it this way. It&amp;rsquo;s a low risk opportunity to design a green-field solution based on a simple (&amp;frac12; page) RFP.</description>
    </item>
    <item>
      <title>Context</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/03/26/</link>
      <pubDate>Fri, 26 Mar 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/03/26/</guid>
      <description>Context can mean a lot of different things in different contexts. Golang even has a built in interface for it. Today I&amp;rsquo;m using context in the context of communication. Specifically, context as the collection of thoughts, ideas, and biases two or more people bring to a conversation. Even more specifically, the context I&amp;rsquo;m talking about is the difference between the contexts the people in that aforementioned conversation have.&#xA;There are the things you know (your context), the things the other people know (their context), the things everyone knows (global context) and the overlap between those three (shared context).</description>
    </item>
    <item>
      <title>Marie Kondo It</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/03/25/</link>
      <pubDate>Thu, 25 Mar 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/03/25/</guid>
      <description>You know what kind of code has zero bugs? The kind you didn&amp;rsquo;t write. You might have less features, but I assure you there are no unhandled exceptions or edge cases in code that doesn&amp;rsquo;t exist. Less code equals fewer interfaces, fewer special cases, fewer leaky abstractions, and fewer hidden bugs.&#xA;But you can&amp;rsquo;t just remove things that don&amp;rsquo;t spark joy. Some things are simply necessary, not joyful. But you do want to remove things that diminish joy.</description>
    </item>
    <item>
      <title>Lessons From Buckaroo Banzai</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/03/23/</link>
      <pubDate>Tue, 23 Mar 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/03/23/</guid>
      <description>But first, today is a day like any other day, but it&#39;s also different. Especially here in Colorado, but not just here. Shocking events are just that, shocking. And it takes time to process them. So take the time. Take care of yourself. Recognize that different people process shock differently. Don&#39;t expect today to be just like any other day.&#xA;I first heard the phrase Don&amp;rsquo;t tug on that in The adventures of Buckaroo Banzai Across the Eighth Dimension.</description>
    </item>
    <item>
      <title>Tell Me About A Time When ...</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/03/19/</link>
      <pubDate>Fri, 19 Mar 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/03/19/</guid>
      <description>I&amp;rsquo;ve been doing interviews for a while now. And one of the questions I like to ask candidates, of all levels, is to tell me about a time when they made a mistake that had significant impact. I find that there&amp;rsquo;s a lot of signal in the answer. There&amp;rsquo;s information on how self-aware the candidate is, what they find important, and how they respond to mistakes, both in the moment, and afterwards.</description>
    </item>
    <item>
      <title>String Style</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/03/18/</link>
      <pubDate>Thu, 18 Mar 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/03/18/</guid>
      <description>Text is hard. Ascii is fairly straightforward, but Unicode is hard, and UTF-8 is NOT Ascii. Styling your text is hard too. Markdown is supposed to be simple and hopefully transportable, but &amp;hellip;&#xA;And that doesn&amp;rsquo;t even get into how you type out an identifier, even if you&amp;rsquo;re using ASCII. Most (all?) languages use a space as a separator, so if you want a variable for the number of words in a paragraph you can&amp;rsquo;t use &amp;ldquo;number of words&amp;rdquo;.</description>
    </item>
    <item>
      <title>Creep</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/03/17/</link>
      <pubDate>Wed, 17 Mar 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/03/17/</guid>
      <description>Creep is not just a really bad acronym for political fundraising group. It&amp;rsquo;s also moving slowly forward, or in development terms, Scope/Feature Creep is when the requirements expand beyond the initial definition. The question is not if it&amp;rsquo;s going to happen, but what you&amp;rsquo;re going to do about it and if it&amp;rsquo;s a good thing or not. Invariably, when you&amp;rsquo;re trying to do something you, and possibly no-one, has ever done before you&amp;rsquo;ll find that the work needed does not exactly match the work you expected.</description>
    </item>
    <item>
      <title>Artificial Stupidity</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/03/16/</link>
      <pubDate>Tue, 16 Mar 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/03/16/</guid>
      <description>Back when I was working on Combat Flight Simulator we had a problem. The game had varying levels of difficulty, but what did that mean? What&amp;rsquo;s the difference between Easy, Medium, and Hard? There were lots of things we did before we gave anyone a chance to try it out. Some were simple, like unlimited ammo and fuel, or invulnerability. Others were a little more involved, like changing how accurate your aim needed to be and the damage radius of things.</description>
    </item>
    <item>
      <title>Single Responsibility Principle</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/03/15/</link>
      <pubDate>Mon, 15 Mar 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/03/15/</guid>
      <description>The Single Responsibility Principle (SRP) is a follow-on/extension to Don&amp;rsquo;t Repeat Yourself (DRY). It basically says that and given module should be responsible for one part of a program&amp;rsquo;s functionality.&#xA;Or does it? That&amp;rsquo;s the common understanding, but if you go back to the author and the original text that&amp;rsquo;s not quite it. In Robert Martin&amp;rsquo;s clarifying blog post you find something a little bit different. Instead of being based on functionality, it&amp;rsquo;s based on reasons for change.</description>
    </item>
    <item>
      <title>Tick-Tock</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/03/12/</link>
      <pubDate>Fri, 12 Mar 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/03/12/</guid>
      <description>Commits and Pull Requests (diffs) are very similar, but they&amp;rsquo;re not the same thing. The basic difference is that git commits are local (ish) and PRs/Diffs are public. And there&amp;rsquo;s a lot of value in understanding the difference between your private and public record of changes. But what&amp;rsquo;s that got to do with tick-tock?&#xA;One way they&amp;rsquo;re related is refactoring. There are lots of reasons to refactor code, but they mostly come down to not knowing what you didn&amp;rsquo;t know.</description>
    </item>
    <item>
      <title>A Question Of Balance</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/03/11/</link>
      <pubDate>Thu, 11 Mar 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/03/11/</guid>
      <description>And it&amp;rsquo;s not just an underrated Moody Blues album It&amp;rsquo;s been said that it&amp;rsquo;s important to write code for the maintainer, code that&amp;rsquo;s easy for a person to understand. It&amp;rsquo;s also been said that code should be decoupled and easy to change as requirements change. The problem is that these two goals are often in conflict. One of the easiest ways to make code easy to understand is to make it very explicit.</description>
    </item>
    <item>
      <title>Experimental Results</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/03/10/</link>
      <pubDate>Wed, 10 Mar 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/03/10/</guid>
      <description>We&amp;rsquo;re always doing experiments. Right now we&amp;rsquo;re probably doing more formal experiments than normal, but whenever you&amp;rsquo;re doing something new it could be considered an experiment. Depending on your knowledge and experience, it might be one with a much higher expectation of success than a traditional experiment, but writing code is just an experiment to validate the hypothesis that is the design.&#xA;Coding, like all experiments, will have a result. Since you&amp;rsquo;re writing the code to add value, you have a vested interest in a specific outcome.</description>
    </item>
    <item>
      <title>You&#39;re Sunk</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/03/09/</link>
      <pubDate>Tue, 09 Mar 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/03/09/</guid>
      <description>Ever been in one of those situations where you know you&amp;rsquo;ve almost got something figured out so you keep trying? You dig and dig, making small steps until you finally reach a solution. That can feel really rewarding. But sometimes you look around afterwards and realize that while you might have ended up in the right place, the route you took to get there was suboptimal. There are many potential reasons for that, and one of the more common is the sunk cost fallacy.</description>
    </item>
    <item>
      <title>Lumpers and Splitters</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/03/05/</link>
      <pubDate>Fri, 05 Mar 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/03/05/</guid>
      <description>Are you a lumper or a splitter? I like to think of myself as a splitter, finding boundaries and cleaning architecture as I go, but I&amp;rsquo;m not sure that&amp;rsquo;s always true.&#xA;Because to be a splitter, you need to have a deep(ish) understanding of the problem. And you can&amp;rsquo;t have a deep understanding of the problem, solution, and its internal boundaries until you&amp;rsquo;ve lived with both the problem and a solution for a while.</description>
    </item>
    <item>
      <title>Functional Options</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/03/04/</link>
      <pubDate>Thu, 04 Mar 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/03/04/</guid>
      <description>I&amp;rsquo;ve written about the Builder pattern before. It&amp;rsquo;s a way to give folks a set of default options for a constructor along with a way to set all of the options, and then validate things before actually creating the object. It&amp;rsquo;s nice because it lets you set all the parameters, in whatever order you see fit, and only validate them at the end. This can be important if setting parameters one at a time can put things in an invalid state temporarily.</description>
    </item>
    <item>
      <title>The Way</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/03/03/</link>
      <pubDate>Wed, 03 Mar 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/03/03/</guid>
      <description>I recently stumbled back across an article titled Ron Jeffries Says Developers Should Abandon &amp;quot;Agile&amp;quot;. And it&amp;rsquo;s strictly true. Jefferies did say that. Unfortunately it&amp;rsquo;s not the whole story. That&amp;rsquo;s much more nuanced, and won&amp;rsquo;t fit in a headline.&#xA;What he said was that many organizations are imposing processes and systems with &amp;ldquo;Agile&amp;rdquo; in their name. Those systems use many of the same words and descriptions from the original Agile Manifesto.</description>
    </item>
    <item>
      <title>A &#39;Just&#39; Culture</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/03/02/</link>
      <pubDate>Tue, 02 Mar 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/03/02/</guid>
      <description> Safety and a &amp;quot;Just Culture&amp;quot;. Things we all want and need. How do we get there? The Blameless Postmortem is a great start. </description>
    </item>
    <item>
      <title>Optimizing Tests</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/03/01/</link>
      <pubDate>Mon, 01 Mar 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/03/01/</guid>
      <description>Like most things engineering, the answer to the question &amp;ldquo;Is this a good test?&amp;rdquo; is it depends. Tests have properties and the different kinds of tests make different tradeoffs between those properties.&#xA;While there are a lot of different properties a test could have, some of the most important are:&#xA;Deterministic: A good test gives the same result every time. Which usually means it has no external dependencies.&#xA;Fast:Tests should be fast.</description>
    </item>
    <item>
      <title>Oracles</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/02/25/</link>
      <pubDate>Thu, 25 Feb 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/02/25/</guid>
      <description>One of the things I was taught about driving, particularly night driving, way back when, was that you should never drive faster than you could see. Taken literally, that either makes no sense, or says never driver faster than the speed of light. But it does make sense. It means you should make sure you always have time to avoid any obstacle you suddenly see or, make sure you can stop before you hit something you suddenly see.</description>
    </item>
    <item>
      <title>Containment</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/02/24/</link>
      <pubDate>Wed, 24 Feb 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/02/24/</guid>
      <description>I&amp;rsquo;ve talked about failure modes before, but there was an incident last weekend that reminded me of them again. United 328, from leaving Denver for Honolulu, had a failure. A pretty catastrophic one. Most likely they lost a fan blade, which took out the rest of the engine. But as scary as it was for the folks on the plane and on the ground under it, no-one got hurt. That&amp;rsquo;s because a group of engineers thought about the safety case and the possible failure modes and planned for it.</description>
    </item>
    <item>
      <title>MBWA vs Gemba</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/02/23/</link>
      <pubDate>Tue, 23 Feb 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/02/23/</guid>
      <description>Management By Walking Around (MBWA) is a management style where a manager walks around to the various people/workstations, seeing what&amp;rsquo;s going on, talking to people, observing and directing as they feel appropriate.&#xA;Gemba is Japanese for &amp;ldquo;the actual place&amp;rdquo; and is used in the Lean Methodology to represent the idea of managers periodically &amp;ldquo;walking the line&amp;rdquo;, or going to the workplace to see how things are going, listen to people, and observe what&amp;rsquo;s happening to better understand value creating and identify waste.</description>
    </item>
    <item>
      <title>Discoverability vs. Findability</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/02/22/</link>
      <pubDate>Mon, 22 Feb 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/02/22/</guid>
      <description>First things first. discoverability and findability are not the same thing. Findable is relatively easy. You know something exists. You saw it once or someone told you about it. You know what you&amp;rsquo;re looking for, but you don&amp;rsquo;t know where it is. Like your car keys or that status dashboard. Discoverability, on the other hand, is about learning. You can only discover something once. The second time you see something you haven&amp;rsquo;t discovered it, you&amp;rsquo;ve found it.</description>
    </item>
    <item>
      <title>I&#39;ve got you covered</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/02/19/</link>
      <pubDate>Fri, 19 Feb 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/02/19/</guid>
      <description>Code coverage is important. If you haven&amp;rsquo;t exercised your code then you don&amp;rsquo;t know if it works. If you don&amp;rsquo;t know it works, how can you be done?&#xA;So code coverage is important. If all your code is covered by your unit tests you can feel pretty confident that your code does what you think it does. Test Driven Development (TDD) is a good way to approach it. Figure out what you want your code to do.</description>
    </item>
    <item>
      <title>YAGNI, but ...</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/02/18/</link>
      <pubDate>Thu, 18 Feb 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/02/18/</guid>
      <description>I&amp;rsquo;ve said it before, and I&amp;rsquo;ll probably say it again. Remember YAGNI. You Ain&amp;rsquo;t Gonna Need It. But, YAGNI, until you do. And if you haven&amp;rsquo;t planned for it, then what?&#xA;We got about 5 inches of snow overnight here in sunny Colorado. It&amp;rsquo;s all shoveled now, and I used my legs, not my back, so I&amp;rsquo;m fine. Actually, this is Colorado Powder, so I used a 36&amp;rdquo; push-broom for most of it.</description>
    </item>
    <item>
      <title>Ch-ch-ch-ch-changes</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/02/17/</link>
      <pubDate>Wed, 17 Feb 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/02/17/</guid>
      <description>The greatest payoff of domain-driven design is not that the *state* of a business domain maps cleanly onto software but that *changes* to a business domain map cleanly onto software.&#xA;&amp;nbsp;&amp;nbsp;&amp;nbsp;-- Chris Ford&#xA;Domain-Driven Design has lots of benefits. Ubiquitous language. Clear Boundaries. It works with the business, not against it. And done right it changes with the business.&#xA;Back in my early days I was working with a FORTRAN simulation of an F18.</description>
    </item>
    <item>
      <title>MVP</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/02/16/</link>
      <pubDate>Tue, 16 Feb 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/02/16/</guid>
      <description>Just what is an MVP anyway? Like everything else, it depends. In this case on context. The Super Bowl has a Most Valuable Player, but that&amp;rsquo;s not the MVP I mean, In this case I&amp;rsquo;m talking about the MVP as Minimum Viable Product. But even there, MVP isn&amp;rsquo;t consistently used. I first ran into the term when I was working on the initial release of in-browser 3D mapping for Virtual Earth.</description>
    </item>
    <item>
      <title>Strict Product Liability</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/02/12/</link>
      <pubDate>Fri, 12 Feb 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/02/12/</guid>
      <description>How many times have you heard That&amp;rsquo;s not a bug, that&amp;rsquo;s a feature? Usually it&amp;rsquo;s a developer saying that to a user or tester as an excuse for things not working as expected, but sometimes it&amp;rsquo;s &amp;ldquo;the street finds its own uses for things&amp;rdquo;. And how you respond depends on how you approach the situation.&#xA;Consider this video showing how a developer might react to a tester not using the product as intended.</description>
    </item>
    <item>
      <title>Kinds Of Tests</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/02/11/</link>
      <pubDate>Thu, 11 Feb 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/02/11/</guid>
      <description>There are lots of classes of tests. It all depends on what your goals are. Using the correct test for the situation ensures you&amp;rsquo;re actually testing what you think you are.&#xA;Unit tests are good for testing things in isolation. They let you control the inputs, both direct and dependent, and make sure the result is what you expect. The tighter the control you have the more reproducible the test and the fewer false positives you get.</description>
    </item>
    <item>
      <title>Cognitive Load</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/02/10/</link>
      <pubDate>Wed, 10 Feb 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/02/10/</guid>
      <description>I talk about cognitive load a lot (over 2 dozen times in the last year). Especially about reducing cognitive load. But what is it, and why is it important? And what does it have to do with software development, especially architecture and design?&#xA;To give an analogy, let&amp;rsquo;s imagine the brain is a tool. A general purpose tool that, with some instructions/adjustment can do lots of different things, You can store those instructions away and get them back when you need to do what they&amp;rsquo;re for.</description>
    </item>
    <item>
      <title>Charting A Path</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/02/09/</link>
      <pubDate>Tue, 09 Feb 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/02/09/</guid>
      <description>It&#39;s a sea chart, not a road map. Map out the destination (strategic goals) and the hazzards, but the route depends on the wind. &amp;quot;Road map&amp;quot; is not a useful metaphor.&#xA;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;-- Allen Holub&#xA;Sometimes you run across a phrase that really resonates. This is one of those cases. I&amp;rsquo;ve talked about roadmaps before, but it took me a few paragraphs and 6 questions to say what Allen said in 3 sentences.</description>
    </item>
    <item>
      <title>The -ilities</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/02/08/</link>
      <pubDate>Mon, 08 Feb 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/02/08/</guid>
      <description>In software engineering there are lots of different kinds of requirements. There are the functional ones. They are the obvious ones that describe what the software is supposed to do. There are less obvious ones, that talk about what the software should do when something goes wrong. Then there are business requirements, like time to market and operational costs. And finally there&amp;rsquo;s a whole set of requirements that have nothing to do with how the software should work, or when it should be ready.</description>
    </item>
    <item>
      <title>NoHello</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/02/05/</link>
      <pubDate>Fri, 05 Feb 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/02/05/</guid>
      <description>Software development is an odd mix of collaboration and isolation. Especially now that we&amp;rsquo;re all WFH. And we work for a distributed company. Across at least 4 time zones worth of offices and folks working from even more places. Which means that collaboration takes place mostly on Zoom/gMeet instead of in person. Both of those are pretty high bandwidth and interactive, which is good. But because we&amp;rsquo;re not all awake at the same time, let alone working at the same time, that kind of real-time, high bandwidth, synchronous connection isn&amp;rsquo;t always possible.</description>
    </item>
    <item>
      <title>Precision vs. Accuracy</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/02/04/</link>
      <pubDate>Thu, 04 Feb 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/02/04/</guid>
      <description>Everyone wants to be accurate, and everyone wants to be precise. Those are both great goals. It&amp;rsquo;s a wonderful thing when you can be precise and accurate. On the other hand it becomes a problem when you trade one for another or even worse, mistake one for the other.&#xA;What&amp;rsquo;s the difference between precision and accuracy? The way I think about it, precision is a measure of the &amp;ldquo;size&amp;rdquo; of a quanta.</description>
    </item>
    <item>
      <title>Poor Man’s Polymorphism</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/02/03/</link>
      <pubDate>Wed, 03 Feb 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/02/03/</guid>
      <description>It&amp;rsquo;s been said that an if statement is polymorphism at its most basic. It&amp;rsquo;s also been said that if-else is a code smell. Last year I talked about using data and data structures to eliminate if and switch from your code. Coding to interfaces can make your code cleaner and easier to follow. If reducing if is good then eliminating it is great, right?&#xA;Not always. A big part of development is building a mental model of what you want to happen.</description>
    </item>
    <item>
      <title>Expediency</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/02/02/</link>
      <pubDate>Tue, 02 Feb 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/02/02/</guid>
      <description>Sometimes the wrong solution is the right solution at a particular moment in time. Times when code that might be&amp;nbsp;less than elegant&amp;nbsp;is appropriate. Back in the day of boxed products and in-store shopping, getting the gold master disk to the manufacturer in time to get your production slot was one of them. Miss your slot and you might miss holiday sales. Today it&amp;rsquo;s outage mitigation. The longer an outage goes on the more your customers suffer.</description>
    </item>
    <item>
      <title>Help Me</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/01/29/</link>
      <pubDate>Fri, 29 Jan 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/01/29/</guid>
      <description>I&amp;rsquo;ve talked before about how to ask for help. How you ask is important for lots of reasons. It lets the other person know what problem you&amp;rsquo;re trying to solve. It lets them know what didn&amp;rsquo;t work so they don&amp;rsquo;t suggest that. It shows that you&amp;rsquo;ve put in some effort and you&amp;rsquo;re not just looking for someone to do the work for you.&#xA;But just as important as how to ask is&amp;nbsp;when&amp;nbsp;to ask.</description>
    </item>
    <item>
      <title>The Scouting Rule</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/01/28/</link>
      <pubDate>Thu, 28 Jan 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/01/28/</guid>
      <description>Try and leave this world a little better than you found it.&#xA;&amp;ndash; Lord Baden-Powell&#xA;The scouts have as one of their tenets to not just clean up the campsite after themselves, but to make it a little cleaner/better. While we might not be scouts now, that idea applies to us too. It&amp;rsquo;s also a great way to manage technical debt.&#xA;Development velocity is important. The speed at which we can add features/capabilitiesdrives how quickly we can add value.</description>
    </item>
    <item>
      <title>A Short Pause</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/01/22/</link>
      <pubDate>Fri, 22 Jan 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/01/22/</guid>
      <description>Just wanted to let everyone know that I&#39;m going to take a short pause here. I&#39;m working with the Aurora comms team to figure out the best way to move forward with this and share with an even broader audience.&#xA;I wanted to say thank you to everyone. Working on these has helped me clarify my thoughts and think deeper about my opinions and viewpoints. So thank you to all those who commented or reacted in Slack or reached out directly.</description>
    </item>
    <item>
      <title>Current State</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/01/21/</link>
      <pubDate>Thu, 21 Jan 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/01/21/</guid>
      <description>State is important. And state is hard. It&#39;s one of the two hard things in computer science. Even something as simple as checking if a file exists or the value of a variable as a test to do/not do something. Between the time you check and the time you act the state could change. Unless you do some kind of mutual exclusion to prevent it. a&amp;nbsp;mutex&amp;nbsp;if you will. Having multiple cores and multiple CPUs in a system running multiple simultaneous processes make it even harder, but with global locking and integrated test and set routines in the silicon it&#39;s doable.</description>
    </item>
    <item>
      <title>Moving Day, Part 2</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/01/20/</link>
      <pubDate>Wed, 20 Jan 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/01/20/</guid>
      <description>Today is the first day in the new house. Of course many things are the same. This channel hasn&#39;t changed (yet). Still in the same office away from the office. Still using the same hardware. Still working on the same projects. Goals are still&amp;nbsp;mostly&amp;nbsp;the same.&#xA;But, lots of things have changed. And again, in the spirit of a physical move, some things to keep in mind as we settle into our new home.</description>
    </item>
    <item>
      <title>Moving Day, Part 1</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/01/19/</link>
      <pubDate>Tue, 19 Jan 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/01/19/</guid>
      <description>In case you haven&amp;rsquo;t been paying attention, today is our last day in our old house. Which means it&amp;rsquo;s part 1 of moving day, the packing. Of course this is a virtual move, since there&#39;s been an acquisition and we&#39;re working for a new company, not really changing jobs. Also, we&amp;rsquo;re all pretty much working for home already, and the commute isn&amp;rsquo;t going to change much.&#xA;But lots of things are going to change.</description>
    </item>
    <item>
      <title>Captain Crunch</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/01/15/</link>
      <pubDate>Fri, 15 Jan 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/01/15/</guid>
      <description>This morning I ran across an article on crunch time in the game development industry. As many of you know, I&amp;rsquo;ve been doing the development thing for a while now. And much of the early years was gaming. Mostly flight simulations, but also other simulations and general gaming. And I can tell you from first hand experience and countless discussions with peers at other companies that crunch time is real. And yes, it&amp;rsquo;s not just the last 18 months of a 12 month project.</description>
    </item>
    <item>
      <title>Discoverability</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/01/14/</link>
      <pubDate>Thu, 14 Jan 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/01/14/</guid>
      <description>For a while we had a column on our sprint board called &amp;ldquo;Documentation&amp;rdquo;. It was a catch-all column to help us remember that things weren&amp;rsquo;t &amp;ldquo;done&amp;rdquo; until they were shared. They say that if you build a better mousetrap the world will beat a path to your door. That may be true, but only if the world knows you built it. Yes, iIt&amp;rsquo;s possible for word of something to leak out and for usage to grow, but that&amp;rsquo;s not the normal case.</description>
    </item>
    <item>
      <title>Adapters, Facades, and Decorators - Oh My</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/01/13/</link>
      <pubDate>Wed, 13 Jan 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/01/13/</guid>
      <description>The&amp;nbsp;GOF&amp;nbsp;gave us&amp;nbsp;Design Patterns&amp;nbsp;in 1994. It&#39;s been helping and confusing folks ever since. There&#39;s good high level advice and a bunch of patterns that can be reused. The confusion comes around because some of them are very similar, but as usual, the details are important.&#xA;Consider the adapter, facade, and decorator patterns. All of them take existing functionality and wrap it, changing the interface slightly. So why are there 3 different patterns and which one should you use?</description>
    </item>
    <item>
      <title>YAML</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/01/12/</link>
      <pubDate>Tue, 12 Jan 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/01/12/</guid>
      <description>Hard coded config is bad. Making code flexible is good. We can debate that at another time, but let&#39;s go with that for now. One of the ways to make your code more generic is to move the instance specific data to an external config file that gets read and used at runtime. That way the same code can run in multiple environments and you don&#39;t have to worry about which version is deployed where.</description>
    </item>
    <item>
      <title>Roadmaps</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/01/11/</link>
      <pubDate>Mon, 11 Jan 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/01/11/</guid>
      <description>One of the key things that makes a shared journey possible is a shared destination. If you&#39;re not all going to the same place the chances that you&#39;ll end up in the same place are pretty slim. But while a shared destination is key, it&#39;s not enough. To have a successful shared journey you need a shared&amp;nbsp;roadmap.&#xA;It&#39;s not that everyone needs to be traveling the same path. Although many will travel the same path, there are multiple ways to get from A to B, and if you need a stop at C, D, E, F, G, H, and I to pick things up it&#39;s probably more efficient to split up and have parts of the group go to each destination.</description>
    </item>
    <item>
      <title>Momentum</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/01/08/</link>
      <pubDate>Fri, 08 Jan 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/01/08/</guid>
      <description>Every object persists in its state of rest or uniform motion in a straight line unless it is compelled to change that state by forces impressed on it--&amp;nbsp;Sir Isaac Newton&#xA;People have an enormous tendency to resist change. They love to say, &amp;lsquo;We&amp;rsquo;ve always done it this way.&amp;rsquo; I try to fight that.--&amp;nbsp;Grace Hopper&#xA;Inertia and momentum are real. Change is work. Sometimes hard work. Even when applied to non-physical things, like code.</description>
    </item>
    <item>
      <title>Big Bang Theory</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/01/07/</link>
      <pubDate>Thu, 07 Jan 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/01/07/</guid>
      <description>Big Bang TheoryIn the beginning was the command line (actually it was switches, buttons, and wire wrap). There was no &#34;software industry&#34; and everyone did everything themselves, or at least for in-house customers, and the pace of change was low. After all, that&#39;s how things were always done. In business, changes on the factory floor were expensive and there was lots of planning. Software was treated the same way.&#xA;As software became less bespoke we moved into the era of box products.</description>
    </item>
    <item>
      <title>Hindsight</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/01/06/</link>
      <pubDate>Wed, 06 Jan 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/01/06/</guid>
      <description>Things go wrong. We make mistakes. We don&#39;t always consider all the possibilities. New, different things can happen. The goal is to do better in the future. That&#39;s where Root Cause Analysis comes in. And hindsight is 20/20, right, so we&#39;re done, right?&#xA;First, as I talked about last year, there&#39;s a difference between the proximate cause and the root cause. We need to avoid the trap of thinking that the first time a person&amp;nbsp;could&amp;nbsp;have done something different to prevent the issue is the root cause.</description>
    </item>
    <item>
      <title>Naming Is Hard</title>
      <link>https://friendgineers.rosenshein.org/posts/2021/01/05/</link>
      <pubDate>Tue, 05 Jan 2021 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2021/01/05/</guid>
      <description>There are only two hard things in Computer Science: cache invalidation and naming things.-- Phil Karlton&#xA;We all know that. So what do you do? First, be consistent. A foolish consistency may be the hobgoblin of little minds, but this kind of consistency is not foolish.&#xA;Names, method or member, internal or external, form the basis of a&amp;nbsp;ubiquitous language. Language lets us communicate what&amp;rsquo;s inside our heads with others, and having a consistent language reduces cognitive load.</description>
    </item>
    <item>
      <title>Another Year In Review</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/12/31/</link>
      <pubDate>Thu, 31 Dec 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/12/31/</guid>
      <description>At least I hope the year ends tonight, but I&#39;ll have to check covidstandardtime.com&amp;nbsp;tomorrow to be sure. Going with the assumption that the year does end, some thoughts on the year that was.&#xA;It started like any other year. Lots of interesting challenges, what with shutting down one DC and turning up another. Lots of new tech to learn about and fit together. Then things changed. And they didn&#39;t change. Life went on.</description>
    </item>
    <item>
      <title>Unhappy Customers</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/12/30/</link>
      <pubDate>Wed, 30 Dec 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/12/30/</guid>
      <description>Back at the beginning of the year, in the before times, I wrote that APIs are for life, and that if you change something, even if you make it better, you&#39;re likely to have unhappy customers. And that&#39;s true even if what you&#39;ve changed isn&#39;t a public API.&#xA;One of the things we did with Combat Flight Simulator 3 (CFS3) was improve the graphics. We took advantage of newer hardware to increase resolution and fidelity.</description>
    </item>
    <item>
      <title>Java Isn&#39;t Dying</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/12/29/</link>
      <pubDate>Tue, 29 Dec 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/12/29/</guid>
      <description>Today&#39;s entry in the Betteridge file. Is Java Dying?&amp;nbsp;True to Betteridge&#39;s law, no. It&#39;s one of those perennial questions, and the answer has always been the same. It fills a need, and it&#39;s been deployed to production in countless places. And as COBOL reminded us yet again this year, if it&#39;s in production it will never die.&#xA;And if you look at the Java ecosystem, it&#39;s actually growing, JVM languages continue to grow and evolve.</description>
    </item>
    <item>
      <title>On Branching</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/12/28/</link>
      <pubDate>Mon, 28 Dec 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/12/28/</guid>
      <description>There are lots of different branching strategies. And they have their strengths and weaknesses. And there is no one right strategy. Don&#39;t let anyone kid you. There are however strategies that are wrong, especially ones that are wrong in a specific time and place.&#xA;Given that there is no consistent best strategy, how do you pick which strategy to use. The answer to that strategy is highly dependent on why you&#39;re making the branch.</description>
    </item>
    <item>
      <title>RCA</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/12/23/</link>
      <pubDate>Wed, 23 Dec 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/12/23/</guid>
      <description>RCA can be a lot of things. Most of the usage of RCA I&amp;rsquo;ve seen has something to do with the Radio Corporation of America&#xA;and all of the inventions and spin-offs from it. But more recently, RCA means root cause analysis. As in &amp;ldquo;Why did that really happen?&#xA;As in &amp;ldquo;Why did the program crash?&amp;rdquo; Easy. Like it says right there in the stack trace,&#xA;panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x4a52c6] goroutine 1 [running]: main.</description>
    </item>
    <item>
      <title>This Would Never Occur To Me</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/12/22/</link>
      <pubDate>Tue, 22 Dec 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/12/22/</guid>
      <description>I&#39;ve written code for Apple ][ hi-res graphics with it&#39;s odd interleaving and understood what I was doing. I&#39;ve done (a little) Fortran77 on a Cray-YMP. I&#39;ve done low level graphics, from 2D lines to 3D projections to mip-mapped textures on a CPU and bashed the results into a manually double-buffered framebuffer. I&#39;ve written shaders for procedural texture mapping and phong shading (don&#39;t remember much about it, but I know I did it).</description>
    </item>
    <item>
      <title>ISQ vs ESQ</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/12/21/</link>
      <pubDate>Mon, 21 Dec 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/12/21/</guid>
      <description>There&#39;s a couple of TLAs for you. But what do they mean, and what do you do with them? Let&#39;s start with some definitions. ISQ is Internal Software Quality and ESQ is External Software Quality.&#xA;External software quality is what your customers see. How easy/hard is it for them to do the things you promised them they could do with your software. Is it easy to use? Consistent? Reliable? Full of features?</description>
    </item>
    <item>
      <title>Long Live The CLI</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/12/18/</link>
      <pubDate>Fri, 18 Dec 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/12/18/</guid>
      <description>I&#39;ve talked about the&amp;nbsp;command line&amp;nbsp;before. How important it is, its history, and I&#39;ve made some recommendations. And it&#39;s still important.&#xA;My recommendations center mostly around&amp;nbsp;usability and predictability. Because if you build something and it&#39;s not usable what was the point? Predictable because while you have one or more use cases in mind,&amp;nbsp;the street finds its own uses for things&amp;nbsp;and you never know how someone else might want to use it. So let them</description>
    </item>
    <item>
      <title>Another &#39;Just No.&#39;</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/12/17/</link>
      <pubDate>Thu, 17 Dec 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/12/17/</guid>
      <description>Every year StackOverflow does a developer survey, and this year was no exception. Some of the questions they ask are about language, framework, library and platform usage. What gets used the most/least and what is liked the most/least. Like all surveys, some things make sense right away, some are of the &amp;quot;I wouldn&#39;t have thought that, but it makes sense&amp;quot;, and others are of the &amp;quot;Huh???&amp;quot; category. The one in the last category that always makes me go WAT is Rust.</description>
    </item>
    <item>
      <title>Real World Patterns</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/12/16/</link>
      <pubDate>Wed, 16 Dec 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/12/16/</guid>
      <description>You&#39;ve probably heard of the Gang Of Four&#39;s Design Patterns, and I&#39;ve talked about some of them already. There&#39;s some really good ideas in that book, and like all things architectural, using the right pattern at the right time makes things easier in the future. Get it wrong and not so much.&#xA;Probably the most common mistake I&#39;ve seen with those patterns is overapplication. People learn a pattern and then apply it everywhere.</description>
    </item>
    <item>
      <title>Don&#39;t Cross The Streams</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/12/15/</link>
      <pubDate>Tue, 15 Dec 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/12/15/</guid>
      <description>Domain driven design is all about bounded contexts. I like bounded contexts. They help you know what something is responsible for, and by extension, what it&#39;s not (that would be everything else). Having those boundaries (not crossing the streams) makes it easier to keep things straight and reduces cognitive load.&#xA;On the other hand, having all those different domains is&amp;nbsp;adding complexity, Especially if those domains are each different services with some kind of RPC interface.</description>
    </item>
    <item>
      <title>Experience</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/12/14/</link>
      <pubDate>Mon, 14 Dec 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/12/14/</guid>
      <description>Some say that experience is the best teacher. And baring learning styles, there&#39;s a lot of truth to that saying. And not just learning by doing. Learning from your mistakes. And even better than that, learning from other&#39;s mistakes. But the real key to experiential learning is not the doing of the thing, it&#39;s the reflection afterward. In school you might call it the lab report or case study, and at work we call them tech sharing or incident reports, but regardless of the name, the goal is to identify the parts that made a difference and why&amp;nbsp;so that they can be incorporated into our internal understanding of the world.</description>
    </item>
    <item>
      <title>Forward Looking</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/12/10/</link>
      <pubDate>Thu, 10 Dec 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/12/10/</guid>
      <description>Tis the season. The season for perf. But this one is a little different. First off, we&#39;ve been out of the office for ~9 months. Second, we haven&#39;t done this for a year. Third, the situation is more fluid&amp;nbsp;than usual. So yeah, if this feels weird, that&#39;s because it is.&#xA;That doesn&#39;t mean it&#39;s any less important though. In some ways it might be more important. Because perf season is not supposed to be a personal sales pitch aimed at maximizing&amp;nbsp;your total compensation.</description>
    </item>
    <item>
      <title>Gooooaaaallll</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/12/09/</link>
      <pubDate>Wed, 09 Dec 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/12/09/</guid>
      <description>We do sprints, which come from Scrum. And Scrum has artifacts. There are 3 official artifacts, the product backlog, the sprint backlog, and the &amp;quot;Potentially Releasable Product Increment&amp;quot;. That&#39;s it. The only 3 artifacts of Scrum. Not tasks. Not acceptance criteria. Not burndown charts. Not velocity.&#xA;However, there are lots of things that get created when you implement Scrum (or scrum-like development). Such as tasks. And boards of tasks. And Acceptance Criteria.</description>
    </item>
    <item>
      <title>Is 2020 Over Yet?</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/12/08/</link>
      <pubDate>Tue, 08 Dec 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/12/08/</guid>
      <description>As I&#39;ve noted before, I&#39;m a mechanical and aerospace engineer by training. I think a big part of why is what I grew up reading. Books about competent technical folks who just got things done. Books like Thunderbolt,&amp;nbsp;Flying Fortress, The Dam Busters, and The Right Stuff. Later it was Hackers, The Cuckoo&#39;s Egg, and Surely You&#39;re Joking, Mr. Feynman!&#xA;One of the common themes in those books was someone who saw something that needed to be done to meet a need, and then did it.</description>
    </item>
    <item>
      <title>Owning Your Code</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/12/07/</link>
      <pubDate>Mon, 07 Dec 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/12/07/</guid>
      <description>Code ownership. Good or Bad? It must be good because github has a CODEOWNERS file, and we have `METADATA.yaml`, right?&#xA;Like everything else, the answer is, it depends. In this case it depends on what you mean by code ownership. Because code ownership can mean different things to different people. In this case I&#39;m not talking about who owns the intellectual property. I&#39;m talking about the responsibility for code. Not just writing, but maintaining and extending it.</description>
    </item>
    <item>
      <title>List Comprehension</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/12/04/</link>
      <pubDate>Fri, 04 Dec 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/12/04/</guid>
      <description>The other day I was in a class on `bazel.` Lots of interesting stuff there, and I got a lot out of it. Concepts and &amp;quot;idiomatic&amp;quot; bazel. Because everything works better when you are working with a tool in the way the designers/implementers intended. But that&#39;s a topic for another time.&#xA;In the class the instructor pointed out a few websites that claimed to be &amp;quot;The best list of ...&amp;quot; or &amp;quot;A well curated list of &amp;hellip;&amp;quot; and said that in his experience, in those cases curated generally meant that it was the first N things a google search returned on the day the list was built.</description>
    </item>
    <item>
      <title>Outputs vs. Outcomes</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/12/03/</link>
      <pubDate>Thu, 03 Dec 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/12/03/</guid>
      <description>Right now we&#39;re in the middle of Q1 planning and&amp;nbsp;the 2020 perf review cycle. One forward looking, and one backward looking. One is team/org/company related and one is personal. So what do they have to do with each other, and more interestingly, how do they relate to &amp;quot;outputs vs. outcomes&amp;quot;?&#xA;First, they&#39;re temporally connected. perf always&amp;nbsp;follows planning. And a big part of this year&#39;s perf review is based on the planning from last year.</description>
    </item>
    <item>
      <title>Input Validation</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/12/02/</link>
      <pubDate>Wed, 02 Dec 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/12/02/</guid>
      <description>Little Bobby Tables might not be real, but SQL injection certainly is. And there are lots of ways to prevent it. And we should do all of them. From sanitizing inputs as soon as possible to using least privilege when making changes (why does the student management interface even have drop table&amp;nbsp;permission?).&#xA;But this isn&#39;t about what to do. This is about where&amp;nbsp;to do it. And I&#39;m going to assert that it&#39;s as soon as possible.</description>
    </item>
    <item>
      <title>Abstractions vs. Interfaces</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/12/01/</link>
      <pubDate>Tue, 01 Dec 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/12/01/</guid>
      <description>&amp;quot;Code against interfaces.&amp;quot; Generally speaking that&#39;s a good idea, but let&#39;s be clear about one thing. But there&#39;s a problem with that sentence. What does interface mean? There are a couple of options&#xA;It could be the dictionary definition of an interface, which is &amp;quot;a point where two systems, subjects, organizations, etc. meet and interact&amp;quot; or, in computer terms, the public API. It could be a class, a service, a website, or something else.</description>
    </item>
    <item>
      <title>Decisions, Decisions, Decisions</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/11/30/</link>
      <pubDate>Mon, 30 Nov 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/11/30/</guid>
      <description>Decisions are important. Who makes them. Why they&#39;re being made. When they get made. What the intended consequences are. What the unintended&amp;nbsp;consequences are. Those are all important things about decisions. And there&#39;s another important thing that I didn&#39;t mention. That&#39;s how&amp;nbsp;they&#39;re made.&#xA;Sometimes making a decision is complicated. Like choosing a U.S. President. First you have to jump through the hoops to get on the ballot. Then the eligible people vote in their states.</description>
    </item>
    <item>
      <title>Take Time</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/11/25/</link>
      <pubDate>Wed, 25 Nov 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/11/25/</guid>
      <description>One of the counterintuitive things about productivity is that you can be more productive overall by taking a break. And like everything else, this scales. Taking a short break during the day can clear out the cobwebs, let your mind process what&amp;rsquo;s floating around, and surface ideas that you were too busy to notice.&#xA;Similarly, holidays and vacations give you a slightly longer period to reset. There&#39;s more to life than work and, especially these days of WFH, having the time to not&amp;nbsp;work is critical.</description>
    </item>
    <item>
      <title>Error Types</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/11/24/</link>
      <pubDate>Tue, 24 Nov 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/11/24/</guid>
      <description>Statistics is all about the null hypothesis. You assume it&amp;rsquo;s true and try to prove if it is false. Consider a fire alarm. If it&amp;rsquo;s not ringing you assume there&amp;rsquo;s no fire. If it is ringing then the assumption is that there is a fire. The state of the alarm is a a simple binary. It&amp;rsquo;s either ringing or it&amp;rsquo;s not. And either there is a fire or there&amp;rsquo;s not. So you have the following truth table</description>
    </item>
    <item>
      <title>Implicit vs. Explicit</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/11/20/</link>
      <pubDate>Fri, 20 Nov 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/11/20/</guid>
      <description>&amp;quot;An implicit understanding is anything a skilled geek would have to be told before being set loose in your codebase to make a change. Implicit understandings take lots of different forms, but at their simplest, they often involve hidden correlations.&amp;quot;&#xA;&amp;nbsp; &amp;nbsp; --&amp;nbsp;@GeePawHill&#xA;Computers are very literal. They always do exactly&amp;nbsp;what you tell them to do. Even (especially?) when that&#39;s not what you want them to do. And yet we often write code that lets us do that.</description>
    </item>
    <item>
      <title>Just No</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/11/19/</link>
      <pubDate>Thu, 19 Nov 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/11/19/</guid>
      <description>Intern/work-study is a hard gig. You&#39;re dropped into a company, given a few days intro, a mentor and then expected to produce something in a few weeks/months. It can be stressful, and done right the intern learns/grows a lot. I think it&#39;s the reason that graduates from Waterloo often do so well.&#xA;Years ago I had a discussion with the director of the engineering placement office at a school I was visiting for campus interviews.</description>
    </item>
    <item>
      <title>Hofstadter’s Law</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/11/18/</link>
      <pubDate>Wed, 18 Nov 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/11/18/</guid>
      <description>It always takes longer than you expect, even when you take into account Hofstadter&amp;rsquo;s Law&#xA;&amp;nbsp; &amp;nbsp; &amp;nbsp;&amp;mdash; Hofstadter&amp;rsquo;s Law&#xA;Even if you&#39;ve never read Godel, Escher, and Bach: An Eternal Golden Braid&amp;nbsp;(GEB) you&#39;ve probably heard Hofstadter&#39;s Law. And like most of GEB, it&#39;s a recursive law. That doesn&#39;t make it any less relevant though. The real question though, is how can we acknowledge it and make plans while maintaining our internal honesty.</description>
    </item>
    <item>
      <title>Feedback Please</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/11/17/</link>
      <pubDate>Tue, 17 Nov 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/11/17/</guid>
      <description>Back in September I mentioned that O&#39;Reilly was doing an Architectural Kata competition and that I thought it would be fun to get together a team and enter the competition. Well, we did put together a team, and we our team, selfdriventeam&amp;nbsp;was selected as a semi-finalist. You can see our submission on the github. The final step is a live presentation to the judges on December 3rd.&#xA;My ask is for volunteers to provide feedback on our final presentation.</description>
    </item>
    <item>
      <title>Thinking Like An Engineer</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/11/16/</link>
      <pubDate>Mon, 16 Nov 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/11/16/</guid>
      <description>First, a link to something I posted about 7 months ago. It was relevant then, and it&#39;s still relevant now.&#xA;That said, there are lots of things that go into thinking like an engineer, but here are a few that I think are important.&#xA;Balancing constraints: Everything we do has some sort of constraints. They could be memory, bandwidth, execution time, development time, short vs long term gains, user value, or something else entirely.</description>
    </item>
    <item>
      <title>Ubiquitous Language</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/11/12/</link>
      <pubDate>Thu, 12 Nov 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/11/12/</guid>
      <description>I like bounded contexts. More generally, I like both bounds&amp;nbsp;and&amp;nbsp;contexts. Together they&#39;re really good at defining scope, both &amp;quot;in scope&amp;quot; and &amp;quot;out of scope&amp;quot;. Knowing what you&#39;re talking about goes a long way to reducing cognitive load. If it&#39;s in scope you think about it. If it&#39;s out then you don&#39;t need to worry about it.&#xA;But that&#39;s only part of the battle. Even when you know what&#39;s in scope and everyone is in agreement on the scope, you still need to use the same language to discuss things.</description>
    </item>
    <item>
      <title>Just One More Thing</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/11/10/</link>
      <pubDate>Tue, 10 Nov 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/11/10/</guid>
      <description>There are almost as many reasons to ask questions as there are questions to ask many of them fit into a few categories. This is by no means an exhaustive list, but some of the bigger ones are:&#xA;You&#39;re looking for context to help identify a problem You know what your problem is and you&#39;re looking for a solution You&#39;ve got a solution and you&#39;re looking for an implementation You know the answer and you&#39;re leading the witness (Columbo style) When you have the first kind of question you ask open ended questions, follow up questions, and why questions.</description>
    </item>
    <item>
      <title>A Little Architecture</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/11/09/</link>
      <pubDate>Mon, 09 Nov 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/11/09/</guid>
      <description>A couple of months ago I mentioned that O&#39;Reilly was holding an Architectural Kata competition. A few of us spent some time a couple of weeks ago putting together a response. It was a lot of fun and we all learned a lot about software architecture, what it is, and what it isn&#39;t. If you&#39;re interested in getting some architectural experience I think the idea of a Kata is a great place to start.</description>
    </item>
    <item>
      <title>GC At Scale</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/11/06/</link>
      <pubDate>Fri, 06 Nov 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/11/06/</guid>
      <description>Many of us have used garbage collected languages. Golang, Java, C#, or maybe experimenting with Rust. When we ran the HDFS cluster in WBU2 we routinely had heap sizes of 250+GB, and GC would sometimes reap 50+ GB and take seconds. That caused all sorts of runtime problems with our customers as the Namenode would go unresponsive and clients would time out. We solved that one by switching garbage collectors and tuning it better, as one does.</description>
    </item>
    <item>
      <title>Thesaurus In Use</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/11/05/</link>
      <pubDate>Thu, 05 Nov 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/11/05/</guid>
      <description>Software Architecture is bricks made up of the recursive application of sequence, selection, and iteration, emplaced within a superstructure of object oriented design, and plumbed with pipelines immutable data governed by functional programming. &amp;nbsp; &amp;nbsp; -- Uncle Bob Martin&#xA;There&#39;s a lot to unpack there. I think&amp;nbsp;there&#39;s a typo in there, but the two changes I&#39;ve come up with give the statement different meanings. And both are correct. So who knows.</description>
    </item>
    <item>
      <title>Inclusiveness</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/11/04/</link>
      <pubDate>Wed, 04 Nov 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/11/04/</guid>
      <description>We all deal with lots of hierarchies. There&#39;s your organization hierarchy. There&#39;s the class structure in code. There&#39;s the ownership hierarchy in code. There&#39;s the ownership hierarchy in uOwn. There&#39;s a hierarchy to resource budgets. It would be wonderful if the shape of these trees was all the same, but while they&#39;re similar, there are subtle differences to them. And those differences grow over time as priorities shift, roles and scopes change, and re-orgs occur.</description>
    </item>
    <item>
      <title>Time Passes</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/11/02/</link>
      <pubDate>Mon, 02 Nov 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/11/02/</guid>
      <description>I&#39;ve mentioned before that time is hard. From leap days/seconds to time zone definition changes to GPS time resetting to 0 every Sunday, it&#39;s just not that simple.&#xA;But it&#39;s even worse than that. Consider the truly functional languages, such as Haskell, Erlang, and OCaml. Functions don&#39;t have side effects, because they can&#39;t. Except&amp;hellip; One side effect you can&#39;t prevent, even in the most functional of languages, is the passage of time.</description>
    </item>
    <item>
      <title>Radar Time</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/10/28/</link>
      <pubDate>Wed, 28 Oct 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/10/28/</guid>
      <description>The new Thoughtworks radar is out. There are a handful of things that I&#39;m really interested in, and high on the list are Security Policy as Code and Run Cost as an Architectural Fitness Function (since we&#39;re cloud first). Also interesting are Data Meshes and Kustomize (which we are already using for a lot of our Spinnaker deployments). And of course there&#39;s the perennial Zero-Trust and Rust. What&#39;s on your radar?</description>
    </item>
    <item>
      <title>Commits vs. PRs</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/10/27/</link>
      <pubDate>Tue, 27 Oct 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/10/27/</guid>
      <description>For each desired change, make the change easy (warning: this may be hard), then make the easy change&#xA;&amp;nbsp; &amp;nbsp; -- Kent Beck&#xA;Pretty good rule of thumb. Similar to the Unix way, do one thing and do it well. Then pipe them together to reach the end goal. But what has that got to do with commits and pull requests?&#xA;This. For small, additive changes, a single commit (modulo bug fixes/typos) is often all you need to implement your change, so you have a 1:1 ratio between commits and pull requests.</description>
    </item>
    <item>
      <title>To Float Or Not To Float</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/10/26/</link>
      <pubDate>Mon, 26 Oct 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/10/26/</guid>
      <description>They say money makes the work go &#39;round. And these days computers are a big part of how the money moves. From accounting to checkbook management to online purchases, it&#39;s all about the Benjamins. Unfortunately, computers are really&amp;nbsp;bad with money.&#xA;Which is odd, because what computers are really good at is arithmetic. They can add, subtract, multiply, and, except for some Pentium 4s, divide. Pretty much everything else they do is just doing that really quickly in complex patterns.</description>
    </item>
    <item>
      <title>Your Personal Board</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/10/22/</link>
      <pubDate>Thu, 22 Oct 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/10/22/</guid>
      <description>Companies have a board of directors to provide oversight, guidance, and advice. They&#39;re generally not involved in the day to day operations of the company, and are composed of people with different experiences and backgrounds, often from other industries. They work to advance the company, but are not beholden to it. That&#39;s nice, but how is it relevant to a developer? It&#39;s relevant because the main role of a company&#39;s board is to help the company progress and grow.</description>
    </item>
    <item>
      <title>Stories vs. Tasks</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/10/21/</link>
      <pubDate>Wed, 21 Oct 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/10/21/</guid>
      <description>We Scrum. Or at least we Sprint. And our sprints come complete with Stories and Tasks. Just ask Jira. Stories and tasks are both important. Together, along with Epics and Initiatives, they make up our backlogs, both Sprint and Product.&#xA;Stories have phrases like &amp;quot;As &amp;lt;persona&amp;gt;&amp;quot;,&amp;nbsp; &amp;quot;I should be able to &amp;lt;X&amp;gt;&amp;quot;, and &amp;quot;so that I can &amp;lt;Y&amp;gt;&amp;quot;. They have Acceptance Criteria that describe what done looks like. They often (almost always) require work on multiple components.</description>
    </item>
    <item>
      <title>A Fiddler On The Roof</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/10/20/</link>
      <pubDate>Tue, 20 Oct 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/10/20/</guid>
      <description>Have you ever been on a high performing team? Not just a good team, with a good manager, where things mostly get done on time and people enjoy their work and team, but a truly high performing team? A team where you can&#39;t wait to start the day. Where problems seem to evaporate before your eyes and the team accomplishes more than anyone expected? The team has an outsized impact and other folks look at the team and want to join?</description>
    </item>
    <item>
      <title>Uncle Bob Says</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/10/19/</link>
      <pubDate>Mon, 19 Oct 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/10/19/</guid>
      <description>Though we may try, and try, there are times when we cannot find a way to make the code express our intent; and so we resort, in the end, to a comment.&amp;nbsp;&#xA;We acknowledge that each comment we write is finally due to our failure to express ourselves in code.&#xA;&amp;nbsp; &amp;nbsp; -- Uncle Bob Martin&#xA;I sort of&amp;nbsp;disagree. Not with the first part. We should always try to write code that clearly expresses our intent.</description>
    </item>
    <item>
      <title>Branch vs</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/10/16/</link>
      <pubDate>Fri, 16 Oct 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/10/16/</guid>
      <description>Maybe I&#39;m late to the party, but recently I learned about git worktrees. I&#39;m familiar with branches, and they&#39;re great. Great for isolation. Great for bug fixes. Great for incremental changes. But they&#39;re not so great when you have large structural changes.&#xA;Or at least they&#39;re not great with structural changes in the presence of compiled languages and caches (both bazel and your IDE at least). From a correctness standpoint they work.</description>
    </item>
    <item>
      <title>Easter Eggs</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/10/14/</link>
      <pubDate>Wed, 14 Oct 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/10/14/</guid>
      <description>Extra hidden code that does something fun. Seems like a good idea, and generally speaking I think they&#39;re a simple, mostly harmless&amp;nbsp;bit of entertainment. I&#39;ve enjoyed them. I&#39;ve built them. Falcon 4&#39;s shared memory output started out as a development tool then became an easter egg, and eventually a feature. They&#39;re an old tradition. The first one I ran into was the &amp;quot;Identify 9&amp;quot; easter egg in the old Wizardry series.</description>
    </item>
    <item>
      <title>Silos vs. Ownership</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/10/13/</link>
      <pubDate>Tue, 13 Oct 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/10/13/</guid>
      <description>What&#39;s better, a very narrow, well defined scope or ownership of a problem? The answer to that, like so many comparative questions, is it depends. But first, what do those terms mean?&#xA;The term silo goes way back to when agriculture shifted from just in time/sustenance farming to commercial farming. It was a place to store all of a certain thing, and a place for everyone else to get it from.</description>
    </item>
    <item>
      <title>Agile, 3X, And 4X</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/10/12/</link>
      <pubDate>Mon, 12 Oct 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/10/12/</guid>
      <description>Almost 20 years ago a bunch of folks, including Kent Beck released the Agile Manifesto. Waterfall planning stopped being the right way to do things. It took a while, but it, and the internet, changed the way a lot of software is developed. Agile, Scrum, Extreme, and Mob programming are all based on the precepts in the manifesto.&#xA;15 years later, Kent had a thought What if those waterfall folks aren&amp;rsquo;t wrong, what if they are solving a different problem than I&amp;rsquo;m solving?</description>
    </item>
    <item>
      <title>Context</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/12/11/</link>
      <pubDate>Sun, 11 Oct 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/12/11/</guid>
      <description>Words have meanings. We have whole books that do nothing but list words and their meanings. Of course they use other words to define words, so it&amp;rsquo;s slightly circular, but somehow we&amp;rsquo;ve managed to make things work.&#xA;Now some of those words can have multiple meanings. Sometimes it&amp;rsquo;s the same spelling but different pronunciation, like lead, You can have lead the element as a noun, or lead the verb as in &amp;ldquo;The captain will lead us to victory&amp;rdquo;.</description>
    </item>
    <item>
      <title>Now You Have Two Problems</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/10/09/</link>
      <pubDate>Fri, 09 Oct 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/10/09/</guid>
      <description>Some people, when confronted with a problem, think &amp;quot;I know, I&#39;ll use regular expressions.&amp;quot; Now they have two problems. -- Jamie Zawinski&#xA;Of course that&#39;s not strictly true. Even if you&#39;re not writing Perl you probably use a regex or two every day. After all,&amp;nbsp;grep&amp;nbsp;and&amp;nbsp;ag&amp;nbsp;(the silver searcher) take your input as a regex and use it to scan your file system.&#xA;And used correctly a regex is great for detecting and potentially extracting/transforming bits of a string.</description>
    </item>
    <item>
      <title>Pass By Value</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/10/08/</link>
      <pubDate>Thu, 08 Oct 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/10/08/</guid>
      <description>Golang is pass by value. There is no pass by reference. It will&amp;nbsp;allocate a new variable to hold every parameter passed to a function. Golang does however have pointers. And you can pass pointers to a function. In practice it works pretty much the same as pass by reference&amp;nbsp;in C++. Inside the called function you have a pointer to a value declared/existing outside the scope of the function and can modify it.</description>
    </item>
    <item>
      <title>It&#39;s All Around Scope</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/10/07/</link>
      <pubDate>Wed, 07 Oct 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/10/07/</guid>
      <description>We&#39;ve all heard about different architectural patterns, from layered monoliths to microservices. And they all have their place. The thing that gets me is that many people look at enterprise architecture&amp;nbsp;and think it&#39;s fundamentally different than other types of software architecture.&#xA;It&#39;s not exactly the same, but then, no two architectures are the same. If they were you&#39;d end up with the same results, maybe&amp;nbsp;with a different color scheme. Kind of like the way you can use different themes and make a presentation different.</description>
    </item>
    <item>
      <title>Git Bisect and Fruit</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/10/06/</link>
      <pubDate>Tue, 06 Oct 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/10/06/</guid>
      <description>What do source code management and splitting things in half have in common? git bisect. Remember the murder mystery @andrew.gemmel wrote about? That was the story about how a simple change to a unit test ended up periodically killing the ssh-agent. What he didn&#39;t talk about was how we narrowed things down to that commit so we could find the problem.&#xA;To do that we used git bisect. If you&#39;re ever trying to figure out exactly which commit changed the behavior of your repo from A&amp;nbsp;to B then git bisect&amp;nbsp;is your friend.</description>
    </item>
    <item>
      <title>Interviewing Up</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/10/05/</link>
      <pubDate>Mon, 05 Oct 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/10/05/</guid>
      <description>You&#39;ve probably heard the term managing up, and you&#39;ve probably even done it, but have you ever been interviewing up? When I started at Microsoft hiring me was my boss&#39;s last checkbox before he moved on to bigger and better things. So, about 2 weeks after I got through New Employee Orientation and it was clear that I wasn&#39;t going to be thrown out, my boss put in his two week notice.</description>
    </item>
    <item>
      <title>Not Even Wrong</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/10/02/</link>
      <pubDate>Fri, 02 Oct 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/10/02/</guid>
      <description>Sometimes I run across articles that make me want to reach through the screen, find the author, and say &amp;quot;Stop it. You missed the point entirely and you&#39;re just making things worse.&amp;quot; The article The essential difference between microservices and APIs is one of those cases.&#xA;To use an analogy, consider an article titled The essential difference between Ethernet and communication theory. And then you read the article and it talks about how Ethernet is better than the old networks because you can get better overall throughput if you have relatively sparse transmitters.</description>
    </item>
    <item>
      <title>Happy Birthday</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/10/01/</link>
      <pubDate>Thu, 01 Oct 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/10/01/</guid>
      <description>Way back in the depths of time (fall of 1988) I was a new grad working for a 3rd tier aerospace company called Eidetics and I got the task of connecting an Apollo DN10000 to an SGI 70GTX to create my first flight simulator. It turned out that we had a cockpit mockup that was used for instrumentation development and a batch simulation system that was running faster than real-time since the latest CPU upgrade.</description>
    </item>
    <item>
      <title>OKRs and KPIs</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/09/30/</link>
      <pubDate>Wed, 30 Sep 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/09/30/</guid>
      <description>Here we are in the middle of planning and people are talking about OKRs and KPIs, but what&#39;s the difference between them and when should you use one over the other?&#xA;Starting from the definition, OKRs are Objectives and Key Results, while KPIs&amp;nbsp;are Key Performance Indicators. Sounds similar, no? Key Results and a Performance Indicators sure sound like the same thing. And your KPIs might be some of your Key Results, but they&#39;re absolutely not Objectives</description>
    </item>
    <item>
      <title>OOP Isn&#39;t Dead</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/09/24/</link>
      <pubDate>Thu, 24 Sep 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/09/24/</guid>
      <description>I&#39;ve been hearing that object oriented programming is dead for a while now. Like 15 years or so. But I don&#39;t believe it. I don&#39;t believe it for a bunch of reasons, but the simplest are that it&#39;s still around, and it&#39;s still useful.&#xA;That&#39;s not to say that there aren&#39;t problems. There are problems with everything. With OOP the problems can get pretty tangled and it can be almost impossible to sort them out without refactoring everything.</description>
    </item>
    <item>
      <title>What is Scrum?</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/09/22/</link>
      <pubDate>Tue, 22 Sep 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/09/22/</guid>
      <description>Do you do Scrum? Do you have an official ScrumMaster who isn&#39;t your EM/PM? Do you rotate the job of Scrum Master? And what&#39;s the job of your Scrum Master anyway? According to the official scrum guide,&#xA;The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.&#xA;The Scrum Master is a servant-leader for the Scrum Team.</description>
    </item>
    <item>
      <title>How Big Is That File Anyway?</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/09/21/</link>
      <pubDate>Mon, 21 Sep 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/09/21/</guid>
      <description>There are lots of hard problems in computing, but you wouldn&#39;t think counting bytes is one of them. Counting bytes is easy, right? If you want to know how big a file is just count the number of bytes in it.&#xA;Or maybe not. It depends on what you&#39;re counting and what you&#39;re going to do with the number. If you want to know how many bytes of RAM it will take to hold the data in a file (assuming it&#39;s just a blob of data) then that might be correct.</description>
    </item>
    <item>
      <title>Excuses, Excuses</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/09/18/</link>
      <pubDate>Fri, 18 Sep 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/09/18/</guid>
      <description>Sometimes it&#39;s so tempting to not test your changes. You&#39;re in a rush, it&#39;s just&amp;nbsp;a config change, it&#39;s a small change, or maybe you know it has no side effects. And if it&#39;s late on Friday or you&#39;re about to go on vacation and who has time? What could possibly go wrong?&#xA;Everything, that&#39;s what. If you&#39;ve been around for a while you might remember the entire SJC datacenter going dark over a 20 minute period.</description>
    </item>
    <item>
      <title>Code Golf</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/09/17/</link>
      <pubDate>Thu, 17 Sep 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/09/17/</guid>
      <description>Code golf is fun and all, and sometimes it can be fun to see just how terse you can write something and still have it work but it&#39;s a good idea to&#xA;Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. Code for readability.&#xA;The comma operator in C/C++ is a great example. You can save a handful of keystrokes, but it&#39;s almost never a good idea.</description>
    </item>
    <item>
      <title>Kata Time</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/09/16/</link>
      <pubDate>Wed, 16 Sep 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/09/16/</guid>
      <description>Who wants to put together a team and enter O&#39;Reilly&#39;s Architectural Kata competition? If you&#39;re not familiar with the idea of architectural katas check out the links below. Basically it&#39;s a way to respond to these questions.&#xA;How do we get great designers? Great designers design, of course.&#xA;&amp;nbsp; &amp;nbsp; -- Fred Brooks&#xA;So how are we supposed to get great architects, if they only get the chance&amp;nbsp; to architect fewer than a half-dozen times in their career?</description>
    </item>
    <item>
      <title>Visualizing Code</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/09/15/</link>
      <pubDate>Tue, 15 Sep 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/09/15/</guid>
      <description>Code is complex. Understanding complex code is either complex squared or complex to the power of complex, and I lean towards the latter. So what&#39;s a developer to do? I&#39;ve thought about this on and off for a while now, and one of the best descriptions of how I &amp;quot;see&amp;quot; big projects is described in this blog post.&#xA;Using those metaphors, I&#39;m definitely a mapper, with some packer&amp;nbsp;thrown in for the little nuggets of things that don&#39;t fit onto.</description>
    </item>
    <item>
      <title>Multiple Oopsies</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/09/14/</link>
      <pubDate>Mon, 14 Sep 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/09/14/</guid>
      <description>Sometimes things go wrong. If they go wrong in unrecoverable ways it can be good stop immediately and let someone know. In Go that&#39;s typically handled by returning an Error from your function. Straightforward enough.&#xA;Sometimes tough, multiple things go wrong, but the actions you&#39;re taking are independent enough that it makes sense to keep going. What do you do then? You could keep a list and do some formatting magic or, you could use Uber&#39;s shared multierr.</description>
    </item>
    <item>
      <title>Hiring</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/09/11/</link>
      <pubDate>Fri, 11 Sep 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/09/11/</guid>
      <description>Part of the return to normalcy, whatever that means in 2020, is a return to hiring. Open positions are starting to show up, recruiting is ramping up, and interview requests are starting to show up in our calendars. Making good hires is one of the most important things we can do for the long-term health and success of our teams and the overall organization. Not&amp;nbsp;making bad hires is even more important.</description>
    </item>
    <item>
      <title>Flexibility</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/09/10/</link>
      <pubDate>Thu, 10 Sep 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/09/10/</guid>
      <description>The first two principles of the agile manifesto are&#xA;Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.&#xA;Welcome changing requirements, even late in development. Agile processes harness change for the customer&#39;s competitive advantage.&#xA;Or, in other words, you need to be flexible and adapt to changes in the world around you. And, as it also states,&amp;nbsp;&#xA;Continuous attention to technical excellence and good design enhances agility.</description>
    </item>
    <item>
      <title>What Would You Say... Ya Do Here?</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/09/09/</link>
      <pubDate>Wed, 09 Sep 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/09/09/</guid>
      <description>Unless you work at Initech, chances are you&#39;re not got to be asked that question. You&#39;ve probably got a Jira ticket or two assigned to you that you&#39;re working on and periodically you close one. Sometimes that involves landing a PR, and sometimes it&#39;s releasing a document. That&#39;s what you do, right?&#xA;But is that really&amp;nbsp;all you&#39;re doing? Probably not, and it&#39;s important to make all the work you&#39;re doing visible, not just the work assigned to you.</description>
    </item>
    <item>
      <title>Github And VSCode</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/09/02/</link>
      <pubDate>Wed, 02 Sep 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/09/02/</guid>
      <description>I keep finding more things to like about VSCode. There&#39;s LiveShare, which I talked about a few months ago for pair programming/demos/help debugging. There&#39;s integration with remote containers, which lets you develop remotely almost like you&#39;re there. And one thing I recently started using, the GitHub Pull Requests and Issues&amp;nbsp;plugin. With the GitHub plugin you can do your PR reviews right in VSCode. There are lots of benefits. It starts with not having to go open some other app/website.</description>
    </item>
    <item>
      <title>To Rewrite Or To Not Rewrite</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/09/01/</link>
      <pubDate>Tue, 01 Sep 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/09/01/</guid>
      <description>That is the question, and like so many other questions, the answer is, it depends.&#xA;Presented here for your perusal, 6 different stories with 6 different initial conditions, 6 approaches, and 6 different results.&#xA;I&#39;ve been through a few of these cycles myself, and I&#39;ve seen most of the different results. It&#39;s often easy to see what was going to happen in hindsight, but looking forward it&#39;s not so easy. And sometimes doing exactly what you planned and having it work the way you expect just isn&#39;t enough.</description>
    </item>
    <item>
      <title>Semantics</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/08/31/</link>
      <pubDate>Mon, 31 Aug 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/08/31/</guid>
      <description>Debugging customer problems can be a challenge, especially over zoom or email where you can&#39;t see the exact input/output. To make it easier I have a set of questions I usually ask at the beginning. One of them is &amp;quot;What version are you running?&amp;quot; That&#39;s really important info since there can be many versions out in the field.&#xA;For the infra CLI it&#39;s pretty easy to get the version. Just run infra version&amp;nbsp;and it will tell you.</description>
    </item>
    <item>
      <title>Rockall</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/08/28/</link>
      <pubDate>Fri, 28 Aug 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/08/28/</guid>
      <description>Back in my early Microsoft days on the FlightSim team we were always looking for better perf. If nothing else we needed to give as much time to the rendered as possible because our customers always wanted to run the graphics with everything set to 11. And since this was somewhere between C and C++ (home made cross module vtable and dynamic linking, but that&#39;s another story) memory management was a thing.</description>
    </item>
    <item>
      <title>In Defense Of Agile</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/08/26/</link>
      <pubDate>Wed, 26 Aug 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/08/26/</guid>
      <description>And just to be clear, it&#39;s not that I think everything was better 30 years ago and all you kids these days should get off my lawn. Like everything else, there are cycles and sometimes things swing too far, or more often, people pick up the terminology / trappings of a new idea and then ignore the details.&#xA;Agile can be like that. Pair/mob programming. Just in time design. Customer feedback.</description>
    </item>
    <item>
      <title>Pick 2</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/08/25/</link>
      <pubDate>Tue, 25 Aug 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/08/25/</guid>
      <description>We&#39;ve all heard that when it comes to quality, scope, and the time you can only optimize 2 of them at a time. And for any given, localized, immediate decision that might be true. But what if I told you that over the long term you&#39;re better off with all three?&#xA;Following up on yesterday&#39;s topic, another one of my issues with two week sprints is the emphasis it places on time and showing value quickly.</description>
    </item>
    <item>
      <title>Cycles</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/08/24/</link>
      <pubDate>Mon, 24 Aug 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/08/24/</guid>
      <description>There&#39;s a lot of value in short sprints and frequent planning cycles. At any given time there&#39;s so much we don&#39;t know about the future needs and requirements of whatever piece of software we&#39;re working on that to write a detailed 6 month plan, let alone a 2 year plan, doesn&#39;t make a lot of sense. Moving away from waterfall development has codified that reality and helped to normalize the level of effort across the development cycle.</description>
    </item>
    <item>
      <title>Circle Of Life</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/08/21/</link>
      <pubDate>Fri, 21 Aug 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/08/21/</guid>
      <description>Did you know that Microsoft released a 3D world map with the ability to look at any part of the globe from any angle? Roads were mostly accurate, as were rivers, lakes, and islands. There were thousands of highly detailed 3D models of significant buildings and landmarks, and over 20K highly detailed areas. Of course, since it was Flight Simulator 2000&amp;nbsp; those 20K areas were airports and your house almost certainly wasn&#39;t one of them.</description>
    </item>
    <item>
      <title>Linkapolooza</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/08/20/</link>
      <pubDate>Thu, 20 Aug 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/08/20/</guid>
      <description>I use StackOverflow as much as anyone when I am looking for the answer to a specific question/problem, but when I&#39;m looking for a deeper description of a topic or approach there are usually better places to go. And sometimes I&#39;m just looking to see how other folks do things and why. Not just to solve today&#39;s problem, but to add tools to my toolbox. You can never have too many tools, you just need to know when to use them.</description>
    </item>
    <item>
      <title>No-Code</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/08/19/</link>
      <pubDate>Wed, 19 Aug 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/08/19/</guid>
      <description>Lately I&#39;ve been reading a lot about no-code platforms and the &amp;quot;end of programming&amp;quot;, but I don&#39;t buy it. Not just because I&#39;m a software engineer and want to keep my job, but because it&#39;s just another bubble. We&#39;ve seen this happen before, in all sorts of fields.&#xA;First, as I wrote last year, no-code is just another domain specific language (DSL), albeit a visual one. And done well they&#39;re incredibly useful.</description>
    </item>
    <item>
      <title>SESE</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/08/18/</link>
      <pubDate>Tue, 18 Aug 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/08/18/</guid>
      <description>Single Entry, Single Exit. Is it a Draconian or outdated rule? I&#39;d argue that tools and languages have changed enough that for what most people do, it&#39;s more of a guideline that should be part of separation&amp;nbsp;of concerns.&#xA;When Dijkstra first wrote his paper on structured programming things were different. In assembly GOTO&amp;nbsp;was one of your only branching mechanisms and you could go anywhere. Jump into the middle of a routine.</description>
    </item>
    <item>
      <title>Dependency Injection - NOT</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/08/17/</link>
      <pubDate>Mon, 17 Aug 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/08/17/</guid>
      <description>I first heard the term dependency injection (DI) a couple of years ago when some folks were talking about UberFX and how DI was the hot new thing and would save us all. And I was very skeptical, because why would I want someone injecting random code into my process? Code injection is an attack vector, not a design principle. Why would anyone build a system around that?&#xA;But the thing is, Dependency Injection isn&#39;t actually injection.</description>
    </item>
    <item>
      <title>Ideas In The Shower</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/08/14/</link>
      <pubDate>Fri, 14 Aug 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/08/14/</guid>
      <description>I don&#39;t know about you, but I&#39;ve solved a bunch of problems in the shower. It&#39;s the perfect combination of no distractions, some manual activity, and no immediate cognitive tasks. It gives the brain a chance to wander, sift, and make connections.&#xA;Sometimes you need to step away from the problem you&#39;re trying to solve and not&amp;nbsp;think about it so hard. Step away from the pressure of a blinking cursor or a blank whiteboard demanding to be filled.</description>
    </item>
    <item>
      <title>XY Problem</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/08/13/</link>
      <pubDate>Thu, 13 Aug 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/08/13/</guid>
      <description>Every now and then a question/request will come up on Slack or in a conversation that seems odd, but in an attempt to be helpful I&#39;ll answer it and a follow-up question or two. And then the next question breaks my mental model of the situation and I do an internal double-take. In those situations my response is usually something along the lines of Wait, what is it you&#39;re really trying to do?</description>
    </item>
    <item>
      <title>Good Design</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/08/12/</link>
      <pubDate>Wed, 12 Aug 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/08/12/</guid>
      <description>As I mentioned a few weeks ago, I run a 3 monitor setup. And two of those monitors have speakers. The big Apple&#xA;monitor has the best sound, so when I&#39;m docked and no-one is around I use that for background music. When I&#39;m not at&#xA;my desk the system switches to the built-in speakers on my Mac. If I&#39;m at my desk an in a meeting or there are folks</description>
    </item>
    <item>
      <title>What I&#39;m NOT Doing</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/08/11/</link>
      <pubDate>Tue, 11 Aug 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/08/11/</guid>
      <description>You know what&#39;s just as important as what you&#39;re working on but almost never gets talked about? What you&#39;re not doing and why you&#39;re not doing it. And that&#39;s a problem. There are a bunch of reasons why describing what you&#39;re not doing is just as important as describing what you are.&#xA;First on that list is that it helps you decide if a task fits or not. Let&#39;s say you&#39;re working on a function that takes in an image and calculates a histogram.</description>
    </item>
    <item>
      <title>Planting A Tree</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/08/10/</link>
      <pubDate>Mon, 10 Aug 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/08/10/</guid>
      <description>In some ways refactoring code like planting a tree. Not just the growing, branching, and pruning aspects (although that&#39;s something to talk about at another time), but also, like the old proverb about the best time to plant a tree being 20 years ago, the best time to refactor your code was back during the design phase. If you had made the change then you wouldn&#39;t be in the mess you&#39;re in now, and you&#39;d be able to add all those new features with minimal friction.</description>
    </item>
    <item>
      <title>Situational Awareness</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/08/06/</link>
      <pubDate>Thu, 06 Aug 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/08/06/</guid>
      <description>We all have biases. Some we know about, and some we don&#39;t. One of the benefits of being data driven is that, if you pick your metrics correctly, you can avoid those unconscious biases.&#xA;Going back to my aviation roots, that&#39;s why one of the leading causes of aircraft accidents is controlled flight into terrain. Basically it&#39;s the pilot not knowing there&#39;s a problem until it&#39;s too late to do anything about it.</description>
    </item>
    <item>
      <title>Careers</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/08/03/</link>
      <pubDate>Mon, 03 Aug 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/08/03/</guid>
      <description>Last week at the Core Platform All-Hands meeting I did a short presentation on Owning Your Career, but I was having some internet issues and there were some dropouts so I figured I&#39;d take some space here to spread the info a little wider and make sure I got all my points out. As a refresher, I started with a review of what a level&amp;nbsp;is and that it&#39;s really a reflection of your scope of influence.</description>
    </item>
    <item>
      <title>DDD and Microservices</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/07/28/</link>
      <pubDate>Tue, 28 Jul 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/07/28/</guid>
      <description>Last week there was a post on Uber&#39;s engineering blog about domain oriented microservice architecture. The first thing that stands out to me is that Jaeger graph of everything talking to everything. When I started at Uber 5 years ago there were more services than engineers in the graph. While microservices, reducing span of control and isolation, are good things, like anything else, you can take them too far. As the article notes, having to wade through 50 services and 12 teams to debug a single issue with a rider pickup is a bit much.</description>
    </item>
    <item>
      <title>Kicking It Off</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/07/27/</link>
      <pubDate>Mon, 27 Jul 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/07/27/</guid>
      <description>Inertia is a thing. Not just for spherical chickens on a frictionless surface in a vacuum or 3 ton robots. It&amp;rsquo;s also a thing in organizations. And one of the places you&amp;rsquo;ll see this the most is when starting a new project that requires multiple groups to change direction. Some groups don&amp;rsquo;t think it applies and make no changes, some over-rotate, and the rest end up somewhere in between.&#xA;But there are ways to provide guardrails and help people stay on track.</description>
    </item>
    <item>
      <title>C Shell, Z Shell ...</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/07/24/</link>
      <pubDate>Fri, 24 Jul 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/07/24/</guid>
      <description>I&#39;m in a quandary. MacOS has been on Bash 3.2.X for a long time, while Ubuntu is on 4.4.X. And instead of upgrading Bash, the folks at Apple have decided to switch the default shell to `zsh`. And to make matters worse, they&#39;ve made it very hard to upgrade bash and have the default version be something else.&#xA;So what&#39;s a developer to do? And I can hear a bunch of you saying &amp;quot;Get an Ubuntu machine&amp;quot;.</description>
    </item>
    <item>
      <title>Ownership</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/07/23/</link>
      <pubDate>Thu, 23 Jul 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/07/23/</guid>
      <description>In software development, as in many professions, way up near the top of the importance list is getting things done. That&#39;s why defining the problem you&#39;re solving is so important. How do you know if you&#39;re done if you don&#39;t know what problem you&#39;re solving.&#xA;And knowing who&#39;s responsible for getting things done is just as important as knowing what done is. This is more than having a task list with names attached to each item, although that&#39;s critical too.</description>
    </item>
    <item>
      <title>Hello. Who Are You?</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/07/22/</link>
      <pubDate>Wed, 22 Jul 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/07/22/</guid>
      <description>There are lots of times in logging and observability that you write a nice standard function to handle the boilerplate part(s), making it easier to focus on what you want to say/observe. And that&#39;s a good thing. Being able to focus on what you want to say and not worry about the details of getting the message out reduces cognitive load and increases the likelihood that things will be said.</description>
    </item>
    <item>
      <title>A Scrolling We Will Go</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/07/21/</link>
      <pubDate>Tue, 21 Jul 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/07/21/</guid>
      <description>Many of our datasets are big. Thousands or millions of rows. That&#39;s fine. We can search them, we can order them, we can get a subset. And getting a subset is good because UIs like small datasets so they can be responsive. Quick scrolling. Short data query times. And that leads to pagination, so users can scroll through the data without ever having to have the entire set available.&#xA;The simplest way to paginate is to use the equivalent of SQL&#39;s OFFSET and LIMIT.</description>
    </item>
    <item>
      <title>Data, Information, Knowledge, And Wisdom</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/07/20/</link>
      <pubDate>Mon, 20 Jul 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/07/20/</guid>
      <description>We like to say we&#39;re a data driven company and we have a data driven culture, and that&#39;s good. But what does it mean? Ideally,&amp;nbsp; being data driven means using current and past information to make knowledgeable decisions and plans to encourage a desired future outcome.&#xA;There&#39;s a lot to unpack there, so let&#39;s just dive into 3 of those words, data, information, and knowledge.&#xA;The first thing to realize is that while on the surface they&#39;re similar, they are not the same thing.</description>
    </item>
    <item>
      <title>Don&#39;t Always Minimize WIP</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/07/17/</link>
      <pubDate>Fri, 17 Jul 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/07/17/</guid>
      <description>One of the questions I often ask during interviews is some variation of &amp;quot;If you take this job, what will your current (or last if appropriate) manager not miss about you?&amp;quot; Once we get past them realizing I&#39;m looking for something their manager doesn&#39;t like and that this is partly about self-awareness and honesty they often ask for an example. So what I tell them is that my manager is a big proponent of minimizing WIP, and I&#39;m usually working on multiple projects at once.</description>
    </item>
    <item>
      <title>NO</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/07/16/</link>
      <pubDate>Thu, 16 Jul 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/07/16/</guid>
      <description>As important as what we do as developers is, what we don&#39;t&amp;nbsp;do is equally important. There are a fixed amount of seconds in the day, and you can&#39;t spend them on two things at once. The corollary of that is that you need to guard your time.&#xA;I&#39;ve talked about the fact that a backlog should be an ordered list of work, and how to use Priority and Severity to help you order it, so no need to rehash that.</description>
    </item>
    <item>
      <title>Natural Science</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/07/15/</link>
      <pubDate>Wed, 15 Jul 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/07/15/</guid>
      <description>Wheels within wheels&#xA;In a spiral array&#xA;A pattern so grand and complex&#xA;Time after time&#xA;We lose sight of the way&#xA;Our causes can&#39;t see their effects&#xA;&amp;nbsp; &amp;nbsp; -- Neil Peart&#xA;Software development is about patterns. Design patterns, data patterns, and execution patterns. Flow graphs, timing graphs, and relationship graphs. Project structure, team structure, and organizational patterns. All fitting together to make an even bigger pattern&#xA;We&#39;ve all heard about the GOFs design patterns.</description>
    </item>
    <item>
      <title>Tag, You&#39;re It</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/07/14/</link>
      <pubDate>Tue, 14 Jul 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/07/14/</guid>
      <description>Docker and immutability have an interesting&amp;nbsp;relationship. Docker images&amp;nbsp;are immutable. They even have a SHA, and when you pull an image with its associated SHA you always get the same one. Docker tags, on the other hand. are associations between a string (the tag) and an &amp;lt;repository&amp;gt;:&amp;lt;sha&amp;gt; pair. And that association is&amp;nbsp;mutable. Or at least it&#39;s mutable according to the spec. That means that you could pull an image today, maybe docker pull debian:stretch-20200607&amp;nbsp;and get an image with a SHA256 of 554173b67d0976d38093a073f73c848dfc667d3b1b40b6df4adf4110f8a3e4ce.</description>
    </item>
    <item>
      <title>Branching</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/07/13/</link>
      <pubDate>Mon, 13 Jul 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/07/13/</guid>
      <description>I&#39;ve mentioned Martin Fowler before, and he recently finished his series on branching. While there&#39;s way too much info to share here, it can be summarized with this quote, so I&#39;ll just send you all over to his page to read about it there.&#xA;I start with: &amp;quot;what if there was no branching&amp;quot;. Everybody would be editing the live code, half-baked changes would bork the system, people would be stepping all over each other.</description>
    </item>
    <item>
      <title>Why Are We Doing This</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/07/10/</link>
      <pubDate>Fri, 10 Jul 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/07/10/</guid>
      <description>ERDs, PRDs, RFCs. Regardless of what you call it, a lot of what these documents do is define what you&#39;re doing. Often in excruciating detail. And that detail can be important, for lots of reasons.&#xA;First, it forces you to think through what you intend to do. It forces you to think of corner cases and happy paths, and ways things can go wrong. It forces you to understand what you&#39;re doing well enough to describe it to others.</description>
    </item>
    <item>
      <title>Unintended Consequences</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/07/09/</link>
      <pubDate>Thu, 09 Jul 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/07/09/</guid>
      <description>Remember when Slack went down a couple of months ago? That probably got your attention. And appropriately, it got the attention of everyone at Slack too. It turns out that the big outage was a delayed consequence of an earlier outage, and exacerbated by &amp;quot;what you know that just ain&#39;t so&amp;quot;.&#xA;There&#39;s a bunch of good lessons in here, but two of the biggest are that monitoring is important, but you need to make sure that it really is monitoring what you think, and small bugs in one place can manifest themselves in completely different areas weeks/months later.</description>
    </item>
    <item>
      <title>Target Fixation</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/07/08/</link>
      <pubDate>Wed, 08 Jul 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/07/08/</guid>
      <description>I spent way too much time with fighter pilots early in my career and learned a lot about how they think. Yes, they&#39;re typically confident (arrogant actually) and maybe a little boastful, but they&#39;re also very disciplined, particularly when it comes to their craft. And one of the ways that manifests is their ability to focus on a target while maintaining enough situational awareness to respond to changes in the situation.</description>
    </item>
    <item>
      <title>Multi-Mon</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/07/07/</link>
      <pubDate>Tue, 07 Jul 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/07/07/</guid>
      <description>I&#39;ve been dealing with multi-monitor issues for 30+ years now. Back when I was working on flight simulators in the aerospace industry we needed multiple monitors because aircraft had multiple monitors and a HUD, and we needed to drive them all from a single computer. For that, we cheated. We had analog monitors, and by simply ORing into the framebuffer with separate red (left multi-function display), green (right multi-function display), and blue (HUD) images we could drive three monochrome displays.</description>
    </item>
    <item>
      <title>Inconsistent Consistencies</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/07/06/</link>
      <pubDate>Mon, 06 Jul 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/07/06/</guid>
      <description>ACID is Atomic, Consistent, Isolated, and Durable. CAP is Consistent, Available, and Partition Tolerant. According to the definition, both ACID and CAP have consistency. But English is a slippery language, and often, as in this case, the context of a word is important. ACID and CAP use consistency very differently.&#xA;ACID consistency means that if a transaction completes then it has fully completed and that *all* of the rules in place for the dB are met.</description>
    </item>
    <item>
      <title>Chaos</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/07/02/</link>
      <pubDate>Thu, 02 Jul 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/07/02/</guid>
      <description>Distributed systems are hard. And they&#39;re hard in lots of ways. One of them is emergent behaviour, or the idea that simple rule changes can have big impacts. Sometimes good, sometimes bad, but often surprising.&#xA;Consider the simple Nginx load balancer. Let&#39;s say you&#39;ve got 5 stateless backends behind a single address. By default Nginx does round-robin load balancing, passing the same number of requests to each backend. Great. You&#39;ll end up with consistent, even load.</description>
    </item>
    <item>
      <title>Capabilities</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/07/01/</link>
      <pubDate>Wed, 01 Jul 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/07/01/</guid>
      <description>Back in the days of PCs and &amp;quot;PC Clones&amp;quot; Flight Simulator was the defacto standard for compatibility. If your clone ran FlightSim it was golden and everything would work. The FS team took compatibility seriously, and we worked really hard to work on as much hardware as possible, from a sales perspective (the bigger the addressable market the more sales) and from a brand marketing standpoint.&#xA;Being compatible with lots of different hardware got much easier when DirectX rolled out.</description>
    </item>
    <item>
      <title>Vorlons vs. Shadows</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/06/30/</link>
      <pubDate>Tue, 30 Jun 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/06/30/</guid>
      <description>It was the dawn of the third age of mankind, ten years after the Earth/Minbari war. The Babylon Project was a dream given form. Its goal: to prevent another war by creating a place where humans and aliens could work out their differences peacefully. It&#39;s a port of call, home away from home for diplomats, hustlers, entrepreneurs, and wanderers. Humans and aliens wrapped in two million, five hundred thousand tons of spinning metal, all alone in the night.</description>
    </item>
    <item>
      <title>POC vs MVP</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/06/29/</link>
      <pubDate>Mon, 29 Jun 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/06/29/</guid>
      <description>So what&#39;s the difference between a POC and an MVP? Let&#39;s start with definitions. POC is proof of concept, while MVP is minimum viable product. A POC is something you show your boss or PM to demonstrate that something is possible, while an MVP is something the business team thinks should be put in front of customers.&#xA;A POC could be lots of things. It could be a technology demonstrator. It could be re-running a log with a new model, or it could be doing A/B testing with FLAGR.</description>
    </item>
    <item>
      <title>Under Construction</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/06/26/</link>
      <pubDate>Fri, 26 Jun 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/06/26/</guid>
      <description>A couple of months ago I talked about the builder pattern for object instantiation. Another option is the factory pattern. It certainly has its place. Factories let you isolate the logic and flow of construction from both your code and the thing being constructed. Factories can also give you a kind of dependency injection, which can make testing easier.&#xA;The ability to isolate and extend leads me to an article I ran across a couple of weeks ago.</description>
    </item>
    <item>
      <title>One Step At A Time</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/06/25/</link>
      <pubDate>Thu, 25 Jun 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/06/25/</guid>
      <description>You&#39;ve probably heard of The Phoenix Project. Considered as a novel it&#39;s boringly one-dimensional to almost OK. Considered as allegory though, it&#39;s got a lot going for it. Archetypes, broad statements, and simply worded lessons. One of the simplest of those lessons is Kaizen, or continuous improvement. The idea that most efficient things you can do is the thing that makes your daily work more efficient. That&#39;s kind of circular, and deserves to be unpacked.</description>
    </item>
    <item>
      <title>How Old Is Old</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/06/24/</link>
      <pubDate>Wed, 24 Jun 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/06/24/</guid>
      <description>Not only is what&#39;s old new again, what was once new gets old. And it seems like it gets old faster and faster. When I got my first paying job writing software 30+ years ago I was using FORTRAN77, and it was a 10 year old standard that was in the process of being updated. When I left that job Fortran90 was the new hotness, and we were just starting the conversion process.</description>
    </item>
    <item>
      <title>Zip It</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/06/23/</link>
      <pubDate>Tue, 23 Jun 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/06/23/</guid>
      <description>Tales from the trenches.&#xA;Geometry is hard. Let&#39;s say you needed to take pictures of every street in the US, or at least every address. Because street level imagery is fairly temporal you wanted to do areas quickly so you have &amp;quot;squads&amp;quot; of vehicles in an area. And for technical reasons you needed to keep the vehicles from operating in the same area. How would you break the country into workable areas?</description>
    </item>
    <item>
      <title>The First Year</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/06/22/</link>
      <pubDate>Mon, 22 Jun 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/06/22/</guid>
      <description>It&#39;s been just over a year since I started writing these notes. It started out as just sharing some links with my team, then with all of the infra org, and finally with all of ATG. Just over 230 notes. Some more humorous than others, but hopefully all interesting and informative.&#xA;First off, what a year it&#39;s been. When I started sending those links our team was the infra team for the Maps organization in &amp;quot;Prime&amp;quot;.</description>
    </item>
    <item>
      <title>Inheriting Code</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/06/18/</link>
      <pubDate>Thu, 18 Jun 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/06/18/</guid>
      <description>One of the things we&#39;ve all had to do is learn how to work with an established system. Whether it&#39;s your first internship, switching teams, going to a new company, or just helping someone use something you&#39;ve built, you have to orient yourself. So what do you do? The first thing to do is ask questions. If you&#39;re lucky, there are folks around who can give you an overview, tell you where the problems are, and give you some history on why things are the way they are.</description>
    </item>
    <item>
      <title>How Severe Is Severe</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/06/17/</link>
      <pubDate>Wed, 17 Jun 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/06/17/</guid>
      <description>Last month I talked about how a set of priorities is nice, but whenever the size of a set of priorities is less than the number of items being prioritized you have a problem and an ordered list of items is needed. Priority is just a way to order the operations. So how do you come up with the ordered list? That&#39;s where severity comes in.&#xA;Severity is a measure of the impact of a bug or work item.</description>
    </item>
    <item>
      <title>What&#39;s Old Is New Again</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/06/16/</link>
      <pubDate>Tue, 16 Jun 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/06/16/</guid>
      <description>Did you know that using GPUs to make processing faster is old technology? Back in the late 80s/early 90&#39;s I was working with the flight simulators at Wright-Patterson AFB, They ran on Gould SELs, and right next to the main CPU were a couple of other cabinets, about the same size. They were the co-processors, the I(nteger)PU and the F(floating point)PU. And together they could do math orders of magnitude faster than the CPU.</description>
    </item>
    <item>
      <title>Backing Up</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/06/15/</link>
      <pubDate>Mon, 15 Jun 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/06/15/</guid>
      <description>I ran across an article on how to not ding your rented semi-trailer when backing up. Don&#39;t ask why. That&#39;s not important to this conversation. What is important is how much of the article actually applies to development.&#xA;The first and most important rule for backing up safely is &amp;quot;Don&#39;t back up&amp;quot;. For software development the corollary is some combination of *Y* ou *A* in&#39;t *G* onna *N* eed *I* t, use the tools you already have, not putting yourself in a situation where you need to do write the that piece of code by putting in guardrails earlier.</description>
    </item>
    <item>
      <title>Getting Started</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/06/12/</link>
      <pubDate>Fri, 12 Jun 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/06/12/</guid>
      <description>It&#39;s summer, and welcome to our new interns. You&#39;re bright-eyed and eager to learn. You&#39;ve got an amazing opportunity to learn from some of the sharpest minds in the business. So what should you learn?&#xA;Here&#39;s my top 6 things, in no particular order.&#xA;Sharing/Asking/Working on a team and email/Slack/ZenHub/Jira/Zoom: This is a big one. In school most of what you do will be on your own, and even when you&#39;re working on a team the projects are (generally) small enough that you can hold all of the details of the entire project in your head at once.</description>
    </item>
    <item>
      <title>Know Your Tools</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/06/11/</link>
      <pubDate>Thu, 11 Jun 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/06/11/</guid>
      <description>Learning how to use a tool is usually pretty easy. Learning when not to use a tool is harder. Especially when your &amp;quot;tool&amp;quot; is a Turing Complete language. If a program can be written, it can be written in any turing complete language, but that doesn&#39;t mean it&#39;s a good idea. In theory you can use sed&amp;nbsp;to implement your workflow, but that&#39;s a very bad idea. Conversely, if you need to loop over a list of numbers and add them up you could write a bespoke program in Rust to read a file, add them up, and spit out the answer, but again, probably not the right choice.</description>
    </item>
    <item>
      <title>Why Are An Elephant&#39;s Ears So Big?</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/06/10/</link>
      <pubDate>Wed, 10 Jun 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/06/10/</guid>
      <description>RTAPI or 3000+ services? The architect says &amp;quot;It depends&amp;quot;. It depends on a lot of things. And a lot of them come down to why elephants have big ears. The cube/square law. Generally speaking, surface area goes up with the square of size, while volume goes up with its cube. Consider the sphere. Surface area is &amp;pi;r^2, while volume is 4/3 &amp;pi;r^3. Comparing the titular elephant to a mouse, the elephant has a lot more body (volume) generating heat per square inch of skin (surface area) so to radiate that extra heat it has big ears to dramatically increase the surface area.</description>
    </item>
    <item>
      <title>Crawl, Walk, Run</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/06/09/</link>
      <pubDate>Tue, 09 Jun 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/06/09/</guid>
      <description>Or, as Kent Beck said &amp;ldquo;Make it work. Make it right. Make it fast&amp;rdquo;. But what does that mean? What&#39;s the difference between crawling, walking, and running or working, right, and fast? What goes in each phase?&#xA;Crawling or making it work is the happy path proof of concept. As long as the inputs make sense (whatever that means in a given context) then the output is good enough to use.</description>
    </item>
    <item>
      <title>Eventual Consistency</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/06/08/</link>
      <pubDate>Mon, 08 Jun 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/06/08/</guid>
      <description>Consistency, availability, and partition tolerance. CAP theorem. If you&#39;re working on a distributed database then a lot of what you do is guided by CAP theorem. The world is an imperfect place, and networks break. So you have to deal with network partitions. And in the face of a network partition you can&#39;t guarantee consistency and availability. That&#39;s the CAP theorem in a nutshell. But what if there were a way to, if not break the rules, at least ignore them in some cases?</description>
    </item>
    <item>
      <title>TIL ...</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/06/05/</link>
      <pubDate>Fri, 05 Jun 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/06/05/</guid>
      <description>TIL what TIL&amp;nbsp;means. Not really, but that is one of the TLA&#39;s I seem to have trouble remembering. Kind of like I know that PCMCIA doesn&#39;t mean People Can&#39;t Memorize Computer Industry Acronyms, but I can never remember what it really means.&#xA;Actually, what I really learned was more about Optional vs Nullable. I gained a deeper understanding of the advantages of Optional&amp;nbsp;types. Not having to worry about NULL pointers can make things cleaner, easier to comprehend, and of course, avoid NPEs, which is always a good thing.</description>
    </item>
    <item>
      <title>Abstract vs Interface</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/06/04/</link>
      <pubDate>Thu, 04 Jun 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/06/04/</guid>
      <description>Whatever your language of choice, at some point you&#39;re going to need to think about inheritance, composition, and hierarchy. That&#39;s when you start thinking about abstract classes vs interface classes. Regardless of what your language calls them, pretty much all modern languages (C++, Golang, Javascript. Python, etc) include the functionality directly or indirectly.&#xA;The difference between the two is kind of subtle, but for the sake of simplicity let&#39;s say an interface is the definition of the contract between caller and provider, but has no implementation, while an abstract class provides at least one overrideable concrete implementation of part of that contract.</description>
    </item>
    <item>
      <title>Toward A Better PM</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/06/03/</link>
      <pubDate>Wed, 03 Jun 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/06/03/</guid>
      <description>I&#39;m not talking about Nyquil or Tylenol PM or [Program|Project|Product] Manager. I&#39;m talking about Post-Mortems, or Post-Incident Reviews as they&#39;re starting to be known. Whatever you call them, they&#39;re critical to improving the system. And that&#39;s the goal. Make the system better. Make it more reliable. More self-healing. To do that you need to figure out two things. What&amp;nbsp;happened, both leading up to and during the incident, and why&amp;nbsp;those things happened.</description>
    </item>
    <item>
      <title>Logging</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/06/02/</link>
      <pubDate>Tue, 02 Jun 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/06/02/</guid>
      <description>Ever run into an error dialog on a web page that said something like &amp;quot;An error has occurred. Hit ok to continue&amp;quot;? Not very helpful was it. What about &amp;quot;An error has occurred and has been logged. Please try again later.&amp;quot; Still not really helpful, but at least you feel better because someone knows about it now. Well this isn&#39;t about that error dialog (although some of it applies). This is about that log that got mentioned.</description>
    </item>
    <item>
      <title>Avoiding The Wat</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/06/01/</link>
      <pubDate>Mon, 01 Jun 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/06/01/</guid>
      <description>In the beginning was the command line. And the command line is still there. Whether you&#39;re using sh, bash, csh, tch, zsh, fish or something else, you end up running the same commands. Today I want to talk about those commands. Or at least those commands and the principle of least surprise.&#xA;Let&#39;s start with a simple one. `-?` Should print out help for your command. I know someone can come up with a valid case where that doesn&#39;t make sense, but unless you&#39;ve got a really good reason, go with that.</description>
    </item>
    <item>
      <title>6 Stages Of Debugging</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/05/29/</link>
      <pubDate>Fri, 29 May 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/05/29/</guid>
      <description>That can&#39;t happen. That doesn&#39;t happen on my machine. That shouldn&#39;t happen. Why is that happening? Oh, I see. How did that ever work? Not quite the 5 stages of grief, but surprisingly similar.&#xA;First, Denial. It&#39;s impossible. The user did something wrong. It&#39;s not my code. The sunspots did it. Come back when you&#39;ve got real proof that this is my bug and I there&#39;s something for me to fix.</description>
    </item>
    <item>
      <title>Just Keep Learning</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/05/28/</link>
      <pubDate>Thu, 28 May 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/05/28/</guid>
      <description>The only constant is change. That&#39;s true for many things, including being a developer and a developer&#39;s career. Lots of things change. The computers we use. The tools that we use. The language(s) we write in. The business environment. The goals we work toward. And on top of all of those external changes, we change too. While there&#39;s an unbroken line of &amp;quot;me&amp;quot; all the way back to when I got that first part-time developer job in school to now, I&#39;m not the same person I was then.</description>
    </item>
    <item>
      <title>In Defense Of Laziness</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/05/25/</link>
      <pubDate>Mon, 25 May 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/05/25/</guid>
      <description>The parentage of invention is something of an open question. It&#39;s often been said that necessity is the mother of invention, and that seems reasonable, but who&#39;s the father? I&#39;ve heard a bunch of different answers, including opportunity and ability, but my money&#39;s on laziness.&#xA;But it&#39;s a special kind of laziness. Not the kind that sweeps the dust under the rug instead of cleaning up or the kind that finishes a project and leaves the tools wherever they lay.</description>
    </item>
    <item>
      <title>Solving Problem Solving</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/05/22/</link>
      <pubDate>Fri, 22 May 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/05/22/</guid>
      <description>I&#39;ve mentioned this before, and it&#39;s still true. They don&#39;t pay us to write code. They pay us to further the mission, and the ATG mission statement is _Our mission is to bring safe, reliable self-driving transportation to everyone, everywhere_. Nothing in there about writing software, or building AI models or more secure hardware. Nope. We write code (or do all the other things we&#39;re doing) in support of the mission.</description>
    </item>
    <item>
      <title>Velocity Is Internal</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/05/21/</link>
      <pubDate>Thu, 21 May 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/05/21/</guid>
      <description>Story points and burndown charts. Two staples of the agile planning process. They&#39;re what let you have confidence that what you&#39;re planning for any given sprint is close to what will be delivered. And they&#39;re pretty good at that. They let you compare projections and actuals over time for your team. But that&#39;s pretty much all they&#39;re good for.&#xA;One of the things they&#39;re very bad&amp;nbsp;at is comparing across&amp;nbsp;teams. You can make all the claims you want about common definitions for story points and capacity, but the reality is that every team goes through the 4 stages of development (remember forming/storming/norming/performing?</description>
    </item>
    <item>
      <title>Everything Can&#39;t Be P1</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/05/20/</link>
      <pubDate>Wed, 20 May 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/05/20/</guid>
      <description>A few weeks ago I talked about priority inflation in bugs and tasks. It really happens, but it also kind of doesn&#39;t matter. You could have P0 - P3, P1 - P4, or P[RED|YELLOW|GREEN|BLUE|BLACK|ORANGE] or any other way of distinguishing priorities. That&#39;s because the priorities themselves don&#39;t mean anything. They&#39;re just a ranking. They have no intrinsic value/meaning.&#xA;And once you get past the fact that all priority is relative, and in fact only relative to the other things it was prioritized with, you realize that with a finite set of priorities, your prioritized list of bugs/tasks becomes far less useful.</description>
    </item>
    <item>
      <title>Swallowing The Fish</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/05/19/</link>
      <pubDate>Tue, 19 May 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/05/19/</guid>
      <description>Back when I joined Microsoft as the dev lead for the Combat Flight Sim team Bill Gates was CEO and the mission statement was pretty simple, &amp;quot;A computer on every desk and in every home&amp;quot;, with the unspoken ending, running Microsoft software. By the time I joined Uber, Satya Nadella was CEO and the mission statement had gone through a few iterations and was &amp;quot;To empower every person and every organization on the planet to achieve more.</description>
    </item>
    <item>
      <title>Pictures Or It Didn&#39;t Happen</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/05/18/</link>
      <pubDate>Mon, 18 May 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/05/18/</guid>
      <description>One of the oddities of software is that the vast majority of the work done can&#39;t be seen. It&#39;s just a series of 0&#39;s and 1&#39;s stored somewhere. You can spend man years working on paying down technical debt or setting yourself up for the future.&#xA;When I was working on the Global Ortho project we had something we called the MBT spreadsheet. The Master Block Tracking list. It started life as a PM&#39;s way of tracking the status of those 1 degree cells through the system, from planning to acquisition, ingest, initial processing, color balancing, 3D model generation, then delivery and going live to the public.</description>
    </item>
    <item>
      <title>Optimization</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/05/15/</link>
      <pubDate>Fri, 15 May 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/05/15/</guid>
      <description>Premature optimization may or not be the root of all evil, but optimizing the wrong&amp;nbsp;thing certainly doesn&#39;t help. When we talk about optimization we&#39;re usually talking about minimizing time, and the example says that if you have two sub-processes and one takes 9.9 seconds and the other takes .1 seconds then you should spend your time on the first one, because even if you manage to eliminate the second no one will notice.</description>
    </item>
    <item>
      <title>Cost Of Control</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/05/14/</link>
      <pubDate>Thu, 14 May 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/05/14/</guid>
      <description>The other day I ran across a presentation which appeared to have a very different take on incident management. And it talked about some of my hot topics, hidden complexity, cognitive load and their costs, so I was looking forward to seeing the recommendations and seeing how I might be able to apply. But the presentation kind of fizzled out, ending up with some observations of how things were, and identifying some issues/bottlenecks, but not taking the next step.</description>
    </item>
    <item>
      <title>The Art Of Computer Programming</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/05/13/</link>
      <pubDate>Wed, 13 May 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/05/13/</guid>
      <description>A little history lesson today. Have you ever used a compiler? Written an algorithm? Used the search function inside a document? Then chances are you&#39;ve used work by Donald Knuth. For the last 60-odd years he&#39;s been learning, teaching, doing, and writing about computer science and it&#39;s fundamentals.&#xA;By far his greatest contribution to the field is his magnum opus, The Art of Computer Programming. It was originally going to be one book, but it&#39;s up to 4 volumes now and growing.</description>
    </item>
    <item>
      <title>Scale Out, Not Up</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/05/12/</link>
      <pubDate>Tue, 12 May 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/05/12/</guid>
      <description>If you&#39;ve spent much time around folks who work on large scale data centers you&#39;ve probably heard them talking about pets and cattle and wondered why that was. Yes, data centers are sometimes called server farms, but that&#39;s not why. Or at least it&#39;s not that simple.&#xA;It all goes back to the idea of scale and how that has changed over the years. 50 years ago computers were big. Room sized big.</description>
    </item>
    <item>
      <title>IP Tables To The Rescue</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/05/11/</link>
      <pubDate>Mon, 11 May 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/05/11/</guid>
      <description>HDFS is great for storing large amounts of data reliably, And we had the largest HDFS cluster at Uber and and one of the largest in the world in WBU2. 100 PB, 1000 Nodes, 25,000 Disks. HDFS manages all those resources, and it does it in a reasonably performant manner. It does it by keeping track of every directory, file, and file block. You can think of it like the master file table on a single disk drive.</description>
    </item>
    <item>
      <title>The 3 Tells</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/05/08/</link>
      <pubDate>Fri, 08 May 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/05/08/</guid>
      <description>I&#39;m not talking about how to tell when the person across the poker table from you is bluffing. I&#39;m talking about how you can effectively get your point across in a limited amount of time. You&#39;ve got good ideas. Knowing how to get your point across, whether it&#39;s formal with a slide deck or a quick hallway conversation, makes it much more likely that those good ideas will become realities. And it starts with the three tells:</description>
    </item>
    <item>
      <title>How Much Config Is Enough?</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/05/07/</link>
      <pubDate>Thu, 07 May 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/05/07/</guid>
      <description>Pop quiz. You&#39;re building an application. What parameters do you put in your config file? The answer, like any other architectural question is, &amp;quot;It depends.&amp;quot; On one extreme you spend a lot of time with your customers and bake everything into the application. Changing anything, from the name on the splash screen to the on-disk fully qualified path to the splash screen image is compiled right into the binary. On the other end, the only thing the application knows how to do is read a configuration file that tells it where to find the dynamic libraries and custom DSL files full of business logic that actually do anything.</description>
    </item>
    <item>
      <title>Your Bug, Your Customer&#39;s Feature</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/05/06/</link>
      <pubDate>Wed, 06 May 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/05/06/</guid>
      <description>It&#39;s not a bug, it&#39;s a feature. We&#39;ve all heard it. We&#39;ve probably all said it. But think about it. What exactly is a feature. It&#39;s the application doing something the customer wants, when the customer wants it done. It doesn&#39;t matter if that&#39;s what you expected. It doesn&#39;t matter if that&#39;s what the spec called for or the PM really wanted. It&#39;s fulfilling a customer need. And to the customer, that&#39;s a feature.</description>
    </item>
    <item>
      <title>Disk Errors</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/05/05/</link>
      <pubDate>Tue, 05 May 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/05/05/</guid>
      <description>I&#39;ve been working on datacenters and parallel computing for over 10 years now. Back in 2007 we had about 100PB of spinning disk and had our own home-grown distributed file system. Roughly equivalent to HDFS, but of course Windows (NTFS) based since we were part of Microsoft. We had filesets (roughly equivalent to an HDFS file) composed of individual NTFS files (blocks in HDFS terms), and instead of a namenode/journalnode we had a monstrous MS-SQL server that kept track of everything.</description>
    </item>
    <item>
      <title>Star Wars Security</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/05/04/</link>
      <pubDate>Mon, 04 May 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/05/04/</guid>
      <description>Besides turning datacenters on and off, making them more efficient, and helping users take advantage of them, the other thing that&#39;s been occupying my time is coming up with a way to figure out who&#39;s making that call in the DC and if they are really allowed to do it. Otherwise known as Identity and Access Management, or IAM.&#xA;I could go into a lot of boring detail about cryptographically secure messages, the basics of TLS, x.</description>
    </item>
    <item>
      <title>What&#39;s In A URI?</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/05/01/</link>
      <pubDate>Fri, 01 May 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/05/01/</guid>
      <description>The other day I came across an article that asked if you could identify every part of a URL, then listed the 6 parts of a URL, scheme://domain:port/path?query=string#anchor. Now that&#39;s not wrong, in that those 6 parts, put together that way do make up a valid URL, but that&#39;s hardly all of the story. In the article&#39;s defense, it does say there are other parts and that those are the most common, but if you went into an interview and insisted that was the definition of a URL you wouldn&#39;t be &amp;quot;acing&amp;quot; the interview.</description>
    </item>
    <item>
      <title>Else, Switch, And Map</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/04/30/</link>
      <pubDate>Thu, 30 Apr 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/04/30/</guid>
      <description>Back when I was in 7th grade I entered some kind of scholastic programming competition. No idea what it was called, or what most of the tasks were. I do remember it was 3 hours on a Sunday afternoon, we were using Basic on a TRS-80, and one of the tasks was to come up with a frequency chart of characters in a block of text. The code I submitted looked a lot like</description>
    </item>
    <item>
      <title>Fear, Courage, and Professionalism</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/04/29/</link>
      <pubDate>Wed, 29 Apr 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/04/29/</guid>
      <description>Rumors of layoffs suck. Let&#39;s be upfront about that. There are no platitudes that make it easy. I know. I&#39;ve been there. Take all the downsides and issues from a layoff and then layer in lots of fear, uncertainty, and doubt. You don&#39;t know if or when something might happen, or even who might be impacted, but life goes on. Work goes on. So what do you do?&#xA;I&#39;m not suggesting that you simply ignore rumors, social media, Blind, or news reports.</description>
    </item>
    <item>
      <title>80/20 Rule</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/04/28/</link>
      <pubDate>Tue, 28 Apr 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/04/28/</guid>
      <description>Ever notice how projects seem to go quickly at the beginning and then take longer and longer when you get close to the end? Or the opposite, that making a few small fixes in a codebase can make everything better? That&#39;s the Pareto Principle&amp;nbsp;at work. 80% of the work takes 20% of the time, and the remaining 20% of the work takes 80% of the time. Fixing 20% of the bugs eliminates 80% of the issues customers are seeing.</description>
    </item>
    <item>
      <title>Awareness</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/04/27/</link>
      <pubDate>Mon, 27 Apr 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/04/27/</guid>
      <description>The world is always changing. And the rate of change appears to be changing as well. The stone age lasted 3000 years, and ended 5000 years ago. The bronze age took the next 1800 years, ending 3200 years ago. Iron ruled for about 1500 years, and technology stabilized for a while. Then things took off again. The industrial revolution, the atomic age, the space race, the silicon era, all in the last 250 years.</description>
    </item>
    <item>
      <title>On Language</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/04/24/</link>
      <pubDate>Fri, 24 Apr 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/04/24/</guid>
      <description>Just a little humor today.&amp;nbsp;&#xA;ACHTUNG&#xA;ALLES TURISTEN UND NONTEKNISCHEN LOOKENSPEEPERS!&#xA;DAS KOMPUTERMASCHINE IST NICHT F&amp;Uuml;R DER GEFINGERPOKEN UND MITTENGRABEN! ODERWISE IST EASY TO SCHNAPPEN DER SPRINGENWERK, BLOWENFUSEN UND POPPENCORKEN MIT SPITZENSPARKEN.&#xA;IST NICHT F&amp;Uuml;R GEWERKEN BEI DUMMKOPFEN. DER RUBBERNECKEN SIGHTSEEREN KEEPEN DAS COTTONPICKEN H&amp;Auml;NDER IN DAS POCKETS MUSS.&#xA;ZO RELAXEN UND WATSCHEN DER BLINKENLICHTEN.&#xA;The inspiration for your favorite language:&#xA;Python: &amp;nbsp; What if everything was a dict?Java: &amp;nbsp; What if everything was an object?</description>
    </item>
    <item>
      <title>Priority -1</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/04/23/</link>
      <pubDate>Thu, 23 Apr 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/04/23/</guid>
      <description>We all have lots of work to do. During the development phase there&#39;s often so much work that at any given moment there is more work to be done than there is time to do it. In what we used to call the test phase (now beta or pre-GA) there are defect reports. So how do you know what to work on next and/or when you&#39;re done? The traditional answer is priority.</description>
    </item>
    <item>
      <title>It Depends</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/04/22/</link>
      <pubDate>Wed, 22 Apr 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/04/22/</guid>
      <description>Time for a car analogy. What&#39;s the right way to make your car faster? More reliable? More efficient? Have higher resale value?&#xA;There&#39;s really only one answer to all those questions. And that answer is &amp;quot;It depends.&amp;quot; It depends on what your priorities are. It depends on where you&#39;re starting. It depends on what you mean by those questions. It depends on how much you can spend to meet your priorities.</description>
    </item>
    <item>
      <title>Real Engineering</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/04/21/</link>
      <pubDate>Tue, 21 Apr 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/04/21/</guid>
      <description>Here&amp;rsquo;s a question for you. Are you a programmer, developer, computer scientist, software engineer, hardware engineer, or something entirely different? Maybe you&amp;rsquo;re an artist working in the medium of bits? A data wrangler? Some combination of all of these, depending on the day and the task at hand?&#xA;For the last 50 years or so people have been trying to figure out if software development was an art or a science.</description>
    </item>
    <item>
      <title>Outdoor Sports</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/04/20/</link>
      <pubDate>Mon, 20 Apr 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/04/20/</guid>
      <description>Continuing on with the string of GlobalOrtho stories, image capture, both aerial and terrestrial, is, just like operating a robot car, an outdoor sport.&#xA;At the heart of the GlobalOrtho project was the UltraCam-G. Designed and built by our team in Graz Austria. Something like 200 MP, taking simultaneous RGB, Monochrome, and NIR images at 30cm resolution for the RGB image. And this camera was tested. Countless flights over Graz and the surrounding areas.</description>
    </item>
    <item>
      <title>Murder Mystery Theater - Acting All Roles</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/04/17/</link>
      <pubDate>Fri, 17 Apr 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/04/17/</guid>
      <description>-- By Andrew Gemmel&#xA;There&amp;rsquo;s been a mild annoyance bothering developers on our team - and likely others - for a few months now. Occasionally the ssh-agent on development machines will die. Needing a ussh cert for most remote actions, the remedy for one terminal session is a quick eval $(ssh-agent)&amp;nbsp;or more permanently, restarting the machine. We all chalked it up to a bad chef configuration or similar, at least until today.</description>
    </item>
    <item>
      <title>GIGO</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/04/16/</link>
      <pubDate>Thu, 16 Apr 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/04/16/</guid>
      <description>Even the greatest algorithm can&#39;t correct for bad data. Ever hear of photogrammetry? Probably. It&#39;s using images to understand the physical world. We use it to map the world. Using stereoscopic techniques and two (or more) pictures of a scene from a known position, you can extract 3D information. Roughly speaking you find points in each image that are the same thing, then, correcting for all sorts of distortions, use the difference in camera locations and the directions to the point from each camera to calculate the position of that point relative to the cameras.</description>
    </item>
    <item>
      <title>Test It Again Sam</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/04/15/</link>
      <pubDate>Wed, 15 Apr 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/04/15/</guid>
      <description>Unit tests, integration tests, black box tests, end to end tests, user tests, test driven development, demo days. There are lots of kinds of tests. And they all can provide value. But only if you run the right tests at the right time. And as with so many things, it comes back to context, scope, and scale.&#xA;You want to have enough inputs to test that it works, that the different combinations of flags/features/datasets all work together the way you expect.</description>
    </item>
    <item>
      <title>Syntax Matters</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/04/14/</link>
      <pubDate>Tue, 14 Apr 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/04/14/</guid>
      <description>But memorizing all of the possible syntaxes (syntaxi?) doesn&#39;t. In my career I&#39;ve spent months/years with _at least_ Ada, Assembly (x86), Bash, Basic, Csh, C/C++, C#, Fortran (4/77), Golang, HTML, Java, Javascript, Pascal, Perl, Python, Scala, SQL, and VisualBasic (v6 and VBA). Then there&#39;s &amp;quot;config&amp;quot; file formats, css, ini, json, xml, and, yaml. What about .bzl, .csv, .proto, and .thrift? What about your favorite DSL? Are they config files? Languages? Who knows?</description>
    </item>
    <item>
      <title>Rubber Ducky, You&#39;re The One</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/04/13/</link>
      <pubDate>Mon, 13 Apr 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/04/13/</guid>
      <description>On the silver lining front, one nice thing about WDP is that I get to spend more time with my kids. My daughter has taken to sitting with me on and off during the day, sometimes doing her schoolwork, sometimes watching videos, and sometimes being my debugging aid.&#xA;The other day she noticed I was arguing with my computer, doing some Google searches, then yelling (quietly) at my computer again. After she got over being surprised that I was using Google to figure things out I started explaining to her what I was trying to do.</description>
    </item>
    <item>
      <title>Remote Extreme Programming</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/04/10/</link>
      <pubDate>Fri, 10 Apr 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/04/10/</guid>
      <description>You&#39;ve probably heard of pair programming. That&#39;s where two programmers work on one screen with one keyboard, taking turns being the typist and the navigator/observer. Not my favorite way to work long term, but I&#39;ve definitely taken advantage of it during debugging or exploring a new area with another developer. It&#39;s really easy to do in person, and not too hard even now with WDP. Zoom and screen sharing are almost like being there in person.</description>
    </item>
    <item>
      <title>Bob The Builder</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/04/09/</link>
      <pubDate>Thu, 09 Apr 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/04/09/</guid>
      <description>There are lots of design patterns. The most famous are probably the ones in the Gang of Four&#39;s book, Design Patterns. There are lots of good patterns in there. Each pattern has its strengths and weaknesses. Of course, like any good tool in your toolbox, you can use any particular pattern for multiple things. As important as it is to know when to use a pattern, knowing when to NOT&amp;nbsp;use a pattern is more important.</description>
    </item>
    <item>
      <title>Alles Ist In Ordnung</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/04/08/</link>
      <pubDate>Wed, 08 Apr 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/04/08/</guid>
      <description>Everything is in order. That&#39;s what coding standards are all about. Making sure everything looks right. Especially the ones we have linters for. Correct?&#xA;Sort of. Yes, coding standards include formatting and layout. And that&#39;s the part linters are best at finding/fixing and annoying us with. And it&#39;s important too. Especially in languages that we _mostly_ agnostic to the amount and location of whitespace. Like C/C++. You can pretty much throw spaces and tabs anywhere you want (outside of string literals) and the compiler won&#39;t care.</description>
    </item>
    <item>
      <title>Time For A Walk</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/04/07/</link>
      <pubDate>Tue, 07 Apr 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/04/07/</guid>
      <description>I don&#39;t know about you, but I&#39;ve been spending a lot of time in one spot for the past few weeks. It&#39;s great that I&#39;ve got a workspace with a stand-up desk and enough pixels to keep all the text I need to read big enough to see, but I don&#39;t even get to walk to the various conference rooms anymore. And that&#39;s a problem for me. No changes of scenery.</description>
    </item>
    <item>
      <title>Staying In Sync</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/04/06/</link>
      <pubDate>Mon, 06 Apr 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/04/06/</guid>
      <description>Technology changes. A lot. All the time. So how do you stay on top of it? How do you know what&amp;rsquo;s coming so you can be prepared?&#xA;One important thing to remember is that you can&amp;rsquo;t be an expert in everything, so don&amp;rsquo;t try to be. You&amp;rsquo;ll have your strengths, things that you&amp;rsquo;re better at, or enjoy working on more, and you should always play to them. There are going to be things that are &amp;ldquo;outside your wheelhouse&amp;rdquo;, and that&amp;rsquo;s fine.</description>
    </item>
    <item>
      <title>Sharding Shouldn&#39;t Be Hard</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/04/03/</link>
      <pubDate>Fri, 03 Apr 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/04/03/</guid>
      <description>When you get down to it, most of what we do is keep track of things. Objects in motion. Objects at rest. Files. Data in files. Where we put the files. Metadata about the data. Who wrote the data. Who read the data. For source control systems (Git, TFS, Perforce, VSS, etc), that&#39;s all they do. And when that&#39;s your business you keep track of a lot&amp;nbsp;of data. Typically that means storing the data in a database.</description>
    </item>
    <item>
      <title>To Test Or Not To Test</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/04/02/</link>
      <pubDate>Thu, 02 Apr 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/04/02/</guid>
      <description>The NA repo has a requirement on code coverage. And not just a requirement, A high one. And that makes sense. The Autonomy code is mission, critical, man-rated, and people&#39;s lives depend on it not going wrong. But that requirement applies not just to the Autonomy code. it applies to everything in the repo. Frameworks, web services, and command line tools among other things. And that makes sense. Yes, unit tests add some up-front cost, but overall they speed things up.</description>
    </item>
    <item>
      <title>Go Big, Go Blue</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/04/01/</link>
      <pubDate>Wed, 01 Apr 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/04/01/</guid>
      <description>ATG isn&#39;t a small company anymore. ZenHub was a good idea, but it didn&#39;t scale as far as we had hoped, and Phab wikis are deprecated. AWS identities are confusing and we&#39;re already reaching scale limits on accounts, roles, and cross-connects. Google drive is great for storing and collaborating on documents, but discovery is nigh-on impossible. Yet work must continue. We still need to plan and execute. We need to track defects.</description>
    </item>
    <item>
      <title>Concurrency And Parallelism</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/03/31/</link>
      <pubDate>Tue, 31 Mar 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/03/31/</guid>
      <description>Getting computers to do what you want is hard. Getting them to do more than one thing at a time is even harder. In fact, for a given CPU core, it&#39;s impossible. But they can do things so fast, and switch between things so fast, that it looks&amp;nbsp;like they&#39;re doing more than one thing at a time. That&#39;s concurrency. Add in multiple cores and in fact they are doing multiple things at once.</description>
    </item>
    <item>
      <title>No UML</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/03/30/</link>
      <pubDate>Mon, 30 Mar 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/03/30/</guid>
      <description>You&#39;ve probably heard of Unified Modeling Language (UML). You&#39;ve probably even drawn up a few system diagrams with it. It&#39;s so popular that tools like Visio and Google Draw have the templates built in. But does it work? It&#39;s certainly good for analysing an existing system and understanding the relationships between the parts, but what about up-front design. Doing UML right often requires you to know, or make decisions about, things that aren&#39;t done yet.</description>
    </item>
    <item>
      <title>Overcommunicating</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/03/27/</link>
      <pubDate>Fri, 27 Mar 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/03/27/</guid>
      <description>I&#39;m one of the folks down in the engine room (the infra team). Our job is to make sure that all of our customers are happy and their appetite for processing (batch, long running services, stateful, stateless, etc) and storage (HDFS, Blob, Posix, etc) is met. As such, we&#39;re essentially a service team. That doesn&#39;t mean we write services (we do that), but that we provide&amp;nbsp;a service to our customers. And our customers use those services to do their work, whatever it is.</description>
    </item>
    <item>
      <title>I Feel You Man</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/03/26/</link>
      <pubDate>Thu, 26 Mar 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/03/26/</guid>
      <description>Is your code empathetic? Do your users think it is? Do your users think you&#39;re empathetic? Is there anything you can do to change that? Does it matter?&#xA;All good questions. And of course it does. But before you can answer them you need to understand what empathy is. People often think that having empathy means that you feel what the other person is feeling, and that&#39;s part of it, but there&#39;s a more important part.</description>
    </item>
    <item>
      <title>Shiny Happy People</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/03/25/</link>
      <pubDate>Wed, 25 Mar 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/03/25/</guid>
      <description>We&#39;ve been working from home for almost 2 weeks now. How are you feeling about it? There&#39;s no question that there&#39;s been a huge disruption in the force. It&#39;s something we all need to get used to. And as someone pointed out the other day, this isn&#39;t really WFH, it&#39;s WDP (work during pandemic) which is not exactly&amp;nbsp;the same thing. But there are some similarities. The priorities might have changed, and the relative ranking of taking care of yourself and your family vs work has certainly changed.</description>
    </item>
    <item>
      <title>Keeping It Clean</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/03/24/</link>
      <pubDate>Tue, 24 Mar 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/03/24/</guid>
      <description>Compilers are really good at turning the code you write into some kind of executable, be it machine code that executes directly or ByteCode that gets run by some virtual machine. It always does what you tell it, and most of the time it does what you want.&#xA;But that doesn&#39;t make it clean. To write clean you, first, you need to know what clean code is. There are lots of lists and acronyms that talk about what clean code is, but I think Martin Fowler summed it up best, with &amp;quot;any fool can write code that a computer can understand.</description>
    </item>
    <item>
      <title>On Conflict</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/03/23/</link>
      <pubDate>Mon, 23 Mar 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/03/23/</guid>
      <description>Conflict is real, inevitable, and everywhere. Every comment on a PR or RFC is conflict. So is every question in a design review. If you&#39;re on a team that truly&amp;nbsp;has no visible conflict then take a deep look around and try to figure out why. It&#39;s probably not&amp;nbsp;a good sign. I doubt you all really agree about everything.&#xA;Unless you never make decisions anyone disagrees with, every decision you make involves some conflict.</description>
    </item>
    <item>
      <title>Naming Is Still Hard</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/03/20/</link>
      <pubDate>Fri, 20 Mar 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/03/20/</guid>
      <description>Back in January I wrote about naming things and I came across another article with more info so I figured I&#39;d share that. The one I have some disagreement with is the emphatic advice to avoid hungarian notation. While I agree that prefixing with the base type information is wasteful and makes things harder for your IDE, the original usage for hungarian notation, particularly when writing C&amp;nbsp;code for windows makes a lot of sense.</description>
    </item>
    <item>
      <title>Circles</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/03/19/</link>
      <pubDate>Thu, 19 Mar 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/03/19/</guid>
      <description>I was wandering around the internet the other day and came across an article describing something called the trinity&amp;nbsp;architecture. It&#39;s a way to indicate composition, dependencies, and abstractions. And this is important because everything we do in the world of 0&#39;s and 1&#39;s is a model of something that we interact with. Ideally the model and the interactions develop together or at least the model works to handle the expected interactions.</description>
    </item>
    <item>
      <title>Intro To Architecture</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/03/18/</link>
      <pubDate>Wed, 18 Mar 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/03/18/</guid>
      <description>Name dropping today. Neal Ford and Mark Richards. I&#39;ve met and talked to both of them a few times. Had some really interesting conversations around scope of influence and the difference between a software developer and a software architect. They&#39;re both very good at not only high level architecture discussions but digging in to the details and thinking about specific use cases and approaches. They&#39;ve got a new book coming out, Fundamentals of Software Architecure, and they&#39;re doing a webinar about it next month.</description>
    </item>
    <item>
      <title>Write It Down 2</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/03/17/</link>
      <pubDate>Tue, 17 Mar 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/03/17/</guid>
      <description>Documentation is a thing. And there are lots of different kinds, each with their own use case and requirements. But one thing is consistent. Keep the audience in mind. What do they know? What don&amp;rsquo;t they know? What are they looking to know? What do you want the reader to know?&#xA;The most important thing to remember is that it&amp;rsquo;s for the reader. Whether you&amp;rsquo;re writing API docs for the RNA Docset, end user documentation for a public facing website, a postmortem, a bug report/feature request, or notes to yourself.</description>
    </item>
    <item>
      <title>Dates Are Hard Too</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/03/16/</link>
      <pubDate>Mon, 16 Mar 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/03/16/</guid>
      <description>I mentioned a while back that one of the things developers make assumptions about is that time is a monotonically increasing function. If only that were so. But it&#39;s not just time, one second ticking into the next, that isn&#39;t as simple as it seems. Duration is hard too. Not just the number of seconds between two times, but how you turn seconds into weeks, months, and years. For example, the windows calculator can tell you how many days, weeks, and months there are between two dates.</description>
    </item>
    <item>
      <title>For Want Of A Nail</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/03/13/</link>
      <pubDate>Fri, 13 Mar 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/03/13/</guid>
      <description>We build fault tolerant distributed systems. Not just fault tolerant distributed systems, but fault tolerant systems built on top of fault tolerant distributed systems. And they&#39;re connected by a distributed, fault tolerant network, using diverse fibers from different companies. That&#39;s a lot of fault tolerance. You&#39;d think something that tolerant couldn&#39;t fail. Yet sometimes we get failures.&#xA;Most of the time they&#39;re simple failures and the system is degraded. We lose a fiber and traffic gets a little slower.</description>
    </item>
    <item>
      <title>Generally Speaking</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/03/12/</link>
      <pubDate>Thu, 12 Mar 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/03/12/</guid>
      <description>What shape are you? What shape do you&amp;nbsp;want&amp;nbsp;to be? What shape&amp;nbsp;should&amp;nbsp;you be? Is there a right shape? Is there a wrong shape? And what does shape even mean here? All good questions. Let&#39;s take them in reverse order. In this case shape refers to a person&#39;s familiarity/ability in a cross-section of technologies. The generalist, jack of all trades, but master of none. The deep specialist, who knows more and more about less and less until they know everything about nothing, The focuser, not as deep as the specialist, but with a broad base.</description>
    </item>
    <item>
      <title>Guides</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/03/11/</link>
      <pubDate>Wed, 11 Mar 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/03/11/</guid>
      <description>Last year at the Software Architecture conference I saw a presentation by James Thompson on &amp;quot;Beyond Accidental Architecture&amp;quot;. Afterward he and I got to talking about the topic and my position that everything is really about scope of work and scope of influence and the difference between a senior architect and a junior developer was not in the kinds of problems being solved, (time, complexity, interfaces, etc) but in the scope.</description>
    </item>
    <item>
      <title>Gazinta&#39;s and Gazouta&#39;s</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/03/10/</link>
      <pubDate>Tue, 10 Mar 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/03/10/</guid>
      <description>A long time ago I was working on a simulated environment for a hardware mission computer on a 1553 bus and my boss told me to make sure and match the gazintas and gazoutas. As a freshly graduated Mechanical and Aerospace engineer who found himself doing hardware-in-the-loop work with computers I was somewhat confused. He told me that they were the things (data/information) that goes in to (gazinta) or goes out of (gazouta) each device on the bus.</description>
    </item>
    <item>
      <title>Cycles Of History</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/03/09/</link>
      <pubDate>Mon, 09 Mar 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/03/09/</guid>
      <description>Or, `The more things change, the more they stay the same`. A long long time ago computers were big. They took up entire rooms and required cadres of experts who would care for them, take your punch cards, and then some time later tell you that you punched the wrong hole on card 97. So you&#39;d redo card 97, resubmit your cards, and get the next error. Rinse and repeat until lo, an answer appeared.</description>
    </item>
    <item>
      <title>Committed</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/03/06/</link>
      <pubDate>Fri, 06 Mar 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/03/06/</guid>
      <description>What do you do more of, read PR commit messages or write them? Like almost everyone, I read a lot more PR messages than I write. And even more than the code it represents, which represents your intent to the compiler/interpreter, PR messages are about expressing your intent to the reader. And like good code, the purpose of your PR message is to meet a business need. In this case, the business need is to represent to the reader (which is often future you) what&amp;nbsp;and why&amp;nbsp;the PR exists in the first place.</description>
    </item>
    <item>
      <title>Stable Code</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/03/05/</link>
      <pubDate>Thu, 05 Mar 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/03/05/</guid>
      <description>Stable code is a good thing, right? Write it, build it, deploy it, and it just keeps working. It just runs and runs. You don&#39;t need to worry about it anymore. What more could you ask for? How about repeatability? There&#39;s more to a stable service than the first release. There&#39;s all the subsequent releases as well. You need to keep doing it. New requirements and requests come in, you write some more code, build it again, then deploy it.</description>
    </item>
    <item>
      <title>Architect&#39;s Newsletter</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/03/04/</link>
      <pubDate>Wed, 04 Mar 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/03/04/</guid>
      <description>Monoliths, Microservices,&amp;nbsp; Distributed&amp;nbsp; Monoliths, Domain Driven Design (DDD), Service Meshes, Data Modeling and more. All in the latest Software Architect&#39;s Newsletter.&#xA;Personally, I like DDD, as it helps with system decomposition, isolation, reducing coupling and cognitive load, and generally gives developers more&amp;nbsp;freedom inside their domain because the boundaries are clearly defined. This is especially important when you&#39;re out on a sea of uncertainty. Anything you can do to bound the context you&#39;re working in lets you focus more on what you&#39;re trying to get done and not have to worry about what others are doing.</description>
    </item>
    <item>
      <title>Foundations</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/03/03/</link>
      <pubDate>Tue, 03 Mar 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/03/03/</guid>
      <description>I recently ran across an article on &amp;quot;The 10 things every developer should learn&amp;quot;, which is a great idea, but kind of hard to specify in practice. I mean, every developer should understand loops, conditionals, and data structures, right? How about discrete math and formal logic? Set theory? Big O notation is something every developer should have a basic understanding of too. It would be good to know TCP/IP at a high level, know what 3NF is.</description>
    </item>
    <item>
      <title>Onboarding</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/03/02/</link>
      <pubDate>Mon, 02 Mar 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/03/02/</guid>
      <description>How do people join your team? How long until they can do a build and run some tests? I&#39;m not talking about understanding things well enough to submit a bug-fix PR or add a new feature, just build the code as is and run all the unit tests?&#xA;Our repo is hermetic, so that&#39;s good, it doesn&#39;t rely on having the right version of the compilers and libraries installed on dev machines.</description>
    </item>
    <item>
      <title>Incompatible Markdown</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/02/28/</link>
      <pubDate>Fri, 28 Feb 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/02/28/</guid>
      <description>Quick question. Are these two html blocks equivalent?&#xA;&amp;lt;table&amp;gt; &amp;lt;tr&amp;gt; &amp;lt;th&amp;gt;Product&amp;lt;/td&amp;gt; &amp;lt;th&amp;gt;What it&amp;#39;s good for&amp;lt;/td&amp;gt; &amp;lt;th&amp;gt;When to avoid/limitations&amp;lt;/td&amp;gt; &amp;lt;/tr&amp;gt; &amp;lt;tr&amp;gt; &amp;lt;td&amp;gt;Spinnaker&amp;lt;br&amp;gt;[Docs](http://docs/for/spinnaker)&amp;lt;/td&amp;gt; &amp;lt;td&amp;gt;Services on K8s&amp;lt;/td&amp;gt; &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt; &amp;lt;/tr&amp;gt; &amp;lt;tr&amp;gt; &amp;lt;td&amp;gt;Batch API&amp;lt;br&amp;gt;[Docs](https://docs/for/batch.html)&amp;lt;/td&amp;gt; &amp;lt;td&amp;gt;Batch Jobs&amp;lt;/td&amp;gt; &amp;lt;td&amp;gt;Not SparkSQL&amp;lt;/td&amp;gt; &amp;lt;/tr&amp;gt; &amp;lt;/table&amp;gt; and&#xA;&amp;lt;table&amp;gt; &amp;lt;tr&amp;gt; &amp;lt;th&amp;gt;Product&amp;lt;/td&amp;gt; &amp;lt;th&amp;gt;What it&amp;#39;s good for&amp;lt;/td&amp;gt; &amp;lt;th&amp;gt;When to avoid/limitations&amp;lt;/td&amp;gt; &amp;lt;/tr&amp;gt; &amp;lt;tr&amp;gt; &amp;lt;td&amp;gt; Spinnaker&amp;lt;br&amp;gt;[Docs](http://docs/for/spinnaker)&amp;lt;/td&amp;gt; &amp;lt;td&amp;gt;Services on K8s&amp;lt;/td&amp;gt; &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt; &amp;lt;/tr&amp;gt; &amp;lt;tr&amp;gt; &amp;lt;td&amp;gt; Batch API&amp;lt;br&amp;gt;[Docs](https://docs/for/batch.html)&amp;lt;br&amp;gt;&amp;lt;/td&amp;gt; &amp;lt;td&amp;gt;Batch Jobs&amp;lt;/td&amp;gt; &amp;lt;td&amp;gt;Not SparkSQL&amp;lt;/td&amp;gt; &amp;lt;/tr&amp;gt; &amp;lt;/table&amp;gt; According to the browsers I&amp;rsquo;ve tried, they are.</description>
    </item>
    <item>
      <title>WIP It Good</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/02/27/</link>
      <pubDate>Thu, 27 Feb 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/02/27/</guid>
      <description>As I talked about in DevOps Book Club, reducing work in progress (WIP) is generally&amp;nbsp;a good thing. It lets you focus, makes things more predictable, reduces time lost to context switches, decreases time to value, and in my case, makes my boss happy. The place where I have some disagreement with the idea of minimizing WIP is around bigger things and things that mostly come under the category of Internal Projects.</description>
    </item>
    <item>
      <title>Scope Of Influence</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/02/26/</link>
      <pubDate>Wed, 26 Feb 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/02/26/</guid>
      <description>Perf season is over (for now). Time to think about your career. And not just think about it, but write it down and share it with your manager. What do you want from your career? That&#39;s a personal decision and there are lots of things to think about. Manager vs. IC? Technology Driven? Product or infrastructure focus? Customer facing? Data science vs PM vs Engineering (or some combination of the 3)?</description>
    </item>
    <item>
      <title>Breaking New Ground</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/02/25/</link>
      <pubDate>Tue, 25 Feb 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/02/25/</guid>
      <description>Ever have to work on a new technology? Something new to you? Maybe building a gRPC client/server and sending the first gRPC message to it. Or deploying your first service on Spinnaker. Takes a long time, doesn&#39;t it? Then you look back and wonder what took so long. You&#39;ve been writing code for a while. You&#39;ve sent messages before. You&#39;ve deployed code. This should be old hat, right? Wrong.&amp;nbsp;&#xA;Think back to high school physics and consider the lowly ice cube.</description>
    </item>
    <item>
      <title>Improve The Daily Work</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/02/24/</link>
      <pubDate>Mon, 24 Feb 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/02/24/</guid>
      <description>Following up on last week&#39;s entry on DevOps, one of the key tenets in The Phoenix Project&amp;nbsp;is&amp;nbsp; that &amp;quot;Improving daily work is more important than doing daily work&amp;quot;. Or maybe you&#39;ve heard it said as &amp;quot;Work smarter, not harder&amp;quot;.&#xA;Whether you call it friction, cycle time, down time, idle time, or wasted time, anything that isn&#39;t time spent thinking about, codifying, and implementing the solution to the business problem you&#39;re trying to solve is time time not adding value.</description>
    </item>
    <item>
      <title>Dev Ops Book Club</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/02/21/</link>
      <pubDate>Fri, 21 Feb 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/02/21/</guid>
      <description>The Phoenix Project, Accelerate&amp;nbsp;The Dev-Ops Handbook, and recently, The Unicorn Project. Two novels and a two how-to books backed by research. Full disclosure, the novels, as novels aren&#39;t that good. Character development is shallow, the plot moves at the speed of the message, and there are more stereotypes than you can shake a stick at.&#xA;However, if you can get past that there&#39;s some really good information in all of those books.</description>
    </item>
    <item>
      <title>Good Fences Make Good Neighbors</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/02/20/</link>
      <pubDate>Thu, 20 Feb 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/02/20/</guid>
      <description>Speaking of bounded contexts, I love contexts, or more precisely, I love the idea of bounded&amp;nbsp;contexts. Boundaries are great tools for simplification. They help you maintain separation of concerns and isolation both inside a module and between modules. And that&#39;s domain driven design. One of the things you&#39;ll find when you dig a little deeper into microservice architecture is that everyone talks about Bounded Contexts and Domain Driven Design. The important thing to remember though is that regardless of the &amp;quot;architecture&amp;quot; you&#39;re building, good architecture is good architecture.</description>
    </item>
    <item>
      <title>The More Things Change</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/02/19/</link>
      <pubDate>Wed, 19 Feb 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/02/19/</guid>
      <description>Last week I wrote about the difference between an engineer and a technician. Another way to think about it is where in the technology stack you operate. 30+ years ago the tech stack was a CPU, some ROM, some RAM, and maybe&amp;nbsp;a persistent storage device. And that was enough to go to the moon. Today you can find that amount of processing and storage in the wall charger for your phone.</description>
    </item>
    <item>
      <title>Rightsizing</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/02/18/</link>
      <pubDate>Tue, 18 Feb 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/02/18/</guid>
      <description>How big is too big? How small is too small? How do you decide? What criteria goes into the decision? A good place to start thinking about this is the Unix Philosophy. Small and simple. Composable. Do one thing and do it well.&#xA;And you can apply it at just about any level you want. Functions should be small and single purpose. It would be odd to see a function called `HandleFile(.</description>
    </item>
    <item>
      <title>FI/RI, Flag, Merge, Rebase, Trunk</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/02/14/</link>
      <pubDate>Fri, 14 Feb 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/02/14/</guid>
      <description>How do you develop a feature? Do you go off into your own little world (feature branch), develop for a few weeks/months, then spend another week dealing with merge issues and releasing your shiny new feature on the world fully formed and integrated? Or maybe after weeks of work you just rebase, handling the text conflicts relatively&amp;nbsp;easily, but then dealing with hidden logic changes for a week. Or you might have tried to just live in master (trunk) and make small, innocuous changes all along until somehow there&#39;s enough there there for users to notice and ever so slowly becomes a full feature?</description>
    </item>
    <item>
      <title>2038 == 2000</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/02/13/</link>
      <pubDate>Thu, 13 Feb 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/02/13/</guid>
      <description>How many of you remember the Y2K&amp;nbsp;problem? How many of you had to fix your way through it? For those that weren&#39;t involved, the Y2K bug was the result of an optimization. It went something like this, circa 1970:&#xA;Dev 1: Our database is getting too big. We need to save some space.&#xA;Dev 2: Ok. Let&#39;s not store redundant data.&#xA;Dev 3: Hey, Look. All of the years stored in our database start with 19.</description>
    </item>
    <item>
      <title>Architecture vs Design</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/02/12/</link>
      <pubDate>Wed, 12 Feb 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/02/12/</guid>
      <description>Here&#39;s a tough one. What&#39;s the difference between software architecture and software design? Both are obviously about software. Both talk about how things fit together. Both have patterns and best practices. Can you have one without the other? Can you have good architecture and bad design at the same time? What about vice-versa?&#xA;I think the difference between the two is about the difference in scope. I think a lot of things that seem similar, but aren&#39;t, are different because of scope.</description>
    </item>
    <item>
      <title>Engineer vs Technician</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/02/11/</link>
      <pubDate>Tue, 11 Feb 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/02/11/</guid>
      <description>I&#39;ve been doing campus interviews for tech companies for a long time now. Long enough that it&#39;s been 10+ years since I told a candidate that I got my BS in 1988 and the response was &amp;quot;I was born&amp;nbsp;in 1988.&amp;quot; In that time I&#39;ve done 100&#39;s of interviews at dozens of schools. And one of the things I quickly learned is that while there are lots of schools and cultures and styles, not everyone who learns to code and looks for a job as a programmer is a software engineer.</description>
    </item>
    <item>
      <title>Let It Crash</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/02/10/</link>
      <pubDate>Mon, 10 Feb 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/02/10/</guid>
      <description>This is the philosophy of Erlang. Only do the right thing, as specified in the requirements. If you can&#39;t do that, fail. Don&#39;t try to make it better. Don&#39;t try to hide it. Don&#39;t pretend it didn&#39;t happen. Just fail. And let something else deal with the problem. Something with more scope/visibility/understanding of what&#39;s going on. And that&#39;s not a bad idea. So maybe we should just let it crash.</description>
    </item>
    <item>
      <title>Innovative Data Transfer</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/02/07/</link>
      <pubDate>Fri, 07 Feb 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/02/07/</guid>
      <description>While we&#39;re on the subject of moving things over the interwebs, it&#39;s not just copper wires or fiber that can be the backbone of the internet. Have you ever heard of IPoAC? There&#39;s IETF RFC 1149, A Standard for the Transmission of IP Datagrams on Avian Carriers. And if that&#39;s not good enough there&#39;s also IETF RFC 2549, IP over Avian Carriers with Quality of Service, so you can ensure you get enough bandwidth for your VOIP data.</description>
    </item>
    <item>
      <title>GeoStatisticians vs Default Values</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/02/06/</link>
      <pubDate>Thu, 06 Feb 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/02/06/</guid>
      <description>Statisticians love numbers. They love patterns. They find patterns everywhere. Add in a healthy understanding of GIS and/or an ArcGIS license and you never know what they&#39;ll find.&#xA;Consider the case of the 500 mile email. Imagine you&#39;re the part-time admin of the email system for a university and you get a call from a department head letting you know that they haven&#39;t been able to send email more than 500 miles away for a few days.</description>
    </item>
    <item>
      <title>Owning Your Comments</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/02/05/</link>
      <pubDate>Wed, 05 Feb 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/02/05/</guid>
      <description>&amp;lt;soapbox&amp;gt;&#xA;I&#39;ve been providing feedback on documents (RFCs, RFPs, Incident Reports, Proposals, Code Reviews/PRs, etc) for a long time. I&#39;ve been doing it so long that I remember doing it with notes in the margin and sticky notes attached to the relevant pages. For the last 10+ years, of course, the comments have been in MS Word/Google Docs and Codeflow/Phab/GitHub. Generally, there&#39;s no question who owns the document being reviewed. Who owns those comments however, is less clear.</description>
    </item>
    <item>
      <title>Managing Your Inbox</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/02/04/</link>
      <pubDate>Tue, 04 Feb 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/02/04/</guid>
      <description>Remember Inbox Zero? The idea that to keep your sanity and maximize productivity you should keep your inbox empty. Basically, treat your email inbox as a task list, and make sure that by the end of every day you&#39;ve dealt with all of the items. Now this didn&#39;t mean everything was done, just that you&#39;d dispositioned it. There were 5 basic options, delegate, delete, defer, do, or respond. Regardless of which one you chose, you didn&#39;t need to worry about that email (at least for a while).</description>
    </item>
    <item>
      <title>From BeyondCorp to BeyondProd</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/02/03/</link>
      <pubDate>Mon, 03 Feb 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/02/03/</guid>
      <description>Like what they do and stand for or not, there&#39;s little question that Google has a very large presence and impact on the technology world. From defining a language (Golang), a build system (Bazel), a container management system (Kubernetes), and a database (Bigtable) to an entire service mesh to tie them together (Istio), a lot of what is used is based on what Google has done and is doing. And it&#39;s not just the technology itself, it&#39;s how those technology pieces get put together.</description>
    </item>
    <item>
      <title>Technical Debt And Inflation</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/01/31/</link>
      <pubDate>Fri, 31 Jan 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/01/31/</guid>
      <description>I&#39;ve talked before about technical debt, and as I&#39;ve noted, I think it&#39;s a really good way to think about and explain to others the fallacy of a simple, linear tradeoff inside the quality, feature set, and ship date triangle. You can usually trade between feature set and ship date and think of it as an opportunity cost. At any given moment you have a certain amount of &amp;quot;developer capital&amp;quot; (capacity) available.</description>
    </item>
    <item>
      <title>Panzer Is NOT German For Tank</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/01/30/</link>
      <pubDate>Thu, 30 Jan 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/01/30/</guid>
      <description>Or at least it wasn&#39;t originally. When I was working on Combat Flight Sim 2 we released 5 fully localized versions. Not just English, but FIGS (French, Italian, German, and Spanish). Since it was Microsoft, the process of localization was well defined. We did the easy things like using the correct locale for dates and numbers, and all of the UI and in-game text were resource based. We had 3rd party vendors to provide the resources and people trained in testing such things.</description>
    </item>
    <item>
      <title>Quality Is Job #1</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/01/29/</link>
      <pubDate>Wed, 29 Jan 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/01/29/</guid>
      <description>Ford may have stopped using that tag-line over 20 years ago, but it&amp;rsquo;s still relevant. Quality is more than building something that usually works or &amp;lsquo;meets requirements&amp;rsquo;. It&amp;rsquo;s more than that. It&amp;rsquo;s something that not only works when things are perfect, but degrades gracefully and in a controlled manner when things aren&amp;rsquo;t. It&amp;rsquo;s not just done according to spec, it&amp;rsquo;s something the user thinks is done. It&amp;rsquo;s something that provides more value than cost.</description>
    </item>
    <item>
      <title>Mini-Maxing Your Java</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/01/28/</link>
      <pubDate>Tue, 28 Jan 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/01/28/</guid>
      <description>&amp;quot;It is by caffeine alone I set my mind in motion.&#xA;&amp;nbsp; It is by the beans of Java that thoughts acquire speed,&#xA;&amp;nbsp; the hands acquire shakes, the shakes become a warning.&#xA;&amp;nbsp; It is by caffeine alone I set my mind in motion.&amp;quot;&#xA;&amp;nbsp; &amp;nbsp; - The Programmer&#39;s Mantra&#xA;I first ran across that line in the mid 90s, and to the best of my sleuthing, it was pretty new then.</description>
    </item>
    <item>
      <title>Shift-Left Is Silly</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/01/27/</link>
      <pubDate>Mon, 27 Jan 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/01/27/</guid>
      <description>Ok, the idea isn&#39;t silly, but&amp;hellip;&#xA;When I started in this business it was developers, developers, developers and the ubiquitous Ballmer Monkey Dance (I was there for that). Write some code, throw it over to the testers, ship it over their objections, and then release updates. Maybe there was a PM (Program Manager) in there to mention the customer. Then came agile. We renamed our software test engineers (STE) to software development engineers in test (SDET), asked them to do some automation, called the PM a scrum master, then shipped the code.</description>
    </item>
    <item>
      <title>The Wisdom Of James Mickens</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/01/24/</link>
      <pubDate>Fri, 24 Jan 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/01/24/</guid>
      <description>Ex-Microsoft, Harvard prof, Distributed Systems Guy, Philosopher? James has been in the business of computer science and thinking about computer science for a long time. Besides doing the work he&#39;s been writing about the work. Whether it&#39;s about the life of pointer math coding systems programmer (The Night Watch) or protecting yourself from the Mossad (This World of Ours) or the dream of the web (To Wash It All Away). he gives cynical, humorous, and honest insights into some of the things we deal with every day.</description>
    </item>
    <item>
      <title>Hofstadter&#39;s Law</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/01/23/</link>
      <pubDate>Thu, 23 Jan 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/01/23/</guid>
      <description>&amp;quot;Hofstadter&#39;s Law: It always takes longer than you expect, even when you take into account Hofstadter&#39;s Law&amp;quot;&#xA;Let&#39;s be honest. Estimation is hard. It doesn&#39;t matter if you&#39;re talking about digging a ditch, building a house, doing year end perf feedback, or planning a sprint, let alone a whole software project. We estimate and we get it wrong, over and over again. There are lots of good reasons for it. From rocks, roots, and pipes where you want the ditch to shifting software requirements, you don&#39;t know what you don&#39;t know until you know it.</description>
    </item>
    <item>
      <title>Surprise And Delight</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/01/22/</link>
      <pubDate>Wed, 22 Jan 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/01/22/</guid>
      <description>You read about how you should always surprise and delight your customer, but really, you just want them then be delighted. And they really shouldn&#39;t be surprised to be delighted. An unexpected new feature they like is OK, but really indicates a failure to properly market the new feature and create demand. The flip side of surprise is when your customer expects something to work and it doesn&#39;t.&#xA;There are lots of ways that can happen.</description>
    </item>
    <item>
      <title>Project Euler</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/01/21/</link>
      <pubDate>Tue, 21 Jan 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/01/21/</guid>
      <description>One of the nice(?) things about being a developer is that there&#39;s always something new to learn. It could be a design pattern, it could be a framework or library, or it could be a whole new language. For all of those, I find the best way to really&amp;nbsp;learn is by doing. The problem with that is you need something to do. It could be a problem from work, it could be part of your hobby, or it could be something that came up as part of daily life (that&#39;s where my favorite interview question came from).</description>
    </item>
    <item>
      <title>Debugging</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/01/17/</link>
      <pubDate>Fri, 17 Jan 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/01/17/</guid>
      <description>It&#39;s always the little things. Ran into a problem yesterday with the opus&amp;nbsp;tool and pushing to the WBU2 docker registry. Docker is a wonderful thing, and we&#39;ve made it scale to Terabyte registries serving data to 1000&#39;s of nodes simultaneously, but it has its warts. Crossing the CORP/PROD boundary and http/https are a couple of them. On OSX you have the added bonus of docker-machine, so there are lots of moving parts.</description>
    </item>
    <item>
      <title>Always Learning</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/01/16/</link>
      <pubDate>Thu, 16 Jan 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/01/16/</guid>
      <description>Things you know, things you know don&#39;t know, things you don&#39;t know you don&#39;t know, and things you know that just ain&#39;t so. 4 categories of information. You know the first, and I&#39;ve talked about the 4th. This is about the 2nd and 3rd. Whether it&#39;s starting a new job, joining a new team, getting assigned a bug in code you didn&#39;t write or something else, we&#39;ve all been in the situation where we know enough about the situation to know that we aren&#39;t experts in it.</description>
    </item>
    <item>
      <title>Naming Things</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/01/15/</link>
      <pubDate>Wed, 15 Jan 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/01/15/</guid>
      <description>There are 2 hard problems in computer science, cache invalidation, naming things, and off-by-one errors. I&#39;m going to talk about the middle one.&#xA;Names are important. At the simplest, they are identifiers that are (hopefully) easy to remember. But they are more than that. They set context. They inform metaphors. They can guide you in the right direction. Good names also respect and help manage scope.&#xA;Scope of influence is a good place to start with naming.</description>
    </item>
    <item>
      <title>Compatibility Mode</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/01/14/</link>
      <pubDate>Tue, 14 Jan 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/01/14/</guid>
      <description>Have you ever wondered what Windows Compatibility Mode&amp;nbsp;is for? It&#39;s because APIs are forever. As new versions of the Windows OS came out they needed to handle the old APIs, bugs and all. So when Microsoft fixed a bug in a later version of Windows and broke a lot of 3rd party software they added a compatibility mode that lets you rely on that bug. Kind of a neat hack, but not a situation you want to get yourself in to.</description>
    </item>
    <item>
      <title>Blameless Post-Incident-Review</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/01/08/</link>
      <pubDate>Wed, 08 Jan 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/01/08/</guid>
      <description>I&#39;ve been doing the software thing for 30+ years, but I come out of the Mechanical/Aerospace Engineering world. Man rated, safety of flight discussions. Long product cycles. Lots of physical prototypes, bench test models, and iron birds, up to and including destructive testing to figure out exactly&amp;nbsp;where the limits are. Then flying models and test pilots to figure out where the edge of the envelope is.&#xA;And still, sometimes things go wrong.</description>
    </item>
    <item>
      <title>Counting From Zero</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/01/07/</link>
      <pubDate>Tue, 07 Jan 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/01/07/</guid>
      <description>Whole numbers, counting numbers, natural numbers. Which of those sets has the number 0 in it? You&#39;d think mathematics would be precise, but naming things is hard. Depending on who you talk to, the natural numbers include 0, or they don&#39;t. It depends.&#xA;What about array indexes? They&#39;re zero based, right? Not exactly. Yes, the C family, Lisp, anything JVM based, ECMAScript, Go, and now Rust are 0 based. Other well known languages such as FORTRAN, COBOL, R, and Matlab are 1 based.</description>
    </item>
    <item>
      <title>APIs Are For Life</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/01/06/</link>
      <pubDate>Mon, 06 Jan 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/01/06/</guid>
      <description>APIs do lots of things. One of the most important things is that they make the work you&#39;ve been doing available to others. It doesn&#39;t matter if your API is HTTP, gRPC, C++, Python, a string of characters, a bunch of 1&#39;s and 0&#39;s stored in some kind of persistent store, or something else entirely. Without an API it&#39;s unusable, locked away where no-one can get at it and you&#39;ve wasted your time.</description>
    </item>
    <item>
      <title>Random Is Hard</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/01/03/</link>
      <pubDate>Fri, 03 Jan 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/01/03/</guid>
      <description>Not only are people bad at understanding random events, seeing patterns where they don&#39;t exist and not expecting things that they should, we (and the computers we use) are bad at generating&amp;nbsp;random things. The best a computer can do is a Psuedo-random number and then calculate the next one from there. While people have done a good job of making sure the overall distribution of random numbers from these calculations are flat, we know, from the word calculation&amp;nbsp;in that description, that given the same input you will get the same output.</description>
    </item>
    <item>
      <title>The Paper Of Record</title>
      <link>https://friendgineers.rosenshein.org/posts/2020/01/02/</link>
      <pubDate>Thu, 02 Jan 2020 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2020/01/02/</guid>
      <description>From today&#39;s everything old is new again files, Blockchains and The Gray Lady.&#xA;While the most widely known usage of blockchains today is crypto-currency, all blockchains really are is an immutable, distributed, verifiable transaction log that lets you verify that not only is something what it says it is, it hasn&#39;t changed from the original.&amp;nbsp;&#xA;Bitcoin has been around for almost 11 years, but what if I told you that almost 15 years earlier a company called Surety started one of (if not the) first public blockchains and used notices in the NYTs classified section as the public, distributed ledger for their hashes?</description>
    </item>
    <item>
      <title>The Year In Review</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/12/31/</link>
      <pubDate>Tue, 31 Dec 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/12/31/</guid>
      <description>Everyone else does these, so why shouldn&#39;t I? Here are some of my favorite postings from this year. Enjoy and see you all next year.&#xA;Worse is Better&#xA;Won&#39;t you be my Neighbor&#xA;Asking good questions&#xA;Platforms&#xA;One on One Meetings&#xA;Silos&#xA;Hello vs NoHello&#xA;PM is more than Provider of Meals&#xA;You are not paid to write code</description>
    </item>
    <item>
      <title>Programming In The Dark</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/12/30/</link>
      <pubDate>Mon, 30 Dec 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/12/30/</guid>
      <description>We all know about serverless programming in general, and AWS Lambda in particular, but have you ever heard of Dark?&amp;nbsp;&amp;nbsp;Dark is a holistic programming language, editor, and backend all in one. It sounds pretty intriguing. Everything is boiled down to http endpoints, datastores, background workers and scheduled jobs. Everything else is handled by the backend. It autoscales. it&#39;s highly available. Deploys in 50ms. Built in version control. Built in feature flags.</description>
    </item>
    <item>
      <title>Lessons From Ancient Rome</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/12/27/</link>
      <pubDate>Fri, 27 Dec 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/12/27/</guid>
      <description>A few years ago when Uber did the first Harvard Business School classes one of them was called Leadership Lessons From Ancient Rome. The pre-readings were a bit dense, and since they were direct translations from the original latin they seemed a but harsh to our way of thinking. When the class was done this year the reading weren&#39;t as hard to get through, but the intent was the same.</description>
    </item>
    <item>
      <title>Failure Modes</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/12/25/</link>
      <pubDate>Wed, 25 Dec 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/12/25/</guid>
      <description>How does your system fail? What are the impacts of the most common/likely modes of failure? What are the workarounds? Does it fail-safe? Does it Fail-Degraded?&#xA;Consider the lowly moving walkway. The Pittsburgh airport has a bunch of them. They just sit there, going around and around. They make your life easier. But sometimes they fail. They can fail in multiple different ways, but the most common is to simply stop moving.</description>
    </item>
    <item>
      <title>Wall Of Perl</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/12/24/</link>
      <pubDate>Tue, 24 Dec 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/12/24/</guid>
      <description>Back in my Flight Simulator days I ran the build system. The build system supported about 15 developers, 20 testers, and 30 artists. We did daily builds and internal releases of code and content. No check-in builds, no automated unit tests. Code builds were easy. Fire up MSVC via command line with options and wait. If it failed send email to lots of people.&#xA;Content builds were a little different. We used 3DStudio Max for models and custom plugins for model export/processing.</description>
    </item>
    <item>
      <title>On Testing</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/12/23/</link>
      <pubDate>Mon, 23 Dec 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/12/23/</guid>
      <description>My title is Senior Software Engineer II. I work on Infrastructure. No mention of customers or testing in there, but I&#39;m a tester. I write and execute tests to make sure my customers always get what they expect, and if something goes wrong *I* know before they do. It wasn&#39;t always that way.&#xA;Back in the day, there were different roles, and they kept to themselves. PMs talked to business leaders and customers and published the requirements.</description>
    </item>
    <item>
      <title>That&#39;s The British Spelling Of ...</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/12/20/</link>
      <pubDate>Fri, 20 Dec 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/12/20/</guid>
      <description>There are lots of ways to delight your users. Do the right thing. Do what they expect you to do. Figure out what they want even when they don&#39;t know or spell it wrong. You&#39;re probably familiar with the way search engines will take your search string, fix a misspelling, then run the search and make sure that&#39;s what you mean. And they do that for more than simple transpositions like teh -&amp;gt; the or nad -&amp;gt; and.</description>
    </item>
    <item>
      <title>Distributed System Superpowers</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/12/19/</link>
      <pubDate>Thu, 19 Dec 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/12/19/</guid>
      <description>We all work on distributed systems. We all like superpowers. If you were Distributed Systems Man&amp;nbsp;what superpowers would you want? As a user of distributed systems I&#39;d want, in no particular order:&#xA;Idempotency: I want to be able to send the same message multiple times until I get a response and not worry about partial application. If I have to set something and get a connection error then have to check to see if it was set, figure out the new set command, and try again I will get it wrong.</description>
    </item>
    <item>
      <title>How Do I Use This Thing?</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/12/18/</link>
      <pubDate>Wed, 18 Dec 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/12/18/</guid>
      <description>Speaking of APIs, how do you know the API (or UI) you&#39;ve lovingly crafted solves a user&#39;s problem? I assume you&#39;ve done your homework and talked to your customers, observed what they&#39;re doing, and understand their domain reasonably well, and what you&#39;ve built works, but that&#39;s not enough. Remember, customers (users) want solutions (to their problems), not features and cool technology. So how do you know if you&#39;re actually solving their problems?</description>
    </item>
    <item>
      <title>I Need A REST</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/12/17/</link>
      <pubDate>Tue, 17 Dec 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/12/17/</guid>
      <description>REST is representational state transfer, and is in truth transport agnostic, but when people talk about RESTful APIs they&#39;re usually talking about REST over HTTP. And when you&#39;re talking about HTTP and REST, you need to think about your `goesintos` and `goesoutofs`, your verbs and your bodies. HTTP 1.1 only defines 8 verbs, and which one to use for a given method is pretty well defined. When you&#39;re defining your API think about safety and idempotence.</description>
    </item>
    <item>
      <title>What&#39;s Your Charter</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/12/16/</link>
      <pubDate>Mon, 16 Dec 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/12/16/</guid>
      <description>I&#39;ve talked about mission and vision statements, but I haven&#39;t talked about charters. You&#39;ll hear charters talked about in two contexts, team and project. Personally, I don&#39;t believe in team (or org in general) charters. Those are mission and vision statements.&#xA;To me, a charter has an end goal (just like a vision), but when the end goal is reached the project is over and work stops. Yes, a project can evolve and where you end up isn&#39;t always where you thought you were going, but there is an expected end.</description>
    </item>
    <item>
      <title>I&#39;ll Tell You Later</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/12/13/</link>
      <pubDate>Fri, 13 Dec 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/12/13/</guid>
      <description>In the spirit of YAGNI, sometimes it&amp;rsquo;s better to put off a decision until a later date. Management books tell you a sub-optimal decision now is better than no decision. And that&amp;rsquo;s often the case, especially when there are lots of people sitting around doing nothing while they wait for a decision. Sometimes you do need to choose, and in those cases making a choice is better than not.&#xA;Sometimes, the reason you need to make a choice&amp;nbsp;now&amp;nbsp;is because of time constraints.</description>
    </item>
    <item>
      <title>DSLs and You</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/12/12/</link>
      <pubDate>Thu, 12 Dec 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/12/12/</guid>
      <description>Domain Specific Languages are a thing. They let you express what you want in terms relevant to the problem at hand, and can hide a lot of complexity. Consider the lowly SQL&amp;nbsp;select&amp;nbsp;statement. You get to specify a few parameters and the system does yeoman&amp;rsquo;s work to actually figure out how to optimally read the data. CSS is also a DSL. Our team wrote and used Turtl to process JSON files and it makes templating and data extraction a lot easier.</description>
    </item>
    <item>
      <title>You Are Not Paid To Write Code</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/12/11/</link>
      <pubDate>Wed, 11 Dec 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/12/11/</guid>
      <description>How&amp;rsquo;s that for an attention grabber? If we&amp;rsquo;re not here to write code (or design hardware, or manage projects/products, or whatever it is you spend your time doing), then why are we where.&#xA;We&amp;rsquo;re here to increase business value by making cars that drive more than themselves. Very often that means writing code, or designing or managing, but those are the means to an end, not the end in itself.</description>
    </item>
    <item>
      <title>The Maintainer</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/12/10/</link>
      <pubDate>Tue, 10 Dec 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/12/10/</guid>
      <description>Last week I talked about some principles for developers.&amp;nbsp;Today I want to drill down into the&amp;nbsp;Code For the Maintainer&amp;nbsp;idea. As developers we really like to work on green-field projects. There&amp;rsquo;s room to explore and innovate, and you don&amp;rsquo;t need to worry about pesky things like backward compatibility and existing user expectations. However, most of the work we do isn&amp;rsquo;t green-field. We work inside existing systems, adding functionality and fixing bugs. We extend them into new operational domains.</description>
    </item>
    <item>
      <title>Kilobytes, Megabytes, Gigabytes and Copy-Pasta</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/12/09/</link>
      <pubDate>Mon, 09 Dec 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/12/09/</guid>
      <description>We&amp;rsquo;ve all looked online for solutions to problems, and that&amp;rsquo;s a good thing. Learning from others gives you time to focus on what&amp;rsquo;s important for you and your team, adding value for the company instead of reinventing the wheel. Whether it&amp;rsquo;s personal blogs, public Stack Overflow, internal Stack Overflow, or a generic Google search, it&amp;rsquo;s easy to find code snippets that purport to solving your problem, or at least something not entirely unlike your problem.</description>
    </item>
    <item>
      <title>Cautionary Tales</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/12/06/</link>
      <pubDate>Fri, 06 Dec 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/12/06/</guid>
      <description>In the face of ballooning system requirements or the need to future proof your code, you may be tempted to add another layer of indirection. All problems in computer science can be solved this way, right? Not so fast. Overly-complex designs can be difficult to comprehend and maintain, and when they go wrong, they can go really wrong. A wonderful new podcast from Tim Harford highlights the risks--particularly for safety systems like nuclear power plants--of layering on complexity without enough thought.</description>
    </item>
    <item>
      <title>Kissenger, Schmidt, and Huttenlocher, and AI</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/12/05/</link>
      <pubDate>Thu, 05 Dec 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/12/05/</guid>
      <description>What do a former Secretary of State, the ex CEO of Google, and the current Dean of the MIT College of Computing have in common? Not their age, not their education, and certainly not their jobs. But they all, through direct actions and through the people and companies they advised, led, and taught, have had big impacts on your lives and the world in general. And what do they have in common around AI?</description>
    </item>
    <item>
      <title>Engineering Principles</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/12/04/</link>
      <pubDate>Wed, 04 Dec 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/12/04/</guid>
      <description>Here&#39;s a few of my favorites. BSR, CFtM, DRY, KISS, PLA, SOC, YAGNI&#xA;According to wikipedia, a principle is a&amp;nbsp;proposition or value that is a guide for behavior or evaluation. Following your principles is a good thing, both at work and at outside work. They help you make decisions and figure out what to do. Good principles help you make good designs. Good designs lead to good products and good outcomes.</description>
    </item>
    <item>
      <title>PM Is More Than Provider Of Meals</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/12/03/</link>
      <pubDate>Tue, 03 Dec 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/12/03/</guid>
      <description>I&#39;ve been working with PMs of various breeds at multiple companies for years now. Many years ago at Microsoft there was a class called &amp;quot;PM is more than provider of meals&amp;quot;. Yes, at MS the PM was often worrying about team morale and making sure we were fed and clothed (lots of t-shirts), but that&#39;s not really why they existed. They were the voice of the customer (whoever that was, internal or external), worked with partner teams, vendors, and generally filled all the gaps that no-one else was filling.</description>
    </item>
    <item>
      <title>Prediction</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/12/02/</link>
      <pubDate>Mon, 02 Dec 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/12/02/</guid>
      <description>As engineers we make lots of predictions. Some of them are about our what customers/users want and need, some are about how the things we build will interact, and some are about ourselves, what we are going to do and when we are going to do them. If you were to order our predictions by how accurate they are, that&#39;s probably the order to put them in. Which is kind of odd.</description>
    </item>
    <item>
      <title>Makefiles</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/11/24/</link>
      <pubDate>Sun, 24 Nov 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/11/24/</guid>
      <description>Relevant or not? What&#39;s the point of a Makefile in a bazel world?&#xA;bazel is a turing complete, extensible build system, so if your core build is done with bazel is there any reason to use anything else? In theory, no. You can do anything with a collection of bazel rules and targets. In practice though, bazel isn&#39;t the simplest of systems to use, and the best tool around to understand what bazel is doing is bazel query, so there&#39;s a bit of a chicken and egg problem there.</description>
    </item>
    <item>
      <title>Imposter Syndrome, Dunning–Kruger, or Just Do It</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/11/22/</link>
      <pubDate>Fri, 22 Nov 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/11/22/</guid>
      <description>There are new things for us to learn all the time. Some of them are just new coats of paint on the same old thing, some of them build on existing tech, some of them are really new. Sometimes you end up in working on something tangentially related to your area of expertise that&#39;s new to you. How do you approach it? Is it a problem or an opportunity? Generally, I choose to see them as opportunities.</description>
    </item>
    <item>
      <title>Hello vs. NoHello</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/11/21/</link>
      <pubDate>Thu, 21 Nov 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/11/21/</guid>
      <description>Hello or NoHello? It&#39;s a thing. Some people want the social lubricant, some don&#39;t. The first thing to remember is that Slack (or any other asynchronous communications method) is not a face to face, real-time, discussion, so the rules/norms/best practices are different. It&#39;s also much more likely to be remote/cross time zone :)&#xA;The two biggest things to remember in chat are&#xA;1) It&#39;s very hard to communicate emotion/expression/intent, which means the failure mode of &amp;quot;clever&amp;quot; is &amp;quot;jerk&amp;quot;</description>
    </item>
    <item>
      <title>Asking For Help</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/11/20/</link>
      <pubDate>Wed, 20 Nov 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/11/20/</guid>
      <description>I love helping our customers. As a person on the infra team I get to see my customers every day and I get to see the results of making their lives easier, helping them build self driving cars that drive more than themselves. Asking for help can be a good thing. You save time, you get to learn something, Knowledge is shared. If you do it right you also make it easier for the next person who runs into the same problem.</description>
    </item>
    <item>
      <title>Talking To Customers</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/11/19/</link>
      <pubDate>Tue, 19 Nov 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/11/19/</guid>
      <description>How do you talk across functions? When engineers talk to other engineers, even across disciplines, there&#39;s usually at some shared language/terminology. When you start talking cross-functional, that doesn&#39;t always hold true. In fact, many of the assumptions aren&#39;t shared, and that can lead to huge misunderstandings. For example, you would expect your customer to know what they want.&#xA;And they do. They want it to not suck. They want it to be easier.</description>
    </item>
    <item>
      <title>The Juice Shop</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/11/18/</link>
      <pubDate>Mon, 18 Nov 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/11/18/</guid>
      <description>I didn&#39;t get this posted during security awareness month, but it&#39;s timely nonetheless. Security is everyone&#39;s business, whether you&#39;re building a robot, a two sided marketplace, a shared infrastructure, or an online juice shop. Lots of things to keep in mind, and it&#39;s more than just &amp;quot;Who has access to what data?&amp;quot;. What and how you deny access to something can tell an attacker a lot about your system and the protected data.</description>
    </item>
    <item>
      <title>What Are You Reading?</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/11/11/</link>
      <pubDate>Mon, 11 Nov 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/11/11/</guid>
      <description>There are lots of great books on being a developer, and not just books about how to code (although they are kind of important). Algorithms, design patterns, compilers, all important. But there are also books that aren&#39;t directly about writing code. Books like The Cathedral and the Bazaar, In The Beginning Was The Command Line, Debugging the Development Process, or maybe, Zen And The Art Of Motorcycle Maintenance. Books that talk about the bigger picture.</description>
    </item>
    <item>
      <title>Options</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/11/08/</link>
      <pubDate>Fri, 08 Nov 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/11/08/</guid>
      <description>We&#39;ve got lots of them. Almost always there&#39;s not one right answer for a given set of constraints, but there are often wrong ones. One of our jobs as engineers is to balance those constraints and make the right trade-offs for now and what we know about the future. We also need to keep in mind that the constraints can/will change over time, and the &amp;quot;right&amp;quot; answer might shift.&#xA;Consider&amp;nbsp;joining two text files and doing some simple analysis on the results.</description>
    </item>
    <item>
      <title>Assumptions</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/11/07/</link>
      <pubDate>Thu, 07 Nov 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/11/07/</guid>
      <description>You know what happens when you assume. That happens everywhere. Especially with computers. They&#39;re logical. They do&amp;nbsp;exactly&amp;nbsp;what you tell them, even if that&#39;s not what you want. And of course, they&#39;re all the same. Or maybe they&#39;re not. Look at this from the 90s. How many times have you heard the phrase &amp;quot;It works on my machine.&amp;quot;? Of course it does. You built a bespoke system in an environment and it works.</description>
    </item>
    <item>
      <title>Silos</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/11/06/</link>
      <pubDate>Wed, 06 Nov 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/11/06/</guid>
      <description>They&#39;re not just places to store your grain. Information gets into silos. Processing gets into silos. And we all know that silos are a bad thing, right?&#xA;Duplication of effort. How many configuration management/payment/SWN systems does Uber need anyway? Everyone should be using thrift, and custom thrift over TChannel, not Apache thrift, unless you&#39;re working with gRPC, or over Muttley, or with Yarpc, or maybe even hyperbhan.&#xA;Working at cross purposes.</description>
    </item>
    <item>
      <title>Software As A Service</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/11/05/</link>
      <pubDate>Tue, 05 Nov 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/11/05/</guid>
      <description>I think this says it all.&amp;nbsp;</description>
    </item>
    <item>
      <title>GOLANG Oddities</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/11/04/</link>
      <pubDate>Mon, 04 Nov 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/11/04/</guid>
      <description>Don&#39;t get me wrong, I like using go. It&#39;s clean, the standard library has almost everything I want/need, it&#39;s cross platform, and it&#39;s fast. VSCode, IntelliJ (and flavors), Emacs, and Vim have good support. Tabs vs spaces isn&#39;t a thing (gofmt has the one true answer). There are lots of people around that I can go to and get good answers. But&amp;hellip;&#xA;Golang is opinionated about where things go. GOPATH is king, and woe betide any who think they know better.</description>
    </item>
    <item>
      <title>The Gift Of Feedback</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/10/31/</link>
      <pubDate>Thu, 31 Oct 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/10/31/</guid>
      <description>People keep saying feedback is a gift. And as the recipient of feedback, that&#39;s a good approach to take. If someone goes out of their way to give you feedback you should at least think about it. You certainly had enough of an impact to make the person take the time to provide the feedback, so take the time to consider it. But what do you do if you&#39;re not getting feedback.</description>
    </item>
    <item>
      <title>Language Security</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/10/30/</link>
      <pubDate>Wed, 30 Oct 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/10/30/</guid>
      <description>In the spirit of Security Awareness month and in today&amp;rsquo;s homage to bad research, I present What are the most secure programming languages. There is so much wrong with this doc I don&amp;rsquo;t know where to start. I&amp;rsquo;m sure there are many data scientists here who can quote chapter and verse about the flaws, but there are a couple I want to touch on.&#xA;The first has nothing to do with data science or research, it&amp;rsquo;s the on the editorial/marketing side.</description>
    </item>
    <item>
      <title>Growing</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/10/28/</link>
      <pubDate>Mon, 28 Oct 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/10/28/</guid>
      <description>How do you grow as a developer? How do you get better at your craft? What should you be doing? There are lots of recommendations online, lots of proposed approaches. I think it comes down to a couple of things though. The first is practice. Solve lots of different problems. Not the same thing over and over again.&#xA;One of my old marching band instructors said &amp;quot;Don&#39;t practice until you get it right, practice until you can&#39;t get it wrong.</description>
    </item>
    <item>
      <title>Doc Culture</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/10/25/</link>
      <pubDate>Fri, 25 Oct 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/10/25/</guid>
      <description>Doc Culture I&#39;ve touched on this a couple of times before, but never focused on it. ATG is a large organization. There are lots of people to talk to and lots of channels to talk through. We also have lots of meetings. So many that teams are starting to institute &amp;quot;No Meeting xxxday&amp;quot; so people can focus for extended blocks of time. Uninterrupted time for focus is great. We should have more of it.</description>
    </item>
    <item>
      <title>SLOs, SLIs, SLAs</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/10/21/</link>
      <pubDate>Mon, 21 Oct 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/10/21/</guid>
      <description>Objectives, Indicators, and Agreements. What&amp;rsquo;s the difference, who do they apply to, and why should you care?&#xA;The Objective is the vision you share (with your customers). It&amp;rsquo;s what you want to do. It&amp;rsquo;s how things would look in a (realistic) perfect world.&#xA;The Indicator is how you know what&amp;rsquo;s really going on. How you define your indicators is critical, because if the don&amp;rsquo;t measure and report on your objective your setting yourself (and your customers) up for failure.</description>
    </item>
    <item>
      <title>Open Source</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/10/18/</link>
      <pubDate>Fri, 18 Oct 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/10/18/</guid>
      <description>We all benefit from it. I know I do. The number of open source plugins/add-ons/tools I have had to install to make OSX useable as a developer system is way higher than I think it should be, but there it is. I&#39;ve done a little bit to help out open source projects, from HDFS to Docker to Peloton. Not PRs or commits, but bug reports, beta testing, code contributions that someone else added, but the benefits I&#39;ve getting fro OS tools far outweighs what I&#39;ve put in.</description>
    </item>
    <item>
      <title>One On One Meetings</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/10/17/</link>
      <pubDate>Thu, 17 Oct 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/10/17/</guid>
      <description>What are they? That&#39;s easy. They&#39;re (usually) regularly scheduled 2 person meetings with a manager and direct report. What are they good for? More fundamentally, who are they for? Once you know and internalize the last question answers to any other questions become much clearer, so let&#39;s tackle that part first and be very clear.&#xA;1:1 meetings, whether between a manager and direct report, a skip level, or a meeting with the CEO, belong to, and are for, the subordinate.</description>
    </item>
    <item>
      <title>Old Passwords</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/10/15/</link>
      <pubDate>Tue, 15 Oct 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/10/15/</guid>
      <description>Nothing serious today, just Ken Thompson&#39;s old password. Hopefully he&#39;s changed it by now.</description>
    </item>
    <item>
      <title>Writing It Down</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/10/14/</link>
      <pubDate>Mon, 14 Oct 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/10/14/</guid>
      <description>RFCs are critical. None of us know everything about every system, deeply understand all of the customer use cases, or can anticipate what some other group is working on. An RFC gets your ideas and plans down in a shareable and discussable format. It&#39;s about documenting a specific solution to a problem and gives others insight into what you&#39;re doing, why you&#39;re doing it, and how it might impact them. It lets others use their experience and point of view to help avoid problems in the future.</description>
    </item>
    <item>
      <title>Pattern Matching</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/10/11/</link>
      <pubDate>Fri, 11 Oct 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/10/11/</guid>
      <description>We are pattern matching machines. We love them and we&#39;ll find and match patterns even if they&#39;re not there. From raindrops on a sidewalk to the stock market to assassinations of US Presidents, we project patterns into statistically knowable events and then make predictions. If your take the long view you&#39;ll do OK, but Hari Seldon&#39;s psychohistory? Maybe we&#39;ll get there one day, but today is not that day. The same applies to large, interdependent systems.</description>
    </item>
    <item>
      <title>Lego</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/10/10/</link>
      <pubDate>Thu, 10 Oct 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/10/10/</guid>
      <description>In today&#39;s Lego related ideas, and in honor of tomorrow&#39;s team build of the&amp;nbsp;Imperial Star Destroyer,&amp;nbsp;Systems&amp;nbsp;Thinking at Work and Play. Systems are all around us, and there are lots of educational shows that show them. From &amp;quot;Dirty Jobs&amp;quot; to &amp;quot;The Magic School Bus&amp;quot;, understanding how things are built out of parts and work together is the system mindset. One of my favorite systems, and it has been lo these many years, is the Lego System.</description>
    </item>
    <item>
      <title>In The Beginning Was The Command Line</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/10/07/</link>
      <pubDate>Mon, 07 Oct 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/10/07/</guid>
      <description>Back in the old days the competition for users came down to Operating Systems. OS&#39;s were proprietary walled gardens and everything was done in service of selling the OS. Sun and Solaris owned the Internet (the network is the computer), Microsoft and Windows were going after the desktop (a computer on every desk), and Apple had the creative niche (think differently), and BeOS and NextStep were out there selling themselves as better than everything else, but no-one was buying.</description>
    </item>
    <item>
      <title>Statistics</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/10/04/</link>
      <pubDate>Fri, 04 Oct 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/10/04/</guid>
      <description>Big data is all about statistics, and lots of what we do comes down to statistics. Precision, Recall, MPBE, Code Coverage, SLAs, expected battery life, Texas Hold-em, and more. We look at a large enough sample, do some math (or let a computer do so math that we may or may not be able to follow), pick a threshold, and declare that meeting it is enough. No-one has found a better way.</description>
    </item>
    <item>
      <title>WAT?</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/10/03/</link>
      <pubDate>Thu, 03 Oct 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/10/03/</guid>
      <description>I was working on the Infra dashboard yesterday and had a problem with one of my &amp;lt;script&amp;gt; tags. There&#39;s some bug somewhere that was translating&#xA;&amp;nbsp;&amp;lt;script type=&amp;quot;method&amp;quot;&amp;gt;&#xA;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;if (Math.random() &amp;amp;lt; 0.05) {&#xA;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;document.getElementById(&#39;logo&#39;).src = &#39;/static/other.png&#39;;&#xA;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;}&#xA;&amp;lt;/script&amp;gt;&#xA;to&#xA;&amp;nbsp;&amp;amp;lt;script type=&amp;quot;method&amp;quot;&amp;gt;&#xA;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;if (Math.random() &amp;amp;lt; 0.05) {&#xA;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;document.getElementById(&#39;logo&#39;).src = &#39;/static/other.png&#39;;&#xA;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;}&#xA;&amp;nbsp;&amp;nbsp;&amp;amp;lt;/script&amp;gt; And of course, that didn&#39;t work. Turns out that there&#39;s a parsing bug somewhere and removing the type=&amp;quot;method&amp;quot; from the &amp;lt;script&amp;gt; tag makes it work.</description>
    </item>
    <item>
      <title>Languages</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/10/02/</link>
      <pubDate>Wed, 02 Oct 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/10/02/</guid>
      <description>We&amp;rsquo;re all multilingual. We speak C, C++ (yes, they are different languages, not dialects), Python, Go, Java, Javascript, Matlab, Assembler, and many others with varying fluency. And that&amp;rsquo;s good and proper. Using the right tool at the right time is one of the marks of a craftsperson, just as much as the ability to do quality work with the available tools is. Master craftspeople not only know which tool to pull out of their toolbox, they also stay aware of new tools and methods being developed.</description>
    </item>
    <item>
      <title>Platforms</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/10/01/</link>
      <pubDate>Tue, 01 Oct 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/10/01/</guid>
      <description>For most of my career I&#39;ve been working on platforms, From Flight Simulation to 2/D3D geospatial visualization to infrastructure. One of the keys to building platforms (or for anything really) is customer value. A long time ago a marketing instructor told me that developers build features, but customers buy benefits. Those two are very closely related, but they&#39;re not the same thing. When you&#39;re building a platform they intersect at your API.</description>
    </item>
    <item>
      <title>Kaizen</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/09/27/</link>
      <pubDate>Fri, 27 Sep 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/09/27/</guid>
      <description>I&#39;ve seen people wearing t-shirts have the Kanji for Kaizen on them. If you&#39;re going to wear the shirt you should know what you&#39;re saying. According to the Googles, Kaizen translates to &amp;quot;Improvement&amp;quot;. That&#39;s simple enough, and a worthy goal, but when you connect the term to Toyota it brings in an additional level of meaning, the Toyota Production System, or The Toyota Way. It&#39;s about culture and culture change. It&#39;s about expectations.</description>
    </item>
    <item>
      <title>Monoliths vs Microservices</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/09/26/</link>
      <pubDate>Thu, 26 Sep 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/09/26/</guid>
      <description>MIcroservices are all the rage. Prime is all-in on microservices, moving from RT-API to thousands of microservices (there are more services in the Prime call graph then there are engineers). They&#39;re an answer, but are they the answer? Before you can answer that you have to decide what your goals are, and what the payoff threshold is. At a high level things like separation of concerns, reduced fragility minimizing unintended side effects and reducing developers learning curves are good things.</description>
    </item>
    <item>
      <title>Software Architecture</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/09/25/</link>
      <pubDate>Wed, 25 Sep 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/09/25/</guid>
      <description>What does an architect do anyway?&#xA;What is software architecture.</description>
    </item>
    <item>
      <title>Following The Vision</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/09/24/</link>
      <pubDate>Tue, 24 Sep 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/09/24/</guid>
      <description>On a related note, one of the most important parts of architecture is being able to explain your architecture/design to others so that they can follow the vision when you&#39;re not looking. If you don&#39;t do that you have at best a bottleneck, at worst an architecture that doesn&#39;t match what gets built. There are lots of ways to communicate architecture, and one of the keys is tailoring the content to the intended reader.</description>
    </item>
    <item>
      <title>Architecture is just software design at scale</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/09/23/</link>
      <pubDate>Mon, 23 Sep 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/09/23/</guid>
      <description>If you&#39;re ever interested in a 15 minute speech about why let me know. Happy to spend time over a coffee (or 2 or 5) talking about how the difference between code design and architecture (or different levels for that matter) is just a matter of scale. For a quick overview, here&#39;s Uber&#39;s own Gergely Orosz talking about it.</description>
    </item>
    <item>
      <title>Is It Useful</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/09/20/</link>
      <pubDate>Fri, 20 Sep 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/09/20/</guid>
      <description>Customer Journeys, User Stories, Personas, Use Cases. All different ways of trying to ensure that whatever you are building is actually useful for the customer. Whether you&#39;re putting together an architecture or a team, they&#39;re a good thing to keep in mind.</description>
    </item>
    <item>
      <title>You Get What You Inspect, Not What You Expect</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/09/19/</link>
      <pubDate>Thu, 19 Sep 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/09/19/</guid>
      <description>Metrics are good. You can&#39;t make data driven decisions without good data, but you have to be careful. Sometimes the data you collect and make visible drives behavior. From Dilbert&amp;nbsp;to the Harvard Business Review, think about it.</description>
    </item>
    <item>
      <title>Clean Code</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/09/18/</link>
      <pubDate>Wed, 18 Sep 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/09/18/</guid>
      <description>I can assure you there&#39;s at least one person who will benefit from it,&amp;nbsp;future you. How many times have you looked at a piece of code, cursed the author, then realized you were the one who wrote it? Do something for future you&amp;nbsp;</description>
    </item>
    <item>
      <title>Gosling On Open Source</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/09/17/</link>
      <pubDate>Tue, 17 Sep 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/09/17/</guid>
      <description>History lesson today. James Gosling and Open Source.</description>
    </item>
    <item>
      <title>Strlen Is Surprisingly Hard</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/09/16/</link>
      <pubDate>Mon, 16 Sep 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/09/16/</guid>
      <description>How long is a string? Sounds like a simple question, but It&amp;rsquo;s Not Wrong that &amp;quot;:man-facepalming::skin-tone-3:&amp;quot;.length == 7. It might not be wrong, but is it right? What are you measuring? What&#39;s your contract with the user? What are the expectations?</description>
    </item>
    <item>
      <title>Work/Life Balance</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/09/13/</link>
      <pubDate>Fri, 13 Sep 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/09/13/</guid>
      <description>Here&#39;s an interesting approach</description>
    </item>
    <item>
      <title>Design Paradigms</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/09/12/</link>
      <pubDate>Thu, 12 Sep 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/09/12/</guid>
      <description>We&#39;ve all heard of design patterns. They&#39;re ways of doing things. What about ways of thinking about things?&amp;nbsp;What if there were a taxonomy of them? And what if there are 4 really important ones.</description>
    </item>
    <item>
      <title>Campus Recruiting</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/09/11/</link>
      <pubDate>Wed, 11 Sep 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/09/11/</guid>
      <description>Campus recruiting is a great thing. Finding and hiring the right talent, the right coworkers for the future, is one of the most strategic investments we can make. 30 years after graduation and you can still learn things on campus. Yesterday I ran across this posting from an ECE Professor&amp;nbsp;Martin&#39;s Somewhat Heretical Thoughts for Cornell Engineering Students.</description>
    </item>
    <item>
      <title>Tracing</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/09/10/</link>
      <pubDate>Tue, 10 Sep 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/09/10/</guid>
      <description>Distributed systems and microservices. Seems like a natural fit, but oh the complexity. Emergent behavior, hidden loops, unknown dependencies. How do you get a handle on it? Uber&#39;s own Yuri Shkuro presents Jaeger to handle distributed tracing.</description>
    </item>
    <item>
      <title>Huh?</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/09/09/</link>
      <pubDate>Mon, 09 Sep 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/09/09/</guid>
      <description>Here&#39;s some obscure &amp;quot;C&amp;quot; for you. Some more obscure than others.</description>
    </item>
    <item>
      <title>Refactoring</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/09/06/</link>
      <pubDate>Fri, 06 Sep 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/09/06/</guid>
      <description>A disciplined technique for restructuring an existing body of code. It&#39;s an opportunity we get over and over again. What&#39;s the best way to take advantage of they opportunity?</description>
    </item>
    <item>
      <title>Security</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/09/05/</link>
      <pubDate>Thu, 05 Sep 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/09/05/</guid>
      <description>Today&#39;s topic is security. More specifically security anti-patterns. 6 things to NOT do according to the British National Cyber Security Centre.</description>
    </item>
    <item>
      <title>Unicode</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/09/04/</link>
      <pubDate>Wed, 04 Sep 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/09/04/</guid>
      <description>On the subject of what you know that just ain&#39;t so, text. It ain&#39;t all ASCII anymore. ASCII is almost 60 years old stands for &amp;quot;American Standard Code for Information Interchange&amp;quot;. It&#39;s great for American English, but Unicode is a thing and it&#39;s here to stay. Any time you deal with (or ever hope to deal with) international users you need to speak Unicode. Here&#39;s a quick primer. It&#39;s 15 years old, but AFAIK everything said is still true&amp;nbsp;</description>
    </item>
    <item>
      <title>Knowledge Gaps</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/09/03/</link>
      <pubDate>Tue, 03 Sep 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/09/03/</guid>
      <description>What do we know, what don&#39;t we know, and how to figure it out.</description>
    </item>
    <item>
      <title>Big Data</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/08/30/</link>
      <pubDate>Fri, 30 Aug 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/08/30/</guid>
      <description>We&#39;ve got lots of data, but we&#39;re not the only ones. Think about CERN. The keep gigabytes/sec for 10s of Pb per experiment and they run multiple experiments a year.</description>
    </item>
    <item>
      <title>Meetings</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/08/29/</link>
      <pubDate>Thu, 29 Aug 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/08/29/</guid>
      <description>Meetings. They&#39;re a part of life, and with teams spread across 3 time zones, 5+ buildings and a test track, meetings with at least one person not in the room are common, almost the norm. Some are great, some are terrible, and most are kind of mediocre. Unless you&#39;re that one person who&#39;s remote. In that case great meetings are like unicorns. We&#39;ve heard about them. Some of us have even been in them, but they&#39;re rare, All hope is not lost though.</description>
    </item>
    <item>
      <title>What&#39;s In A Name?</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/08/28/</link>
      <pubDate>Wed, 28 Aug 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/08/28/</guid>
      <description>http://journal.stuffwithstuff.com/2016/06/16/long-names-are-long And that doesn&#39;t even touch the use of acronyms and tribal knowledge.</description>
    </item>
    <item>
      <title>Asking Good Questions</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/08/27/</link>
      <pubDate>Tue, 27 Aug 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/08/27/</guid>
      <description>Here&#39;s a handy&amp;nbsp;checklist for asking coding questions. It&#39;s targeted at StackOverflow and non-realtime questions in general, but the list applies to asking questions directly of someone else as well. The better you understand and can explain your question the more likely you&#39;ll get an answer.</description>
    </item>
    <item>
      <title>SESE Or Not?</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/08/26/</link>
      <pubDate>Mon, 26 Aug 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/08/26/</guid>
      <description>Single Entry Single Exit or not. Here&#39;s two viewpoints.&amp;nbsp;Return Early, Return Often&amp;nbsp;and Are You a Hacker or a Designer?</description>
    </item>
    <item>
      <title>Lego Design Sprints</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/08/23/</link>
      <pubDate>Fri, 23 Aug 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/08/23/</guid>
      <description>I have no idea if this is a good idea or not, but LEGO.</description>
    </item>
    <item>
      <title>Things You Should Never Do</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/08/21/</link>
      <pubDate>Wed, 21 Aug 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/08/21/</guid>
      <description>An oldie but a goody. I sure wish there was a part 2, but at least we&#39;ve got part 1.</description>
    </item>
    <item>
      <title>Lint</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/08/19/</link>
      <pubDate>Mon, 19 Aug 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/08/19/</guid>
      <description>Linting has&amp;nbsp;come a long way. I first used PC-Lint back when it was new and it was valuable back then. Today linters do a lot more than look for strangely placed ,s that change the meaning of a statement. Today, a list of common issues found/reported by Intel&#39;s PVS-Studio.</description>
    </item>
    <item>
      <title>Python Vs. Go Vs. Rust</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/08/16/</link>
      <pubDate>Fri, 16 Aug 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/08/16/</guid>
      <description>Python vs. Go vs. Rust. https://www.nicolas-hahn.com/python/go/rust/programming/2019/07/01/program-in-python-go-rust/ Discuss&amp;nbsp;</description>
    </item>
    <item>
      <title>Code Reviews</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/08/14/</link>
      <pubDate>Wed, 14 Aug 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/08/14/</guid>
      <description>A big part of a developer&#39;s life. They can be a great way to get a broader perspective on the code you&#39;ve written and suss out hidden gotcha&#39;s others know about. They can also slow you down. Multiple iterations, arguments over style vs substance, or just waiting for someone to take a look. There&#39;s lots of anecdotal evidence (user dreams/nightmares) on the topic, and even some more academic publications. Starting from the idea that code reviews are worthwhile and we want to make the most of them, how do we avoid some of the perils?</description>
    </item>
    <item>
      <title>Building And Scaling A High Performing Culture</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/08/13/</link>
      <pubDate>Tue, 13 Aug 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/08/13/</guid>
      <description>Today&amp;rsquo;s link isn&amp;rsquo;t directly technology, but it&amp;rsquo;s oh so related to everything we do. It&amp;rsquo;s a little longer than some, but very foundational.&#xA;How do we build a culture that supports high performing teams? I&amp;rsquo;ll bet many of you have heard of Bruce Tuckman&amp;rsquo;s Stages of Development&#xA;Tuckman&amp;rsquo;s Forming, Storming, Norming, and Performing model is a really good way to describe how teams come together and grow, but isn&amp;rsquo;t very prescriptive about how to help a team get from one stage to the next, particularly how to get to Performing.</description>
    </item>
    <item>
      <title>Metaprogramming</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/08/12/</link>
      <pubDate>Mon, 12 Aug 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/08/12/</guid>
      <description>Code that changes based on it&#39;s data. Heady stuff. Generics are a thing in many languages. Used properly they can be amazingly powerful and abstract complexity away from the developer. Used improperly they add unnecessary abstraction and make it harder to understand and debug code. There are also different &amp;quot;levels&amp;quot; of generics, from function overloading to Rust&#39;s implementation. Our challenge is to make the right choice so that we can make progress today and be prepared for the future.</description>
    </item>
    <item>
      <title>Beyond Accidental Architecture</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/08/09/</link>
      <pubDate>Fri, 09 Aug 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/08/09/</guid>
      <description>Software always has some architecture. Often it just happens based on the conditions at the time of development. That&#39;s accidental architecture. On the other hand there are lots of benefits to moving beyond accidental architecture. Check out the slides.</description>
    </item>
    <item>
      <title>Pipes</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/08/08/</link>
      <pubDate>Thu, 08 Aug 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/08/08/</guid>
      <description>Today, a little bit of history. Think about the lowly pipe |. Where did it come from? Is it really that important? How is something that was developed overnight 45 years ago relevant today?. Then think about rNA and how there&#39;s a graph of data flow. AXL is more than a simple |, but conceptually it&#39;s | + tee. Something to think about. And for further reading, the Bell Systems Technical Journal from August 1978.</description>
    </item>
    <item>
      <title>State Machines</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/08/07/</link>
      <pubDate>Wed, 07 Aug 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/08/07/</guid>
      <description>If you wanted to teach a class in state machines, defect reports would be a great case study. They have a very limited set of states and clearly defined rules for when to transition between them. They don&#39;t always touch every state, and they can have cycles, going back and forth between states. One common question with defect reports is&amp;nbsp;Who Closes Out the Defect Report. Some say the developer, some say the TPM, some say the tester, but I think it&#39;s really pretty straightforward.</description>
    </item>
    <item>
      <title>XP</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/08/06/</link>
      <pubDate>Tue, 06 Aug 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/08/06/</guid>
      <description>Extreme programming is guided by 4 rules. They&#39;re very simple, easy to understand, and apply cleanly to how we should be working. However, like any generalization there are lots of edge cases. David Copeland presents a more nuanced approach&amp;nbsp;to try and deal with some of those edge cases and the way we do work.</description>
    </item>
    <item>
      <title>Won&#39;t You Be My Neighbor</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/08/05/</link>
      <pubDate>Mon, 05 Aug 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/08/05/</guid>
      <description>My daughter is a teacher at the local JCC and as part of their continuing education program I had the opportunity to see Won&#39;t you be my neighbor, the story of Fred Rogers and Mr Rogers&#39; Neighborhood. I grew up with his show and jumped at the chance to see it. As an added bonus, there was a short presentation by Hedda Sharapan, who was part of the show from the beginning and is a Senior Fellow at the Fred Rogers Center.</description>
    </item>
    <item>
      <title>Interface Driven</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/08/02/</link>
      <pubDate>Fri, 02 Aug 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/08/02/</guid>
      <description>Speaking of feedback loops and developer velocity, is there a way to look at the way we&#39;ve done things in the past, learn from it, and make changes so that we can move faster in the future? In the software architecture world we talk about patterns such as monoliths, microservices, event driven, and space-based, but what if there&#39;s a better way to think about it? Instead of letting the system components drive the architecture, what if we let the interfaces drive?</description>
    </item>
    <item>
      <title>Control Theory</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/08/01/</link>
      <pubDate>Thu, 01 Aug 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/08/01/</guid>
      <description>Control Theory. Feedback loops. PID Controllers. As someone who was formally trained as a mechanical and aerospace engineer and cut his teeth on flight control systems and air combat AI those words are music to my ears. Autonomous vehicles are feedback loops wrapped inside control systems surrounded by a two sided marketplace. But what does that have to do with the theory and practice developing and deploying code? Check out this talk (and transcript) PID Loops and the Art of Keeping Systems Stable.</description>
    </item>
    <item>
      <title>Imperative vs. Declarative Programming</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/07/31/</link>
      <pubDate>Wed, 31 Jul 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/07/31/</guid>
      <description>Or to put it a different way, does your design model the CPU or the data? A 60 second video on the difference&amp;nbsp;and a slightly more detailed version in text.</description>
    </item>
    <item>
      <title>Worse is Better</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/07/30/</link>
      <pubDate>Tue, 30 Jul 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/07/30/</guid>
      <description>Worse is Better, Perfect is the Enemy of Good, and The Cathedral and the Bazaar. Lots of different ways to think about the same thing. There&#39;s the &amp;quot;Right Thing&amp;quot;&amp;trade;️ and the New Jersey approach. Is there a correct answer? If so, which is correct? Is it situational? If it&#39;s situational, what are the situations? This one is so deep that the author of the original Worse is Better paper spent the next 10+ years developing a second persona and arguing with himself about it and still hasn&#39;t come to a conclusion.</description>
    </item>
    <item>
      <title>Tech Debt</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/07/29/</link>
      <pubDate>Mon, 29 Jul 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/07/29/</guid>
      <description>My personal b&amp;ecirc;te noire. I know we&#39;re going to create some. That&#39;s a good thing and we should do it. That&#39;s not the question. The real questions are how much should we take on, and when/how should we pay it off? As we transition from On-Prem (IRN) to Cloud (EKS/EC2) and HDFS/Posix to HDFS/S3 we need to balance today&#39;s business needs and developer velocity against tomorrow&#39;s. To help frame the problem I offer these links&amp;nbsp;and a reminder that there are lots of resources available in the O&#39;Reilly library, including this book.</description>
    </item>
    <item>
      <title>Customer Focus</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/07/27/</link>
      <pubDate>Sat, 27 Jul 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/07/27/</guid>
      <description>It&#39;s not just for PMs and UI designers. How can we be more engaged and bring joy to our teams and customers at the same time?</description>
    </item>
    <item>
      <title>Orm?</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/07/26/</link>
      <pubDate>Fri, 26 Jul 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/07/26/</guid>
      <description>There&#39;s been an interesting conversation in gophers and python dev mailing list over the last few days, so I figured I&#39;d send some links on ORMs for you all to peruse. Another thing to think about as services/processing moves and dB choices are upon us yet again.&#xA;Anti Anti-ORM&#xA;To ORM or Not To ORM</description>
    </item>
    <item>
      <title>Errors Vs. Exceptions</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/07/25/</link>
      <pubDate>Thu, 25 Jul 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/07/25/</guid>
      <description>Today&#39;s gem is from Raymond Chen&#39;s The Old New Thing. Raymond is an old Microsoftie, and among other things he was an SRE back before there were such things. Of course then we called them Sustainability Engineers, and their job was to make sure everything stayed working and existing functionality didn&#39;t break with releases and updates. This was especially important back in the day because releases happened every few years and quarterly updates were considered quick.</description>
    </item>
    <item>
      <title>Apollo 11</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/07/24/</link>
      <pubDate>Wed, 24 Jul 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/07/24/</guid>
      <description>In honor of the completion of the Apollo 11 mission, I give you Margaret Hamilton, lead developer for the Apollo Guidance Computer software,&amp;nbsp;and the AGC software itself. It&#39;s old (1969) and in assembly, but here it is.</description>
    </item>
    <item>
      <title>Try?</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/07/23/</link>
      <pubDate>Tue, 23 Jul 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/07/23/</guid>
      <description>As Yoda would say, &amp;quot;Do. Or do not. There is no try&amp;quot;</description>
    </item>
    <item>
      <title>Hard Things</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/07/22/</link>
      <pubDate>Mon, 22 Jul 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/07/22/</guid>
      <description>Two things in computing are hard. Concurrency, Distributed Systems, and Off-By-One errors. You&#39;d think reliably writing a file wouldn&#39;t be one of them, but you&#39;d be wrong. Luckily much of the complexity is hidden from most of us by &amp;quot;the system&amp;quot;, but you&#39;d be surprised how much potentially leaks to user code.</description>
    </item>
    <item>
      <title>10X Engineer?</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/07/21/</link>
      <pubDate>Sun, 21 Jul 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/07/21/</guid>
      <description>Here&#39;s a topic for discussion. There was a recent twitter thread about the &amp;quot;10x Engineer&amp;quot;. Does that person exist? Would you want to work with them? Is there a time and place for such a person?&#xA;Founders if you ever come across this rare breed of engineers, grab them. If you have a 10x engineer as part of your first few engineers, you increase the odds of your startup success significantly.</description>
    </item>
    <item>
      <title>Bounded Chocolate Contexts</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/07/19/</link>
      <pubDate>Fri, 19 Jul 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/07/19/</guid>
      <description>What does chocolate sauce have to do with bounded contexts and software design? Enquiring minds want to know.</description>
    </item>
    <item>
      <title>Link to Links</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/07/18/</link>
      <pubDate>Thu, 18 Jul 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/07/18/</guid>
      <description>For today, a link full of other links, including preparing for high-load days and why people got into programming.</description>
    </item>
    <item>
      <title>SRE</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/07/17/</link>
      <pubDate>Wed, 17 Jul 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/07/17/</guid>
      <description>It&#39;s a thing and we should care about it, but how does the Triangle Shirtwaist Factory Fire relate to SRE?</description>
    </item>
    <item>
      <title>Limiting Cognitive Load</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/07/16/</link>
      <pubDate>Tue, 16 Jul 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/07/16/</guid>
      <description>I mentioned Conway&#39;s law last week, and that got me to doing some semi-random link following. I ran across a couple of articles on structuring the development of large systems so as to create bounded contexts and limit cognitive load&amp;nbsp;and organizational refactoring&amp;nbsp;to reducing organizational debt.</description>
    </item>
    <item>
      <title>Who Does Architecture</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/07/15/</link>
      <pubDate>Mon, 15 Jul 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/07/15/</guid>
      <description>Not as much fun as the Steel Curtain, but a fairly light read with some deeper context. Who does Software Architecture?</description>
    </item>
    <item>
      <title>Intro to AI/ML</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/07/13/</link>
      <pubDate>Sat, 13 Jul 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/07/13/</guid>
      <description>https://xkcd.com/2173/&#xA;Seems like everything is a AI/ML these days.</description>
    </item>
    <item>
      <title>Learning From Others</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/07/12/</link>
      <pubDate>Fri, 12 Jul 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/07/12/</guid>
      <description>Learning from your mistakes is important and key to building stable efficient systems, As good as that is, learning from others mistakes is even better. With that in mind, here&#39;s a list of Kubernetes mistake stories we can all learn from.</description>
    </item>
    <item>
      <title>Vim Tips</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/07/11/</link>
      <pubDate>Thu, 11 Jul 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/07/11/</guid>
      <description>Not to kick off a religious war, but I like vi/vim since it&#39;s what my fingers learned lo those many moons ago, but I ran across this list of vim tip and tricks and I learned something new. Enjoy/discuss at leisure.</description>
    </item>
    <item>
      <title>Conway&#39;s Law</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/07/10/</link>
      <pubDate>Wed, 10 Jul 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/07/10/</guid>
      <description>Here&#39;s a topic for discussion. Conway&#39;s Law&amp;nbsp;says that&amp;nbsp;organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.&#xA;There&#39;s lots of evidence, anecdotal and structured, that this is in fact the case. Knowing that, how might we approach our infrastructure design, both the internal interfaces and the customer facing ones?</description>
    </item>
    <item>
      <title>Getting Sleep</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/07/09/</link>
      <pubDate>Tue, 09 Jul 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/07/09/</guid>
      <description>Getting a good night&#39;s sleep is important to health and wellness, but our customers expect things to work 24/7. What&#39;s an engineer to do to get a good night&#39;s sleep?</description>
    </item>
    <item>
      <title>Linux Containers</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/07/08/</link>
      <pubDate>Mon, 08 Jul 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/07/08/</guid>
      <description>Here&#39;s an intro to containers presentation&#xA;Some code and the start of what I hope will be a good set of blogs.</description>
    </item>
    <item>
      <title>Obscuring Complexity</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/06/25/</link>
      <pubDate>Tue, 25 Jun 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/06/25/</guid>
      <description>How to insulate your users from the necessary complexity of your systems</description>
    </item>
    <item>
      <title>The Old New Thing</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/06/24/</link>
      <pubDate>Mon, 24 Jun 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/06/24/</guid>
      <description>Today&#39;s thoughts are much less serious. Courtesy of the always interesting Raymond Chen,&#xA;Pay attention to the janitor (otherwise known as the &amp;quot;Don&#39;t Panic&amp;quot; rule)&amp;nbsp;and&amp;nbsp;sometimes it really is the simple things.</description>
    </item>
    <item>
      <title>Write It Down</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/06/21/</link>
      <pubDate>Fri, 21 Jun 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/06/21/</guid>
      <description>Infrastructure As Code&#xA;Immutable Infrastructure </description>
    </item>
    <item>
      <title>Cargo Cult</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/06/20/</link>
      <pubDate>Thu, 20 Jun 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/06/20/</guid>
      <description>As we journey towards rNA, fully embracing AWS and cloud, while still maintaining some presence in the on-prem world, we want to take advantage of our opportunities build on each areas strengths, abstracting where appropriate, but avoid cargo cult programing.</description>
    </item>
    <item>
      <title>Correctness Vs. Change</title>
      <link>https://friendgineers.rosenshein.org/posts/2019/06/19/</link>
      <pubDate>Wed, 19 Jun 2019 00:00:00 +0000</pubDate>
      <guid>https://friendgineers.rosenshein.org/posts/2019/06/19/</guid>
      <description>https://www.infoq.com/articles/correctness-versus-change/</description>
    </item>
  </channel>
</rss>
