Gant Software Systems


Announcing The Complete Developer Podcast

I’ve been away from the blog for a bit. Life got really busy back in July and I finally realized I was a bit over-committed and had to scale back for a bit. During the down time, I’ve been re-evaluating my business and trying to determine what things I want to continue doing. Blogging is definitely one of the things I plan to continue, but I needed to get some other things handled. I’ve thinking a lot about the direction in which I want to take my career as well, and I realized I was doing a lot of stuff that really isn’t what I want to do. However, that thought process also revealed a number of things that I DO want to do that will help my career go in the correct direction.

Ready, Fire, Aim!

We live in a pretty amazing world. Right now, I have on my desk several devices with which I can communicate with people nearly anywhere on the globe. I use one of those devices every day for several hours at a time, both for communication with others and to create things. The money I earn doing that is automatically put into my checking account, and I can spend it on groceries with a little plastic card that I carry in my wallet. I can even order food online and have it delivered directly to my house, for a very modest charge, that is nearly always a better choice (price-wise, not nutrition-wise) than driving down the street to get the food (at least for pizza, grocery delivery isn’t quite here yet, but will be). I could, right now (well, if I had renewed my passport) be in India, Iceland, or Argentina within a day. In short, we live in truly amazing times and are capable of things our ancestors would have never dreamed of.

Instability Is The Default Plan For It

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.

When To Automate

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.

Your Value Is Not Your Profession

One thing that separates successful career programmers from those with a bit…less success (we won’t call it failure, because it usually doesn’t manifest as abject failure, but rather as stunted potential) is their ability to figure out their value to the people who are retaining their services. Regardless of what that job posting says, what the recruiters tell you (more on this in a minute), or what you’d like to hear, you are NOT ever hired into a position simply to write code. You are hired to solve a problem that someone has, with the expectation that your solving of said problem presents an advantage greater than that provided by simply keeping (or using elsewhere) the money required to hire you. It’s a simple thing that is missed fairly frequently when discussions of programmer salaries come up, as well as when programmers sit and complain about the messes they deal with at their jobs. It also happens in just about every other industry. I’ve had similar discussions with people in other industries. The fitness industry, for instance, is loaded with people who live under the belief that the fitness program they are selling is actually the reason they have clients, instead of what the clients are actually there for, such as losing weight, gaining muscle, just the feeling of accomplishment and pushing past obstacles, etc. The dividing line between the successful ones in that industry and those who are unsuccessful is also remarkably similar, in that the latter fail to line up their offerings with what their customers are actually buying, versus what they think they are selling.

Advice for Green Developers

Someone pointed out to me the other day that I am a bit of “an old fart” in the .NET development space. At first, I was about to protest and insist that I wasn’t that old. Then it occurred to me that I have been using .NET since the first public beta, which came out in 2001 (if I recall correctly, which I may not, because I’m old). That said, as I think back over my career and the loads of developers who eventually got out of the industry, I wistfully contemplated giving some advice to the folks just getting started. The reasons for it are many. First, I want to see more people succeed. Second, I’ve watched loads of people fail (or worse, not rise to the full level of their potential), including screwing up via self-sabotage. Here, then, are some things that I’ve noticed that might serve as “lifehacks” for making your climb through your career a little easier as well as making your survival more likely.

Reader Questions - September 2014

So, I’ve been blogging for a bit and finally got something I had hoped to receive for a while, that is, some questions from a reader. In this particular case, the reader was a friend who called to ask the questions on the phone, but I thought they were darned good ones and took notes. I think committing them here is a good idea because if one person is asking a question, it’s a good bet that others are too. Further, it’s an excellent way to generate a bit of actually useful content based on what readers actually want to know, which is often a hard thing to discover, since readers tend to stop being readers if they don’t read things that are useful to them. I didn’t quite get the exact questions down, but I got enough of a gist that I think I can answer a few. I’ve thrown in a few others as well that have come up casually in conversations with other friends, as I kept the list until I had enough items to make a post out of it. Some of these I didn’t completely answer during the conversations in question because I kind of wanted to chew on them a bit.

The Rant Is Overdue

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.

The Cost of The Deathmarch

I’ve had a few projects over the years that have required insane amounts of work in a very short time period and usually have tremendous and horrible consequences for at least one person on a team (or the company as a whole). Besides the occasional server crash or “if we get this thing out, we land a huge customer” type of work, I’ve noticed some significant commonalities about deathmarch projects that I believe could be used to help an individual detect whether they are about to sign onto one. It’s hard to tell when you are interviewing, but after mulling it over, every single time it has happened to me, the signs have been there all along. So, without further ado, allow me to introduce some warning signs that I’ve noticed that frequently come during interviews or the first week of working a death march project.