const app = {
lines: document.getElementById('lines'),
textbox: createTextbox(),
lineTemplate: createLineTemplate(),

const socket = connect(

initial({ lines, uuid, charLimit }) {
app.uuid = uuid
app.charLimit = charLimit

added(line) {

removed(i) {

server.onclose = (ws) => {
if (ws.line) {
const i = lines.indexOf(ws.line)
lines.splice(i, 1)
server.sendToAll({ removed: i })

server.commands = {

begin(ws) {
const line = {
hash: ws.hash,
uuid: ws.uuid,
text: '',

ws.line = line
server.sendToAll({ added: line })

run() {
console.log(`Running on port ${this.port}`)

this.wss = new WebSocket.Server({
port: this.port,
verifyClient: this.verify.bind(this)

this.pruneInterval * 1000


Steven Degutis

Full-stack software developer for hire

"Clean code" isn't actually clean

August 28, 2017

For the better part of the past decade, I’ve been able to work directly with some very strongly opinionated software veterans. This gave me the unique opportunity to learn several different perspectives, to gain valuable real-world experience, and to see first-hand just how these gurus put their beliefs of the best ways to code, which they hold pretty religiously, into practice.

Clean code is unfinished code

One thing is that no code will ever actually feel clean, because there are always flaws in code from a certain perspective, usually the perspective of future features or additions or worries. In the constant pursuit to future-proof every line of code, we actually can’t. And the sooner we accept that, the sooner we can avoid the common mistakes of over-engineering. We just have to trust that most of the time, YAGNI.

Sometimes we do know about requirements ahead of time that we need to factor into the code as we write it, even though we aren’t quite at the point of writing it. But usually, it’s best to avoid writing any code that you don’t need right now, until you actually do need it, because you’re almost always going to guess wrong about how you’re going to implement it, since you’re missing a lot of context about the structure and architecture of your app that you won’t have until the second you actually start implementing the feature.

Clean doesn’t mean perfect

I’ve come to believe “clean code” means “code that doesn’t slow you down”. There’s no magical formula that will make your rapid development even more rapid. There’s a maximum speed you can go, as a programmer, each day. (And it’s actually not even the same every day!) Your only hope is to avoid making the code such a tangled mess that you can’t make progress anymore without giant refactorings or even rewrites.

Sometimes code is going to have ugly spots and warts and things you just don’t feel comfortable with, even though you can’t quite put your finger on why. If you can’t name an actual, tangible, immediate reason for changing some code, then it’s best to just ignore that feeling and leave it well enough alone unless you have a really good reason.

Clean code might look really ugly

Sometimes, especially early on in my career, I’ve gone into a code-base and said to myself, “wow, this code is really terrible. It should be rewritten from scratch.” And then one day, technomancy told me the fence story. Something about a guy and a fence, I don’t really remember. Ask technomancy, he knows it pretty well.

Most of the time projects don’t need rewrites. If someone thinks it’s so ugly or unclean that it does need a rewrite, it’s usually that they really need to just spend a little while (maybe even a long while) absorbing how the program works, understanding every aspect of the architecture. Eventually they’ll come to appreciate the reasons behind the warts, and they might even say to themselves, “hmm, yeah, I would do it this way too now that I think about it.”

Automated tests are not that important

They are important, don’t get me wrong. They have a time and a place. But they’re not perfect for every single project. Sometimes you have a one-off script or web app that you just need to test manually as you go along.

And the kinds of tests, the amounts of them, the obsession with 100% test coverage, some of these are legitimate, in some contexts and circumstances. If I worked for Stripe, I would definitely put 100% test coverage on the public-facing API libraries. If I wrote my own web app with a store on it, I would automate the tests around handing out licenses, and some user registration. But these days, I probably wouldn’t write many tests for it unless it was for the kind of business that needed that extra confidence.

And I do appreciate the value of TDD. For smaller situations, it’s a nifty way to keep you in check, making sure you’re not trying to add too many features all at once. Plus there’s something satisfying about seeing 20 or 50 or 300 tests all green at the end of the day. But I’m not going to condemn someone for not writing tests or for not using TDD. I’ve come to see its value as an assistive tool, not as a religious workflow.

And personally I think this attitude toward testing and TDD is actually more true to the spirit of Agile, which was meant an antithesis to the process-heavy methodologies that it sought to overthrow.

Even the experts struggle

I’ve watched gurus put their minds to the keyboard. They do their best to put their theories into practice, but at the end of the day, they accept the code as it is, clock out, and go home. That was really humbling to see. I mean, if the experts aren’t really even confident their code is all the way clean, how can I ever possibly be sure?

So I stopped worrying about whether my code is perfect. And I just accepted that if I can’t see any immediate flaws with the code, and if all the tests pass (whether automated or manual), then it’s fine. And I trusted that if I ever come across a bug, I can fix it. Once I started putting this into practice, I stopped having coding paralysis. I started being productive. I started writing lots of code that in retrospect I’m pretty proud of.

About me


My name is Steven Degutis, and I've been writing software professionally for a decade. During that time, I've written many apps and websites, quite a few technical articles, and kept up-to-date with the rapidly evolving software industry.

If you have software needs for web, mobile, or desktop, and are looking for a seasoned software professional, please reach out to me at to set up a phone call.

Work Experience

  • Self-employed – present
  • Clean Coders – 5 years
  • 8th Light – 2 years
  • Big Nerd Ranch – 1 year
  • Self-employed - 1 year


  • Web: full-stack
  • iOS (UIKit)
  • macOS (Cocoa)
  • AWS / EC2 / ELB


  • JavaScript
  • HTML5 / CSS
  • Swift
  • Objective-C
  • Clojure


  • Node.js
  • Express.js
  • React
  • Vue.js
  • Electron

Technical articles

Over the past decade, I've written a total of 172 technical articles on various programming languages, frameworks, best practices, and my own projects, as I kept up-to-date and active in the software industry.

Subscribe via RSS / Atom.



Here are some of the projects I'm most proud of. They were created using a variety of technologies, running on several different platforms and OSes. They're all finished products, and many of them are open source.

Website - Online Video Store

I wrote this web store for Robert "Uncle Bob" Martin, using Clojure for the back-end, and JavaScript for the front-end. Over the course of 5 years, I took the site from a simple three-page website to a full enterprise-ready business solution, with nearly 100% test coverage.

  • Clojure
  • Datomic
  • jQuery / D3.js
  • JavaScript
  • ClojureScript


macOS app - Dock Utility

I made Docks in 2009 for users who wanted to swap out icons in their Dock with a single click. Its unique functionality and design aesthetic attracted the attention of Apple, Engadget, MacWorld, and led to an acquisition of my start-up by Big Nerd Ranch.

  • Staff Pick
  • MacWorld 4/5 Rating
  • MacWorld Gem of the Year
  • Featured on


macOS app - Clojure IDE

Source Code

While working on, a website written completely in Clojure, I increased my productivity by building a custom IDE for macOS designed specifically for Clojure projects.

  • Objective-C
  • Clojure
  • C / C++
  • Cocoa
  • Themeable


macOS app - Hackable Automation

Source Code

This began as an experiment to see how many languages I could use to script a custom macOS window manager using our custom TCP protocol. Eventually it had bindings for Clojure, Ruby, Python, Go, JavaScript, CoffeeScript, Node.js, Chicken Sceme, and Racket, as well as other community additions.

  • TCP / Unix sockets
  • Custom protocol
  • Highly Scriptable
  • 10+ language bindings
  • Open source community

Bubble Maker

iOS app - Bubble simulator

This toy was made in a weekend to entertain my 1 year old daughter. It lets you create bubbles with your fingers, which then simulate physics by bumping into each other and falling.

  • SpirteKit
  • Custom art
  • Physics simulation
  • iOS
  • tvOS

Quick List

iOS app - Todo list app

When I couldn't find an app in the App Store that let me make very simple lists extremely quickly, I made one myself. I use it almost every day to organize and track my activities.

  • In-app purchases
  • Custom UI / UX
  • Social media
  • App Store artwork
  • Spring animations

Website - Personal Portfolio

Source Code

This very site itself was written from scratch in about a day. It uses best practices for modern responsive web design, and a custom build phase to compile the sources into a single HTML file.

  • Node.js
  • Pug / Jade
  • LessCSS
  • HTML5
  • WebSockets


Java app - Game

Source Code

The game 2048 (created by Gabriele Cirulli) is so fun that my kids wanted their own copy. So I wrote this version in Java 8, using JavaFx for attractive graphics and silky smooth animations.

  • Java 8
  • JavaFx
  • Modular code
  • Customizable
  • Animations


macOS app - Window Manager

Source Code

I created this app to increase my productivity by letting me move windows around in macOS using keyboard shortcuts. It grew into a community-driven highly extensible app, using Lua for its plugin system.

  • Objective-C
  • Embedded Lua
  • Plugin system
  • Fully documented
  • 5,000 GitHub stars

Website - Social Network

Implementing this elite social network gave me experience integrating both Apple Pay and credit card payments (via seamlessly into web apps, for a frictionless and pain-free payment experience.

  • Clojure
  • Elastic Beanstalk
  • PostgreSQL
  • Apple Pay


Website - Live Chatroom

Source Code

This isn't just any chatroom. In this web app, you can see what everyone is typing while they type it. I made this in order to scratch my itch for making real-time apps and games, and learned how to use WebSockets in the process.

  • JavaScript
  • WebSockets
  • Node.js
  • Vue.js
  • CSS


macOS app - Music Player

Source Code

As iTunes went through many user interface changes, I wanted an app that was consistent, intuitive, and easy to use. So I created Bahamut, a minimal music player for macOS with a custom user interface.

  • Objective-C
  • Custom UI
  • Cocoa
  • Core Data
  • AVFoundation


macOS app - Chat (IRC) Client

Source Code

This was written in 2009, before the time of Slack, when IRC was the main way for programmers to get short-term assistance from each other. Its purpose was to be a beautiful app with an emphasis on simplicity and usability over technical power.

  • Async networking
  • Core Animation
  • Core Text
  • IRC Protocol
  • UI Design


macOS app - Window Manager

Source Code

This is an app I actually use every single day. It lets you move windows with global keyboard shortcuts. Since it uses Vim-like key bindings, it should feel pretty natural to any programmer. There's no configuration needed; it Just Works™.

  • Minimalist UI
  • Simple UI
  • Vim-like Hotkeys
  • Global Hotkeys
  • Zero-configuration


macOS app - Lua window manager

Source Code

As an evolution of Phoenix, Hydra was my first attempt at embedding a full Lua virtual machine into an Objective-C app, to make a lightweight and efficient window manager that focused on speed, low memory usage, low CPU usage, and overall being gentle on laptop batteries.

  • Embedded Lua
  • Generated docs
  • Lightweight
  • Memory efficient
  • CPU efficient


macOS app - JavaScript window manager

Source Code

As an evolution of Zephyros, Phoenix was my attempt to use Cocoa's native JavaScript bindings to make a more lightweight and efficient window manager, that focused on speed, low memory usage, low CPU usage, and overall being gentle on laptop batteries.

  • JavaScriptCore
  • JavaScript API
  • Lightweight
  • Memory efficient
  • CPU efficient

Smaller projects

These may be tiny, but they're interesting technical feats.

Lua4Swift Swift framework for embedding Lua with a native Swift API.
choose Command line fuzzy-matching tool for macOS that uses a GUI
music Command line music daemon for macOS that only speaks JSON
hecto Command line text editor with an embedded Lua plugin system
ZephSharp Window manager for Windows using Clojure for scripting
management Minimalist EC2 configuration & deployment tool in Ruby.
go.assert Assertion helper package for writing tests in Go.
go.shattr Go library for printing shell-attributed strings to stdout.
OCDSpec2 Objective-C based testing framework with Xcode integration.