DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Cover image for 6 Big mistakes most beginner software engineers make πŸ™ - I wish I knew this when I started programming 😒
TURINUMUGISHA Souvenir
TURINUMUGISHA Souvenir

Posted on

6 Big mistakes most beginner software engineers make πŸ™ - I wish I knew this when I started programming 😒

Every master was once a beginner. And every pro began as an amateur. ~ quote by Robin Sharma

As Robin sharma quoted none is a master that was not a beginner. What only differenciate a beginner from a master is the experience gained through all the journey.

Getting started into programming can be thought as something simple as well as you have your PC and access to all the materials needed to get started but the more time you spend into it, the more your eyes get opened and realize all the stupid things you've done and the time you've wasted.

When i started programming I did 6 big mistakes that I wish I had got someone to alert me about them before I got started. I've also seen alot of beginners that I tutored trying to do the same all the times. I lost alot of money and time that I don't wish anyone else to loose.

NOT ALONE
πŸ™‹πŸ™‹

In this tutorial, I will be sharing you these 6 mistakes and how you can avoid them if you are just getting started or have started already but have the same bad habits.

1. Trying to learn alot of things at once

When I was getting started, I had what we call FOMO (Fear Of Missing Out) and its something I see in alot of young developers these days where they want to be up-to-date to each latest trend in Software Engineering. By the time,You could find me learning more than 5 languages at once and even jumping to more advance concepts and framworks before I knew the fundamentals

At the end of it all, I knew it was just a wastage of time because how this industry is set, none hires you because you just know alittle of many trending technologies. No, Companies need someone who master a certain language and is probably the best at it.

Please please πŸ™ don't rush. Focus on one language and start from fundamental concepts, not just rushing to advanced ones or frameworks. This will not only make you a master at that language but also make it simple for you when you try to learn something else.

2. Jumping into code too quick - Coding without planning

This is the most common mistake of programmers that they write code without thinking and planning.
As a beginner engineer, you have so much excitement to code and nothing else.

If you are the kind that jumping to code is the first idea or solution that comes to your mind when you get a problem to solve, you will end up wasting a lot of your time. Resist the temptation to code and think about alternate ways to challenge your own assumptions first. Yes, some of this comes with experience, but it's good to build the habit early on.

It applies to both small applications and large applications. You require to think and plan in advance before coding and this is a rule. The correct process to write quality code is Research. Plan. Write. Validate. Modify.

3. Googling issue

I categorize googling issue into two things.
The first issue that's much common to absolute beginners is not knowing to search for what they need.They waste their time in solving a problem when they can google it and find a solution to a problem. Google helps you to understand that what you think is a problem is not really a problem and stop fixing it. So Google it first. Being creative sometimes doesn’t mean everything you are doing is correct.

google it

The second issue is using search the bad way. this is that you search for something because you are stuck and need some help. But the moment you find a post that gives you the solution, you just copy-paste it and move on without understanding how they solved it and why you could not. You solved your immediate problem, but you didn't fix the root cause. This is very dangerous because it leads you to become the kind of engineer that solves problems in a very hacky and patched up manner without understanding the actual inner workings of your own solution.
Image description

Please use that keyboard wisely πŸ˜‚πŸ˜‚

Don't be the "stackoverflow dev". It's okay to look for solutions online, but when you find one, make sure to fully understand how it works and to fill gaps in your own knowledge that led you to being stuck in the first place!

4. Preferring quantity to quality

Ambiguous code is waste and it cannot re-create. While programming or coding focus should be kept on the quality of the code. By quality I mean code should be readable and clean. Don't repeat yourself and Don't feal eargered to clear ambiguous code because you think it took you a long time to write. If you don't focus one code quality and just code you can't stand out for sure. Being to working, doesn't mean its optimized. Optimize your code again and again till they reach the best standard

5. Just picking a solution because it's probably the first

