Making Of Things

Follow The Money

By Jud | October 16, 2017 | Comments 0 Comment

I read this quote in a completely non-software context last week, and it’s been rattling around in my brain ever since for its implications in numerous disciplines:

“It is difficult to get a man to understand something, when his salary depends upon his not understanding it.”

I’ve had experiences where I’ve been trying to explain the benefits of automation to people whose job descriptions include large amounts of manual work. Or more significantly, managers whose bonuses are directly tied to the profit they can bring in via labor hours billed to the customer. Needless to say those explanations fell on deaf ears.

That’s just one example. I’m certain there are more.

Phantom Fix

By Jud | October 9, 2017 | Comments 0 Comment

I’ve got good news and bad news. The good news is that the system is working now. The bad news is that we have no idea why.

The above scenario plays out regularly in the life of a software developer, and it’s infuriating. In some sense it’s worse for a problem to disappear without warning than it is for the problem to persist, because without reproducibility it’s nearly impossible to determine the actual cause of the issue.

This happened to me after losing a big chunk of my Saturday night. Essentially the issue fixed itself after several retries. No idea at all as to why, but at least I could finally go to bed.

Diligence Is For Lazy People

By Jud | September 29, 2017 | Comments 0 Comment

I wrote yesterday’s post almost a full day in advance, which hadn’t happened before in the (admittedly short) history of this blog. It felt really nice when my daily 9am writing reminder went off to simply click “Publish” and get on with my day, instead of hitting snooze and hoping I get back to it later.

It brought to mind my sophomore year of college, where I learned the value of discipline. My fiancée was at a school ten hours away, and I had a randomly assigned roommate with whom I had nothing in common (and despite his pedestrian physical appearance managed to have three simultaneous girlfriends for most the year, but that’s a different story). I also had a class schedule that finished by 2pm every day.

Since I had little reason to get back to my lonely little dorm room so early in the day, I got in the habit of hanging out in the library studying until dinner. I quickly discovered that this routine completely freed my evenings and weekends of schoolwork. And that was awesome. I wasted gobs of time playing video games during those hours, and didn’t feel the slightest bit bad about it, because my work was done.

It’s Elementary

By Jud | September 28, 2017 | Comments 0 Comment

There are really only two tasks a company must perform:

Make great products
Sell them for a profit

Each employee, no matter her job title or role, must contribute in some way to one or both of those two goals. Any other task is only a means to one of these ends; everyone involved does well to remember that.

And yes, I realize strictly speaking products and services are two different things, but for the sake of pith can we consider the latter a type of the former? Thanks.

Two Days In A Row?

By Jud | September 27, 2017 | Comments 1 comment

Back in my days working for a large defense contractor, it was understood that as a developer became senior she would get involved in writing proposals. At the time I thought it an odd expectation; shouldn’t developers stick to doing what they do best, i.e. writing code?

But now I see the wisdom in getting engineers more involved in the process of winning new business. For one thing, it forces them to write, which is not a bad thing, even though it isn’t always fun. Secondly, it helps build relationships between engineering and sales, two departments which are often at odds (this is probably worthy of its own post, stay tuned for that). Finally, it gives them insight into the kinds of features customers are asking for, and allows them to be a part of suggesting creative solutions for those features.

So yeah, I’m a proponent of proposal writing. And in a completely unrelated note, I’ve got a big spreadsheet of proposal questions I need to divvy up among the team for responses. Who’s with me?

Z Is The Most Important Letter

By Jud | September 26, 2017 | Comments 1 comment

(I’ve been asleep at the wheel for far too long here, time to dive back in with a truckload of mixed metaphors).

Do you get enough sleep? Americans are chronically sleep-deprived, and a body of research is growing that tells us how damaging a lack of rest is to every other area of life (see, for example, this fantastic article). The particularly troublesome aspect is how sneaky the damage can be, manifesting itself in subtle ways over time.

A large part of being a professional software developer is taking care of your meatspace hardware. And that means getting regular sleep. The image of the late-night coding warrior who bangs away at the keyboard until the wee hours of the morning may play well on TV, but it’s false. The most effective engineer is one who rests.

The Bible Of Software Engineering

By Jud | August 28, 2017 | Comments 0 Comment

One of my all-time favorite passages on software development.

The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.

Yet the program construct, unlike the poet’s words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.

Frederick P. Brooks, The Mythical Man-Month

The Name Of Things

By Jud | August 21, 2017 | Comments 0 Comment

If you cannot say the words, you cannot solve the problem.

This is true of many subjects in the world right now, a crippling inability to call things what they are. But it is also true of software development. I’ve written before about the importance of accepting blame when something goes wrong. The first step of that process is being willing to say what went wrong, to name it with precision. Shortly thereafter the people responsible for ensuring that particular thing doesn’t go wrong should be named, not to shame them or make them feel bad, but so they can be given the opportunity to improve in the future.

While it might be easier to “not point fingers”, such an approach rarely helps an organization get better.

The Herpes Of Version Control

By Jud | August 4, 2017 | Comments 1 comment

I love git. Truly. Once I got over the fear of learning something new and dove in, everything else paled in comparison. Maybe it’s just because I was a math major and directed acyclic graphs are cool. Maybe it’s because it everything about it makes sense (kinda like Python in that respect). Maybe because it’s the foundation behind open source software development sites like Github.

But this post is not about how much I love git, or why you should use it over the alternatives. It’s about one particular feature that drives me crazy at times, and that’s tags. Yes those littles things you use to mark important places along the development tree. They’re quick and easy to make (especially by CI tools that vomit them out daily), and really useful to have around. But the darn things are nearly impossible to get rid of.

It’s not that the implementation is confusing or doesn’t have logical justification (it does). But the distributed nature of git means they spread like wildfire, and are incredibly difficult to delete across all cloned repositories. You think you’ve gotten old ones deleted, and then some poor developer who hasn’t cleaned up his repo (or even worse, the local copy of a repo on your CI server) pushes and they all come back. Argh.

For a guy who is as anal-retentive as they come about keeping his repos tidy, tags are just the worst.

Be A Polyglot!

By Jud | July 25, 2017 | Comments 0 Comment

A couple of days ago a colleague of mine was reading out loud some code he was debugging, and I could have sworn he was direct quoting from Execution In The Kingdom Of Nouns.

That story is one of my favorite warnings against the notion that software development is a “one size fits all” proposition. There’s great value in being fluent in a number of tools and approaches, and using the right tool for the job. Can this be taken to an unhealthy extreme? Of course, but in general the benefits outweigh the drawbacks.