Writings

Background The problem seems simple: open, edit, and save text files. This can range from JSON files to source code like every other editor. Turns out, this is a relatively difficult problem. The rise of javascript text editors surfaces the performance problem of editing large text. It’s a non-trivial problem. There are several desirable characteristics that editors want: Editors need to optimize for edits. Having immediate feedback for changes is paramount to text editing. This includes editing large files. Editors need to optimize for reads. This is implied for optimized edits so that users can see immediate feedback to their edit. This also includes support for large files. Editors should minimize memory usage. Reduced overhead for storage of text leaves more memory for more text buffers. This is useful for developers editing multiple projects at once (eg - microservices). Different data structures support these requirements in varying degrees of success. For the sake of this article, I’m ignoring many other features editors usually have: ...

The more you learn, the more this skill seems to be necessary. When missing a bug or a refactor opportunity, I wonder how did I miss this? Sure, everyone wants to learn from their mistakes. But noticing the little details gives you the opportunity to adapt. Massive function definitions starts off looking like an common pattern for code that needs to be refactored. Those dozen one-letter variables names probably should be better named. Shadowing a variable is prone to introduce errors in the future. All those mental notes form from being able to observe it. ...

Let’s mentally build an API for an an e-commerce site. Let’s say we’re tasked with building the cart & checkout portion of the API. Building a RESTful API seems like the natural choice. At first, a Cart seems like any other model entity in the system. But what about an multi-page checkout step? Allow partial updating of the Cart model (sounds like a job for PATCH). We need to preserve as much information as possible on the server to allow the user to pick up where they left off. Each update needs to be validated against the current known state of the world. Store credit may not fully cover an order that has an upgraded shipping method specified later on. The final cart has to be “commited” where final validations need to be performed before commited. An finally, the committed cart requires taking to third party APIs all along the way (shipping, credit card processing, tax calculations) as well as at the commit point. REST doesn’t provide an easy way to model this. ...

Instead of sounding prescriptive, this article is much more descriptive. I’m describing my regular workflows: what is working; what isn’t working. I’m documenting this for completely selfish reasons since it’s useful to track progression (if any). It happens to be a great inflection point since a recent illness has thrown me off my routine in the past week. Like most people, there’s a need to regularly do: Respond to messages (twitter, facebook, texts) Respond to mail (physical, email) Attend events (birthdays, social gatherings, meetups) Capture ideas (they tend to come up in the most random places) Living (rent, bills, taxes, laundry, cleaning) All while (attempting) to achieve other goals: ...

People always ask about how did you learn this or work so quickly doing that? It’s a tough question to answer elegantly. And it’s a cop-out to vaguely say I spent my free time looking into that particular topic. It’s a socially-acceptable excuse. But no doubt that this requires time. The time spent learning comes from somewhere, since we all only have 24 hours in a day for this. In our field, there’s always time you must dedicate to learning to keep up to date. ...

There’s a process behind every result. If you say, “we have no process, there’s no meetings”, then that’s your process. Admitting to no process simply indicates that you don’t have it formalized. A poorly defined process hurts. Processes enable efficiency and consistency. They can also act like a communication protocol among team members, teams, and organizations. Process can improve your quality. Let’s think about how you deploy an application. What does that process look like? A poorly defined deployment process is inconsistent – something undesirable for a deployment. At minimum, a quick checklist works: ...

As an engineer, one of the most valuable skills you can have is to communicate effectively. This applies both to your follow engineers as well as non-engineers (PMs, designers, business). Obviously, this advice is generally applicable, but many engineers don’t craft their communication to the business well. Common problems are: Talking too much about technical implementation. Talking too little about technical implementation. Too much technical implementation drowns out the important details that businesses are concerned about. It drags on discussions and meetings unnecessarily. Imagine if a designer talked for hours about how they picked the correct border radius value and color for their buttons in a meeting. That’s a waste of time for business stakeholders and engineers in that meeting. Getting far into the weeds like that quickly wastes discussions or meetings1. ...

It is difficult to always be improving in the software industry. In creative fields, many artists talk about churn. When starting out, there’s an enormous amount of work to produce to get better. If you’re new, there’s a massive amount of bad code you need to write. That’s OK, it’s necessary. But the rate of improvement decays as time progresses. As your notoriety grows, you can no longer just crank out code to get better, how can you preserve some rate of improvement? It feels like the rate of learning looks like this: ...

Software is always challenging to explain to non-engineers and having a metaphor is valuable to explain complex concepts. Bridges happen to be a good analogy to software. But the devil is always in the details. Any piece of software provides a benefit to its users. It’s similar to people using bridges to cross rivers. As with bridges, many kinds of software can solve the same problems. Some bridges support many cars and pedestrians which is analogous to a high-throughput like a server that can support many users. Others are very nice walkways with trees, a highly usable piece of software that supports only a few users. Most of the time, users only see the bridge from the top. Like seeing only the tip of an iceberg. ...

What is simple? Rich Hickey makes a good abstract definition, but it can be difficult to translate to everyday code. I encourage you to watch that before returning to this. I’ll still be here. Ok, let’s start at that definition. Hickey’s simplicity is the disentangling of concerns. It’s easy to convolute from what seems like straight-forward statement. For example, a high-level example would be what domain-driven design proponents argue for. Separate solving your problem domain from the machinery that you use to solve it. Separate How from What or When. ...