My nephew, Brandon, is a budding director. He’s an 11th grader with a ton of talent. I’ve enjoyed his videos for years, but none more than this one he created with two of his high school classmates.
Author: Nick Bradbury
Android’s Fragmentation Problem Is Being Replaced by the Support Library Problem
Android has long labored under the shadow of a “fragmentation problem” that makes it tough to write apps that work reliably across the many devices and platform versions. I’ve written before that this problem is overblown, yet it’s not without merit.
Google has done a lot to address the fragmentation problem, including creating support libraries that make new features available on older devices. These libraries have been a huge help to developers like myself.
But I’ve noticed my fellow devs getting less enthusiastic with each support library release. Sure, we look forward to the new features and bug fixes – but we’ve learned that with each release comes a new set of problems, some of which are specific to certain versions of Android. We’ll spend time coding workarounds for these problems, then have to revisit them the next time a support library is updated.
This situation is starting to resemble the fragmentation problem the support libraries were designed to address. Instead of writing code to deal with problems in specific Android versions, we’re writing code to deal with issues in specific support library versions.
The Code That No One Touches
Every app that’s been around for a while has code that no one touches.
The rest of the code may be great, but there’s that one area written a long time ago that everyone is scared to work on. It’s so fragile that if you touch it you’re likely to break something, forcing you to descend into its unfathomable depths in order to repair it.
If you do have to work on it, the rest of team turns somber and treats you like a soldier headed to battle. They know they won’t hear from you for a while, and there’s a chance you won’t return.
Perhaps one day you announce you’re finally going to refactor that code. “It’s ridiculous to have this awful code in our app, and I’m going to correct it,” you foolishly say. A few days later, after discovering new swear words as you try to figure it out, you decide now isn’t the best time to fix it. “Maybe I’ll tackle that after the next version ships,” you proclaim, secretly hoping nobody remembers you saying that.
When a new developer is hired, the rest of the team wants their first task to be repairing that old code. They’re new, excited to be on board, and eager to prove themselves – so let’s welcome them by throwing them into the dark pit that hides beneath our software.
But that never happens, because the people in charge don’t know about the problem. Nobody mentions it to management for fear of being assigned to take care of it.
And so the old code lingers, like a basement closet nobody wants to clean out. The code that no one touches never goes away.
Monty Python and the Holy Roller
It’s only Sunday, but I can honestly claim to have had the highlight of my week already.
There’s a local rock radio station whose weak signal sometimes gets overlapped with that of a religious station. This has led to delightful moments such as a Primus song morphing into a hellfire-and-brimstone sermon.
This morning, for some reason the rock station was broadcasting parts of Monty Python and the Holy Grail. As I drove out of my neighborhood the scene with the French taunters was playing. I heard John Cleese utter, “You tiny-brained wipers of other people’s bottoms!” and then it suddenly changed into a hymnal.
Maybe it was a “you had to be there” moment – but I was there, and I found it so hysterical I almost had to pull over.
Cartoon: The Salesman
My daughter is reading Edgar Allen Poe’s “The Raven,” so I figured I’d dust off this old cartoon of mine which was inspired by it.
Septoplasty and the Deviated Stunt Man
Yesterday I underwent septoplasty surgery to repair a deviated septum I’ve had since childhood.
The injury was the result of pretending I was a stunt man when I was a kid. I enjoyed throwing myself onto foldable chairs and tables like I was in some sort of bar fight scene, and one time it didn’t go well. ‘Nuff said.
I’ve had breathing trouble and sinus infections ever since that day but avoided corrective surgery because of the horror stories I’ve heard about it. This year my nasal woes became so severe that I decided to finally have it done.
Turns out it’s not that big a deal, at least not in my case. The surgery took about an hour, and the only real issue for me has been the mental fogginess and irregular sleep caused by anesthesia. I have two splinting “straws” in my nose which are pretty uncomfortable, but they’ll be removed in a few days.
As part of the procedure the doctor cleaned out my sinuses and removed a number of nasal polyps that have affected my breathing. I can already breath better despite the straws, and within a few weeks I expect to feel like I’m wearing Nose v2.0.
This is the third of my youthful compositions. I almost didn’t share it because it’s full of mistakes and teenage pomposity. I probably had a very serious look on my face when I played it :)
Here’s another short song I wrote as a teenager. As with the previous song, I have no idea why I named this one what I did (I probably just thought it sounded cool).
Back When I Wrote Music
When I was a teenager I composed piano instrumentals. Every now and then I dreamed of making it as a musician, but really I only played for fun (I still do, but not nearly as often as I used to).
At one point I borrowed some recording equipment from my older brother and made a cassette tape containing several of my songs. That cassette miraculously survived nearly three decades of neglect before being converted to MP3.
Here’s one of the songs. I wish I could provide a thrilling back story for it, but I can’t remember what I was thinking about when I wrote it and I have no idea why I named it “Lost Prelude.” I do, however, remember that I wrote it in 1985 (the year I graduated high school), and it’s the only song I still remember how to play.
Code is Temporary
Developers sweat blood writing code but in the end our code will vanish. That language you’re learning or framework you’re devoted to will disappear in short time. At some point what you create will only be able to run in some nostalgic emulator.
Your code isn’t important: what matters are the ideas your code brings to life. Shitty code that makes a point is better than perfect code that proves nothing.
Don’t waste your short life getting lost in the geeky details of the toolkit du jour. Spend it using your skills to create something that matters to you, that may even last longer than you.
Most developers have far more power than we realize but too many of us squander it building things we don’t care about. Now is your time to make a difference. If you don’t do it now it may never happen.