The Engineer’s Guide to Babies

This article is exclusive to Pointer — a reading club for developers.

Garbage In, Garbage Out

Engineers learn this early on in their dealings with computers: If you supply bad input to the system, then you’re going to get bad output in return.
There is a similar premise with babies, only more extreme. In fact, the law for babies is better written as, “Anything In, Garbage Out,” because no matter what that kid eats, you’re not going to like the output.

“Have you tried turning it off and back on?”

It’s common knowledge in the computer industry that rebooting the system solves most known problems. For most of us handling remote IT for families afar, it’s the staple of our family relationships. When this technique doesn’t actually solve the problem, it at least delays it long enough for us to get off the phone and leave the house before they can call back.

Babies, on the other hand, have no such easy fix. In fact, they don’t even have a volume control, much less a power switch. There are many things you can press to make them louder, but none that will actually fix a given problem. Fortunately, the solutions to their problems are usually straightforward, from changing, to feeding, to changing again, to feeding again, and then probably changing them. Also, time and a good set of earplugs is usually helpful.

Wait until the third version

Nobody gets the initial version of a software product right, right? Because all those bugs that couldn’t be fixed by the time they shipped an already late release are in there, just dying to be discovered. So they rush out an update release, but wanted so badly to get it out there for the critical fixes that they didn’t have time to look around for more critical problems, so there are still a few more lurking in there. That’s what the third version is for.

Babies don’t have a versioning scheme, so there’s no waiting around for a more stable release. Instead, you’ll just have to help make that baby better all by yourself with a field patch. Fortunately, there are a couple of workarounds for this situation:

• Continuous delivery: Fixes can be applied to babies at any time, and the improved version can be used immediately. Babies are like web apps, only louder.
• Siblings: Sometimes, there are inherent flaws that cannot be fixed, only worked around. In this case, consider having another baby. This new baby won’t be like Baby 2.0, because the new baby will have learned nothing from their sibling and will come with their own unique set of flaws. Think of them, instead, as a companion product in the growing Baby Suite line.

Freedom of speech

One of the great things about programming is that you can often choose the language you work in, based on personal preference, compatibility with existing APIs and systems, and suitability for the domain. This builds up, in many programmers, a religious fervor about their chosen languages based on the common knowledge that if they found that language helpful to them in their time of need, it must be THE BEST LANGUAGE FOR EVERYONE ELSE EVER. While this usually results in engineers quickly losing colleagues, friends, and personalities, it is a good dynamic in our industry that we have this freedom of choice with which we can pave the way to our own, personalized Hell.

The same is not true for babies, however. They will come out speaking no language whatsoever. It’s not even assembly or machine code; it’s just noise. Instead of being a library you must interface with, it is instead a steaming pile of nonsense that you must simply listen to while you wait painfully for them to learn your language. You have left the comfort of language choice and entered the land of racket, in which no amount of type-safety, scriptability, productivity, or brevity arguments can be made, however fervently, to get that baby to speak in your preferred language.

Scheduling

Finally, one of the most important differences to realize between babies and software is that software schedules slip… but birth schedules don’t. In software, we think of the ship date as some completely fictional, minimum milestone created in a panic by someone up the management chain that had to have something to report that week in their status meeting. The team will always blow past this proposed date, and subsequent proposed dates, on their way to some time in the distant future.

Baby delivery doesn’t work that way. The doctor’s going to give you a date, and that baby has a pretty good chance of making it. They might slip by a week or two, but that’s as far as it will go. The doctor will even force a ship date if necessary, because that baby’s going to arrive. Even weirder, for software engineers, there’s a really good chance the baby’s going to release early. Now when in your career have you ever seen that happen with software?

However, after this initial timely release, be advised that your kid will be late for every other milestone ever, which is perfect preparation for a career in software.