What actions you should take when you are stuck on a coding problem

Theodoros Kokosioulis — Wed, 05 Aug 2020 03:09:58 +0000

This post was originally published on June 30, 2020 on my blog.

Have you ever felt stuck on a coding problem? I know it’s a rhetorical question 😛. It’s almost impossible not to get stuck at some point throughout your career as a software engineer and not only once. This is the nature of our job. To solve riddles every day. We accepted that reality when we decided to get involved with code either professionally or as a hobby. Even senior software engineers will encounter unknown concepts for them. If you are in this position I can totally relate with you. I know very well how frustrating it can be. First things first, do yourself a favor and don’t beat yourself up or even worse don’t start having doubts about your existing skills and your experience. That’s something you definitely not need!

Don’t worry though, I’ll do my best and try to help you by giving you some tips that personally helped me go through such situations in the past.

1. Read the documentation

Yes, I know this might sound mundane but trust me this can be most of the time the solution to your problem. The documentation will (almost) always provide you with what you’re looking for. Even if it is poorly written, a simple search to its API could be proved very helpful. Personally, I refer to the documentation before jumping into other mediums. Be sure you have a clear understanding of the input, processing, and output expectation of each code unit and how that matches the principles on the documentation. Many times I have started working on something without even reading the documentation in the first place believing that I’ll figure it out by myself and had nothing but an undesired result.

2. Break it into smaller chunks

This is the first principle of software engineering. I’m quite sure that you have never worked on something complex enough and you managed to get it to a satisfactory point without breaking it into smaller tasks. This is how we go from A to B point. We have the big picture in our mind but in order to achieve the end result, we go step by step and build around it.

3. Search Google

We definitely can’t neglect the help of the Google search. They say that a good Googler is a good software engineer as well. That’s 100% true but that, only, is not enough by itself. It’s not only the Google search per se but the fact that you have to know exactly what to expect on the results. You’ll become more experienced on that as time goes by. You’ve probably seen that before. You searched for something and you didn’t get back what you expected from, but when you modified your query you finally got the answer to your problem.

4. Ask for help

Don’t be afraid to ask for help. No one born to know everything at the beginning. Colleagues, stack overflow, Facebook communities, and slack groups are one of the best mediums you could address your problem to. Always a second pair of eyes can make the difference. What may appears to be elusive for you might be obvious for someone else. If you need instant support from an experienced software engineer I highly recommend using codementor.

Conclusion

I hope you found these tips useful enough! Let me know which one(s) you use often and what other approach have you taken to tackle this situation.

10 mistakes I made when I started programming

Theodoros Kokosioulis — Sat, 18 Jul 2020 16:37:26 +0000

This post was originally published on May 31, 2020 on my blog.

01. Self-doubt

This feeling is something that anyone can have and does not apply only on programming but in every aspect of life. Personally, I believe that the self-doubt is the number one mistake you can make as a beginner programmer. When you think that you’re not good enough or smart enough, then you will never achieve what you are aiming. I believe that anyone can learn to program to at least a basic level, if they stick with it.

Code might seem very daunting at the beginning and you’ll probably think that this is not for you. That’s normal! But day by day and with constant occupation you learn what each part does, and it’s not scary anymore, and then you see it starts making sense and how things are connected together. Undoubtedly, there are people that can grasp notions of algorithms very quick and write good code sooner than others, but, without hard work and hours spent on actual coding, reading tutorials/books will never reach their full potential.

02. Not linting my code

Do you want to know if the code was written by an experienced programmer? If yes, then you should be able to see a well-formatted code having consistency on indentation and its logical structure. By tabbing or spacing code in from the edge of the window, we show where functions, loops and conditionals start and end, so we can be sure all our code is in the right place. That makes the code readable and less prone to syntax errors that could lead to bugs in the long run.

Here comes the linter which is a powerful tool providing an easy way to scan your code and fix any syntax anomalies. You can easily use Prettier alone just to format your code, which works just fine. But, if you combine this with an ESLint process, you get both a powerful linter and a powerful fixer.

03. Poor variable and function names

I used to name the variables and function names just with whatever I came up with when I was writing code. Apparently, that was a huge mistake. One of the best factors that indicate that the code you’re working on is clean, the function turn out to be pretty much what you expected to be. Therefore, naming variables as descriptive as you can is one of the first and most important things you can do to create code that feels expected.

The intent of the code becomes a lot clearer, and you can easily understand what a function does by just reading its name. And apart from that, when you will have to deal with legacy code you will thank your past self for giving proper names to both variables and functions in the first place.

04. Belief of knowing it all

After some days or months of persistence and hard work on learning how to code and when you see some actual results then it happens! Your confidence grows, you feel powerful having the fundamental knowledge for building things and you feel you can take on the world! This is awesome, and you should enjoy that feeling of finally having the computer do what you want it to.

But don’t forget that you’re still just learning. You will still have so many concepts to learn, so many ways of improving your current code and this is, perhaps, a good time to start looking back at your old code and reflecting. Which parts of your code do you understand one hundred per cent, and what you would do better? Maybe it’s time for some refactoring as well?

05. Planning too much before writing code

Planning before jumping into writing code is a good thing, but when you over do something it ends up hurting you eventually.

Do not look for a perfect plan. Look for a good-enough plan, something that you can use to get started. Very often the business requirements change and that means your plan can be easily affected by that. Thus, don’t spend too much time on planning.

Writing programs is an ongoing process. Code is like a living organism. You will add features you have never thought about, you will remove features because of reasons you would never have considered. You need to fix bugs and adapt to changes. You need to be agile.

06. Messing with the master branch

I remember myself pushing code directly to master branch instead of creating PRs. As a result, when I needed to revert something was such a pain. The git history was pointless since there wasn’t any branch to checkout to. Essentially, we create branches so that we can roll back to an earlier version of our codebase.

Do not mess with the master. The master branch is deployable. It is your production code, ready to roll out into the world. The master branch is meant to be stable, never push anything to master that is not tested, or that breaks the build. Creating branches for new features and bugs should be non-negotiable.

07. Not writing tests

I admit that I belong to those who don’t like writing tests. However, I understand the importance of having your codebase tested. Although writing tests increase the duration of a project, it can become the savior for the future. Undoubtedly, it’s fine to test your code manually, but writing code to automatically perform the exact same interaction can save you to avoid bugs the next time you add more code to the project.

08. Not questioning existing code

When I am working to codebases that other people push code too instead of me I used to take it for granted that the code is good and the practice they used is the ideal one. I assumed that since the code is working it should be good. I was wrong.

Consequently, I was more inclined to repeat that bad practice elsewhere in the codebase because I learned it from what they thought was good code.

Indeed, some code looks bad but it might have a special condition around it that forced the developer to write it that way. Hence, this is a good place to wonder why this code was written in that way and which purpose serves.

09. Not being fan of code reviews

I used to fear the criticism that lies behind code reviews. This is a lie. If you feel that way, you need to change this attitude right away. Look at every code review as a learning opportunity. And most importantly, thank your reviewers when they teach you something. Code reviews are there only to make us better.

Sometimes, the reviewer will be wrong and it will be your turn to teach them something. It is a two-way interaction and the only goal is to make you both enhance your skills.

10. Not taking breaks

We are humans and our brain need breaks. I know that sometimes we can be really absorbed in the flow state and we forget to take breaks. It is always very helpful to leave the chair, take a short walk and think about what is the thing we need to do next. Coming back with fresh eyes always leading to resolving that bug you were dealing with.

This has been a long post. You deserve a break 😄

DEV Community: Theodoros Kokosioulis