6 common mistakes programmers make when starting out

6 common mistakes programmers make when starting out

Programming is a journey, a continuous process of trying to become better than you were yesterday, writing code that is readable, usable, and maintainable.

It is more than just writing codes, you have to develop a knack to solve problems, think creatively.

This might be easy to say, but it's actually possible. Over 5 years of coding, I've made and seen some mistakes which other programmers have made while learning to code.

See yourself as a problem solver

This might sound funny because of course, as a developer the solution you build might actually solve a problem, but a lot of developers see themselves as X developers; instead of problem solvers.

Simply put, an X developer is one who sees himself/herself as one who knows X language.

Imagine someone who doesn't know programming decides they want to be a software developer. They go online and find a code school that teaches them how to write software in Python. They learn enough to build software using Python.

Voila! They are now a Python developer. Learning more about Python and trying to get better at it. Frankly speaking, that is not bad at all.

But then the company where they work decides to use Node, suddenly, their knowledge of Python isn't as valuable and the Python Developer has a few choices: become a Node developer, stay a Python developer at the same company while the job becomes less significant, or go to another company.

The point is real programmers don't identify themselves with a particular niche. Over the years I've comfortably shift between tech stacks depending on the project; not because I'm a fast learner. It's just that I see these tools as tools that they are and I use them to solve the problem(s) I encounter.

One book I'm currently reading to improve my problem-solving skill is Think Like a Programmer: An Introduction to Creative Problem Solving

Trying to learn everything

One thing that scares people away from programming and also attracts them is the number of technologies they have to learn.

Some are overwhelmed with those numbers, and they are like "I have to learn X, Y, and Z language to be a frontend dev", "Can I learn A, B, and C then become a full-stack dev?"

And some go to the extent of using the number of languages they know to measure how good they are, that in itself might be counterproductive if you are not building anything with them.

There are lots of stacks to learn, and the technologies keep coming. In fact in the JavaScript ecosystem, UI frameworks are released every six months. So imagine trying to learn all these frameworks with no direction.

A rule of thumb is to keep learning and using different stacks, but focus on at least one stack, subsequently, your knowledge of these stacks will grow.

Not asking questions

I use to think this was the best, you know, trying to figure out what the error was and how to fix it; I'll spend hours, sometimes days on something trivial just because I was thinking that was the best way to learn.

I'm not saying you should not try and fix bugs, of course, that's one of the things that makes you a software developer, but spending immense time and effort, sweating out, slamming the keyboards, gnashing your teeth is not the best.

Asking questions is a skill every developer needs to develop, why sweat out and waste so much time when you can ask for help.

There are lots of helpful resources online that are dedicated to helping you out: Stack Overflow, Github, Laracasts, etc.

One more thing...Google!

Not getting enough practice

There is no point in reading lines of code if you are not going to practice. It is easy to make your mind think you've understood what you've read or watched, but you then discover that you make silly mistakes.

When you start getting your hands dirty early enough, you begin to face the real world, you start catching errors and fixing them.

Not writing quality codes

Apparently, there are many aspects to quality codes, but one important aspect which I'll focus on is writing clean code.

First of all, why do people write bad codes? It's simply because they don't write clean code.

Writing clean code is an art, an art you have to inculcate, an art that requires discipline.

Writing clean code requires the disciplined use of a myriad little techniques applied through a painstakingly acquired sense of “cleanliness.” - Clean code: A Handbook of Agile Software Craftsmanship

Just like you can't learn a language in a day, you've to keep learning how to write clean code, in fact, writing clean code is one of the qualities every developer should have.

And I must tell you, it is easy to start writing bad code and forget that it's bad.

Bad code breeds a buggy codebase, buggy codebase breeds slow solutions, and as you may know, slow solutions damage a company's reputation.

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - John Woods

People are only exposed to what they know, something that has helped me to write clean codes is reading other developers' codebase, not just any developers; developers who are obsessed with clean code, developers who take clean code as a priority.

One book that has helped me write clean code is Clean Code: A Handbook of Agile Software Craftsmanship by Robert Cecil Martin

Host your projects

Many developers don't see the need to host their projects. But there are lots of benefits: people see your work, you get opportunities and also grow yourself.

It took me a while to start hosting my projects on Github, but then I realized it was a way to grow myself and let people see my work. Sometimes, words of mouth are not enough.

Happy Coding!