DEV Community

Cover image for The Art of Understanding Before Coding
Vitor
Vitor

Posted on • Edited on

The Art of Understanding Before Coding

Some developers when receives a task starts thinking about implementing the requirements, whether it will be complicated or not, the piece of the code to be refactored, or something like that. You shouldn't think about code before understanding your business.

Split

If you're this developer, I suggest splitting the process of understanding and organizing the task to implement the requirements.

It does not make sense to start doing something you don't understand. If you need to know if you understand something, an excellent way is to write about it or draw the task - using Excalidraw, for example. This process will force you to understand the task, think about problems, and help you ask the right questions. Some questions that would be nice to ask yourself, for example:

For features

  • Why is this feature important?
    • What kind of problem this feature is solving?
  • Who needs this feature?

For bugs

  • Conflict the wrong and proper behavior;
  • Think about what logs are saying;
  • Understand the nature of the bug
    • Does it happen during some specific flow?
    • Does it happen for a wrong implemented business logic?
    • Can you reproduce it?
  • If it is from a ticket, what is the customer reporting?

If you think that you understand it, try to draw it. Something like this:

Image description
(image from researchgate)

Code

Now that you think about the problem, you can start to think about the implementation. If you are doing it well, you will believe that the code is the more uncomplicated part of the process. And the crucial is to understand what to code.

With it, you can reduce the scope of code debugging and start to visualize your app in chunks instead of wasting time writing or reading something unrelated to your task.

You will probably write less code and deliver your job faster and with more quality. Also, you will improve your knowledge about the business and the code and will be more efficient in helping others in your team.

Conclusion

Ultimately, the deal is that you understand that you would split your task into steps and start by really understanding what and why you are doing.

Don't worry about time. This process can take some time, but the deal is always to try to understand what you are doing.

Banner from unsplash

Top comments (0)