7 Reasons We Suck At Coding And We Need To Fix That

With too many boot camps and coding initiatives, more and more people are flooding to develop software. In fact, some programming knowledge has become almost essential for the modern job market. This is in part a very good phenomenon as it democratizes the development of technology to a wider range of people. But this also comes with a price; the quality of the produced code cannot survive the rapidly changing technologies.

Let’s be clear: we cannot control how people write code nor force them to follow good practices. This is basically because programming is intellectually challenging and everyone has their own way of thinking. If you ever get the feeling that your code doesn’t look good, this is probably because of one of these reasons:

1. We google solutions before we think about the problem
   Once there is an error, we immediately copy and paste it to Google without thinking about what could be the problem. What happens next? We solve the problem with something we don’t actually understand; all we know is that it solves the problem!
2. We stick shitty pieces together
   When we continue doing #1 in every problem we face, we end up sticking different pieces of solutions together, again without understanding what they do. Congratulations! we have a large piece of horrible code.
3. Algorithms? huh!
   Programming is not always about using existing packages or libraries. Sometimes, we have to connect the dots. For that reason, algorithms play a joker role to have efficient implementations of common tasks. For example, we might have a better running software just because we changed the algorithm that sorts a list of users on your application. But we don’t really care about algorithms. Do we?
4. The recommended design pattern
   Our code works and produces the expected results, But it does accomplish that with either bad execution time, or many unnecessary memory usage, or furthermore with repeated, ugly and unorganized code. Why? because we just broke the recommended design pattern. So what? next time, we will break more patterns and our software will end up (again?) being a large piece of horrible code.
5. Create problems now, solve them later
   We know the code runs and it has a major wrong flaw that may be exploited, and we don’t fix it now because nobody is going to trigger this scenario. Well! it’s gonna be sooner than we think.
6. Look back into your 1-year old code
   If you don’t believe me, have a look at a code that you wrote a year ago. You would feel like a 5-year old child could have written a better code than that (I just did now and felt sorry for myself, and my code too). Don’t worry programming is a skill and we continuously improve ourselves at it.
7. We need a code reviewer
   In high-school, we always have a teacher to review our homework and give us feedback. This is how we educate ourselves. However, in writing code, we don’t have the luxury of reviewing our code all the time (unless we work in a team who cares about code quality).

For all of these, I think we need to get better at code reviews and peer programming. Git Flow helps development teams adopt a clear methodology for that. But what about freelancers and hobbyist programmers?