Happy Presidents Day everybody.
Alexa, what’s the most all-out-of-fucks thing a developer would say at the end of a Friday before a 3 day weekend?
If your “hack” has been running in production for years, was it really a hack?
I can’t tell if developers are idealistic pessimists or pessimistic idealists. The most common manifestation of this paradox? Apologizing for delivering working software. The idea that one could have done a better job if only they had more time is admirable, even tragic sometimes, but should we really be so hard on ourselves? Useless Dev Blog takes a refreshingly honest look at this phenomenon in Stop lying to yourself – you will never “fix it later”
Recently I approved a pull request from a colleague, that had the following description: “That’s a hacky way of doing this, but I don’t have time today to come up with a better implementation”.
It got me thinking about when this “hack” might be fixed.
I could recall many times when I, or my colleagues, shipped code that we were not completely happy with (from a maintainability / quality / cleanliness aspect, sub-par functionality, inferior user experience etc.).
On the other hand, I could recall far far fewer times where we went back and fixed those things.
…So, we realise that if we don’t fix something right away, we’re likely to never fix it. So what? why is that important?
Because it allows us to make informed decisions. Up until now, we thought that our choice was “either fix it now, or defer it to some point in the future”.
Now we can state our options more truthfully – “either fix it now, or be OK with it never being fixed”. That’s a whole new conversation. One which is much more realistic.
Emphasis mine, and emphasized because it gets right to the heart of the fundamental conflict driving all software development compromises, aka Rule 9:
Later == never, temporary == forever, shipped > not shipped
Rule 9
Well, it gets to 2/3rd of it at least. The author argues convincingly that if the code is “bad” you have a very short window to make it “good”, because once new features start relying on it you’re stuck with it forever. I agree, but there is another factor missing from the author’s calculus – is the presumptively bad code worth fixing? From the Old Testament:
As a software developer, fixing bugs is a good thing. Right? Isn’t it always a good thing?
No!
Fixing bugs is only important when the value of having the bug fixed exceeds the cost of the fixing it.
Joel Spolsky, Hard-assed Bug Fixin’
Joel is talking about bugs, but since presumptively bad code is just a bug that hasn’t hatched yet it applies here as well. He’s also talking about value in terms of money, but that’s really just another way of saying time. Time blows the referee whistle in the 3rd part of Rule 9, shipped > not shipped. In the quantum flux of unfinished code, all possible outcomes exist simultaneously until a deadline forces them to collapse into one pull request. Sure, it could have been perfect given enough time, but if your product has to actually sell and serve customers there is a point on every new feature or fix where good enough will have to do. I’ll take someone’s working hack over their hypothetically better solution that doesn’t exist every time.
To Scale! The cause of, and solution to, all of (startup) life’s problems
Jason Cole slices off a steaming slab of ribeye from my favorite startup false idol – the obsession with scale.
The moment that you create a solution, whether it’s a piece of software or a business process, you start to feel pressure to optimize it…this urge to prematurely scale is almost entirely fear-based, a fear that’s ironically fed by a startup’s intense desire to succeed…In our quest to reduce risk, we add the two things our growing company doesn’t need: weight and inertia…Every moment is precious to a startup. The time and money that you spend overbuilding could be invested in growing your customer base and refining your products…The young company that constantly asks, “but will it scale?” rarely gets the chance to find out.
Who Cares if it Scales?
The solution? Commit to learning instead.
A learning organization doesn’t worry about scale because it knows that it will get there when it needs to… it recognizes that agility and adaptability defeat complexity every time. Standardization and locked-down processes — “This is how we do it here” — are the enemies of learning and optimization, so hold them at bay forever if possible. Make learning and experimentation your standard process instead.
Eric Ries said as much in 2011:
Failure is a prerequisite to learning… If you are building the wrong thing, optimizing the product or its marketing will not yield significant results.”
The Lean Startup, p154
But even before that, Ted Dziubia gave the tl;dr version of it back in 2008: “Scalability is not your problem, getting people to give a shit is.”
Solve the problems you actually have today, because in a startup you’re not promised tomorrow.
UI Fails # 8 – Get This App to Urgent Care
Checking my place in line at the urgent care clinic:
The only thing more broken than my son’s arm is this markup.
Never miss a pull request with this one easy trick!
Like all high-functioning dev teams with a modicum of self-awareness, we thrive on gallows humor and existential dread. No wonder we’ve adopted the this is fine dog for our mascot.
I was searching for the original image source when, to my immense surprise and delight:
A This Is Fine dumpster fire vinyl figure that I can buy?! Shut up and take my money. I did and they did. 2 days later…
I’m flattered Cap’n Quacks thinks I could pull that off, but I’m a home automation luddite and I plan to die that way. There’s probably a million smart LED light options that would have worked, but after 5 minutes of looking my eyes glazeth over, so I went old school instead. Here is the laziest pull-request activated signal light that I could come up with.
Hardware:
- 100% Soft This is Fine Dumpster Fire Vinyl Figure – I bought mine from Amazon.
- A smart electrical outlet that supports IFTT (If This Then That) automation. I bought the Etekcity ESW10-USA, also from Amazon.
- A lamp cord with an E12 candelabra socket from the friendly neighborhood big-box hardware store. I found it by the ceiling fan repair parts.
- The lowest wattage LED bulb you can find. DO NOT use an incandescent bulb, no matter how low the wattage, it will melt the vinyl. I found that out the hard way.
Next, drill, cut, or gnaw a lightbulb-sized hole into the back of the vinyl figure. It should be just wide enough that the bulb slides in with a little resistance and doesn’t fall out.
Screw the bulb into the socket/cord, plug it in, and make sure everything works (the first socket/cord combo I bought didn’t). Now it’s time to set up the smart socket.
Socket to me
Install the VeSync app on your mobile device, create an account, plug in and turn on the smart socket, follow the instructions to activate the device, update firmware, and name it. Test turning the socket on and off through the app. Here’s how mine looked after setup:
Automate
The printed instructions that come with the sockets include a QR code link to the full users manual, but mine just led to a dead page. Fishing around on the Etekcity support site I found the manual for a similar model. It was close enough. Search for “IFTTT” (If This Then That) in the manual to get right to the good stuff. Naturally, you will need to create an IFTTT account. I followed the guide to install the IFTTT app on my mobile device and pair the outlet, but after that I much preferred using IFTTT website on the desktop to finish setting up the automation.
IFTTT has a selection of pre-made GitHub integrations, none of which do the thing I wanted, so I created this one from scratch. Be advised at some point in this process you will be prompted for your GitHub credentials. I forget which step. While logged in to IFTTT, click the create button at the top from any page:
At this point you may get an error about accessing the repository. I got several. After a while I got an email from GitHub.
Follow the link and configure it to allow repository access. Mine looked like this when I was done:
Got back to IFTTT to finish creating the applet.
The beacons are lit!
Get your pull request on, and…maybe immediately, maybe eventually, the trigger will fire and light your dumpster fire.
Room for improvement
This was a lot of fun to put together, but there is more I wish it could do. I wish it would turn off by itself, but there is no way to do that on the free tier of IFTTT. I wish I could make it light with different intensity and color for different events, but that would take a more advanced LED setup. Finally, I wish it was more responsive to GitHub events, but it uses polling instead of web hooks or push notifications. Maybe that is supported for the paid tier as well. But for now, I’m very pleased.
The Eternal Optimism of the Spotless Repository
We’re programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand…It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time.
Joel Spolsky in Things You Should Never Do, Part 1
There is a fleeting moment in every software project when it is absolutely perfect. It is the time between clicking “New” and “Save” in your code editor. In that brief interval, limitless potential and beauty. In every moment that follows, compromise and doubt (but working software, too!). Thus rule #24:
The original sin of code is writing it.
Me
No wonder the siren song of rewriting from scratch is so hard to resist. It’s a chance at redemption. But what about an entire programming language? The creator of JSON thinks it’s a dandy idea:
The best thing we can do today to JavaScript is to retire it. Twenty years ago, I was one of the few advocates for JavaScript. Its cobbling together of nested functions and dynamic objects was brilliant. I spent a decade trying to correct its flaws…But since then, there has been strong interest in further bloating the language instead of making it better. So JavaScript, like the other dinosaur languages, has become a barrier to progress. We should be focused on the next language…
Douglas Crockford
Replace JavaScript with the name of whatever you’re working on, and this conversation happens everywhere software is being made all the time. The causal disdain for “dinosaur languages” is a nice touch. Joel has something to say about that too:
Before Borland’s new spreadsheet for Windows shipped, Philippe Kahn, the colorful founder of Borland, was quoted a lot in the press bragging about how Quattro Pro would be much better than Microsoft Excel, because it was written from scratch. All new source code! As if source code rusted.
We all know how that worked out for Borland.
Of course, JavaScript is terrible. Is it scalable? No. Is it maintainable? No. Is it portable? Not really. But to paraphrase Winston Churchill, JavaScript is the worst web programming language, except for all the others that have been tried. As bad as it is, it’s pitfalls and shortcomings are thoroughly documented and understood. It is ubiquitous. As a working software developer, you’re almost certainly better off spending your time getting better at the language you’re using than jumping to a trendy new one. With JavaScript you may not enjoy the journey, but you will reach your destination. If you have the time and money to chase utopia, by all means please create the perfect language. If you have to ship a product to put food on your table, choose the devil you know over the one you don’t every time. And thus rule #17:
Legacy == proven
Also me
Everything I whish every developer knew about SQL Server queries
…summed up masterfully by Brent Ozar in just 45 minutes. All the ways you’re doing error handling wrong and don’t even know it, why that table valued function is going to bring the pain, and so much more. This should be required viewing for anybody who writes T-SQL.
Recommended Reading
Early in my career, I read everything I could find trying to become a better programmer. Over time I realized the most helpful material didn’t deal with a specific language or trendy workflow, but instead dealt with the psychology and philosophy of software development. Eventually I collected the ones that made the biggest impact on me and offered them to new team members as recommended reading. They reflect my problem solving and management philosophy pretty well.
The Old Testament – Joel Spolsky
- Don’t Let Architecture Astronauts Scare You
- Can Your Programming Language Do This?
- Craftsmanship
- Fire and Motion
- Hard-assed Bug Fixin’
- Human Task Switches Considered Harmful
- Rub a dub dub
- Set Your Priorities
- The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
- The Duct Tape Programmer
- Things You Should Never Do, Part I
- The Law of Leaky Abstractions
The New Testament – Jeff Atwood
- It Came From Planet Architecture
- Sucking Less Every Year
- The First Rule of Programming: It’s Always Your Fault
- We Make Shitty Software.. With Bugs!
- Why I’m The Best Programmer In The World*
Apocrypha – Ted Dziuba
UI Wins #0 – Retool FTW
Noticed this gem trying out the Retool quickstart demo. Retool looks like a web version of MS Access, which I think is long overdue because not everyone wants or needs mocks and models and interfaces and tests and controllers and an api and dependency injection and my eyes glazeth over just to add a record to a fucking table that no outside user is ever going to see. Rock on Retool.
The only blockchain developers need to worry about
…is the chain of blocked tasks in the backlog. Ever leave a sprint kickoff feeling really confident about the planning that was done, only to find your team stuck a few hours or days later? No matter how well prioritized the backlog is, “priorities don’t mean anything if you can’t make progress” as rachelbythebay explains, and gives some advice on how to untangle the chains.
The Lair of Leaky Abstractions 
You must be logged in to post a comment.