I’ve been writing software for many years. And I’ve realized lately that the more I engaged with (wrote in, integrated with, etc.) open source technologies, the better the code I write gets. Which got me wondering: correlation or causation?

Reading Code Makes You Better

I learned early on in my programming career that the more code I read, the better my code became. I learned that when I had to maintain other people’s code, simple and clean almost always beat fancy or complex code – even if there were comments. On the other hand, when I took enough time to understand the complex code, I usually learned new tricks. Either way, I improved.

This led me to push for code reviews in shops where we weren’t doing them. And when there ‘wasn’t enough time’ to do code reviews officially, I would browse the repositories and read the code on my own. Of course, back then I was limited to the company source from small teams.

Going Beyond the Syntax

While you inevitably had to wrestle with the syntax of any programming language, that’s the most trivial aspect of learning how to fully leverage that language. The syntax of a language tends to be pretty static, and if you get it wrong your compiler will complain. Deeper lessons involve what kind of problems a language is best suited to solve (“right tool for the right job”), and how best to write code in that language so it is efficient and maintainable.

There are many ways to pick up a new language; courses, tutorials, mentors, books and more. I often use combinations of these options when I learn a new language. One thing I noticed is they are frequently very similar when it comes to the non-syntax elements. Obviously following recommended practices.

When you read real deployed code from other people you get something more. You learn patterns and practices beyond what’s in normally structured learning. The “correct” way to do something in a language is not always what works best. You see the edge cases, one-offs and unexpected integrations. You will see solutions to these issues, both good and bad, but if you really think about it, this is where “recommended practices” are born. Today’s pattern is tomorrow's anti-pattern.

You may have strong feelings about things such as ‘always comment’, ‘commas go at the end’, ‘indent x spaces’ and of course you’re ‘right.’ I’ve had very strong feelings about those and other aspects of coding.

As I read other people's code sometimes I would get angry that ‘they were doing it wrong.’ As I read more, I started to understand that there were situations common in other people's code that I had not encountered in mine and my way could be unnecessarily more difficult. I not only changed some of my opinions, but I am learning to be more flexible.

Open Source is Everywhere

As the open source movement grew, so did the amount of code available to read and learn from. With sites like Gitlab, GitHub and BitBucket we can pull down fully functioning applications to not only read but tinker with. I rarely encounter something I want to learn that doesn’t have at least some open source code available to play with.

I remember starting out with a new language and stressing over simple things such as directory structure and naming conventions. Now I go look at a few different open source projects and I can start to piece together common approaches. I rarely stress over these types of things anymore.

Nowadays there is so much code available, both good and bad. When you’re learning, you don’t really know which is which. Just keep reading and you’ll learn to tell the difference. Reading ‘bad’ code helps you understand why it’s ‘bad.’ The key is not being afraid to try whatever you think looks correct, admit when you get something wrong, fix it and move on.

Bad Code Is Bad, or Is It?

Some would say “there is more ‘bad code’ out there than ‘good code.'” Here’s a sub-reddit dedicated to bad code.

I’ve written plenty of good and bad code over the years. When I look at my older code I often wonder how I could have written such crap. This really means I’m still learning. If I can look at my old code and think it looks great, it means I’m not growing.

So how can we learn from bad code?

The More Bad Code You Read, the Better You Will Be at Spotting It

As you’re learning and searching for examples, you will find and use a lot of code that doesn’t quite work. Remember, just because it doesn’t work for your situation, that doesn’t make it bad. Learning how to make it work makes you better.

How Do You Know It’s Bad?

People love to criticize. Read the comments, if you see a lot of ‘WTFs‘ you may be looking at the bad code, figure out why it’s bad. Please don’t be one of those people who just leave a “this code sucks” comment. Don’t assume you know all of the requirements for the bad code, there may be a valid reason for the way it’s written. If you can see why it’s bad try to leave a constructive comment. Or…

Don’t Leave It Bad

Put in a pull request that makes the code better. Fix the syntax, use a better method, add comments or fix the indentation; these are all great ways to help. Add a good explanation for why you are recommending a change.

I learn more when I help someone else learn than I do on my own. If I think I understand a new topic I go looking for someone to explain it to, this makes it stick in my head and I quickly find out if I’m writing bad code.

Give Back

Remember open source works best when there is participation. Code changes are welcome in most projects, but there are lots of ways to contribute.

Test open source code (you know you want to!) and file bug reports; help complete the documentation set; write tutorials and how-to examples; participate in the conversations – or simply help spread the word. Everything makes a difference, and the more fingers in the pie, the better!

Resources

Here are a few links to help get you started. Some I’ve worked with, some I haven’t yet had time to dive into. If you find something useful – or something that needs correction in this post, please don’t hesitate to share it.