The Ways I've Changed as a Programmer

23 Jan 2016

I’ve been doing professional software development for nearly eight years. That’s not an exceptionally long time, but it’s twice as long as the time I spent in college as an undergrad and it seems like a good place to stop and do some reflection.

I recently noticed at work that I’m now on the top of the heap with more junior developers working alongside of me than ever before. My input is weighed more heavily, my contributions are valued more highly, and I think I’m even getting small glimpses of this new feeling called “respect”. It’s an exciting time.

With all this new clout, I’ve compiled a short list of the ways that I’ve grown as a software developer.

I’ve learned to not be a control freak

Early in my career, I worked on really small teams on small, tight projects. I could know every detail of the baseline and know exactly how all the pieces fit together. I saw the projects as direct extensions of my worth and I found myself really nervous if I heard someone was trying to make some big changes. What if they don’t get my elegant designs and just kludge the whole thing up? What if they don’t have my same skills as me and turn the whole thing into an unmaintainable mess for me to deal with?

I had two options: I could constantly be checking the work of these outsiders and spend hours trying to “clean up” their messy less-than-perfect code. Or, I could just let go of my control freak nature and let them contribute like a professional. This has been incredibly difficult for me to do, but I’m finally getting around to it. If I tried to monitor every single code check-in and every change being made, I wouldn’t have any time to get real work done. On top of that, I’d look like a jerk who can’t play nice with others.

In the end, I really have to remind myself a few things:

• The success or failure of a project doesn’t depend solely on me.
• I was once a wide-eyed junior programmer who couldn’t wait to start contributing, no matter how little I knew of the code. I turned out okay.
• You gotta let things go sometimes. Walking away isn’t a sign of defeat or apathy.

I’m less concerned with style

Spaces versus tabs. Semicolons versus semicolon-free. Single quotes versus double quotes. So many battles rage on within software development teams. I have strong opinions of what good clean, readable code should look like, but these days, I’m much less apt to try to enforce it on others. We have a style guide at work for our code and I only like about half of the style choices, but I’m not about to spend the effort to try to change people’s minds on really petty stuff.

I have a theory on this: in college, I was used to doing work and getting a grade on it. It felt good to get validation. In the real world, I might go weeks before getting feedback from someone on my work, and even then, it might just be superficial. For a while, I really craved the kind of validation that I got from jshint and pylint and whatnot. To me, it was a way to write code and have someone tell me that it’s “good”.

I’ve discovered that even well-styled code can still be pretty lousy and I think I’ve outgrown the need for the praise.

My unit testing is way better

Unit testing is a skill that, unfortunately, doesn’t seem to be taught in college and most developers aren’t actively seeking out tutorials or books on how to write good unit tests. Most new developers write really, really awful unit tests, myself included. I could probably write a whole blog post on how you should go about learning how to write a good test suite (I probably will at some point).

In short, your unit tests need to meet some basic criteria:

• Independent, no external requirements, –that includes databases, network connections, filesystems, etc.
• Repeatable, you should get the same result each time you run the tests no matter what order you run them.
• Concise, you should be testing one thing in each test case.

One obstacle for me was learning how to mock out objects and modules for your unit tests. Most unit testing frameworks don’t present this up front and it’s incredibly difficult to write good unit tests without a good mocking framework in your toolbelt.

The Zen of Python is everywhere

The Zen of Python is a short mantra that describes the ethos of the Python community. It’s intended for Pythonistas, but honestly, it works for every language.

When combined with some of the things I’ve gained from functional programming, I’ve found that my code feels much more elegant and even fun to write.

I’m no longer afraid of exceptions

Somewhere back in college, a lot of programmers make the connection that exceptions crash your programs. Therefore, exceptions must be bad and you should do everything you can to remove them from your code.

But exceptions are a very powerful construct! In C code, you have to return positive or negative return codes and the calling function has to interpret them and react. I don’t want to go back to that.

A lot of rookie programmers will eat exceptions and this is universally considered bad form. Another anti-pattern I often see is avoiding situations where explicitly throwing an exception would be appropriate. Usually they will return a null value and let the calling function do a null check to figure that out.

If you’re a junior programmer and want to impress your seniors, learn some of the exception handling idioms of your language and find places where they help your code.

Frameworks are cool, but not a substitute for fundamentals

Frameworks are designed, in part, to reduce boilerplate code and the amount of cruft that you might otherwise write. I used to think that knowing a framework was a fast track for writing better code, e.g. Angular.js has modules and dependency injection so it’s halfway there to making you a JS ninja.

Well, not quite. It turns out, you’ll bend the framework to your bad habits. I’ve seen it so many times that I’m starting to understand the no-framework camp of developers.

For this, I think it’s just a lack of solid hands-on time with a language. I see developers mature in the language over time as they write code and find themselves maintaining it.

I’m going to set a reminder for myself to revisit this in 5 years and see what else I’ve learned. I could have a new job by then, a new favorite language, or a new database that I love. I don’t expect to stay the same, and that’s a good thing.