This point is connected to the fourth one, While you might think your first searched solution is all inviting and true, good solutions are found after evaluating all possible solutions you find. Coders should be able to find multiple solutions to a problem. If you are unable to do so that means you do not understand the problem. As a programmer you need to find a solution that is simple enough to read, understand and maintain. Instead of rushing towards implementation, think about the potential failures of the solutions and try to find the solutions of a problem in the simplest way.

6. Not reading others' code

This is so common, it's not even for absolute beginners only. I've seen great devs who can code up quick, effective solutions on their own, but completely crumble when they have to contribute to any project that is not their own. The reason is, they are just not used to reading other people's code. Reading other people's code, understanding it quickly and being able to debug through it is a skill on it's own! So start building this early - because you will be doing a lot of this in your job, and reading others' code can sometimes be more challenging than writing your own. The end goal as you progress through your career is to not only be able to read a codebase that multiple devs have worked on, but understand the big picture quickly and identify areas where you can improve.

A great way to build this skill early on is to go to open source projects, read the code there and try to understand what is going on. Even better if you can identify some improvements and put in a pull request to do so!

I just want to keep this article short, Let me conclude

Conclusion

You might be worried that you are making alot of mistakes after reading this article. But don't panic,

stay condifent

It's just a part of the journey. The only bad thing you can do is persisting on not correcting what you've seen as a mistake. Stop worrying about best practices and focus on what you can do best. Invest enough time in research and find good practices that suit well for programming. Do not go looking for best practices on the basis of what others found. Best practices come from own research and practices. Rely on self-searched steps for quality coding. Every content is different from others and every good practice does not necessarily apply to all.

Done πŸ˜€

Boom! We are done πŸ˜€, its your turn now to share us what you think about the article and any mistake that you might have done that you think others should avoid.

Stay tunned! Bye πŸ™‹

Top comments (3)

Collapse
lukeshiru profile image
Luke Shiru

I agree with some items, disagree with others...

1. Trying to learn a lot of things at once: Yes and no. Is ok to take a look at a bunch of different things until you find whatever you like the most and then focus on that.

Companies need someone who master a certain language and is probably the best at it.

There are companies out there asking for people with 100 years of experience in a technology that was released last month. That doesn't mean this is a valid point to avoid learning whatever you want yo learn, it only means there are shitty companies out there and you should avoid them.

2. Jumping into code too quick - Coding without planning: Nope. Go ahead an code to your hearts contempt. The best way of learning is making mistakes and learning from them. Is not wasted time, you're investing that time on learning. Is way more important to gracefully take feedback for what your wrote and keep improving.

3. Googling issue: Let me tell you an industry secret: The seniors need to google stuff as well. We only are better at googling stuff than the juniors. The only issue is the XY Problem, when a junior comes with a problem that's not actually what they want to solve, but what they think they want to solve. Also, there's not problem with copy & paste, just read and understand that code before pasting it into your codebase.

4. Preferring quantity to quality: I tend to agree on this, but I would say is more of a 75/25 ... like 75% of the times chose quality, for that 25% of the times where you need to finish that feature right now and you know you'll be able to work on that debt later, then chose quantity/speed.

5. Just picking a solution because it's probably the first: I agree, but I would phrase it as: "Compare solutions before committing to one", and similar to what I mentioned in the response for 3, read and understand that code before using it.

6. Not reading others' code: I feel this is a common topic, and the one we agree the most, but yeah, blindly copying and pasting code will take you nowhere. Do as much as possible to understand the code you use if you didn't write it yourself, and if you don't understand, then ask. You'll find some asshole devs around that don't want to explain their code, but in general we are more than happy to explain it and help you grows as a dev.

Cheers!

Collapse
sauvejeanluc profile image
SAUVÉ Jean-Luc

Well Explained Shiru,
Good Article @Turinumugisha

Collapse
turinumugisha_s profile image
TURINUMUGISHA Souvenir Author

Thanks

🌚 Browsing with dark mode makes you a better developer by a factor of exactly 40.

It's a scientific fact.