Us “do it all yourself” developers tend to look at cryptography as yet another opportunity to just be clever and be done with it. At least, that’s how I felt a few years ago. Tony Arcieri wrote a pretty solid rant about why we should keep our hands out of the Pandora’s box that is cryptography if we don’t know enough:

The most important question is: are you using an authenticated encryption mode? If you don’t know what authenticated encryption is, then you’ve probably already made a mistake. Here’s a hint: authenticated encryption has nothing to do with authenticating users into a webapp. It has everything to do with ensuring the integrity of your data hasn’t been compromised, i.e. no one has tampered with the message.

If you’ve actually read the OAuth 1.0 specification, you should have stumbled on the concept. Like me, you may not have given too much thought to why HMAC signing was chosen though, which only serves to prove Tony’s point:

tl;dr: use authenticated encryption. use authenticated encryption. use authenticated encryption. use authenticated encryption. use authenticated encryption. use authenticated encryption. use authenticated encryption. use authenticated encryption. use authenticated encryption. use authenticated encryption.

Doug Hellmann wrote an interesting post on how two functionally equivalent ways of creating a dict in Python are by no means performance wise equal:

Using dict() to create an empty dictionary took 6 times longer than using the literal syntax. [literal syntax: {}]

This may come as a surprise to a lot of script kids who’ve never even given a single thought to what actually goes on below the surface of the interpreter of their favorite language. Hell, to most people, those damn .pyc files are probably just an annoyance that need to be rid in a .gitignore file every damn time you create a new Git repository.

Having personally spent a lot of time studying both the inner workings of CPython, pypy, MRI and a few other VMs, the above behaviour doesn’t surprise me at all. This goes to show that in the long run, you’re probably wise to sit down and read the source, because no matter how you flip and turn it, language implementations will always leak abstractions.

Mert Yazıcıoglu gives a few good hints as to why we tend to dump our greatest projects:

• #1: Working on so many projects at the same time
• #2: Spending ages to build a prototype
• #3: Consistently postponing the release date
• #4: Working on things that do not teach something new

In my opinion though, he misses the point of why we do projects in the first place. The kind of projects that fit the bill above are the more ambitious projects — the kind that are actually thought up as a product from day one. Well, really, it fits the second and third points, but the first and last points are symptomatic of another kind of project; the experiment.

An experiment is usually a project of a much smaller scope, and while the ambitious projects tend to eventually get done, experiments rarely ever do. Why? In my experience it’s because we tend to do them to learn a specific thing, not to solve a problem. But, most people, including me, feel like they’re wasting their time if they simply do that little bit that is the learning exercise. Therefore, experiments are often wrapped in a shell to look like a much more ambitious project, thus justifying the time spent away from “the really important things.” What ends up happening is that once the actual learning is done, interest in the project is lost and it’s put aside and is usually never finished. Really, though, the essence of the project is done. Maybe, point #4 should have said something along the lines of “the primary purpose of the project has been fulfilled.”

This leads us back to point #1; projects pile up. Because we tend to wrap experiments, what’s actually abandoned is the nice wrapping. The wrapping still feels like it needs to be done, though. One of my biggest learnings over the last couple of years has been to accept that it’s okay that I don’t do the wrapping.

Projects are not made equal — they’re made to serve a purpose.

Having always been good at learning and picking up on new things but never being able to describe why, this very introspective essay, on how some programmers are virtually stagnant all the way through their careers while others seem to always shine no matter the challenge you throw at them, provides a very good hint:

“A programmer can gain 10 years of experience, or a programmer can get the same years experiences 10 times over.”

Paul Carr has written probably the single most spot on piece about the ridiculous protectionism enjoyed by the overpriced taxi service, Uber, and the underlying problem — the mindset of “neo-disruptive” entrepreneurs:

The truth is, what Silicon Valley still calls “Disruption” has evolved into something very sinister indeed.

Sadly, this “Disruptive” feeling has spread beyond the borders of the Valley, which makes me want to sucker punch anyone who even uses the word, despite the “original” meaning of the term being a lot more fruitful to society as a whole:

I’ve written before that to be truly disruptive (small ‘d’) the startups must have a moral dimension, even when that jars with the pursuit of profit.