andy stone

"Why is this system so complex?" The most common answer to this is pretty simple. Building systems as a series of loosely-connected steps creates complexity. The often well-thought-out step implementations failed to consider their place in the overall system design. More times than not, this is a direct result of aggressive deadlines. When working in these systems, it's essential to recognize the external influences that could have forced a shortcut delivery. Try to separate the implementation...

How often are you in a meeting and hear someone say, "Can you repeat that?" Well, if they were present, no repetition would be necessary. Multitasking in a meeting is not respecting everyone else's time. The team will get more out of the time if people are focused. The email or chat can wait. If only a few people consistently act this way, don't blame the schedule. The issue most likely lies in their discipline. However, if you see multiple people not paying attention, a review of the meetings...

With the release of Go 1.18, Workspaces allows you to reference local copies of project imports. Workspaces are convenient when your projects share common dependencies. Instead of pushing up code to get a new commit hash reference for your import, you can now reference your local copy. This new ability has simplified development a lot for this scenario. Thank you to the Go team for delivering such a helpful development capability. example go.work file: go 1.18 use . replace github.com/myo...

Team I/O is a way to organize teams by the information consumed and produced.  For as long as this post is, it's still only a brain dump that needs refinement. Proceed with caution. Roles and responsibilities are common ways to document but fall short in context. Roles are generally generic titles found on job posting sites, and like roles, identical responsibilities are present in multiple teams.  The thought behind Team I/O is to give context on how people fit into the business process an...

I like the concept of 25-minute and 50-minute meeting times; it gives people time between meetings to reset and take care of personal business. These times are great when the attendees know the subject matter well and can produce clear outcomes at the end. However, when the meeting topic is exploratory, like planning, proposals, troubleshooting, or anything that benefits from focused thought beforehand, a 45-minute meeting is ideal. The 45-minute meeting runs differently. The collective chat d...

Brad Mohs and I worked on these principles for several weeks attempting to strike the right balance of terms and coverage of concerns.I’m quite happy where we landed on this, but I do expect this to evolve over time. technology guiding principles scalable: design and implement to be dynamically scaled learnable: short time to meaningful contribution for new team members including: documentation needed for self motivated engagement reliable: system continues to operate properly in the event of...