As a few of you know, I was briefly employed from the tail end of February until late last Thursday, when I got downsized. It was an excellent group to work with and I plan to stay in contact with those guys. While I can’t get into too many of the details, it wasn’t due to performance or anything like that. It’s just that the sort of clients I work with sometimes have things change out from under them and things go in different directions. It stinks, but life is full of surprises. If I wanted a boring, perfectly safe job, I’d get that tomorrow (and some HR algorithm would probably reject me, but let’s just go with the optimistic case for now). That’s not what I do though. I’ll go back and work for them again in a heartbeat if the opportunity presents itself.

As software developers, one of the main things we are tasked with is the automation of business processes. Typically, we’re given a task to do, with much of (if not all of) the process laid out and told to get it done. As a result of this sort of thinking, it tends to be our default mindset to either attempt to automate everything, or to avoid automating anything in our own workflows. The decision of when to automate is something a lot of developers struggle with, as it’s very easy to either put up with irritating, repetitive processes, or to get lost in the weeds trying to automate something that really isn’t worth bothering with.

I know this is a bit outside the normal content for this blog, but since I get asked frequently, I figured I would share my method. It usually takes me an hour or two in total to build a blog post, although some of the longer ones might take as much as three hours. I do sometimes get interrupted, but for the most part, I’m able to write the whole thing without too many problems. I’ve refined the method over time to help improve my speed as well.

’ve been developing in JavaScript for a long time and have seen client side techniques evolve drastically over that time. However, I have to say right now is about the most frustrating (and promising) time to be working with JavaScript in a professional capacity that I’ve seen in many years (and possibly ever). Let’s do a little retrospective of what I recall from back when I started really getting into computers.

Sometimes, the truth is remarkably annoying and not what you told yourself it would be. So it is with managing website, both your own and those of others. People talking about these things often seem to be doing so with rose-tinted glasses on, as you’ll discover that it doesn’t all work like that. Here are some things I’ve learned on my little journey through being a webmaster.

Probably at least once every couple of weeks, I get into (sometimes heated) discussions with other software developers about their careers. I see so much helplessness, so much hopelessness, and so much dependence on others and it’s all entirely unnecessary.

So, it’s time I said some things that need saying. It’s time to smash some ugly, easy lies so that beautiful, subtle (and often difficult) truths can flourish. It’s time for me to have THE TALK with you (no, not that one, this one). It’s time for me to tell you why you are absolutely nuts as a software developer not to be making progress towards self-employment. After more than a decade in this industry, I can tell you that the best time to have gotten in business for yourself is five years ago. The second best time is right now. Below are some very good reasons. It may sound like I’m bashing employers; I’m not. It’s just that their concerns and yours are increasingly not intersecting. As a consultant, that is fact number one in your mind; as an employee, it should be, but is easily ignored until it can’t be ignored.