I do my best to remember what I have learned, to think outside the box, to be creative and break the code into smaller parts when necessary, but it...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
This may not work for coding challenges and Im not sure why number of lines matter. But below is what I follow for real time problems
A key for me is reduction of variables. So like removing lines of code debugging etc.
I think this applies to general problem solving. Figure out what you don't have to worry about first.
A good teacher on youtube once said:
This approach really worked for me!
Right
I tend to find that if a Developer is going to go "off the reservation" they'll do it in chasing that bit of optimization that gets us from 6 lines to 5 or whatever... so I try to stay focused on the words "Solving Problems" rather than "with Code".
First iteration: Solve the problem.
Second: Clean up egregious stuff.
Try to stop there unless new information comes to light or unless the system is life-and-death - because otherwise, you can spend a lifetime tweaking something - the returns diminish rapidly.
I have learnt the hard way that diving headfirst into code is a bad idea.
My process is simple.
This reduces time spent figuring out how stuff work when writing the actual code.
My first step to solve a problem, is setup the state structure which collect a necessary data from input and good enough to represent the goal data.
After that step I just need to make two method:
This method work even complex problem, when state are some stream.
I usually start by breaking the problem into smaller, manageable parts to clearly understand what’s being asked. Once I’ve grasped the requirements, I try to relate it to any standard approach or technique I’ve learned—either from coursework or practice. I actively solve daily problems, like LeetCode’s Problem of the Day (POTD), and regularly follow structured problem-solving sheets like Striver’s, which also include detailed solution approaches. This routine helps me recognize patterns more quickly and apply the most efficient solutions. Hope this works!
Just break the problem into smaller problem -- (just like tagline of recursion 😅)
My approach to solving problems with code starts with understanding the why—what exactly needs to be solved and who it impacts. I break the problem down into smaller, manageable parts, then plan a solution before touching any code. I usually write pseudocode or draw diagrams to map things out, then start building iteratively—testing and refining as I go. I also try to keep things simple and readable, because future me (or someone else) will thank me later. And when I get stuck, I ask questions, read docs, or look for patterns in how others have solved similar issues. Problem-solving with code is as much about mindset as it is about syntax.
Back in the day, I used to do codeforces. good times.
Oh wow, that sounded like an awesome one!
Yes, although I was not very good at solving. My highest rating was 1150, which was considered mid.
That is well done as well :)
I totally agree. Problem-solving is the real core of programming. My usual approach is to break the problem into smaller chunks, write down what I think should happen step by step, and only then start coding. I also try to rewrite the problem in plain language before jumping into syntax.
Funny enough, I sometimes take short breaks when stuck, like browsing random things to reset my brain. The other day I ended up scrolling through the kfc menu while debugging a tricky function 😅. It worked, though the solution clicked right after!
For my experience it depends on what you work. If you try with coding challenge is understand the proble, write a brute solution and then improve the solution. Instead if you talk of developing a code or an app or website, only studying and practice.
Really loved reading all the different takes here!
For me, it’s all about progressive breakdown. I usually start high-level (what’s the actual outcome?) then gradually break it into smaller chunks that I can test fast.
Totally agree with the idea of solving the problem first, then worrying about polishing or line counts later. That mindset helped me ship real features in the wild where messy > perfect if it moves the needle, haha
That said, trimming lines on platforms like CodeCombat still feels like solving a puzzle on expert mode. Super satisfying when you crack it!!
Usually I like to stop and think if I did understand the problem and what it's asking me to do, paper and pen are always close to taking some notes and breaking the problem into smaller parts. If I get stuck, I ask myself, Is it a logical or language problem that sticks me.
Nice thoughts! I also break problems into small steps and test as I go. One thing that helps me is pretending I'm explaining the problem to someone else—it often gives me new ideas. Shorter code is cool, but clear code that solves the problem is even better.
Pretty cool seeing you trim the code like that, feels nice when it clicks. For me, most of the time it’s just chipping away even when it’s slow, and every now and then it adds up.
I think it's always a trade-off between writing concise code and keeping it readable and maintainable. I usually aim for clarity first, then try to simplify without losing meaning.
The first thing i start with is removing any duplicated code and export them in separate functions, then make components as less dependent as possible.
In my experience, the simpler a solution is, the better it works. After that, I just try to go with the flow of the code and try to optimize it at the very end if it is needed.
I like to sketch out the smallest possible solution first, then layer improvements. Do you find the code length challenges change the way you think about problems?
Aha, I see. Hm, perhaps. It certainly forces you to become more creative!
I always choice the first and simplest solution that comes to my mind and make it better later only if needed or if I have extra time
I use print/debug statements if needed to trace logic.
Honestly, trimming code down always feels so good for me too - feels like cracking a puzzle.
It truly does!
I just readthedocs.Io
I have just read some great insights.