Results: 48
-
The value of a great tech stack
Non-technical reasons to have a great <mark>tech</mark> stack
2022-08-13 09:54
I’ve been doing some thinking lately about how much value to place on a great <mark>tech</mark> stack. There are two lenses in particular that I’m looking at this through: value to a product organization and value to the individual engineer as a measure of the desirability and enjoyment of working there.
I’ve been doing some thinking lately about how much value to place on a great tech stack. There are two lenses in particular that I’m looking at this through: value to a product organization and value to the individual engineer as a measure of the desirability and enjoyment of working there.
-
Staff tech-lead archetype
2022-06-11 22:52
A tech-lead staff archetype guides the approach and execution of a single particular team. Sometimes they partner across teams and are occasionally part of a Tech Lead Manager role or similar to that role but with less people management responsibilities.1
These are the most common of staff engineers. They do a lot of coordination and team process. They set roadmaps and work with product managers. They delegate more over time to grow others and their impact. They code less over time and acknowledge that when they code less, their team is growing more. They are still the vision behind the team’s direction though and step in to unblock and build alignment when needed.
-
Larson, W. (2021). Staff engineer: Leadership beyond the management track. https://staffeng.com/ ↩
-
-
Migrations are the only solution to tech debt
2022-05-11 13:10
Migrations are both essential and frustratingly frequent as your codebase ages and your business grows: most 202205131318 Software only supports one order of magnitude before becoming ineffective, so rapid growth makes them a way of life.
In fact, if your software survives an order of magnitude increase, it may have been over-designed in the first place. Add to that the simple fact that they are usually the only available avenue to make meaningful progress on technical debt1 and it follows that we have to know how to do them well.
So how are we going to deal with these inevitabilities?
-
Larson, W. (2018, April 15). Migrations: The sole scalable fix to tech debt. https://lethain.com/migrations/ ↩
-
-
Tech — Work — Ramblings
2016-10-27 00:00
#structure #microblog #tech #ramblings #work #blog
This page serves as a simple index of all my blog posts. This list should be roughly equivalent to searching for the #blog tag.
If you're looking for my shorter #microblog posts, see 202208270000 Microblog.
- 202208010000 Making a Rust Roguelike
- 202206171206 Delivery Performance vs Value Delivery
- 202205150000 Learning Rust
- 202205010000 Making a Fitbit Sense Watch Face
- 202109150000 Idea Gardening
- 202109010000 Prototype Expand Consolidate
- 202108010000 Designing for Big Screens
- 202107150000 Working in Public
- 202107010000 Unifying My Domain
- 202106010000 Rewrites Are (Almost) Never the Answer
- 202105010000 The Silent Majority of Engineering
- 202009010000 The Only Correct Way to Organize Code
- 202007010000 2019 Work Reads
- 202006150000 Gestalt Principles of Design
- 202006010000 Revamping My Blog
- 202004010000 CodeMash 2020 - Review
- 202001080000 CodeMash 2020 - Live
- 201911150000 What React and Kubernetes Teach Us About Resilient Code
- 201810010000 Development Estimates
- 201809010000 Piping Code With GitLab CI
- 201808010000 Cloud Native Computing
- 201807010000 Architecting a More Modern System
-
Making a Fitbit Sense Watch Face
Time for a Better Watch
2022-05-01 00:00
There are a lot of good first- and third-party watch faces out there for the Fitbit Sense, but none of them are exactly what I want.
Motivation
There are a lot of good first- and third-party watch faces out there for the Fitbit Sense, but none of them are exactly what I want. So instead of putting up with something slightly sub-optimal, I'm taking a look at what it takes to develop my own. Being a programmer is great isn't it?
This post is still a work in progress, but as I've said, I'm working on showing off more works in progress.
-
CodeMash 2020 - Review
A More Formal Report on a Conference
2020-04-01 00:00
A review of the sessions I attended, what I learned, and how I liked the overall experience of CodeMash 2020.
Short Post
I said in my live blog post from CodeMash that I was going to do a follow up to the conference and review the experience. Since there were other people at Beam interested in writing about their experiences too, we decided to pool our effort as a team and write a single post for the Beam Engineering Blog. Because it was co-authored by other Beamers on Beam time, I'm not sure if I should cross-post it in its entirety. Instead, here's a link to the finished product, Yet Another CodeMash Blog Post. Go check it out.
On a final note, if you're on the fence about CodeMash, I'd strongly recommend going. I had a great time and would definitely go back in the future.
-
The Silent Majority of Engineering
A Bit of Perspective
2021-05-01 00:00
Most engineers aren't using all the new shiny tools. Most are quietly coming to work every day, writing code in tried and true ways, and getting things done.
I once heard a quote about software engineers. It went something like this:
Most engineers aren't using all the new shiny tools. Most are quietly coming to work every day, writing code in tried and true ways, and getting things done.
The sentiment has stuck with me. It's something that we don't think about all the time as developers.
There's always something new and interesting to learn and try out. There are never ending amounts of opinions and preferences, ergonomics and design.
It's good to keep up to date. It's good to be a lifelong learner.
But what happens when we need to get something done reliably and predictably?
We don't use all the new shiny tools.
We quietly come to work every day, write code in tried and true ways, and get things done.
-
Making a Rust Roguelike
Making a Game Out of Learning
2022-08-01 00:00
In the process of learning Rust, I'm following a great tutorial for building a roguelike game.
Background
There are a lot of ways to learn a programming language: from docs and books to puzzles to fun side projects.
There's a really great community on Reddit called /r/roguelikedev and one of their coolest resources is a comprehensive tutorial for making a roguelike game from scratch in Python called The Complete Roguelike Tutorial or TCOD. A guy named Herbert Wolverson built a really amazing version of that tutorial in Rust (with some changes).
One of my friends who's into game development showed me all these things and how he was going through that Rust tutorial and porting it to his most comfortable language, C#. Since I was already learning Rust, I thought I would give the Herbert's Rust version a try.
So come along and join me as I document some progress and thoughts about Rust and game development. Hopefully I'll be able to build the final game to WASM and embed it as a project here on the site.
-
Unifying My Domain
A Question of Scope
2021-07-01 00:00
Bringing all my projects under one roof.
I've been working a lot of small projects lately, learning some cool things, and wanting to write about it all. At the same time, I want to host the projects so I can link to them and show them off.
So I started updating my old site so that I could use it for hosting these projects, but then thought better of it. Instead of blogging on my blog, putting my portfolio on my homepage, and other things on other sites and domains, I'm just going to put it all in one place.
I think this approach is a good idea for a few other reasons too:
- All the code will live in one place so I'll be much more likely to maintain it and keep evolving it over time to be the tool that I want it to be.
- Building things is quicker and easier because I don't have to bootstrap a new project every time.
- I can easily expose all of my ongoing work to the world.
- There's no question about where something new should live.
On the other hand, there are some downsides:
- The project will get big.
- I'll be constrained by the tech and framework I chose here. It'll be more difficult to show off something like a Haskell project.
- Rewrites are tricky to do well. Though I have a leg up here because I'm the demanding stakeholder as well as the developer and customer.
-
Don't stress over releases
2021-10-22 21:22
As it turns out, they didn’t even look at the release [until] a few days later.1
Most stress from deadlines is self-imposed and unwarranted. Tech moves so fast that even the things that are truly mission critical probably won’t be around in a year, two, or five. Don’t let the rush and bustle of the tech world claim your mental well-being.
Be aware of burnout. Ask yourself questions about your stress levels and what you need to take care of (202110220840 Simple stress measurement questions). Use PTO and use it frequently enough to ensure you can actually separate when you’re away.
Would you rather spend extra time trying to get that product out that will quickly be forgotten, or would you rather spend a bit more time with your spouse, kids, pets, learning a new hobby, or life reading a book?1
Live your life!
-
Preston, J. (2021, August 17). Mental health impacts of a Big Tech job. Jake’s Tech. https://oilyraincloud.com/2021/08/16/mental-health-impacts-of-a-big-tech-job/ ↩ ↩2
-
-
Prototype Expand Consolidate
A Method for Building Maintainable Systems
2021-09-01 00:00
Today we look at an efficient, sustainable engineering loop — prototype, expand, consolidate.
TODO: remove for regular zettel?
The Loop
An efficient, sustainable engineering loop can be describe through the motto prototype, expand, consolidate.[^foote1994] This loop consists of three eponymous phases. This has also been referred to as the Fractal Model of software development lifecycles.
Phases
Prototype
Our primary objectives during the prototyping phase are learning about the problem space and fitting a solution to that. We pick specific portions of the problem space to stake our understanding to and just start building something.
We deliberately don't spend time trying to build perfect understanding and systems during this phase. Doing so is a waste of time because we're inevitably blind to the realities at the end location without walking the path first.
Expand
Our next objective is to expand. Similar to prototyping, we expand our understanding of the problem space and the robustness of our solution. This is the phase where nuance comes in. People find themselves saying "I didn't know that worked like that" or "I didn't know it needed to be able to do that" which causes us to expand our knowledge and systems to incorporate new ideas and functions.
-
Piping Code With GitLab CI
A Simple Way to Make Your Life Easier
2018-09-01 00:00
I finally got around to adding continuous integration pipelines to my personal projects.
What is Continuous Integration?
At its most basic, continuous integration (CI) is the practice of frequently merging developers' code changes into a mainline code repository. In recent years, the concept of continuous integration has taken on a life of its own and been expanded to include other aspects of development. For instance, almost anyone referring to continuous integration is under the assumption that the frequent merging will be automated. There have also been expansions of the idea such as continuous deployment (CD) where the code is not only automatically merged into mainline branches, but also built, tested, and deployed. By automating all of these simple repetitive tasks, developers can stop spending time on manual integrations and deployment processes and spend more time coding.
GitLab CI
For various reasons that are far outside the scope of this post, I host my personal code on an on-premises GitLab server. GitLab has hundreds of amazing features to take advantage and one of the nicest of them all is their CI/CD pipelines. GitLab has all of the automation and task running capabilities of other separate solutions built in.
-
Use a simple heuristic to guide gradual adoption
2023-04-05 10:01
unless you have a good reason write it in [new tech]
Have to give autonomy, have to spend the effort to justify the reason not to, have to allow people to do the right thing without you dictating
202203231647 Leading from vision 202107240951 Visionary leadership style 202205111310 Migrations are the only solution to tech debt
Software unscripted change management minute 30
-
Revamping My Blog
A New Coat of Paint
2020-06-01 00:00
You may have noticed that the blog got a new look and feel recently. The changes weren't purely cosmetic though. Let's take a look at how I migrated from a Bootstrap and PHP based blog to React, Next.js, and Styled Components.
Motivation
It's probably not a surprise to most people that I'd want to switch from a PHP based blog to something a little more modern, but honestly — and perhaps controversially — I think PHP is still an amazing solution for simple use cases like mine. No, the shininess of tech isn't a good enough reason on its own for me to rebuild the blog from the ground up. So what reasons were there for updating things and switching tech?
Criteria
- Ease of Maintenance — My blog was running like a dream for years on a crazy simple setup, so any solution that I went with was going to have to at least match it in terms of maintenance effort.
- Ease of Writing — There was quite a bit to be desired in the old setup. I was using a rich text editor that was hard to get well formed rich text data out of. It was also really difficult to use on mobile. Wanting to use a simpler format (like markdown files) and the ability to use a plain text editor was a big reason to make a switch.
- Performance — My old setup was slow for a host of reasons. I was running PHP and MySQL on the same old machine sitting underneath my printer. The thing was ancient when I acquired it longer ago than I care to admit. It would be nice if I could take advantage of something out there that did lightning fast static site edge cached delivery.
-
First Reactions to React
A Review of Building My First React App
2018-06-01 00:00
We're moving our corporate site in house and I thought it would be the perfect time to try out a new javascript framework.
There are plenty of good javascript frameworks out there right now; among the most popular are Vue.js, Angular, and React. (Yes, I'm aware that React is a library not a framework, but for the sake of this article, I'm going to set that aside.) There's also a ton of posts and articles that can help you understand the differences between them if you're not familiar. Breaking down all the reasons we chose React over the other two would be a whole post in itself. Maybe I'll write something comparing the frameworks and our opinions on their features in the future. For now, it's enough to say that we took a hard look at all three of these and we felt that React was the best choice for our specific situation.
Diving In
We're using webpack for build tooling, a React front-end, and a C# .NET Core API backend. Getting started was the most challenging part of the whole process with the majority of the issues coming from the webpack configuration. I only ever used gulp before and we wanted to switch to webpack so that we could more easily bundle and ship specific components to third-party API consumers. I'm sure that someone more experienced with webpack could have gotten up and running in much less time than it took me, but it's always nice to have the opportunity to learn a new tool. Besides my personal inexperience, there were some versioning issues between the .NET world and the NPM world that we needed to resolve. We also added to our own headaches by using a slightly wonky legacy environment setup (that's hopefully going away shortly) and by having some external requirements from businesses we partner with. With all of the preliminaries out of the way, we could finally get coding.
-
Architecting a More Modern System
A Look at Microservices
2018-07-01 00:00
Making the move from one monolithic service to many microservices can be a complicated process. Here are some reasons why we decided to make the move anyway.
We have a need for external businesses to be able to embed parts of our apps into their front ends, connect with our APIs, and not bother the third parties with implementation or data handling details. We also don't want to have to maintain too many different solutions and technologies, so if possible the solution should overlap with our own internal needs.
The Solution
Microservice architecture to the rescue, but what really does that mean besides being a marketing buzzword? I'm going to cover three core ideas of microservices: decoupling, distribution, and technology agnosticism.
Decoupling
The obvious result of turning one application or service into many is that the resulting services are less tightly tied together. For people who aren't developers, it might not be obvious why services that are less reliant on each other might be better than the alternative.
As in all things, programmers deal with side effects of their actions, or more precisely, the actions of their code. Without getting into too many details, programming side effects can be nasty. There are a whole host of frameworks, technologies, and design patterns that are specifically built to avoid unwanted side effects. Microservice architecture isn't built with that sole goal in mind but it does help us mitigate side effects by requiring our service to have well-defined interfaces for interacting with other services. Basically, when turning one application into many that act as one, we need to take the time to define how they talk to each other including any security and permissions that exist as part of those interactions. We now have a single point of failure for these interactions. It also means that one service can't accidentally do something with another service that it's not supposed to. It's much easier to test our services' internal logic, test their interactions with other services, and even test adding new external services before they even exist. Decoupling leads to more secure, predictable, testable, and fault-tolerant systems.
-
What React and Kubernetes Teach Us About Resilient Code
A Similarity Among Widely Different <mark>Tech</mark>
2019-11-15 00:00
A brief intro to control theory and declarative programming
This post was initially published as part of the Beam Engineering Blog here and cross posted here on my blog.
Two Concepts
Here at Beam, we're on a quest to make our technology work for everyone. As part of this quest and as a need stemming from our hyper-growth, my development team is shifting our focus away from feature development toward platform technology and developer experience.
On the infrastructure side, we've been working on a CLI tool for our devs that will let them easily manage infrastructure from the command line. They can spin up entire AWS environments and deploy code from multiple repositories with a single command — no more waiting on other developers for testing and staging environments to be free, and no more inconsistency between production and testing environments. The quest for consistency led us to containerization, and our quest for easy infrastructure management led us to infrastructure as code. Our containers and infrastructure then lead us to a need for better orchestration of those containers. We needed tools that would make the often complex task of deploying, integrating, scaling, and managing services simple and routine — enter Kubernetes.
-
Designing for Big Screens
An Experiment in Adding More
2021-08-01 00:00
I've always wanted to see what was possible on the web when we use all the space we're given. Today we look at my take on how to add more for those who have the extra real estate.
There's that old, inaccurate saying, "we only use 10% of our brain". As terrible as it is, it's stuck with me over the years for some reason and it popped into my head the other day while working on this site.
I was trying to decide how to handle extra large breakpoints and was settling on containers with a
max-widthso that the content stays centered and predictable. It works well, but when using a ultra-wide screen or ultra-high resolution screen there's a lot of blank space just hanging around. So I started trying to think of a way to make the site more useful for people with all that extra real estate. After all, more and more people are using UHD screens.Note: For the rest of this post, I'm going to use the abbreviation UHD to refer to anything that's got enough screen space to end up in this category where there's usually a lot of blank space. Typically, I'm thinking of screens that are over 1440p. So something more in the 4k range, but not necessarily. A ultra-wide 1080p screen might also be considered UHD in this context just because it has much more horizontal space than a typical 1080p screen.
-
CodeMash 2020 - Live
An Informal Report on a Conference
2020-01-08 00:00
Live blogging from CodeMash 2020
Welcome to CodeMash
This is my first time attending CodeMash. I had some content about PASS SQL Summit (the only other big tech conference I've been to) when I attended back in 2016 but that all got "lost" when I overhauled my servers/blog/websites. I say "lost" but I still have a backup of all of that data somewhere. It's all compressed down into cold block storage in a backup of backups. It'd be an interesting project to try and do a restore of that version of my stuff. I don't know if I actually could remember how to get it all going again. If that's the case, what's the point in keeping the old backups? I suppose I could still get that data even if it's not on a functioning server. I could grab the text from those old posts and add them here or something. But I digress...
I'm really looking forward to all the sessions here. This is also going to be a new experience for me. I was the only person I knew at SQL Summit, whereas there are at least 30 Beamers here. It should be fun having people to go to talks and sit at meals with. Although, SQL Summit pushed me to do those things with people I didn't know and make the most of it. There's probably good and bad to both situations. I'm glad I'll be able to experience both of them.
-
Cloud Native Computing
A New Way to Build
2018-08-01 00:00
First Salesforce revolutionized IT with SaaS, then other service platforms extended those ideas for the full stack. Cloud Native Development is here to stay.
Eons ago, people developed enterprise software as standalone packages that were delivered to companies who then painstakingly installed and updated them. Often installation or upgrade projects could take over a year to complete. The software ran on servers that cost hundreds of thousands of dollars and were physically located at the company's headquarters. To the younger readers, I know this is sounding like some sort of nightmarish hellscape, but I promise that it really happened.
Software as a Service
In 1999 at the beginning of recorded history, a man named Marc Benioff founded a company called Salesforce that saw a better way forward. The goal was to provide a better experience and value to their consumers — enter the software as a service model (SaaS). SaaS aimed to improve on enterprise software delivery in a few key areas.
First, it decided on a subscription pricing structure so that customers were only paying for the features they were using. It also lowered the barrier to adoption and let users land on a platform for lower cost. The idea was that after the users landed, the quality of the product and the variety of features would incentivize them to increase their usage and feature adoption on a higher subscription tier.
-
Lightning Talks
A Great Way to Teach and Learn
2018-05-15 00:00
Lightning talks are a great way to share knowledge in your organization. Here's how to get started and get everyone to love them.
A Lightning Talk is a short 5-10 minute presentation on any topic followed by about 5 minutes of open Q&A. A common format for a lightning talk is 6 minutes for presenting and 4 minutes for Q&A. The goal of a lightning talk is always to share knowledge, but can also be to convince people of the benefits of something or to take a particular action. Basically, lightning talks are lightning-fast knowledge sharing.
What's the Benefit?
Ok, so we know what a lightning talk is, but what's the point of doing them? There are plenty of obvious benefits and some that aren't so obvious. The important thing is that everyone who participates, from the speaker to the audience to the organization all benefit. It's an all-around win-win situation.
Share Knowledge
The IT industry is a knowledge industry and the vast majority of us who work in IT are knowledge workers. It's our job to gain, handle, and use information and it's impossible to be an effective knowledge worker without the ability to share that knowledge with others. We all gain insights and learn new things on a regular basis as we work on our projects. It's important that the knowledge gained is passed on to everyone even if they're working on a different part of the project or team.
-
Second-order thoughts about the 2020s
2022-11-02 09:29
Much of these excellent thoughts are from Eli Dourado's great post on the subject.[^dourado2020]
- Bring science to market in order to end 202110220905 The great stagnation.
- mRNA vaccines are amazing. They can be developed quickly and cheaply. There is an HIV/AIDS vaccine in trials and it could be eradicated this decade. There are also "miraculous" treatments for cancer in this vein that aren't true vaccines, but could improve outcomes drastically.
- There are a number of anti-aging techniques coming out that are backed by more credible science than before (therapeutic plasma exchange, aging clocks, other senolytic drugs). Expect people to live longer and healthier by the end of the decade.
- Solar and wind costs were drastically cut in the 2010s and in the 2020s deployment will accelerate. We need a storage price of $20/kWh for a grid powered completely by today's tech. The closest we come is a $542/kWh battery based solution from Tesla.
- Instead of solar and wind we need scalable zero-carbon baseload energy — nuclear or geothermal. Current tech for nuclear targets around 6.5¢/kWh but is delayed until at least 2030. More likely is geothermal which looks to crack 3.5¢/kWh. Not only this but geothermal's drilling advancements mean that even Lockheed Martin's promising compact fusion reactor might not be able to compete if it comes to market this decade. This is because digging the wells this decade means we just have to replace the heat exchange pieces but not re-dig the wells, effectively halving the cost of new wells for the following 15 years, meaning 1¢/kWh energy by the 2050s. Fusion will kill in space though.
-
The Only Correct Way to Organize Code
A Joking Rant About Keeping Code Neat
2020-09-01 00:00
Why we need a system for code organization and what that system should look like.
Highway to the Danger Zone
Though the pattern is full and it will definitely get me in trouble, I'm going to metaphorically buzz the tower by putting some pretty strong opinions out there today about file naming and code organization. So buckle up Goose, and don't hit that eject button.
First off, file naming. The correct answer here is
kebab-aka-hyphen-casewhich is all lowercase and hyphen delimited. No exceptions, and no, your community standards aren't a good enough reason to change this one as we'll see in a minute. Looking at youComponentName.jsx👀 .Second, code organization. The only correct answer is
folder-by-featureas opposed tofolder-by-random-devs-logicorfolder-by-tech. We'll take an organic trip through all three of these systems and see where we end up.Either of these alone is enough to spark a holy war among devs, but unlike tabs vs spaces, I think there's good enough objective reasons to pick one over the others. Let's take a look.
File Naming
I don't want to spend too much time on this topic because it's much less important to a team of developers than having a consistent system for creating, finding, and maintaining the actual functionality of your product through its source code. Still, you can see how it's in the same vein and deserves an honorable mention.
-
Microblog
2022-08-27 00:00
This page serves as a simple index of all my microblog posts. This list should be roughly equivalent to searching for the #microblog tag.
If you're looking for my longer #blog posts see 201610270000 Tech — Work — Ramblings.
- 202410220101 The Final Edition of Embedded Muse
- 202410201110 Engineering Multi-classing
- 202408250920 1BRC in rust in depth
- 202408220939 Go is not worth it
- 202405051458 Mobile Content Width
- 202405051251 Timeout Killer
- 202405021450 Ideating
- 202404232122 Masonry Layout CSS
- 202404232120 Hell yeah NASA
- 202208270311 Up too late
-
Effective staff engineering meetings
2022-11-01 10:39
The measure of an effective staff engineering meeting is the same as the measure of an effective 202206112233 Staff-plus engineer. The goals are the same and having a meeting simply facilitates people doing their jobs well. A huge portion of high-level engineering is communication and alignment. There's no better way to achieve those two things than regularly talking with people.
How to get started
Just schedule the first meeting with staff engineers to go over what this is and how the group would like to proceed.
- Set a cadence
- Assign an owner of the calendar meeting and agenda
Going forward, the agenda should be collaboratively set, allowing for leads from teams to bring things that their team and engineers on their team care about or are working on. Particularly, they should present things that would benefit from feedback from this group, things that people on their team are struggling with, or things that other teams would benefit from knowing about. This is primarily a communication meeting, though working sessions are valuable from time to time.
Purpose, benefits, and outcomes
- Setting company-wide technical direction.
- Coordinating mentorship and sponsorship for engineers across the company.
-
Learning Rust
A Quick Lesson in Ownership
2022-05-15 00:00
I'm learning rust
A note on format
This is a little stream of consciousness post about my experience working through the official intro to rust book. There's not much point to it other than to help me evaluate how I feel working with the language.
Getting going
I started out by installing
rustup, but immediately hit a problem. I already had a version of rust installed on my system. It was an old one installed through homebrew. Nevermind that, I just needed to uninstall the brew version and install a newer one via the recommended approach.Next, I installed
rust-analyzermaking sure to grab the VS Code extension which (at the time of writing this) is the recommended language server even though the RLS extension has many more downloads. There's been some sort of maintenance issue or something. I didn't look into it too much, but this is the community direction right now.I found that
rust-analyzeronly works when you have a wholecargoproject as the root of your workspace in VS Code though. It's a bummer that we can't have non-root rust projects and still get the benefit of the language server and all it's hover/intellisense/type goodies. I think there's a way to make this work with arust-project.jsonfile, but I didn't want to get sidetracked before even getting started. -
Staff architect archetype
2022-06-11 22:55
An architect staff archetype is responsible for the direction, quality, and approach within an area. They leverage in-depth technical knowledge and organization level leadership to satisfy user needs and org objectives.1
For a domain to warrant an Architect role, it must both be complex and enduringly central to the company’s success. Some companies like architects to be deep in the code and others don’t want them to write any code at all. Typically architects are effective with areas of exceptional complexity or large amounts of tech debt.
-
Larson, W. (2021). Staff engineer: Leadership beyond the management track. https://staffeng.com/ ↩
-
-
Joe the Axolotl, Clever Closet, & Demonic Robots
2024-05-03 15:30
- Anyone can start a girls who code club and if you have enough people sign up, you can get free resources like lessons, notebooks etc.
- Dept of Ed standards alignment
- 7x more likely to go into STEM than national avg
- She led the Otterbein one, it does something a little different than the provided web lessons
- Build things “clever closet” and others (had never seen clueless so they thought it was original which is cool)
- Pololu 3 Pi Robots pre-built 4 AAA batteries, hokey pokey robot, Rube Goldberg machines, etc
- LEGO Robots now, loved those
- Game dev
gwcotterbein@gmail.com afholcomb72@gmail.com @gwcotterbein insta
-
Debugging migrations
2022-05-11 13:03
Given that 202205111310 Migrations are the only solution to tech debt, we need to make sure they proceed productively from start to finish. If your migration is struggling, ask yourself some key questions:1
- Where are people getting stuck in the migration process?
- Are people not starting the migration?
- What cohorts are and aren't migrating successfully
- For teams that aren't migrating, what are they doing instead? How is that going? Should we re-examine our migration path?
- For teams who are migrating, where is the migration bottleneck and what would resolve it?
-
Larson, W. (2022, May 5). Your migration probably isn’t failing due to insufficient staffing. https://lethain.com/migration-isnt-failing-due-to-lack-of-staffing/ ↩
-
Work on what matters
2022-06-11 23:10
Make the most out of your time.
Hamming has a good quote about this in 202205092134 The Art of Doing Science and Engineering.
To the extent you can choose, work on the problems that you think will be important.[^hamming2020]
[...] how to do great things. Among the important properties to have is the belief you can do important things. If you do not work on important problems, how can you expect to do important work?[^hamming2020]
Working on what matters is important because the only viable long term bet on your career is to focus on work that matters, do projects that develop you, and steer towards companies that value genuine experience. (202109251140 Play long term-games)
- Avoid snacking — 202204091039 Impact vs effort model of task value and 202106241531 Eisenhower matrix of task value
- 202206112313 Stop preening
- 202206112312 Stop chasing ghosts
What does matter?
This section was written specifically with the responsibilities of a 202206112233 Staff-plus engineer in mind, but is generally adaptable to other situations as well.[^larson2021staff]
Companies operate in eternal iterative elimination tournaments
- Existential issues — nothing else matters if your company stops existing. Note that this isn’t the most efficient place for effort but it should be swarmed on by everyone.
-
Staff-plus engineer
2022-06-11 22:33
Staff engineering is a complex topic. As nebulous as it can be to get promoted to a 202206112236 Senior engineer role, it’s considerably harder to move into staff-plus roles. Whereas the definition varies a bit from company to company for senior engineering, the definition or even existence of staff-plus roles is completely irregular across the industry. Will Larson wrote an excellent book, Staff Engineer: Leadership Beyond the Management Track[^larson2021staff] on what it means to be a staff-plus engineer. This structure note and its children mostly come from that resource, but also other citations where noted. That book is also (mostly) publicly available at staffeng.com.
[!important] Being a staff engineer is not just a role. It’s the intersection of the role, your behaviors, your impact, and the organization’s recognition of all those things.
The value of the title
- Bypass informal gauges of seniority (especially useful for underrepresented groups)
- Facilitating access to “the room”
- Increase current and career earnings
- Access to interesting work
- Different rather than better
Archetypes
-
My next level
2021-09-06 08:25
I'm 30, what do I want to do by the time I'm 40? 10 years is a long time, but will be here before I know it.
Some candidate ideas that have consumed mind-share before now:
- Continue down the tech leadership path
- Blaze an entrepreneurial trail of my own
- Research and create something completely new
- Write a book
- Are any of these what I want?
- What would it take for me to pick one and follow it relentlessly?
- Is there a way to do more than one in a meaningful way?
The first thing is 202205231130 Knowing when to leave.
- Leave
- Stay
After that our paths diverge:
- If I leave, where do I go, how do I decide, what would I want to work on, what areas would I want to grow in?
- If I stay, what do I want to work on, what areas do I want to grow in, what is my future, what goals do I have?
A note on open-ended work
For much of the ground-breaking work, the challenge lies even in figuring out what to do. Not just how to do it. Breaking things down and checking things off a list day in and day out isn't satisfying looking back on a year's time span or more. If things can be broken down that easily and checked off, it must not be all that interesting.
-
Make reversible decisions quickly
2023-12-09 15:03
Make reversible decisions quickly and irreversible decisions deliberately.
This saying has been popularized in the tech world (though I don't know the original source to attribute here, it's also mentioned in 202307241042 The Pragmatic Programmer1).
We tend to spend too much time in 202109090909 Decision paralysis when it's more often the case that either direction is fine and even if one is bad, we can reverse course. Because of this mis-attribution of weight on the importance of our decisions, we need a reminder like this one to push through that and take action.
Another interpretation of this is that 202312091509 There are no final architectures and 202312091511 There is no such thing as sacred code. Everything is subject to change and re-evaluation at any point in time. The only thing we should surely do is 202205031449 Optimize for change, which means making decisions with the knowledge that they'll be changed later.
-
Thomas, D., & Hunt, A. (2019). The pragmatic programmer, 20th anniversary edition: Journey to mastery (Second edition) (pp. 48). Addison-Wesley. ↩
-
-
Incremental change is always better
2022-08-15 13:17
When making drastic changes or migrations (202205111310 Migrations are the only solution to tech debt), it's always better to make deliverable, incremental change than to try to do big projects and releases.
There are times when it's tempting to think that things are just too different and there needs to be a big cutover or separation from the old. This could be true, but even in those circumstances, there are ways to make the cutover incremental, the feature replacement incremental, or similar.
It's true that incremental change can be more complex and is most likely slower than a big change, but as we know 202203221630 Slow is steady, steady is smooth, smooth is fast and 202304031244 There is never time to fix things later.
This is one of those rakes that people (including myself) want to continue stepping on even though we have stepped on it many times in the past. This is why I say incremental change is always better and not almost always. It's because you have to be strong to not allow yourself to be fooled into thinking you're the exception (202109251155 Desire vs expected outcome in decision making).
-
The world wants new men
2022-09-12 10:25
The earth does not want new continents, but new men.[^verne1870]
Spoken by Captain Nemo in Twenty Thousand Leagues Under the Sea.
Captain Nemo is a supporter of revolutionaries around the world and a strong enemy of colonialism. He was a revolutionary in his own country (drafted originally by Verne as a Polish revolutionary against Russia, but later changed to an Indian one against Britain) and lost his family and friends to his oppressor. He renounced his citizenship of all nations of men and took to the seas, fighting (and sinking) colonial ships as well as accumulating riches and giving them to revolutionary causes around the world.
In this context, the quote is lamenting that land and nations are not needed to solve the problems of the world. Instead, men need to fundamentally change ethically and morally in favor of freedom, liberty, and self-determination.
In a broader context, this quote could be interpreted as a general sentiment to re-evaluate the direction something is going in. In tech, if someone said "we need better advertisements that respect people's privacy", I might reply with this quote meaning "we don't need better ads, we need a fundamental shift from this paradigm."
-
Software only supports one order of magnitude
2022-05-13 13:18
Most implemented systems are only designed to support one or two orders of magnitude of growth from the current load. Even systems that were designed for more growth typically run into this problem anyway since knowing the specifics of the future is nearly impossible (202204031033 Abstractions and future-coding are actively harmful).[^larson2016magnitude]
Perhaps contrary to intuition, the fact that the systems don't support more than that means that they were designed well in the first place. They achieved the goals of what they needed to do, didn't try to solve problems that couldn't be predicted, and were efficient solutions to the previous constraints rather than being over-designed.
So, if your systems' usage are doubling every 6 months, you cross an order of magnitude every 18 months. Things that were trivial or afterthoughts at one point can become the focus of whole teams of people and require deep, plateauing investment to use and adapt. You'll have to rewrite or re-implement all of your systems twice every three years. These rewrites are risky and can contend with each other for resources, but they need to be done since 202205111310 Migrations are the only solution to tech debt.
-
Ten percent time
2023-04-11 22:03
The concept of "10% time" (or any given percent) is the idea that we set aside 10% of our work week for non-immediate work problems.
While it doesn't have to be each work week, it's important to do this 10% time on a regular basis. It could be daily or biweekly, but it shouldn't be less frequent than that.
This practice helps us avoid staying immersed in the sea of detail where almost everyone stays almost all of the time. We need to examine the big-picture on a consistent, frequent basis for many years (202304041619 Keep the whole in mind, 202203231646 Affecting long-term change) especially if we're going to be leaders instead of followers.
The well supported[^hamming2020] outcome is that the value we get out of this time is greatly repaid through the process in both direct (202304102048 Compounding Interest) and indirect (202106221146 Leverage) ways.
As a software developer, we might experiment with new tech, do some independent learning, get around to cleaning up that bug in the developer experience flow that is annoying you, or anything else. It's an open ended time for research and development, for thinking, for play and experimentation, and for inefficiency.
-
Software Engineering
2021-09-06 13:38
Maybe this should be a structure note of structure notes only since this is a huge topic that I'd like to really dive deep on. There is also the 202206191300 Computer Science structure note that I’ve split out to dig in to the more technical, theoretical stuff in order to keep this one focused more on the practice of writing software and careers or organizations in this field.
Topics
Documentation
- Co-locate tech docs with the code
- C4 Modeling
Abstraction
- You aren't gonna need it (YAGNI)
- 202204031033 Abstractions and future-coding are actively harmful
- 202204262054 Prefer duplication over the wrong abstraction
- On the spectrum of abstraction[^lou2016]
- Open for extension closed for modification O in SOLID. Means you can add new behavior without modifying any existing code. Always green, always confident in lack of side effects.[^metz2013]
Measurement
- 202304231046 List of SDLC metrics
- 202204272219 The fastest code is no code
- 202109251100 Verify behaviors and assert properties
- Thought experiment. Coding as function, what do the derivative and integral represent? Related to 202107291950 Optimizing requirements and implementations and 202110111901 Run to change ratio of a program.
-
Always bet on text
2021-10-22 16:53
Text is the most powerful, useful, effective communication technology ever.[^hoare2014]
- Text is the oldest and most stable communication technology (assuming we call speech a natural phenomenon). You can read text from 5000 years ago and can engrave granite that will outlast the human species.
- Text is the most flexible communication tech. Text can convey ideas with a precisely controlled level of ambiguity and precision, implied context, and elaborated content, unmatched by anything else. It is not a coincidence that all of literature, poetry, history, philosophy, mathematics, logic, programming, engineering, and everything else rely on textual encoding for their ideas.
- Text is the most efficient communication technology. By orders of magnitude.
- Text is the most socially useful communication technology. It works well in 1:1, 1:N, and M:N modes. It can be indexed and searched efficiently, even by hand. It can be translated. It can be produced and consumed at variable speeds. It is asynchronous. It can be compared, diffed, clustered, corrected, summarized and filtered algorithmically. It permits multiparty editing. It permits branching conversations, lurking, annotation, quoting, reviewing, summarizing, structured responses, exegesis, even fan-fic. The breadth, scale and depth of ways people use text is unmatched by anything. There is no equivalent in any other communication technology for the social, communicative, cognitive, and reflective complexity of a library full of books or an internet full of postings. Nothing else comes close. Nothing.
-
Zero to engineer
2022-08-10 19:44
How do get into 202109061338 Software Engineering?
Let's go at this from a specific angle.
What would it take for me to get an entry level job as a programmer?
- Get past the résumé screen
- Get past the recruiter screen
- Get past the coding exercise
- Get past the onsite interviews
Preparing for these takes different amounts of time and require different skillsets. If we include the dependencies between each step and sort them by preparation time, we get a new ordering.
- Getting past the coding exercise — is the basis for 2 and 3, so it must be solid and come first.
- Getting past the résumé screening — requires things like example projects and raw time spent coding.
- Getting past the onsite interviews — definitely the point where not knowing your shit can bite you, but it's also possible to be great at interviewing and compensate for your rough patches with things like work ethic and initiative.
- Getting past the recruiter screening — easy to bullshit past if the résumé checks out, but always easier if you're confident and capable than faking it.
Getting past the coding exercise
Helps if you know what it will be. Many companies make things like this available in advance. If so, you have an obvious path.
-
My Brand New Blog
An Exercise in Futility?
2016-10-28 00:00
Maybe it's the infinite hubris of a millennial or maybe its just that I doubt anyone will actually read this, but I found a few reasons to convince myself to do it anyway.
I thought about that question a lot before building this. Most blogs are out of date, under-maintained, new year's resolution-esque things that wither and die after a few entries. Why create something that has a high likelihood of being abandoned? Beyond that, how could I possibly think that anything I have to say is worth writing about? Maybe it's the infinite hubris of a millennial or maybe its just that I doubt anyone will actually read this, but I found a few reasons to convince myself to do it anyway.
I'm Already Writing Anyway
I've been in the habit of keeping a journal for a long time. I keep it for a lot of reasons: it helps me think aloud, it helps me recap my days, weeks, months, years, it teaches me about myself, it gives me perspective on why things did or didn't break my way. However, a journal, at least how I write mine, doesn't work well for giving a single topic more attention. I still write about topics that interest me, but diving in and exploring those topics fully isn't something that fits in a medium whose primary purpose is to record and reflect. A blog, on the other hand, is the perfect medium to write in-depth on a single topic. A blog also gives me the flexibility to write about any topic that's currently interesting me.
-
Stir Trek 2024
2024-04-30 10:34
Selected Sessions
time room rank speaker track session 08:45 could not attend -
System design
2022-08-13 13:27
Designing systems is one of the common, critical tasks of a 202206112233 Staff-plus engineer. It's something that sets a 202206112236 Senior engineer apart. It proves that you can understand tradeoffs in technology and organizational size and maturity. It shows that you understand how to build things that are optimal for now and have a clear path to the future you're working toward. Many engineers plateau at a place where they can understand and implement any type of tech but aren't capable of planning out new systems from scratch based on some need of the business.
Example systems to learn how to design
- Rate limiter
- Consistent hashing
- Key-value store
- Unique id generator in distributed systems
- Url shortener
- Web crawler
- Notifications
- News feed
- Chat
- Search autocomplete
- YouTube
- Google Drive
Example: Scale from 0 to 1M users
- start with a single server. DNS somewhere directs all traffic to the web server where everything from apps, to APIs, to DBs are housed.
- The first interesting scale point is when you need to separate your database from your web servers. At this point you probably have enough reason to discuss the exact details of the DB you're using. Should you be using a relational DB or a NoSQL document store?
-
Curriculum design for software engineering
2022-06-28 20:18
I want to teach computer science, what should I do?
vs
I want to make software, what should I do?
Need to ask questions about the desired solution to figure out things like goals, constraints, and methods before you can build that solution. In the education case, the “solution” is the curriculum.
Ask things like:
- What age are the students?
- What exposure have they had before?
- Is this required? An elective? An extracurricular?
- How long is the class? How often does it meet?
- Is it even a class or something else?
- How many students are in the room?
etc. but also think about things like
- Is there internet access?
- Is the teacher new to programming?
- Can the students type?
- Are there students with disabilities?
- Do the students have regular computer access at home?
- Do the students have regular computer access at school?
Think about
- Equity, Rigor, and Scale
Methods
- Required courses
- Don’t scale though, need certifications for teacher. The economy for experts means that they’ll go to Jane Street and learn a huge amount more than public HS
- Rigor has to take a hit because everyone has to pass the course to graduate
- Elective courses
- Not equitable. Hugely biased (currently) to white and asian males, failures and achievement gap #thread lead to further disparity.
-
Minimum Viable Replacement
2024-05-03 14:00
About 100x as long as needed and poorly written. Did not even introduce a “framework” in the end, literally just set up the problem and ended with GLWTS. But the slides are good.
The problem: Replacing an existing system is the exact opposite of an MVP
If you’re trying to retire a legacy platform — instead of having the luxury of just solving very specific customer segment needs — you need to solve the needs for every customer segment using your software! [...] Instead of trying to solve the needs of just one small segment, you now have to deliver 20 years worth of software development for thousands of customers across multiple countries and segments to retire the system [...] Consequently, we need to prove that the new technology matches or exceeds the value of the old technology for our existing customer base.
Retiring systems takes longer and costs more than your executives want to hear
Stir Trek Talk
- Charlie Brown kicking the ball, but yet we think it’ll work this time
- Turns into deadline driven development
- Problem is that expectations are out of alignment with reality
- Ignore laggards and edge cases but laggards are biggest customers and edge cases are your critical risks
-
Cleaning Out the Skeletons
An Effort to Put My Best Foot Forward
2016-12-01 00:00
Growing up at the start of social media has its downsides. Today I talk about cleaning up my online presence.
Cultivating a professional online presence is something that I've been casually working towards this year. In fact, I mentioned in a previous post that one of the main reasons that I started this blog was to further that goal.
In my mind, there are two important steps along the way to building something I'm proud of: cleaning out low-quality content from the past and adding new high-quality content going forward.
Out With the Old
Now begins the painstaking task of combing through every old post, tweet, status update, etc. that I've ever posted. If you've ever been a teenager, you probably know the kind of things that I'm sweeping under the rug here: teen angst, vaguely subtextual nonsense, humble brags, and any of the other cardinal sins of social media.
I've never publicly acknowledged it before, but for a while in college, I was lost. I didn't know what I wanted with my life, I wasn't happy with myself or the things I was doing. I felt depressed and anxious every day. I put a lot of my worth in other people. Many of my core values and perceptions of the world were changing for the better and I was experiencing growing pains. As you can imagine, I posted some things that I'm not proud of. I also posted a lot of things that bring back painful memories as I look back on them today.
-
Gestalt Principles of Design
A Crash Course on the Whole
2020-06-15 00:00
Today we're looking at 'die Gestalt', the result of early 20th century studies in psychology that described how humans perceive the world, and how it can help us make outstanding user interfaces.
Gestalt Psychology
Gestalt (ɡəˈʃtælt) feminine noun: 1. An organized whole that is perceived as more than the sum of its parts.
Around the turn of the century, German and Austrian psychologists were investigating the human mind's ability to perceive the world around it. Even though we're confronted with a world filled with exceptions and strange sights, we can somehow sort it all out. How do we come to form a meaningful, consistent perception of reality based on the chaotic conditions around us?
The prevailing conclusion of this school of psychology is that when perceiving the world, the mind sees eine Gestalt — or a "global whole" — instead of a collection of individual parts. The mind also has the ability to organize these wholes into even larger wholes. For instance, the mind can recognize a hat or a person as a whole object instead of a collection of lines and curves, but our mind can also perceive a larger whole of a person wearing a hat instead of seeing two smaller unrelated objects near each other. According to one of the founders of Gestalt psychology, Kurt Koffka,
-
2019 Work Reads
A Slew of Short Book Reviews
2020-07-01 00:00
My professional reads from last year, rated and reviewed.
Overview
I like to read. I read a lot about a lot of things, but I would say that I devote maybe 40% of my reading time to things that I'd consider “professionally oriented”. These are books, articles, blog posts, white papers, etc. that I probably wouldn't read if I didn't have a job. They aren't all directly related to my job, but they all make me better in some way.
So here's a list of professional books I read in 2019 (roughly in chronological order) along with a rating out of five possible stars and the two second summary of why you should or shouldn't read them. Spoiler — they weren't all winners.
Clean Code
by Robert “Uncle Bob” Martin
Rating: 3/5
A slightly dated look at how code can be simple and maintainable. There are some good gems that can be extracted for programmers of any language or experience level. A bit long to read all the way through and considerably better in paper format as opposed to e-book because of the code blocks. Definitely worth a look if you're a day-to-day coder.