Because coding is play and engineering is work.
What’s less obvious is that play gets more work done than work. Free from obligation, you can explore more options, discover new possibilities, and stay in flow for longer.
Let me show you.
Here’s a typical week of engineering according to my time tracker. I try to click the button every time I context switch for more than 5 minutes. Call it research into office culture, if you will.
Each column is a day
This data is by no means perfect. Context switches happen within categories; I forget to click the button; and I’ve given up capturing the small distractions that happen.
I also spend too much time in faux meetings on Slack. Those don’t show up here.
But you can see a trend: most work happens in half-hour and aaaalmost-an-hour intervals. Then something comes up, and I have to switch. QA bugging out, absolutely horribly urgent code reviews that must happen right this instance, a deployment here and there, or a short meeting or two.
If I’m very lucky, I get to work on something for almost 2 hours. Sometimes, if the stars align just so, almost 3. That happened three times this week. Three times all week that I focused for more than an hour. ?
Now compare that mess to a night of coding.
I started at 12:30am after a short nap. Before me, a choropleth map of household incomes.
By 1:38am, it was a choropleth map of income disparity between the tech industry individuals and the median household. And a histogram.
At 2:35am, the map could focus on specific US states, and the histogram had a line that showed median household income in that state against a backdrop of tech salary distribution in said state.
By 3:46AM, the visualization had filtering controls, a dynamically updating title and description, and was ready to go.
At 4:47AM, it launched, complete with Twitter cards, Facebook open graph stuff, embedded tweets for retweeting, and an email form so people can sign up for more.
It flopped on the open internets with just 1500 uniques, but look at that timeline. 4 solid hours of coding, and a whole thing was born. In the context of engineering, something like this would take a week, involve 2 engineers, 1 project manager, 1 designer, 3 meetings, and 2 QA people. The end result would be 10% better.
PS: the viz flopped because I tried to give it a spin that doesn’t gel with the audience that received it, and I have to improve initial load time somehow. Lessons learned.
Here's how it works 👇
And get thoughtful letters 💌 on mindsets, tactics, and technical skills for your career. Real lessons from building production software. No bullshit.
"Man, love your simple writing! Yours is the only newsletter I open and only blog that I give a fuck to read & scroll till the end. And wow always take away lessons with me. Inspiring! And very relatable. 👌"
Ready to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz components your whole team can understand with React for Data Visualization
Curious about Serverless and the modern backend? Check out Serverless Handbook, modern backend for the frontend engineer.
Ready to learn how it all fits together and build a modern webapp from scratch? Learn how to launch a webapp and make your first 💰 on the side with ServerlessReact.Dev
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️