Many seasoned programmers, especially those that work in a professional setting, tend to heavily criticize aspiring or hobby developers, such as myself, about their code. “How dare you use the global namespace?”, they may scream at you. “How could you possibly assume this variable will not be taken by something else? How dare you camelcase a class name?”
A lot of hobby programmers tend to teach themselves the technologies they use. They read example code, they figure out the concepts from several different manuals and tutorials, and put their knowledge to use by building apps they can be somewhat proud of. Yes, a beginner hobbyist developer may feel pride towards a 40-line slot machine they have written. And, as it turns out, a lot of online tutorials don’t even share opinions or conventions. Is a slot machine less of a slot machine because it’s a slot_machine and not a SlotMachine? *watches screenreader users instantly switch to character review*
Code conventions are there to be respected, of course, by open-source projects that have the chance of being used and edited by a substantial group of people. Open-source projects should definitely try to follow code conventions, just to make it easier for people who want to help with development. This has become even simpler lately with the use of linter software. But should we really cram loads of directive, shoulds and shoudln’ts into the mind of any poor average Joe who just wants to make a game and have fun?
I have been programming for about six years now. This is not a long time at all. I have taken multiple long breaks from it. But I would like to think I’ve grown up. And because of this, I sometimes think about what I would have done different and what I hope wouldn’t have happened to me. Sometimes I even think back on my own behavior and wish I would have done things differently. This is one of those moments, and for those aspiring developers such as myself, I have decided to write this post, in hopes that one sentence or two will stand out to someone and help them in their hobbyist developer career.
Humans are adaptable
The truth is, every half-seasoned programmer hates dirty code. Nobody likes confusing variable names or unreadable one-liners. And the beginning of that last sentence sets up the main point of my argument: a beginner programmer will eventually become a seasoned programmer.
I myself have gone through, and am currently going through, a huge adaptation process. My first game had lines such as this one:
While I was actively developing the game, I of course knew what those variables meant. I disregarded people’s suggestions about making my variable names self-explanatory, because those names worked just fine. Then I took a break from it for a couple weeks. When I came back to it, I saw this line and lost all the motivation I had saved up. While this did signify the end of that first game, it also taught me why I should, in fact, name my variables properly. I did not learn this from the people who shouted at me about it. I learned it because it was necessary for my own sanity.
The same happens with more seemingly unnecessary conventions. Eventually, a developer will need the help of external dependencies to extend their software. When your coding style matches (or is at least similar to) the supporting packages, things just fit together. And most of the time, being yelled at is, yet again, unnecessary.
We adapt to the situations we find ourselves in. We try to make them more comfortable by changing ourselves. This, to a greater extent than people think, applies to programmers too. When we find out that our practices confuse others and even ourselves, we try to change them to match.
With this, I am not saying conventions should be ignored and we shouldn’t let beginner programmers know about them. But there is a huge difference between showing someone why a convention should be followed or suggesting it should be, and causing discouragement by openly and non-constructively criticizing other people’s code.
Everyone starts with “Hello World”
Many times I have seen beginner programmers being laughed at for posting the simplest of games to forums with some degree of pride. Less often, but still occasionally, I have witnessed this behavior in fellow developers. But what makes this acceptable?
I still remember my first days of coding. I got frustrated at BGT because I simply could not get a four-line script to work. A four-line script that initialized a string variable and displayed an alert with the variable concatenated to a string literal. I remember thinking programming was just not for me.
And a few years later, I released my first few games. I thought I would not get past string concatenation, and every aspiring developer does at first. But eventually we do. And the first guess the number game we make is a huge confidence boost. And so is the moment when we add sounds to that guess the number game and it works.
Developers, more than anyone, should know that every step is a big one for a newbie programmer. We shouldn’t blame them for wanting to share their accomplishments, and should instead encourage them to go on and try something more challenging next time.
In most cases, learning to code takes forever
Some beginner developers start off with a clear idea. Some want to create the next big social network. Some have written a story for an RPG and want to bring it to life. But it is important for beginner developers to know that their goal should not be their first project.
One of two things usually happens if a beginner pursues their end goal as their first project:
- They look at the technologies they will most likely need. One thing leads to the next, the list grows, and the beginner developer begins to have no idea where to start, how to start, or what to use. This is really discouraging and it makes newbie developers fear code.
- The developer doesn’t think to look at external tools. They will take whatever they have easy access to and work with it. As a first project, this eventually causes the idea to be whittled down to a level where said tools can handle it, which causes an incredibly underwhelming result.
As much as beginner developers should have ambitions, they should also know their limits. You can’t start building a house from the roof down. As much as it seems stupid to newbie programmers to work on smaller projects before embarking on a larger one, I think it is very important to do so, just for the sake of practice and developing a code style. Practice makes perfect, as they say, and this also applies to programming.
To the aspiring developer
Don’t be scared of code. Have respect towards it. Tame it slowly. Don’t let it limit you. Listen to those with more experience, but don’t let them control how you write.
And always remember: “If it ain’t broke, don’t fix it!”