Why It’s Important to do Unpaid Open Source as a Paid Developer

Programming is an art. And just like any other art, it can be distilled down into easily digested parts that you can profit from. The problem is that by putting this profit layer on your art, you’re psychologically more likely to do less. This was shown in a study done by Desmond Morris in 1962, and witnessed by anyone who’s ever gone from doing code because they loved the challenge, to doing it for a paycheck. The luster of the quest for control loses its sheen, and suddenly you’re just gathering tickets and knocking out patches.

That’s why I say it’s important to add that layer of unpaid open source into your routine. And going off of the study I linked to above, the earlier the better. The chimps in the study permanently stopped enjoying their artwork as much as they had before being paid for it. If you can trick yourself into not looking at the paycheck as the product of your code — or artwork — and instead look at it as simply paying you to show up, you’re a step ahead.

This is easier if you’re salaried. If you have the freedom to not go into work one day, and it won’t affect your paycheck, then you’re effectively not getting paid to do your artwork. You’re just getting paid to be.

But the easiest way, by far, to trick your mind into working better is by doing your artwork for free. Find an open source project that you love, open the tickets, and fix one of them. It’s that simple. Submit your patch, and then walk away. Don’t stick around and wait for the merge, don’t refresh the screen until you’re single handedly DOSing Github. Just walk away. Check your email later, or just go find another ticket, and keep doing it. Do it for the love of the code, for the search for the answer, and feeling you get when you hit submit.

Just don’t do it for money.

Thank you, Netflix, for telling me I have a problem…

I absolutely love the fact that Netflix has most of the shows that I love to watch in it’s streaming catalog. The technology itself is a display of engineering genius, being able to direct high quality content to my Xbox without a lack of quality and lag. That said, in their efforts to expand and improve their customer service, they’ve just gone too far.

I like series. I like watching them. I like watching the stories unfold over multiple episodes. And I binge, I binge on entire seasons at a time. This was never a problem before. Now it is. Because now, it seems, every 3 or 4 episodes, it pops up a message asking me if I’m still watching.

This isn’t an issue on the website, but on the Xbox, it’s a pain in the ass. I’m watching TV, watching a series, I get involved in it, get comfortable, and want to just relax. The controller is across the couch, and I’m relaxed, cuddled up under a blanket with a drink and my wife. And then that damned box pops up.

No, Netflix…I’m not watching…that’s why you’re still on.

Normalization – Use It

So I might just be a bit of an overzealous code nerd, but whenever I download a snippet of code, I always analyze it, and try to make sure it’s up to snuff. So it was no surprise that I did this when I was looking at an email newsletter plugin that I was thinking about using. The problem this time was I didn’t even get to the code before stopping.

Wrong format

  1. admin@gmail.com,admin1@gmail.com,     (Comma at the end)
  2. admin@gmail.com,,admin1@gmail.com     (Two comma)

Why is this bad? It’s called Normalization, people…

…use it. Being the devoted coder that I am, I managed to figure out the solution to this dilemma, in less characters than it took to type that instruction to the end user.

This uses trim to strip away any leading or trailing commas–the first incorrect format–and then uses str_replace to replace any commas that are doubled up into a single comma–the second incorrect format. Simple, efficient, and a single line of code. It can be run when you validate that you actually have a value in that field… I mean…you do validate that, correct?

Why is normalization so important?

To put it simply, the end user doesn’t always know what they’re doing. To make a truly usable product with a wide appeal, you need to normalize the input so you can reasonably predict what’s going to be there. In the example above, the developer ignores this aspect of development, and instead puts the responsibility of input sanitation on the end user. This isn’t good design, it’s also not good customer service.

The end user doesn’t care what’s entered into the box, as long as what comes out on the other side is correct. Good software design should be able to interpret user input in such a way that it can say, “Hey, you probably didn’t mean to do that, so let me fix that for you. It’s okay, no big deal, it’s what I’m here for.”

Get It? Normalize?

Get It? Normalize?

The New TravisWeston.com

If you’re a repeat visitor, you’re probably noticing that this is different than it was before. I’ve gone and done it again. I’ve created a new instance of TravisWeston.com, and removed the old posts and files.

Why?

Well, the basic reason is that I wanted to get back to promoting my programming. I fully intend to move my writing blog to it’s own website, and I’ll post a link when that happens. Until then, it’s back to the freelancer grind for me!