How do I break out of the "intermediate dev limbo" before giving up again?

[u/DogsBarf]

How do I break out of the "intermediate dev limbo" before giving up again? I am past the beginner stage, understanding basic syntax up to classes and objects, but I freeze when it's time to structure projects on my own. I have relentlessly searched for methods, tutorials, and books to guide me to the next level, but I can never find anything that clicks; because of this, I've jumped from language to language, and every time I hit this "limbo," I end up quitting and trying something else, yet I always come back because something inside tells me I’m meant to code. For those who have overcome this block, what architecture or design books do you recommend, what kind of practical exercises changed the game for you, and what real strategies actually work to finally break through this barrier and build confidence?

[u/JonIsPatented]

Hate to break it to you, but you are still absolutely a beginner. Of course, there is nothing wrong with that, but you should be aware of it in order to help you temper your expectations.

For actual advice, in short, don't get stuck thinking "what should I do" and instead just think about "what can I do" and "what do I think might work". It's better to just write stuff and wind up with something bad but functional than to get caught up in being right and wind up with nothing to show for it. In the former case, you learned and you will do better next time. In the latter case, you're still right where you started.

Just build. Just write code. Just do it.

For more concrete advice on figuring out what do next while programming, just ask "what function do I need in order to do this?" And then pretend that function exists and write your code using it. Then go write that function if it doesn't exist. Rinse and repeat. This will at least get you building something, and that is ALWAYS better than building nothing.

[u/marmotta1955]

Funny thing that will attract the usual downvote crowd.

In time, I have noticed how beginners better understand how to approach and eventually structure a project by working with a language (any language) that allows you to design a user interface and write code to handle "events". Yes, Event Driven Programming.

You could even start with your copy of Visual Studio. Visual Basic or C# - does not matter. Create a Windows Form project. Create a simple user interface for a simple application - anything, really. The classic ToDo app, for example.

Now you have a "form". How to you add a new "todo item"? You need a button, and you expect the user to click that button, maybe to invoke an input box.

Now the user has clicked that button and has provided a string for that "todo item". What do you do with it? You insert it into a list box.

.... you probably get the idea.

I only have over 50 years of experience in the field, so I don't know much. But this is the way I have seen many beginners get past the exact "phase" you find yourself in. Start simple, build upon it.

Good luck with all your endeavors!

[u/ghettosixteen → u/marmotta1955]

Great advice, how do you suggest moving beyond event driven prog ?

[u/marmotta1955 → u/ghettosixteen]

It may be surprising, but the "transition" will happen naturally - in time and depending on the circumstances and the projects you may find yourself involved with.

Then again, if you were to work mostly on user-facing applications (desktop or web applications) ... you'll still be in the Event Driven realm ... regardless of the specific terminology and technology. After all, the concept holds water: your code responds to user input and/or your code responds to user interface changes and/or your code responds to back-end processes and notifications.

