Quick win infrastructure
When assigned a design or coding task I’m always looking for "quick wins". What’s the least amount of effort I can spend to produce the highest value. How quickly can I solve the problem at hand and move onto something else?
As projects drag out I realize I should have done it "right" from the start. Determining which projects are "quick wins" and which ones need more thought/effort is a skill, which I hope to further develop. Admittedly I'm much better at this today than I was years ago.
While thinking about this it dawned on me, that frequently we need to slow down to speed up. The better tools we have at our disposal the higher quality we can produce, quickly.
Rules for Identifying "quick wins"
Before diving into some of the things I've found helpful to move fast. I want to focus on getting better at identifying quick wins vs longer-term work. A few observations/rules have emerged in my head. At the start of projects, these seem like some good things to think about as guidelines.
- How long will I be working on this thing?
- How many people will touch this thing?
- How many hours will be saved by a small number of hours on my part?
- If I spend more time today, will I be building knowledge inside of my organization?
- Does this thing exist already or is this new?
Improving my craft
As a designer
Over time I've changed my mind quite a bit about design systems. Previously I cared deeply about the "quality" aspect of design systems. Design the most clever component, craft the cleanest most flexible HTML/CSS/JS. Today I care much more about "enabling laziness" and building a "culture" of building tools for one another.
In my mind laziness is a breeding ground for convention and standardization. If flexible components, shared styles, and standard colors are available I'll reach for those instead of making up new ones on my own.
I'm fairly new to Figma as my primary design tool, I've seen great benefit from crafting "quality" Figma components, keeping shared palettes up to date, and providing shared styles for typography. Utilizing Auto-layout and positioning features makes components for the first time close to as flexible as good old HTML/CSS.
The more time that is invested into building up our asset library the faster we can move in the future.
As a developer
Today more than ever, we have many more tools at our disposal to craft high-quality code, quickly. The same principles ring true here as they do in the design world. The easier it is for me to follow convention the more likely I am to do so.
CI for everything.
It's hard to imagine building a modern application without leveraging some kind of CI/CD pipeline and tooling to perform menial tasks that I just don't want to do. I really rely heavily on these pipelines to build, test, lint style, and deploy my code. The problem with not "codify" these workflows is that I'm lazy and I often forget or miss an important step.
Prettier and code conventions.
When auto code formatting started becoming more popular I felt very passionately that I formatted code the "right way" and that prettier mangled my code. When you have a bunch of developers all coding the "right way" and this happens over months and months it quickly devolves into a flaming mess of random styles. I've been using prettier for a couple of years now I can't do without it.
:any and Typescript.
Similar to code formatting I resisted Typescript for a long time. Being forced to use it on a few projects I've come to really like it. Upfront there was certainly some effort I had to put in to learn the language and get familiar with the syntax. Today I couldn't imagine writing an app without it. Modern applications are complicated and the more safety and documentation we can add to them the better.
Especially when writing typescript I feel there is a varying degree of quality that you can work towards. When I first started using it I would type out API responses and a few other places but leave :any's everywhere. Putting a little effort upfront to create more interfaces and learning more about the tools goes a long way here.
The more and more I've built software I've realized the value in building things a few times until you get it just right. I've never regretted building something in a scalable clean way. I've never regretted learning something new or getting up to speed on new technologies that at first seems silly. Today is a good reminder to get out there and build some better stuff.
Clinton Halpin is a full-stack engineer and product designer based in New York City. You should follow him on Twitter