It’s been a few month since I reviewed my podcast subscriptions. Driving over 150 kilometers every working day gives me plenty of time to readjust my tastes and preferences. Just doesn’t leave me too much time to actually do something about it.
Podcasts are easy to subscribe to. Once you find the ones you like. Finding the ones you like takes forever though. Here’s where WP Tavern’s post “Awesome Geek Podcasts: A Curated List of Tech Podcasts” comes in handy. Cause it provides not one, but two lists of podcasts:
It’s after bits like this one, I think I should spend more time reading documentation:
Create a new transaction.
This routine should _never_ be called by anything other than RT::Ticket. It should not be called from client code. Ever. Not ever. If you do this, we will hunt you down and break your kneecaps. Then the unpleasant stuff will start.
Over the last six years, I’ve become better at using Git for version control. But my conceptions of the index, the working copy, the object graph and remotes have just grown fuzzier.
Sometimes, I can only understand something by implementing it. So, I wrote Gitlet, my own version of Git. I pored over tutorials. I read articles about internals. I tried to understand how API commands work by reading the docs, then gave up and ran hundreds of experiments on repositories and rummaged throught the .git directory to figure out the results.
I discovered that, if approached from the inside out, Git is easy to understand. It is the product of simple ideas that, when combined, produce something very deep and beautiful.
Spoken like a true hacker. My hat is off to you, sir.
A quine is a non-empty computer program which takes no input and produces a copy of its own source code as its only output. The standard terms for these programs in the computability theory and computer science literature are “self-replicating programs”, “self-reproducing programs”, and “self-copying programs”.
It’s what I call the “curse of the present.” When you, as a developer, look at the choices used to build a particular application, you’re blown away at the poor decisions made at every turn. “Why, oh why, is this built with Rails when Node.js would be so much better?” or “how could the previous developer not have forseen that the database would need referential integrity when they chose MongoDB?” But what you may not realize is that you are seeing the application as it exists today. When the previous developer (or team) had to develop it, they had to deal with a LOT of unknowns. They had to make many decisions under a cloak of opacity. You are cursed with the knowledge of the present, so the system seems like a hackjob of bad decisions.
But as true as it is, it’s incomplete. It’s not only about the previous developer. It applies to pretty much all systems that you can access as a user. Things just constantly don’t make sense. And while there are many cases of a developer being inadequate, in many more cases IMHO what you are staring is a bunch of unknowns.
It is easy to assume that the guy who did this (this being anything at all) is just a stupid idiot. But that’s only because you don’t know or care. Who’s decision was it? You might think it was a developer, when in fact it was a clueless boss. Or maybe this was the most feasible approach. Or maybe it was the only possible one at the time. How much resources were allocated for this development? Anybody can do better you say, but could they be as good in 15 minutes only – cause that’s how much time was given. Do you know which technology was used and why? These are usually very transparent.
It’s easy to judge without knowing. And I guarantee you that any system can appear terrible if you stare at it long enough. But who needs all this negative energy? Nobody. Look around, try to understand, try to improve the system and learn something new in the process, and the world will surely become a better place.