My background was linear and procedural, which means I used to think of a problem as a set of steps that needed to be executed in order. Through the years, I found out that many approaches are better than a linear one.
In fact, one of the most basic ways to split a problem into smaller ones is called decomposition. If I'm solving a problem and getting stuck on some aspect, I can isolate that part and focus on it first.
With age and experience, I switched from a linear thinker to a systematic thinker, which triggers envisioning projects as a couple of interconnected elements that must be split first and then combined to fit an entire system.
I developed a process where I try to understand the problem first, isolate it as small as I can, think on a piece of paper on how to solve the problem outside the tool, then move into code.
I can summarize the process to:
1️⃣ Define the problem by isolating it as small as possible.
2️⃣ Think on paper of a simple solution (non-coding).
3️⃣ Code the solution.
4️⃣ Test the code.
5️⃣ Get feedback from peers and use it to improve the code.
6️⃣ Repeat steps 3-5 until satisfied with the result.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
My background was linear and procedural, which means I used to think of a problem as a set of steps that needed to be executed in order. Through the years, I found out that many approaches are better than a linear one.
In fact, one of the most basic ways to split a problem into smaller ones is called decomposition. If I'm solving a problem and getting stuck on some aspect, I can isolate that part and focus on it first.
With age and experience, I switched from a linear thinker to a systematic thinker, which triggers envisioning projects as a couple of interconnected elements that must be split first and then combined to fit an entire system.
I developed a process where I try to understand the problem first, isolate it as small as I can, think on a piece of paper on how to solve the problem outside the tool, then move into code.
I can summarize the process to:
1️⃣ Define the problem by isolating it as small as possible.
2️⃣ Think on paper of a simple solution (non-coding).
3️⃣ Code the solution.
4️⃣ Test the code.
5️⃣ Get feedback from peers and use it to improve the code.
6️⃣ Repeat steps 3-5 until satisfied with the result.