Later, projects will get a bit more complicated and sophisticated. It comes a time when Object Oriented Programming concepts kick in (and you'll wonder why you did not use these concepts much earlier).

And even later, you'll come to terms with Functional Programming ... and even later ... and later ...

Then again, you may find your specific, particular niche and get stuck, or comfortable, or voluntarily choose to become a master of that one domain.

In any case, it is never over. You'll never stop learning and adapting. Heck, I am 71 (I lie, almost 72, happily retired) and I am still learning new stuff every day.

You have a long way to go, I guess. I, for one, just envy the wonders of the technologies and languages and products you'll have the chance to work with in the future.

[u/ghettosixteen → u/marmotta1955]

You’d make a popular professor, just saying! Thanks for the gold though

[u/I_am___The_Botman]

Here's the secret - there isn't really a ock to overcome. You get past it by figuring out the problem, collaborating with colleagues, researching your problem and finding a solution. Once you have a solution, thrn you can figure out if it is a good one or not. Start by picking a language you like, then stick with it. Languages are just tools, so figure out which one you want to focus on ams stick with it. What are your goals? What do you want to work with? What do you like to build? Answering those questions will likely push you towards a particular language, from their just stick with that and build.  What types of things have you built so far?

[u/bytejuggler]

I want to echo JonIsPatented where he says to do "what do I think might work". Think about "the simplest thing that could /possibly/ work", which is to say, you're not ever sure it will work yet, but you think it might. Then start walking in that direction. Try it out. As you go, you'll learn whether you were right as you fill in the blanks and eventually complete the step you were after, or you'll discover something that means you have to course correct, switch gears, change plans slightly or even maybe start over. You will learn and understand the real problem better having learnt what doesn't work and why, and then and can try again to come up with a new "simplest thing that could possibly work" plan. Lather, rinse repeat.

Try not to overengineer things. Make simple choices and move forward. Give yourself permission to figure things out and trust your future self, to change and fix things as needed. "Don't let perfect be the enemy of good." I would suggest learning TDD, which at a mechanical code level makes these baby steps more concrete. Read "TDD by Example" by Kent Beck.

Usually when you feel the fear or freeze it's because you're trying to take a too large leap forward and there's too many unknowns embedded in the step, so your brain is at a loss. The art of unfreezing yourself is to notice when you're facing the freeze, and then aim for a smaller step. Ask yourself what would be a smaller step forward towards that general direction that is workable for now. Then take it and move forward. Baby steps is the way to progress. Always not bigger leaps but smaller baby steps.

[u/Ok-Count-3366]

Learn architecture, design and design patterns. Those are the things that u get asked at a senior swe interview not how a class looks like.

[u/so-brain-washed]

- chatrooms are helpful for getting humans to review your designs & code-- on IRC, slack, discord

- the best thing for designing a project is just sitting down with a pen & paper, or a text document and sketching it out-- get things out of your brain, put them down on paper, then organize and dial them in. Just like writing a draft of a paper. Start with simple, then add things in as necessary.

- Write down the project goals

- Write down the project value proposition

- Imagine the project with the end in mind-- and then plan it backwards.

- Explore project planning & project design methodologies, even

[u/HamNCheeseSupremacy]

Read Design Patterns: Elements Of Reusable Object Oriented Software (1994). That's what did it for me. From what I remember it's like 20ish design patterns. Read about them then pick whatever is suited for what you want to do.

[u/burnt_floppy]

Don't think of it hierarchically: there are no "stages of coding" beyond a very vague sense. Skill level always has to do with experience and time you've spend doing it more than anything else.

Think about it in terms of fun and testing ideas out using what you already know: to me, making a project with a clear goal is more fun than learning about syntax and technical ramifications. Maybe you haven't learned enough yet to start thinking about it creatively, but if I come up with an idea, one of the best things i like about coding is getting carried away with my obsession and trying a bunch of things and failing a lot of them.

I recommend just continuing to get get more and more knowledgable about one particular language you like and asking yourself a ton of questions about programming.

[u/Salamanticormorant]

Might have to exercise your imagination, maybe starting with little things. I do it by trying to wrangle things into images. For example, I did this with the way that MMO guilds allow people to get rare boss drops by spending their guild participation points in an auction. Whoever bids the most points has to spend as many of their points as the person who bid second-highest.

I started with a simplified version: a two-player guild in which both players each bid all their points on one item per week. Each pixel's X and Y coordinate represent the number of points player X and player Y, respectively, start with and earn per week. Consider pixel 2,3. Y beats X and has to pay 2 points, so we have 2,1. Then, they each earn their weekly, so we have 4,4. In case of a tie, I deduct no points. They each earn their weekly again, so we have 6,7. Y pays 6, so we have 6,1. They each earn their weekly again, so we have 8,4. X has to pay 4, so we have 4,4. They each earn their weekly, so we have 6,7. Each iteration includes bidding and earning, so the pairs we're actually looking at are 2,3; 4,4; 6,7; 8,4; and 6,7. 6,7 is a repeat, so we return 4, the number of iterations it took to produce a repeated value. Alternatively we can return the size of the repeating part of the cycle, which is 2, or the number of elements outside of the repeating part of the cycle, which is also 2.

It's similar to the algorithm used to create images via a Mandelbrot orbits function, but I've replaced the usual kind of orbits with the bidding algorithm. Those images turned out to be similar to those produced by an algorithm that chooses each pixel's shade as close to randomly as possible. The number of iterations it takes to get a repeated value can vary monumentally, even among pixels very close to each other.

I also realized that I could run a fixed number of iterations per pixel and return the final x and y values. I tried shading based on the sum, product, and XOR of that final x and y, but the most interesting thing I've done thus far is to feed that new x and y value into one of my other algorithms, one loosely based on nucleotides. You can treat each pixel's X and Y coordinate, together, like a strand of DNA, treat each base 4 digit of each coordinate like a nucleotide, and see how many valid pairings you get. The best-looking images were when I worked in base 3 instead and used a somewhat similar matching rule to generate red, green, and blue values for each pixel.

The attached image shows the original nucleotides image followed by images generated by that same algorithm when I use the two values returned by BidRepetitions(x,y,n) instead of x and y, for n = 1, 2, and 3.

[u/LostInCombat]

Want to up your game? Then just do that by picking a major project on GitHub and trying to figure out how it all works. AI can be your friend here. Build small things to test your comprehension.