There Has to Be a Better Way

Why I'm Where I'm at Today

Cover Image

I realized something the other night as I was thinking whether I would need to justify why I wouldn’t have (m)any examples in hip, modern languages like Rust or Scala or Go. There was a time when I would be eager to learn whatever new language was out there, even when I was focusing my career on .NET. What changed? Is it because I’ve lost that youthful energy? Well, let’s go back.

First, I’m a very curious person. As a kid, computers always outpaced my curiosity so I continued to chase it, like a greyhound chasing the mechanical rabbit. I was hungry and eager to learn more.

I think more than anything else the one thing that has brought me to where I am right now is the phrase “there’s got to be a better way.” It became a mantra of sorts at Microsoft where I saw dysfunction all around me. I was always on the look out for new technology, tools and patterns that would help me do my job better and more efficiently and help me avoid traps. I had the thought that if only syntax was different or if there was more syntactic sugar all our development problems would be solved.

While there are aspects of programming languages that can improve the development experience and reduce the chance of bugs (see generics in .NET compared to Java) almost any modern language will suffice for writing good code. The more important factor is how code is written and that is where I believe the answer lies. I have built a philosophy around writing code that focuses on maintainability and sustainability so the choice of programming language is only a small part of the system. Sure it’s better if a language has Inversion of Control built into the language, eschews global variables, and prevents bad patterns; those aren’t necessary. I don’t need a language to force me to write good code because now that I know the principles I don’t (usually) want to stray from them. And language syntax isn’t going to help you learn why principles are important.

That’s not to say if someone built a programming language from good, solid programming methodologies that it wouldn’t make it better code. It would be like bumpers helping keep your code within the walls of good design.

Ultimately, my search for a “better way” to write software has slowed. Sure there are things that could be better. But with the team I’ve built and the process we’ve developed the job of writing software is enjoyable and the quality of code we create is very high. Now the “problems” to solve are around inter-team dynamics and external relationships. I mean, there has to be a better way, right?