Hey fellow coders! 👋
Getting stuck while coding is something we can all relate to, right? One of the biggest hurdles I face is figuring out the **logic behind my code**. It’s like staring at a puzzle but being missing that one crucial piece! 🧩
When I find myself in this situation, I often resort to solutions I find online, but they don’t always feel like the best or most efficient options. Does anyone else struggle with this? Here are a few **pain points** I’ve identified:
- ⚡ **Overwhelm**: There are countless resources out there, making it hard to discern what’s actually helpful.
- 🕒 **Time-consuming**: Searching for the right logic can steal away precious coding hours.
- 🐢 **Inefficiency**: Implementing a solution that works, but isn’t optimal, can lead to more problems down the line.
So how do you guys tackle this coding dilemma? Here are some possible **solutions** that have helped me:
- 🔍 **Break it down**: Instead of looking at the entire problem, break it into smaller, manageable parts.
- 🤔 **Pseudocode it**: Writing down the logic in plain language can clarify your thought process.
- 📚 **Study patterns**: Learn common algorithms and data structures; they often provide a base for logic you can apply in various situations.
- 🤝 **Collaborate**: Sometimes a fresh pair of eyes can spark the idea you need. Don’t hesitate to ask a friend or colleague for help!
If you’re looking for some good reads, I’d recommend:
- 📖 **”Clean Code” by Robert C. Martin** – A guide to writing code that is easy to understand.
- 📖 **”The Pragmatic Programmer” by Andrew Hunt and David Thomas** – Offers solid tips and techniques to think about coding logic differently.
Let’s turn this into a resource for everyone! **How do you figure out the logic for your code?** What methods or books have helped you? Share your experiences and tips below! 👇
Can’t wait to hear your thoughts! 🤗
#CodingLogic #ProgrammingTips #CodeNewbie #LearnToCode #DevCommunity
Give two examples of what you’ve struggled with.
Practice is usually the answer. However, it could be that you have a blind spot where someone can help you see what you’re missing. But you haven’t given any specific information.
Do it more.
There’s no general secret or trick to it.
Learn data structures and algorithms!
How well do you understand basic programming concepts like functions, scopes, variables, data types? How about control flow like conditionals, loops, switches, returns? How about how to translate that basic understanding into a specific language?
Assuming you understand programming basics: take your concepts and “program” in pseudo code or plain English.
Write that down as a series of steps. Give that collection of steps a name. That’s a program. Start with general steps. Then look at each step and break it down further until you can see the single line of code needed for that step.
Problem solving in programming is all about that work flow: given a unit of program, decompose it into smaller parts until you arrive at single statements of code.
Break it down in pieces. Yesterday I had to do a monte carlo simulation. I did it without looking for a solution online or gpt. I kept breaking the problem into pieces with mock code.
Using pen and paper also helps me when I feel overwhelmed.
> but it’s often not the most efficient one.
“Premature optimization is the root of all evil” – donald knuth, the art of computer programming
!remind me in 4 hours
I usually draw it out on paper in a flowchart like style, or write in as plain english comments in the code first.
First write a code that solves the problem then refactor your solution
>I can usually find a solution online, but it’s often not the most efficient one.
If you can’t figure out the logic, how do you know one given isn’t the most efficient..? (The answer to your question, as others have pointed out, is experience. You’ll know a bunch of strategies and will be able to think above the implementation details, just like you don’t think about moving your feet while walking)
I just write it and pray that it works
Practice. Which doesn’t mean copy a solution online and run it but rather decompose your problem, divide it into smaller problems, solve each individually, put it all together. Write a flowchart of what your code should do, write it in plain text, then translate it to code. Study data structures and algorithms in your free time, recognize the common patterns in real world scenarios. It’s a skill that takes years and lots of practice
If it’s stupid but it works, it ain’t stupid
Break down the problem into smaller and smaller pieces, until you’re left with really simple and easy to solve units.
I like to use A4 paper and then sit in silence, no phone, no pc, maybe likable music if not too distracting. Just you and the problem. I ussually know what I want or know how it should look. And then after few secs or minutes of boredom, I have written whole page of options and variations of how I should solve problem or implement the logic in app. I think boredom is underestimated and can be utilized.
Developing program logic is done by asking “what are the steps I would need to do if I wanted to do this thing manually?” and then implementing them. Those steps can involve “checking whether something is or isn’t the case” (= if/else), they can involve “do this thing for every element of this list” (= for loop), or anything else. It really is as simple or hard as that.
With practice. You start with the basic problems of “Read in a number and then make a triangle of `*` that many lines high” and bang your head against the keyboard until you figure it out and progress to harder problems and so on until you get a feel for it and it starts to become natural.
Here’s a secret: Most people starting out think that learning how to program involves learning a programming language. That’s actually the less important part. Learning how to pogram involves LEARNING HOW TO THINK. Learning how to break a problem down into tediously small pieces while still keeping track of the big picture. That’s what programming is. Java, C, Python, Rust? Those are details.
learn to pseudocode
use comments only and describe in plain english what you want to do, one line at a time
it doesnt need to map to actual code statements, but it should be broken down to where you can re-read it and convert to code
One of the things I get a kick from is going back to old projects and cleaning up the code. It proves my progress as coder, that I can see how I’ve improved and spot methods of improving efficiency. Keep your projects and look back on them in a few years time.
https://www.servicenow.com/products/devops/what-is-sdlc.html
Depends on what you are building but what has worked is writing down what you want to build as pseudocode. From there you can map out data structures, algorithms, functions etc.
just think about it
It usually comes to me when I’m exposed. Somehow the brightest moments are when I am having a shit, taking a shower or right after having sex (or popping one in the sink)
After much thought, I arrived at the conclusion that it must be because I had no pants on. My colleagues don’t appreciate it yet, but they’ll come to accept it with enough time. Such is the cost for working with an enigma like yours truly
Start with a clear problem statement, then break it down into smaller, manageable parts. Practice helps!
I start by writing down descriptive function names for what they are supposed to do. Then I add types for input and output. After that I add code. If it gets too long or complicated, I check if I can split the function in a meaningful way.
You need to practice algorithms and data structures.
Once you have a good grasp of that, it becomes natural to figure out the logic once you look at requirements.
Start with what data you have/need lay out your function such that you start with access to all required data, and then determine what you now need and implement manipulation of that data until you have the new required data. Repeat until you get the target data.
When you hit a roadblock after a couple hours because you realize that your solution isn’t possible, try to go for an approximation/determine necessary concessions.
when the revised function takes several hours of run time or uses way too much memory, find a library that does what you were trying to do and just use that
???
Profit
It usually starts with “how would I do this as a human”. That gives you a naive solution. Then you improve it by thinking about how you could’ve done better.
Solutions rarely come out in one go. We usually have to revise our code multiple times before we get a “good” one.
Name things clearly. Don’t worry about how long the name is.
combineCustomerAndPet() has a long name, but it tells you exactly what it does and helps you follow the bread crumbs.
Lots of whiteboard diagrams and drawings.
Stopping to say, “what do I WANT to happen” and write down the steps.
You first imagine the outcome you want and write the code as you think it should be. The logic comes when writing the code and discover the outcome ain’t what you imagined. You build on that until the outcome suits your idea. A first code almost always runs into unintended flaws. Just build on that and you’ll get your ‘own’ logic.
I think we could be a lot more helpful here if you could give us an example of a specific problem you’ve had an issue with, so we can have a look and walk you through how we might approach it. Depending on which language / framework you’re using, and what you are trying to do there could be a range of different issues causing you to struggle.
If you have an example, pop it up here, and we can walk through it.
I usually did an outline. If you ever done an outline for something. Try this, open word processor and start a new document. and press the outline button.
Now write each step necessary to go from your couch to your car to get that item you think may be in the car. Each main part of the outline is a step. each indent is further info , explanation or logic test (do I have my keys is a logic test), If no, then you may need a function to get the keys to the car so you can access the car. When you get out to the car, is the item actually in the car is another logic test.
Each further indent is further infor, explanation or logic. If you have many levels of indent, you may need to change to landscape and possibly a larger format paper as the indents can get harder to read. The nice thing about this is that you can add or remove things as you go.
Think of the steps (not each single line, but a step), which may involve many lines of code. This is abstract, but will keep you on track as you write code.
As you write the outline, your are writing in abstract, not specifics for now. As you think about the program, you can indent and get more and more specific.
* Am I standing?
*no, then stand up
ETC
I draw boxes and lines between boxes.
In general it helps to think about code you need to write as problems you need to solve.
For big problems I often just write it out literally in steps in plain English. Either on paper, in notepad etc, or often in code comments in an empty file.
Then, I go back through my steps and think about if I know offhand what that would look like in code. If I don’t, I break it into more logical sub-steps, and keep going until my plain English steps can be turned into pseudocode. Then, turn the pseudocode into real code, run it, fix it, repeat, then clean it up.
Once you’re a little more experienced, you can just start from writing pseudocode for a lot of problems, or just know the solution right away.
Pen and paper. Divide and conquer.
If a problem is too big – split it in parts. Then do the same with the parts.
Often I have written code by starting with a function, then calling named but yet unwritten functions from that. Then continue with the sub-functions. They can call new functions as well.
It is basic problem solving.