I reckon that the instant one finds “the thing one wants to make”, instead of “doing 5 minutes each day for the good of it”, suddenly it transforms into “hang on I’ll be there, I just need to fix this…”
11 Likes
This is a very underrated point.
@Icedrinker
A lot of people seem to consider programmers and coders just as those people fiddling with computers and making things work. However, if you really think about it, the meaning of the word algorithm (“a way of solving a problem in a series of well-defined and finite steps” if you want a small definition ) pre-dates the existence of computers.
In a sense, programming is not really a thing you know ( e.g. knowing programming language X), but a lense through which you see reality and try to break it down and solve the problem at hand.
In that regard I will second all the great advice and points made by everyone else in this topic and I want to add just two practical things to help you with your goal.
First thing: The pillar of programming skill/thinking.
Learn to break a big problem to smaller problems. Apply your mind in solving the smaller problems and then try to find how to combine all the small solutions to resolve the original larger issue. This more than just “idle philosophy”. There is practically no modern programming application that does not use functions. And what is a function other than a dedicated sub-routine that is designed to solve a very specific smaller problem?
In your case, you can apply this in real life and consider that aiming to BEGIN programming as a FULL STACK DEV is like me starting to learn DIY by claiming that I want to build a wooden model of the Parthenon in my garden. 
The amount of things you need to learn at the same time is just staggering. Front end, back end, API management, databases all those are actually separate jobs in some fields (on top of other things you need to know like webhosting, scripting and version control). Do note that each of those have their own sub-list of stuff you need to know (more on this below (1) )
Apply the previous basic principle. Start with one. Learn one. Apply the knowledge of it. Then this will make you understand what the other fields need and how they combine with the one you just learned. THEN you can proceed with the next one OR, if you feel like the one you chose suits you, stick with the same thing.
I would suggest begining with front end. For various reasons:
- It is not as technical and interconnected with the other fields like, e.g. databases.
- You can practically see it running and working and have a visual represenation of your work and growth, unlike, e.g. the back-end.
- The sub-skills you need to know are comparatively easier to understand than the other fields. (1) In this case HTML and CSS are the main things. You can combine them with a very beginner friendly language like JaveScript and within a few days have actual tangible results. Then you can transition to some PHP and Wordpress and voila. Some front-end skills that are actually hire-able
( If you want to talk money, full-stack has more money, but front-end commands a good salary too).
Second thing: How to escape tutorial hell.
I was not aware that this was a thing until recently. One could say that I do not really understand the issue, but it is exactly that puzzlement I had with its existence that made me think about it.
To cut a very long story sort, the whole concept stems by a convoluted standpoint/aim on watching tutorials in the first place. Most people that are stuck in “tutorial hell” make the same mistake you do:
They try to learn too much, at the same time, on a theoretical level, cramming their minds with commands, without crossing over to the direct application of the subject at hand.
By applying the previous point, the solution is fairly intuitive:
- Try to narrow the field of your learning.
- Try to focus on gleaming important concepts and good habits out of the tutorials, instead of the knowledge of particular coding commands. Those are comparatively irrelevant. What you want to focus on in the beginning is learning how to write “clean code” and what the over-arching concepts do ( if statements, loops, how to properly write and call functions etc).
- Follow along the tutorial by coding yourself (most of the tutorials say that you should do that, but I do not think that a lot of people really do that correctly). The way to do it is: FIRST copy-paste what was written, THEN check that it works in your environment (because that sometimes this is an issue and you think that you made a mistake, but it is a general issue with the compiler, the paths or libraries, commands being deprecated or whatever else), DELETE what you copied, TRY to THINK about it yourself and ATTEMPT to write the code. Compile and read the errors or bask in the results of a job well done. Repeat this through the practical examples, until the end.
- When you finish this tutorial, do NOT begin a new one. Try to apply all you learned first. Find small projects appropriate for the language you learned and try to do code them. By doing this, then you will get to see what is missing in your knowledge and then try to locate it and start working out finding the results to SPECIFIC issues, rather that the GENERIC, which the tutorials invariably covers since they have to be broad, by definition.
EXAMPLE:
Here is a good starting tutorial with the timestamp where I left it months ago: https://www.youtube.com/watch?v=jS4aFq5-91M&t=9246s
What I was doing is exactly what I said above, but since Javascript is so nice and practical you do not even have to install compilers and software like you need for most other languages, so I went to this online JS compiler and wrote my code there along with the tutorial and kept testing that what I did was working. When I wanted to pause it, I took the timestamp, put it in comments above the code, copy-pasted my whole code in notepad++ and then saved it. Next day all I needed to do is click on the timestamp, re-open the online JS compiler, paste my code back, re-compile and continue working.
Again, do not focus on the coding commands themselves, but on the structure.
I do not know JavaScript and I had written various scripts at work prior to saying to myself “Hmm, they sure come in handy … maybe I should check this JS thing out a bit and maybe watch a tutorial, eh?”.
Now I managed to do that not because I am smart (I am not), but because most procedural programming has the same structure. The languages themselves might do different things in different places, but a loop is a loop be it in Java, or in C++ or Python or JS or in front-end or back-end. And so is “clean code”.
So, I first broke the problem down, figured what I wanted to do, then looked up some documentation, some examples and pieced my code together. Tested, debugged it, re-tested, it didn’t work, found what was obsolete/deprecated, re-wrote, re-tested, it finally worked and pushed it to beta and then re-tested and then pushed to live.
Cause and effect.
Need and study.
Research an issue and then application.
More application, more issues, so more cause for research.
That is a natural flow of learning.
Tutorial hell is “I need to learn more more MORE MOAAAR!”, without a practical reason or a specific problem in mind or a definite goal at hand. Just don’t do that and try something like the above.
Do note this is obviously my take on it, there are various solutions to the tutorial hell problem, but I think that this is the more “beginner friendly”.
I also suggest you begin with that particular tutorial and some HTML, CSS and JavaScript.
Those seem to me to be the “modern GWBasic” of starting to code.
Good luck and happy new year
P.S.
A lot of job descriptions are filled with bloated “job specs” that the company doesn’t really desire or it is mostly impossible to have. I do not know why this is a trend nowadays with HR, but it is an issue. Just ignore them and apply anyway … what most companies want for an entry-level programmer, first and foremost, is a serious person they can trust with access to their systems and that can be down-to-earth and work with the already existing members of the teams.
They know that they will have to give you time to acclimate yourself with their company-specific tools and practices and work-flow and all that jazz, so do not stress to much over “ticking all the boxes”.
Also very true … oh, the post-midnight “I can’t sleep unless I fix this” joy when it finally works … and the solution that sometimes comes in our sleep when it doesn’t work.
I have found out that my brain is much smarter when I am not in the way 
4 Likes
https://www.reddit.com/r/ProgrammerHumor/comments/7vmoa9/debugging/
(I will note that the redditors agreed that the shower is really where this happens, I tend to agree )
9 Likes
I must admit that I have not read everything, so I apologise if this point was already mentioned.
When you start programming the main focus is to get it to work as intended. This is certainly the main goal of any project, but I would like to stress the importance of writing easily understandable code in the pursue of this goal. This is especially essencial when you are working on a bigger project together with other people.
Comments are a possibility to make code more readable, but should be used sparingly in order to not inflate the code too much. Choosing meaningful names for your variables / classes / functions etc. is key to writing readable code.
I like to compare programs to recipes. The grammar may be weird, but the following instructions paint a clear picture:
pot = CleanPots.First
water = new Water()
noodles = new Noodles()pot.Add(water)
await stove.heat(pot)pot.Add(noodles)
await stove.heat(pot)serve(noodles)
These are just my opinions though. Good luck @Icedrinker
5 Likes
I think some analogies can be made between learning to play go and learning to program.
It’s important to start applying things in practice right away, as in actually playing go or actually programming. Many people want to skip practice and move to the next level right away, but I think that doesn’t work.
In my job, I have had some courses on some programming topics that ended up being a waste of time (and money). Not because the course was bad, but because I never got to apply it in my daily work. So 3 months after the course, I’d have forgotten just about all of it. You can’t know everything, and you don’t need to. Avoid wasting effort learning stuff for which you don’t see an immediate use or benefit (yet).
Level 1 (~beginner)
You start by learning the basic elements.
In go you start by learning the rules and the basic mechanics of the game: (strings of) stones, liberties, capturing, eyes.
In programming, you start by learning about the basic building blocks of programs: data, statements, blocks, branching, loops, functions, procedures, classes.
Level 2 (~13k and stronger?)
I think this is already a step further than learning the basic elements. In go terms, I’d compare this with reading, tsumego and counting: analyzing a problem in a structured way. This needs a lot of practice. But from this practice, you’ll develop intuition, making it easier and more accurate over time.
Level 3 (~5k and stronger?)
In go terms, I would compare this with studying joseki and pro games. At some point, you’ll start recognizing some more elaborate patterns of problems and solutions occurring again and again. You’ll discover that some of those patterns even have names and are studied and applied by experts. You’ll be able to understand their applications and the caveats that apply in various situations.
These patterns are very useful, but trying to warp your head around level 3 stuff, when your actual experience is only at level 1, is wasted effort IMO.
Level 4 (~3d and stronger?)
Exactly. I feel it’s a bit similar to someone who only played a couple of games of go (or not even that), dreaming to become a (high) dan or pro player.
It’s good to have a dream, but you have to realize that achieving this level of expertise will require a large amount of time and effort (and there is no guarantee of success). Aiming that high this early in your journey may even be a hindrance, if it causes hesitancy to even take the first step.
4 Likes
`
True - ideally you should suffer from GoTo Hell and write-only code (perl, anyone?) in order to fully see the light and appreciate the joy of well structured and maintained code!
(And to continue the analogy, attaining Dan level of this is impossible, and you too can experience the sheer jealousy of seeing someone else to it, being able to recognise it, but not able to reproduce it yourself 
:D)
3 Likes
I thought of a couple of projects that @Icedrinker (or any aspiring programmer) might like:
- John Conways’s Game Of Life
Choose your favourite (or the most simple you can find) graphical tool for programming, and implement these beautiful simple rules and watch the wonderment unfold:
The universe of the Game of Life is an infinite, two-dimensional orthogonal grid of square cells, each of which is in one of two possible states, live or dead.
The rules are:
- Any live cell with two or three live neighbours survives.
- Any dead cell with three live neighbours becomes a live cell.
- All other live cells die in the next generation. Similarly, all other dead cells stay dead.
You can start with any configuration of live cells you like to see what happens - in some ways that’s the game.
- “Waving Hands” aka “Spellbinder”
I mention this here. It’s much more of a “project” than “Game of Life”.
These two have some things in common:
- Elegant simple rules that lead to wonderous complexity in outcome
- Minimal presentation requirements - they can literally be played on a whiteboard or pencil and paper (respectively)
→ great scope for “basic first, then lots of creativity in implementation later”
And “Waving Hands” is such a good game, if you build a server for it, people would probably play it.
Heck, I’d probably help get it going, if you want a collaborator…
6 Likes
You can’t run before you can walk. Start small. For example, how about creating some simple games to get your feet wet. Some ideas:
I’m not starting from 0. I have some experience making a roguelike, it looks kinda like this: 
It’s mostly you standing around in a location, getting beaten up, and if lucky you lvl up and find better weapons. Took 24 hours to make and was fairly fun to make.
So, I’ve been exposed to classes and all. I’ll still try to do front end with React despite all your warnings
My suggested projects were not intended to be assignments. So don’t feel obligated to make each (or any) of those things.
They didn’t sound like assignments. I find those ideas interesting to tackle. Maybe a hangman with a dark twist ^^
If you enjoy solving puzzles, you can also use https://projecteuler.net/ to get small goals.
Thanks for the suggestion. I’ve tried project euler before and it was kinda fun. But for exercises I’ll reserve Advent of Code, for I find it more fun.
If you intend to spend only 5 minutes per day on this, you’ll be accumulating only about 25 hours of experience per year and it will take 40 years before you’ll be barely employable as a programmer.
Samraku answered this well: “That’s why the 5 minutes (or whatever small thing) per day is just the starting point. It’s meant to not only increase as you go on, but also balloon as you begin to want to go past the 5 minutes, as you inevitably will.”
That’s a big “if” though, isn’t it? You just spent 5 years not doing it … if you’d been in uni you’d be there by now
Pardon the misunderstanding. I meant natural languages, and it was a point mentioned in resolution thread in that context, but it was separated in this thread and lost its original meaning. I was thinking of applying to a university for the sake of studying eastern languages, but I was appalled to know that they teach you a language 4 years, instead of my initial impression that they will teach you three. Nope, you just pick one of them.
So I strongly recommend keeping your eyes out for “what you want to make”.
Thanks. I’ll keep that quote in my pocket
Good luck @Icedrinker
Thank you Martin. I find the advice valuable too.
Thanks everyone for the advice it’s too much to process so I’m not gonna apply most of it yet 
6 Likes
Cheating hangman is a good project. If you don’t commit to what the hidden word is, and the dictionary is known, it becomes a two-player game with perfect information much like go or chess, so there’s a lot of standard stuff you can learn to optimize it, or you can work on a nice GUI, website, etc. And it gets so frustrating needing 20+ guesses to get the word!
4 Likes