Stuck in tutorial hell
I want to learn OOP (object oriented programming) And also learn to think like a programmer, to do stuff on my own, solving problems and ect.
I usually get stuck after getting too advanced. (for my level I suppose) I get an idea to add to my code and I start to try and make it a reality. And thats where I get stuck. Its either my code dosent work as planned or dosent work at all. or.. i just dont know where to start.
I try to code but my mind is making it hard to come up with something.
15 Replies
The only real way is to keep making stuff
And if you get stuck, either try to get yourself unstuck by doing some googling, or ask here
Eventually, all that you've learned in the process will just... stick
Thank you for the advice.
Also try to code as little as possible "in the dark", so to speak. (That's what I call the period of times between compile + test runs.) Sometimes it can't be avoided, you have to code quite a bit in the dark, but it's always best to just get something working, okay good. Now make a small change and test that. Okay good, etc etc.
As in try to be interactive or energetic?
No, I just mean, let's say you're at a point where you have something working. It runs and does what you expect. Okay great. Now when you go to modify it (first commit what you have to your local repo of course), try and keep the number of things you modify between now (a state that you know works) and where you end up (a state that needs to be tested and you don't know for sure if it works) as small as you possibly can, like incrementally built up. I call the period of time when you're adding changes that are as-of-yet untested "coding in the dark" because anything you've added you won't have full confidence that it works until you test it, and these can compound on each other if some part you built in the dark uses another part you built in the dark, etc. I've built entire programs in the dark and had them miraculously come out working either right away or after some minor modifications, but I've also tried to do the same thing before, got lost in a deep dark rabbithole, and ended up wasting a bunch of time. So I advise against doing that. That's what I'm saying.
Usually the more you know exactly what you're going to do ahead of time and there's no sense of "I'll figure it out when I cross that bridge" type of thinking, the more you can code in the dark and get away with it.
But even if you do know (or think you know) exactly how you're going to build something, it's always nice to be able to shine a light on your progress so far by being able to actually execute/test it.
Sometimes, it's rather difficult to avoid though. Just depends on the problem you're trying to solve.
Ohh I get it. Yeah for sure I'll make sure to test way more frequently.
Yeah I only mentioned that because that's one of the reasons why you end up saying things like:
I get an idea to add to my code and I start to try and make it a reality. And thats where I get stuck. Its either my code dosent work as planned or dosent work at all.So, at some point between when you got the idea and when you tested it and realized it doesn't work, that's the time you spent in the dark. And at some point during that time, you erred and did something wrong. The quicker you iterate by testing what you have, the quicker you can spot where you've gone wrong and correct it.
If you know how to unit test, coding in the dark is fine.
Unit tests are very useful btw
Unit tests are turning on the light, so to speak. In my opinion anyway.
3 things:
- debugging
- being confident in changing your code knowing existing functionality didn't break
- a second point of use improves modularity, makes you structure things better
Oh I see what you're saying: if the parts you're building things with in the dark have all been unit tested thoroughly, it's easier to code for longer in the dark that way. Yes, I agree.
test-driven-development is one way of doing this, but knowing how to break down your problem into simple steps is the actual goat here
when you get stuck, ask yourself what is it that you really are trying to achieve
have you strayed from your goal?
are there alternative ways of continuing forward?
ig the TL;DR from me would be, have a conversation with your self, if you can't do that, then bring a colleague/friend, explain the problem to them and converse
often enough, changing your POV is the solution
your friend/colleague doesn't even have to understand the problem, they don't even have to provide advice, just being there is enough
meanwhile I just talk to myself like a crazy person
+ don't be afraid to prototype, write the most horrible code known to man, when it starts working, write tests, and erase all the code but keep the tests
(or write tests from the beginning, that's what TDD is)
rubber ducking. Very effective. I concur. Look it up @DDmax500
oh yeah, it had a name!
@DDmax500 , what's your level in programming ? Do you have any basis, in any language ?
What is the last "project" (or the last change on one of your existing project ?) you tried to work on and could not reach your goal ? What language ? what type of project ? winform, Web api, console ?