How a Biochemist Ended Up Writing Engineering Parables

The unexpected path that led to the Mill series

Photo by Marcin Kolodziejczak on Unsplash

Anyone who knows me personally or has worked with me knows that I don’t have a background in computer science, and the fact that I’ve been working in software engineering for close to two decades might surprise anyone hearing this for the first time. That’s because I graduated with a bachelor’s degree in biochemistry back in the late 90s.

Now, I’ve always been attracted to software engineering, and ever since I got my first computer back when I was oh, 10-11 years old, I’ve always had a computer nearby that allowed me to be creative and just let out some of my creativity by building applications and games and solving puzzles. But I never really thought that I was going to be a software engineer.

What I wanted to be was a scientist, and I dreamed that I would be the one person that would crack open the meaning of DNA, and be able to read it like a cookbook. Sadly for me—but happily for humanity—that feat was completed while I was still in college, pursuing my degree in biochemistry. And I figured that since my objective had already been done by someone else, then the next thing for me would be to invest my time in learning how to do gene therapy, especially using viruses as the vehicle to deliver the DNA payload, if you will, that could fix genetic mutations as early as possible during the gestation of children.

Here’s how I planned it all out in my mind: Parents would come into my clinic (I also dreamed of pursuing a PhD/MD after my bachelor’s, but that’s another story), we’d run tests to detect genetic anomalies, and then engineer a virus capable of attaching itself to a handful of embryonic cells and surgically correcting the defective pieces of DNA. All future cells naturally grown through the normal process of cell division would carry the “fixed” version of the DNA and the anomaly or defect would be eradicated as early as possible.

That was the dream anyhow.

When I graduated from college, getting a job was hard, especially because I only had a bachelor’s degree, and the truth was that my physical condition would not allow me to do the kind of activities and tasks, especially manual activities, that would be required for me to work independently in a lab. I guess I sort of naively thought that my degree would allow me to do more of the research in a lab, and maybe have someone who could help with the physical tasks, or at least be an aid and help me with them.

But I was young—and who was willing to pay a young kid, plus an aid, to help him? I was pretty bummed when I graduated, especially so when there were no job offers on the table for close to 18 months.

In the meantime, I started making a little bit of money here and there by taking on some “IT”-related or software engineering-related tasks for friends and relatives who knew that I knew my way around computers and was pretty comfortable in the nascent world of the internet.

I’m talking about the late 90s, so people would pay me to fix a printer (paper jams, mostly), speed up a slow computer (lots of defragmentation and virus scans) or sometimes just write an application that would automate something that was repetitive to them.

One thing led to another, and eventually, I ended up working for a pharmaceutical company as a software engineer for about, well, 4 or 5 years. I guess that was my way to still stay close to what was then my passion.

But I moved around, went to different places, and software engineering became the thing I did for a living. While I still can remember my goal of becoming the one person that would eventually come up with some kind of gene therapy that would revolutionize health in the world—yes, this is how big I used to dream—I eventually realized that where I could have more impact and where my physical disability wouldn’t be a factor or wouldn’t play a factor in my ability to do the actual job was software engineering.

Software engineering became the thing I did for a living

Now, because I like to read a lot, eventually I met someone who mentioned a book that I hadn’t heard of before: “The Phoenix Project” by several authors, but Gene Kim is one of the, I guess, most well-known and popular of the authors that wrote it. The first thing that struck me when I read the book was that it was… well, basically the story of how to manage a team that works with software engineering and how to work around and resolve the typical problems that one sees and faces in this industry. Things like dealing with unreliable teammates, handling shifting priorities, how to handle stakeholders who are very demanding or high-risk situations. Stuff like that.

“The Phoenix Project” covers everything from those topics and more. But it is told in a format of a parable, which is something that I hadn’t seen before. And the fact that it is told as a parable makes it really easy, in my opinion, for people to read and relate to.

So there I was reading this book, and it felt like they were talking directly to me. And a lot of the problems that the main protagonist of the book faced and had to confront and resolve hit really close to home because a lot of those things I had either already gone through in the past (and not learned how to deal with) or I had learned, but the hard way, through the school of hard knocks, as they say.

Some of the challenges from the book were also new to me, and reading it really helped, and although the book came out in 2013, I didn’t read it until about two years later. I was very impressed, and as a matter of fact, I make a point of re-reading it every other year because I always find something interesting there.

There’s also another book by Gene Kim called “Accelerate,” this one, published in 2018, and I did read it as soon as it came out. This one, especially the first half, spoke to me directly because once again, it touches on a lot of the things that I face during my workday. But it also offers a clear framework that’s easy to understand and implement that shows you how to take a bunch of individuals and turn them into a highly effective and highly efficient team without burning out your teammates or treating them like cogs in a machine.

The second half of the book is a little bit more dry for me. I would say this is the mathematical part of it, the more data-driven part of the book. But still, a lot of the ideas are also really good. I try to re-read “Accelerate” every now and then.

And that brings me back to the point I’ve been trying to make.

The format of telling a story as a parable is something that stuck with me, and I’ve always thought that one day I would like to do something like that. And I guess this is really the motivation behind my last 3 posts about the folks who work on a mill, where they face a lot of the typical pressures, troubles, and problems that a software engineering team would normally face.

If you haven’t checked out the “Mill” series of posts that I’ve written, I just wanted to provide a little bit of a context so that you know what it is that I’m trying to do.

And if you have been following it and you’re wondering where the examples are coming from, I guess I will leave that up to your imagination to figure out, if I’m drawing from real life, or whether it’s based entirely on imagination. I hope you’re enjoying them — and if you are, stay close; the next chapter of the mill is already turning.