The Best Engineer Doesn't Have the Best Setup
What I learned watching two engineers work
You’re a non-technical founder selecting between two Founding Engineer candidates. This hire will be responsible for creating your MVP, scaling the engineering team, and solving the hardest technical problems along the way. They’ll set the bar for engineering excellence, and everyone will try to mimic how this person works and thinks.
You shadow both candidates for a day while they work on a passion project. Although you won’t understand the details, you’re hoping to observe their workflow and the tools they use, since they’ll likely set something similar up for you.
Engineer 1
This engineer runs Fedora on a Framework laptop, with Sway as his tiling window manager, but tmux layered on top as a second window manager inside the terminal. His editor is Neovim, configured through LazyVim, with a fully customized setup that auto-provisions via dotfiles managed by Chezmoi, stored in a private self-hosted Forgejo Git server running on a home Kubernetes cluster. All development happens inside dev containers via DevPod, so there’s always a container runtime running.
Every tool is picked to keep workflows in the terminal and on his hardware. He uses w3m as a terminal browser to avoid trackers. He uses Aerc for email, an open-source terminal client. He also operates his own databases. Claude is kept in a container so Anthropic can’t see his notes or dotfiles.
His setup lets him sit down at any machine and be fully operational in minutes. As the owner of a DevOps education business, his workflow also demonstrates to prospects what’s possible if they commit to privacy and the terminal.
Engineer 2
This engineer works in a single, full-screened terminal. He uses vi with only basic motions and no syntax highlighting. His “workflow” involves changing the default font to Comic Sans.
He’s decided that he needs a USB driver for his kernel. He starts by googling “apple xserve frontpanel usb driver github,” scans the repo, and concludes, “Ja, this is super simple” (German accent).
He starts by copying and pasting Linux kernel code, mumbling in C, and sipping espresso. Thirty minutes in, he leans over to boot up the physical server next to his desk, which hums loudly for the rest of the session. Then he starts writing his own code. After 2.5 hours, he calmly reports back, “So, ja. It works. The future is now.”
My pick
I’m going with Engineer 2. He gets it. It’s not about fancy tools or impressive workflows that require a paid course to understand. It’s about shipping software. If this guy is comfortable raw dogging C in vi without any AI, I’m comfortable trusting him with the codebase.
The people on YouTube agree:
“I trust this man with my life.”
“This guy is not getting replaced by AI.”
“Writing code without syntax highlighting is demon level.”
“This is engineering.”
“Every time he says ‘Yes, of course,’ I just nod along. ‘Yes, of course.’”
To be fair, I straw-maned Engineer 1 big time. He’s a DevOps pro with serious credentials. Comparing his workstation demo to a C programmer’s live stream is apples to oranges. But by Engineer 1’s own admission, his system is elaborate. After all, it took him 70 minutes to explain how it all works. There’s a coherent philosophy of protecting privacy and flow state underneath it all…but it’s still a lot.
Solving meaningful problems for customers will bring plenty of necessary complexity. I want to work with people who are content to keep everything else simple.
Who you picking? Reply to LMK.
More
Watch Linux kernel developer write a USB driver from scratch in just 3h for Apple Xserve front-panel (youtube)
My Entire Neovim + Tmux + AI Workflow (2026 Update) (youtube)