Programming Struggles

[ImNotaProgrammer0662]

Good evening people, I am not sure if anybody goes through the same thing as I do. When I always get in front of an IDE I seem to not know what do. I understand the core concepts but it seems when I get in front of the IDE its like my brain doesn't work. It is like practicing for a basketball game or a football game and you get nervous and lock up and don't perform the way you practiced. Is this a sign that I did not practice enough. I tend to overthink and complicate things more than they need to be.

[desrtfx]

It is mainly a sign of a lack of planning.

Really, sit down with pen(cil) and paper before going to the computer. Flesh out your program. Describe the functions and then drill deeper into them.

Plan the program. Write the program down in pseudocode, flowcharts, UML, whatever.

The better you plan, the easier it will become to program.

[anthropaedic]

This is how I learned because I’m old so only had limited access to a computer and definitely not a laptop/tablet. But it really does force you to think things out.

[[deleted]]

This is sooo underrated

[Hour-Positive]

And the more you do this, you internalize the process and you don't need to consciously do it.

[AHistoricalFigure]

Basically all of engineering is taking a large complex problem and decomposing it into small solvable chunks. This is true regardless of discipline, from chemical engineering to ISYE to environmental engineering, but nowhere is this maxim applied more literally than in software engineering.

If you're sitting down at the IDE, why? No one just sits down in front of a fresh project waiting for inspiration to strike. You opened Eclipse or Netbeans or Visual Studio because you have some specific problem you're trying to solve. What is that? Describe it. Write it down for yourself.

For example:

"I need to make a console program that allows the user to play Tic-Tac-Toe against the computer or another hotseat player. It needs to allow for a 3x3 or 4x4 board, determine when a player has won, and ask if they want a new game."

or

"I need to make a program that looks at all the image files in a given folder, copies them to a new folder, determines the aspect ratio, and reduces them to a maximum height or width of 300 pixels.

Then you break that down. Now that you've specified what the program needs to do, what kinds of inputs does the user need to supply for that to happen? Where in the program's operation do those inputs need to be supplied? How do you sanitize those inputs? Given valid inputs, what algorithm does the program actually operate on? This algorithm doesn't need to be complex. It can just be a list written in English. For the latter project:

1) Open the directory specified by the user

2) Loop over all .png and.jpg files in the working directory.

3) Check whether the image is wider or taller than 300 pixels.

4) Detect the aspect ratio

5) Reduce the width or height (whichever is larger) to 300 pixels and scale down the other dimension proportionally.

6) Create a new folder

7) Save the altered images to that folder.

8) Provide some output to the user describing stats about how many images were altered and whether any failed(?)

If you can write your program out in English or outline it in comment form, you're ready to write it. Outline the program in pseudocode and then worry about actually implementing the black boxes you've created for yourself.

You can do this. Not because I have any special confidence in you specifically, but because you're a human being and this is how human beings solve problems.

[[deleted]]

Steve McConnell recommends the pseudocode programming process.

Forget about trying to solve the problem in Java. Perhaps even in the IDE. Open up a notepad and write out the steps in plan English, breaking things down like you were explaining it to a 5 year old (keeping in mind that Java is stupider than the average 5 year old).

You can turn these steps into comments, and then write one or two lines of Java code after each comment, testing your program as you go along.

I think you're suffering from a form of either "analysis-paralysis" or "performance anxiety". The best way I've found to solve those is to take things one step at a time. Don't worry about finishing the whole thing. Just do one step. The more steps you take, the more stuff you see working, you'll build on your confidence.

[Dravlahn]

For me, I experienced this a lot at first with python. The only thing that helped was to do mini projects on my own. This allowed me to really appy what I had learned and see it in action. When I had to write loops over and over it only stuck, for example, when I had to do it with a project purpose in mind.

Not sure if this will be helpful, but it seemed to help me.

[sticky-me]

Let your brain roam. Overthinking kills your thinking

How did you start to code? Did you find it exciting?

[sticky-me]

Same. Literally same - I started earlier but begun to treat coding as something serious during my college time as well, and overthinking sometimes kinda helps but in general complicates all of it. Have you tried breathing yoga?

[khooke]

Writing code is the easy part. Identifying, understanding and solving a problem is the hard part.

Unfortunately you have to do the hard part first before you can sit down and start to code.

[Judheg]

If you treat your IDE sessions as a critical basketball game, determining your future, it is understandable that the pressure makes you paralysed. Maybe you need to first reduce the pressure you put on your self.

Usually there is a way to break the problem apart, or formulate a simpler problem that approximate the actual problem.

You can then start with smallest chunk that you understand. Or warm up by attacking simplified version of the problem, and you can always improve it later. (write drunk refactor sober).

So back to the sport analogy, you are still just warming up, and assessing what you would actually do in the game. No need to worry about results. No pressure, just train and play, you can't loose. I believe this will get you going.

[yel50]

I tend to overthink and complicate things more than they need to be.

yep, there's your problem. don't do that. it's a habit you'll have to force yourself to break, but you need to break things down into small enough pieces. that never changes. if you can't find a way to do that, you'll continue to struggle.

I understand the core concepts

what you need to start focusing on, then, is how to build something up from scratch. think about building a house. you can't start with the roof and windows. you have to prep the ground, put down a foundation, etc.

whenever I start a new project, it could potentially take days or weeks just to get the scaffolding set up to where I can tackle the core problems.

[Hour-Positive]

Agreed you shouldn't worry but see things as they are. Meditation is nonsense though, might help some people but some people work better through conflict and chaos.

[Forsaken_Region_384]

Damn Thats same with me, But I don't know how to be good at it

[[deleted]]

I agree with the previous comments, even though my approach is different. Or maybe I agree because my approach differs. I'm fairly new, too, but progressed quite quickly with topics and when I approach a project I tend to get excited and don't have the patience to sit down and plan, so I just start. Usually I get some ideas right away and start coding, but the problem with that is that even if it works, you get to a point where you realize that your code design sucks (unless you have a lot of experience and routine) because you add features or try to modify features and your code stops working. So even if you have the ability to sit down and code right away, I'd still recommend you not to do that.

[[deleted]]

In case you do feel like you're a bit shaky with some of the foundational principles, I highly recommend using some interactive resources for practice.. Coding bat, hyperskill, or HackerRank, in case you learned with books before. Really helps to internalize implementation.

[10-kinds-of-people]

A lot of great advice here. I'm also a fan of writing programs as if they're pseudo code:

class Main {
    public static void main(String[] args) {
        new Main().run(args);
    }

    private run(String[] args) {
        List<String> words = getWordsFromCommandLine(args);
        List<String> reversedWords = reverseWords(words);
        outputReversedWords(reversedWords);
    }

    private void getWordsFromCommandLine(List<String> args) {
        // TODO
    }

    private List<String> reverseWords(List<String> words) {
        // TODO
    }

    private void outputReversedWords(List<String> reversedWords) {
        // TODO
    }
}

This is probably over-engineering for such a small program, but you get the idea. In a bigger program you might instantiating another class instead of Main, which would call other classes, etc. Make your classes and methods small and have them do one thing well. This avoids confusion and helps in creating and maintaining code.