Programming, and all that goes with it

There are great things about being “just another developer”. You never burn bridges, your job is stable and respectable, your coworkers and bosses like you or are, at worse, indifferent to you beyond the work you do. Being just another developer is the best thing you can be if you’re interested in a long term, stable commitment with minimal controversy and stress.

And it is totally not for me. Read more

This debate isn’t new, this discussion isn’t new and I won’t pretend it is. The argument between bug and feature has spawned a lot of opinions from a lot of people who want to simplify the question.

Why does it matter? Because how we communicate internally matters a great deal.

Features: 

Features are things we haven’t tried before. Completely new code and functionality. It’s not hard to define, if you’re going to create whole new methods to accomplish it, it’s probably (but maybe not always) a feature.

Why it matters? Read more

Please click on the FHD tag to see all parts in this series.

We interrupt your regularly scheduled program to explain what this is. If you feel the information expressed in this interlude is incorrect, you probably won’t enjoy the rest of the series either.

My opinions are all based around the concept that no portion of software development is contained within its own bubble. Every piece must be interconnected or communications breakdowns will always occur. I won’t bend on that point, and I won’t deviate from it. There may be other and even better ways to keep things flowing, but they must flow naturally. Read more

Before reading part 1, you might want to check out the Finding Harmony in Development Primer.

Warning: All of the following statements, along with the additional entries I’ll make on this topic, are based on personal experience only. While experiences may vary drastically, this is my viewpoint on how development teams can be organized in a manner that will provide the best results and cause the least amount of friction. Opposing opinions are extremely welcomed. This is the first part of a multi-part series.

A development team consists of many parts, and part 1 of this series is going to be dedicated to defining those parts and  talking about their traditional functions. The next section will focus on altering those traditional functions to fit more inline with my viewpoints on the proper structure. In the third part we’ll talk about creating a frictionless transition from the traditional to the non-traditional.

Sometimes multiple parts of these functions will be performed by a single entity, in these cases treat them as two distinct job descriptions being performed simultaneously.

Now, the functions of a software team, in the order their responsibilities will be covered is: Read more

I’m setting forward a few goals I have for the next two months and hoping to kick the new year off right.

Get Prometheus.js to 1.0

This is huge. I will do this one.

Learn Python

#BecauseICan

Convert my Blogs to CppCMS

I’ve been wanting to go custom on this blog, and if I do, why not add CppCMS to my toolbox.

It should give me something unique to write about.

Besides, I’ve always wanted to push up a git commit to the effect of “Fixing that annoying segfault when a user double clicks post”.

Seriously, nothing on the web is double click, just stop it.

Get Prometheus.py to 1.0

Here’s hoping.

I posted yesterday about the thrill of having to get something in a hurry and as a couple of commenters rightfully pointed out, there is a dark underside to that situation. Namely technical debt.

Technical debt takes a lot of forms, from “well, just install it locally” solutions when something goes wrong with deploy, to code that you know just isn’t what it should be, but it’s quick.

We almost never get to go back and clean up technical debt, instead it just keeps accumulating. Like real debt the longer it sits the more interest it builds up as other pieces of your application come to rely on that badly formed code.

There are a few ways to approach the technical debt scenario, but rest assured that if you don’t clean it up you will regret it eventually. Read more

Every programmer has had that discussion.

“Scotty, we need you to do this yesterday,” the brave captain tells you.

“I canna do it captain, there’s nae enough time”

“Well that’s a brilliant observation, Mr. Scott, do you have any other helpful opinions? ”

Okay…we haven’t all had that exact conversation, but don’t we all want to? The point is eventually you’ll be asked to pull off some sort of last second stop gap that will require changing the rules a little. It’s inevitable, it’s almost always without warning, and it will require changing strategies mid stride. It’s the life of a programmer. Read more

Software development is a funny, sometimes cruel experience. What begins as a great idea can turn into a bitter disappointment, if you choose to get attached to the ideal of what you wanted to accomplish. There’s nothing wrong with that, but for many it is hard to deal with.

Not too long ago I was working on Prometheus and realized “This is not going to be the clean, beautiful, API I want,” and I gutted the whole project.

I still failed. Read more

Is it just me, or does it seem like everyone who develops a programming lnaguage puts in specific pieces of syntactic sugar just to allow people to debate obscura?

Recently a post has been making the rounds that explains exactly what ||= does in Rails, and the long and short of it is that it is the same as typing a || a = b.

I’m not really against sugar by itself, but why does it have to be so hard to understand the memory allocation of high level languages? There’s a small but significant difference in a || a = b and a = a || b, and most people were using the functionality without knowing which one they were getting (though they were getting the more performant of the two). Read more

Just a quick update on a few projects that are slowly getting under way here.

Podcasts - 

I’m going to be looking for some developers in the Atlanta area to join me for some podcasts. Topics are still pretty open, but the format will probably be a mix of interview and debate.

Tutorials - 

I’ve started work on a series of rails tutorials, which will kick off later this week with a tutorial on rails engines.

LiveCoding - 

This is only in the concept stage right now, but there will probably be a few live coding events coming up. The basic format will be this. Take a completely unplanned concept, implement it in a single one-hour coding session. This is mostly for kicks, but suggestions are welcome, make it something interesting.