Being a new parent; a software alagory

This weekend my son turned 1. This got me thinking about how so much of what I've had to learn as a new parent is similar to working in the software industry.

You don't understand the scope till your responsible for it

Prior to my son being born, we had no hands on experience with what it's like to have a child. Sure we babysat, a lot actually, and were comfortable around kids. We'd changed a million diapers. But we'd never sat up all night with a child with a fever. We'd never had to monitor a child's eating or sleeping routines. Babysitting, was just not the same as actually having a child. I've found that with parenting, most of the challenging stuff happens in the not-so-obvious areas of life. I think it's similar with engineering.

The challenge of working on a software product isn't on the surface. It's not about just understanding the language or platform. It's not about intellectually understanding the features and road-map. It's about understanding the nuance and not-so-obvious areas of the product. It's about understanding where your customers will be spending their time and what their pain points will be. You can understand software at an intellectual level but it's not until you try to change something, build a new feature, and/or take on operational ownership that you really start to understand the new product.

Everything has limitations

Every person has limitations. Newborns for instance can't talk. They can't crawl, can't feed themselves, can't really do much for themselves other than cry, sleep, and poop. As a new parent you learn the limitations of your child and (in the short term) help them compensate for their limitations and (in the long term) help them learn the skills necessary to overcome them.

A software product is much the same way. In order to help the system really thrive and succeed you need to understand it's limitations. Sometimes you have to put in short term fixes or mechanisms that allow them to work around these limitations. But in the long run, you need to be looking at how you can make the system better. How you can help the system overcome it's limitations. Sometimes this means refactoring. Sometimes it means prioritizing tech debt over new features. Sometimes it means recognizing a systems in ability to succeed and failing fast.

It doesn't grow unless you feed it

You're responsible for the care and feeding of the system. To do that you need to learning about the system as a whole unit, understand what change is necessary, and help to shepherd those changes through the system. Your software has upstream and downstream dependencies. Your job is to identify those dependencies and work to harmonize how your system runs in the context of the existing ecosystem.