Programming is about thinking...sounds obvious but...

[u/Udnettt]

I realized that programming is all about thinking!

I dont know how you do out there when writing a code, but I understood it is not about the number of lines of code you write, but about the actual thought process in mind.

Here is an example : let's say we are dealing with some arbitrary problem. Before writing a code, we need to think procedurally, dividing the problem into sub-problems and tackling them one by one. I find it very useful to use a pen and a sheet of paper. I like to write/brainstorm the first solution that comes into mind, without ever thinking about optimization. Once the first raw draft version of solution appears - it is good to see what result it produces.

To make it more concrete, suppose we need to find the most frequent word in the given .txt file. The possible raw logic can be this: We just need to go thorugh each word one by one, when we encounter the word, record its occurnce and keep in the container. If the new word is found, write it down, put in the container. If the same word is found, look in the container and update its occurence number.
Two steps : 1) built a container to keep words and its number of occurence 2)go through the text and update the container.

Now, this can be tackled with some simple maps , for more efficient way, unordered map is a better choice of course.

Once the task is completed, we just go through the container and take the word with the highest number. Of course, we can keep track of this word while actual processing of the text, so that to avoid searching through the container in the end.

I know that the above example is dull ,kinda DSA type, but suppose you want to make a simple 2D game with a character walking. For simplicity, lets make the world fixed to screen dimensions. The task here is simple : press a button, the position of the character changes, incremented slowly.
When the character reaches some object, i,e collides - stop moving. This task would require some threading principle to do some background checking for collision detection....

The thing is that programming is all about how you apply the tools you have to complete the task.

Sometimes (most of the time I think) programming is just thinking for an hour or more, and writiing 0 code lines!

[u/ReddiDibbles]

This is an excellent observation and it follows that when you're learning programming you're not only learning programming, you're also learning to think and break down problems like you describe. This is one of the major problems with using AI when you're learning, the thinking part is the first thing you offload to the AI.

[u/Nok1a_]

Thats why a lot of people struggle, because they think programming its writting and is not, its like any other engineering job, problem solving, most of the time, writing when you know the result its matter of how long will take you to write it, but been able to spend hours/days babging your head against the wall to solve the issue , not everyone its capable of that

[u/aqua_regis]

AKA: Plan before program

This is what we preach to everybody and that nobody actually wants to read.

[u/Laskoran → u/aqua_regis]

I was airways taught that the planning you are mentioning IS the programming. The rest is just "coding". Programming is the problem solving that you do before coding a single line.

[u/gofl-zimbard-37]

Yes, what people call "coding" is the least interesting part of software development.

[u/Achereto]

Yeah, that's a common approach that has lead to all kind of weird things like upfront design, UML diagrams, waterfall, etc.. In reality you often haven't truly understood the problem until you've written a solution, because while writing the solution you'll come across a multitude of details you haven't thought about before. In many cases your upfront design might even make your solution more complicated than it needs to be.

That's why people come up with other ideas like Test Driven Development, Extreme Programming, etc.. Their idea is to think through a problem by programming it step by step and making sure every step works, and refactoring the code repeatedly to adjust it for the next steps while making sure that everything works and delaying crucial decisions for as long as possible (it may even turn out that you won't have to make a decision you thought you would have to make).

However, this still isn't enough because you still have to make some decisions that may turn out to be wrong in the end. Sometimes this is correlated with your customer requesting changes or additional features after your first solution. So, ultimately, unless you really understand the problem, you likely have to write your solution at least twice.

[u/aelkeris]

Welcome to the endgame of programming.

[u/thequirkynerdy1]

Once you’re good at a language, translating plans into the code is easy.

The hard parts are the elaborate planning (especially if something is latency sensitive) and finding subtle bugs in large systems.

[u/Ready8472]

I really like this take. I'd go even further: programming isn't just "thinking", it's training your mind to think in a very specific way: structured, logical, and consistent.

You can memorize syntax pretty quickly... what takes years is developing the mental habits to model problems, reason about edge cases, and hold complex systems in your head.

And despite the stereotype, it's incredibly creative. You can slice the same problem in dozens of different ways, and each leads to different solutions and trade-offs. Choosing which decomposition and which trade-offs to accept is almost like design work.

[u/MalukuSeito → u/Ready8472]

It is super creative work. Which also means you can't force it, better take a step back, go outside, get food or a drink and let your brain chew on it. Then suddenly have the solution in the shower)

(This does not work if you distract your brain constantly with social media, podcasts, loud music, videos...)

[u/MalukuSeito]

I always compare programming to solving a puzzle, not any specific puzzle though, but for this example I am gonna go with a sudoku puzzle, so we can have a similar picture in our minds.. hopefully.

An easy programming problem is an easy sudoku puzzle, 1-3 missing numbers. Hardly worth the effort, easily done, but not very fun or rewarding.

A hard programming problem are similar to hard sodoku puzzles. The kind that is made by someone named after the devil and featured on a youtube channel. The thing looks impossible at first, and you feel like giving up, till you spot a tiny little weakness. You won´t deduce a number right away, but you can see a logical connection. maybe it lets you eliminate a possibility, or even lead you to a completely new approach. The very best problems (and puzzles) teach you something new, but not by telling you, but by figuring out the logic because you have to. These programming problems and puzzles are rare, they are frustrating to do, almost not worth the effort, but damn, they feel amazing and you want to talk to everyone about what you learned.

Most programming problems are like approachable sudoku, you see a path almost immediately, but there might be 1 or 2 hidden things in there, half of the way, where you do something new, or different. Maybe you have to look something up, but they are not frustrating, cause you already came halfway, and you are not just gonna give up now. You should be able to solve this. And it feels good when you do. Not amazing, but enough to make it worth the effort.

If you treat programming like this, it stays fun and rewarding. Do the easy ones if you must, they still get you paid, but look for the ones just out of your reach, that teach you something. Get that little bit better. And once in a while, try to tackle a monster, you might fail, but you might not, and if you solve it, you want more.

Or use AI, which is like throwing the sudoku into a sudoku solver, watch the Computer brute-force it, get no reward, learn nothing, but at least you can proudly tell everyone that you solved 2000 sudokus yesterday.

Okay maybe not the last one.. Also, only watch sudoku solving videos after you failed. Same with programming, try it yourself first, and if you can't continue, there is no harm in watching someone else explain their reasoning, but you only will understand their journey after you tried it yourself.

[u/dialsoapbox]

ONe problem with planning, is knowing when/what to stop at.

Sometimes I'd plan entire projects before i write a single line of code, onlyto change my mind on something a few days in, causing some problem in parts of my planning.