How to be a great programmer everyone knows. But how about the other way around? I've listed down here some mistakes that many beginning programmers make (I bet you've already made or seen someone make most), and why not. Have a good time.
"Good morning, here I fixed a bug and improved the system", it may sound like a joke but I've seen a commit like the one before. It sure is inspiring. It sure motivates you to work harder. And it sure makes you think for 4 seconds before you understand what just happened.
Don't make other programmers think, much less with motivational commits that say absolutely nothing. This is completely annoying and costly.
Your comments are a book, so play Shakespeare
What do you think of the commit below?
// the function below is intended to analyze a CPF document
// which can be acquired when dialoguing with responsible bodies of the
// Brazilian government and aims to identify a person
// physical by an 11-digit number
// the function will validate the CPF record through a calculation that
// will demonstrate if the CPF is correct or if it is simply a set
// random numbers passed by the programmer
Let's start with the fact that the comment has 7 lines that could be summarized in just changing the function name to
validaCpf. Afterwards, read this comment: it says absolutely nothing relevant to the developer. It is simply a virtual garbage that, in addition to bringing absolutely nothing. You could change this function to:
Then you can ask "but you removed all comments". That's right. A comment should only explain what the code cannot do on its own. I generally only use comments for extremely confusing things, like a regex expression hanging out in the middle of nowhere. It doesn't have to be Shakespeare, just have common sense.
Gambiarra no, permanent temporary improvement
It's okay to do a workaround to solve a problem that the customer is reporting in 5 minutes and then spend more time to do it correctly without the customer noticing that the resolution took more than 5 minutes. The problem is when you do the workaround and don't fix it later. If you do it once, you'll do it again, and it snowballs, until the system turns to chaos.
Just don't do it, try your best not to make mistakes or dirty code, and if you do, fix it as soon as possible. It is vitally important to "keep the house in order" and avoid complete anarchy in your project.
I'm an expert at making "Hello World" in two billion languages
Weekend has arrived and you have decided to learn something new. Instead of starting a course on improving your favorite framework, you, like every weekend, see that the xyz language is on the rise, and decide to learn a little. You install the language compiler, download a super complete and chunky IDE, snap your fingers, create your "Hello World", and... you never touch it again in your life...
Does it remind you of something? Yeah, we all have this phase, but try to get rid of it as soon as possible. There's nothing good about jumping from branch to branch in the world of technology, there's nothing wrong with wanting to learn a different language, but stop learning a new language every week.
I'm going to add these two hundred libraries to make my page static
You want to build a static page for your form, then you create a project with React, import Materialize, JQuery and SwiperJS, then add Babel to get it running in older browsers, add a different router made by an Indian, then add a little WebAssembly with Rust and a little more WebAssembly with C++, add FontAwesome and Google icons, and when you realize that Materialize doesn't meet you 100%, you still add SCSS, Sass and two third-party libraries that need SCSS and Sass. Soon after you realize that you have a nice script in CoffeeScript that could make your system look nicer and more functional. All in all, your system works, but it's a complex, heavy Frankenstein that doesn't seem to make a lot of sense.
It's okay to add different libraries, but keep the system lean. Putting more libraries into the project increases the complexity of the project, as well as the weight and difficulty of maintaining it. Add only the essentials and drop the "Frankenstein architecture".
It's okay to put this variable with the name "numx" here
There's nothing that makes you more angry when opening code than variables that don't describe its purpose and are used all the time, forcing you to read the entire context to understand what it does. This wastes time, creates disorganization, and makes it extremely difficult to understand developer code. Add names that make sense, and that save you time
Testing technology in production is awesome
You are a beginner Ruby on Rails programmer, but an experienced programmer in a completely different framework, and you decide to start a freelance Rails project from scratch to learn. This project will be doomed to failure, and you'll have to deal with delays, bugs, and a host of other things that would be easily fixed if you knew the least bit about the subject.
Learning projects and testing are for just that: testing. Don't test something completely new in production or on a short-term project, take time in between to deal with a test project.
Do you know Debian's motto: "the system will be ready when it's ready"? Yeah, leave it to Debian. It's not very professional for you to take too long a time to deliver a task, a project, or anything else. If you're still on a larger team, not delivering a certain task on time will mean that other tasks dependent on that task will also be on hold, and you could be hindering the development of the entire team.
Agile methodologies are hipster programmer bullshit, the thing is to program as you see fit
Have you ever heard of XGH ? It's a frequent joke with this type of programmer, who simply does everything without worrying about best practices, standards or anything else (and one day the boat sinks, but that's okay). Programmers who program this way, ignoring standards, methodologies, and the way other programmers on the same team act are the cause of complete anarchy in teams, with snippets of code that make no sense at all and large snippets completely out of step with the rest of the code. Please don't be a fan of XGH. I will thank you.
SVN? Git? Nah, I version with .zip files
There's always the guy who delivers his projects in a zip file and who version the code by creating new zip files called
How to be a bad programmer
t.1.0.2.zip and so on. This isn't just ugly, it's archaic, dysfunctional, slow and leaves a bad impression. It's even more agony when you have to maintain a code like that. This is acceptable just for the beginning of your learning with programming, don't go with it later, it's going to get really bad, and it's extremely difficult to maintain decent code with it.
Choose a versioning system such as Git, SVN or whatever you like, learn how to use it, and use it. Zip is for compressing files, not for versioning code...
I'm the one who has to understand the system, the customer to turn around
Nothing worse for the user than software that doesn't describe itself, software where you need to enter 3 different menus to perform a simple action, or actions are not where you expect them to be.
The rule that everyone should take to themselves when developing anything is DON'T MAKE ME THINK!!! If the customer needed to think to take an action, it's because their system is messed up. And it's no use saying "but I can do it in seconds, it's very intuitive". Don't forget that for the Chinese Mandarin is extremely intuitive, but for you it's just a bunch of doodles that look like magic. Just do it the way your user thinks it should work.
Do you know how I can find out if the system is messed up or not? I call my little sister and ask her to use it. If she needs to ask me anything at all, she's too confused. Don't have a sister? So find a friend, a neighbor, someone layperson who is capable of being a guinea pig. I bet it will be better than having to think about how someone else thinks...
Python or Java? Nah, I'm going to learn to program with BASIC in DOSBOX
It's not uncommon to meet the different programmer who wants to learn to program with a completely unrelated technology, but do you really want to be the guy who learned to program with VBScript on Windows 2000 on the team or with some other unusual language?
Programming different things can be fun, but have a main focus, something you are able to use in your everyday life, or do you really think a company is going to hire you to program with 1964 BASIC? Or with Windows Batch?