I'm trying to understand what the hardest part is for people new to programming? Is is understanding what source code means? Syntax? Was it variables or functions? How to think more like a programmer?
Being frustrated about something that no one can help you with.
Sometimes you get bugs that just are real headscratchers. This happens at the beginning of your career, at the end, and all the way through. There's some subtle thing keeping your code from working, even though you've gone through all the guides, stack overflow, and code review you can handle. Examples of issues like this are bugs in other people's code, library incompatibilities, timing issues, and generally trying to do anything.
You really need a lot of patience and a good problem solving attitude to solve these problems and keep going. Some people are lucky and look more productive because they don't run into these problems as often (though they do run into them). But you learn a lot more by solving these issues and understanding random parts of the stack.
To do this you really need to understand the entire system and use your tools. You need to understand things like how the OS might be doing things, how memory works, how threads work, how drivers work, etc.
If you just sit there and get frustrated, you can put in all the time in the world and not come up with the solution. You need an engineering/builder mentality right from the start, IMHO.
I recently did a certificate signing application in Golang. This was my first Golang application. The app would send CSR over to a server which would sign and respond back with certs. For over a week of debugging realised the server had bugs and was not signing the certificate properly. The bug was very subtle. The bug in third party libraries can be overwhelming for a beginner.
God you're bringing up my own personal PTSD. I also had a problem one time in production where my certificate code wouldn't work, and it was live, and everyone was freaking out.
Anything with security, encryption, passwords, certificates is extra hard, because a lot of times the error messages are just too cryptic (ha!) to get to the root cause. They are trying to not give away anything if possible, which can make even the most trivial errors hard to spot.
I would argue that it's thinking programmatically and applying that mindset to a computer.
When humans interact with each other there is a lot of subtlety and nuance that is embedded in that communication. I can say something to you but you can infer that I really mean the opposite by the tone of my communication.
All that is lost with computers, when communicating with a computer you need to be especially precise in what you want the computer to do and when you want the computer to do it. I'd argue that most bugs are a result of improper communication between the programmer and the computer. Either the actual intent was not communicated properly or there is context lacking in the communication (server status, load, etc.) that is not being accounted for.
For me it was the vast number of things that you (eventually) need to know, many of which are assumed by those writing tutorials, such as
1. how to use the command line
2. how to `build from source`
3. how to integrate different technologies (such as the MEAN stack)
4. etc.
In addition to the above, certain parts of the web, like StackOverflow, can be uninviting to new people even though (in my experience) the vast majority of coders are inviting and encouraging both in person and online.
This is a huge issue when it comes to learning React, Angular, Vue, etc. It's never just 'here's how the framework works', it's all the little extras they bundle into the tutorials they make things more and more overwhelming. Webpack, Redux, Jest/Enzyme/another testing framework, etc. It often feels like you can't understand the tech stack your code is running on at all.
The assumptions that documentation makes about what you already know. Sometimes these are such tacit assumptions that they don’t even give you anything to start googling about. Other times they’re assumptions that you’re already skilled in areas of computing that it can take months to years to understand properly.
It's going to be different for everyone, probably. For me, it was always stuff around networking, systems administration, DB administration, and compiling/linking.
A tiny example might be something that uses a symlink or, worse, is hard-linked from multiple places. A newbie might not even know that such things are possible; and if you don't point it out or use the terms, they can end up be horribly confused.
Half of all documentation is meant to be read literally. "Follow these exact steps for this exact reason and this exact thing will happen."
Then the other half is written as if you're supposed to have some secret knowledge. "Just run this, do the usual thing people do, and then you'll probably end up with something like this."
Those halves aren't mutually exclusive by document, and it took me a long time to get a feel for what the documentation author's intended.
I started being interested in coding when I was 7 (in 1990). Our family was quite poor, and no way we could afford even 286DX, and 386DX was well out of our reach. Somehow my father found a half-broken Electronika BK-0011M, an old USSR computer that ran a stripped-down version of BASIC. It didn't have a memory chip, and we couldn't find any in our small and remote Siberian town. No tape either. And the power supply was faulty, so every 3-4 hours it would reboot, leaving me with a clean slate. We found some "books" that were badly translated BASIC manuals retyped on a typing machine. I was mostly coding various graphical and physical simulations then, drawing procedural images and such. Because of reboots, I had to write it in parallel on the computer and a sheet of paper, so I could type it again if power cycled before I could run and briefly enjoy it. At 11, I was skilled enough to land a first "job" for my mom's research institute: analyzing and visualizing some agricultural data. It paid enough to get a 2nd hand 80486, and my "career" went upwards from there. This whole experience taught me a valuable lesson: ignore excuses, stop complaining, make do with what you have, and move forward.
These days my biggest gripe is probably the state of the JavaScript world. I'm mostly a Python person, but having to deal with JS leaves me frustrated more often than not: new frameworks, tools crop up every year, old tools stop working, breaking changes are introduced at such pace that someone not fully dedicated to frontend has a hard time keeping up. If any JS framework had the same stability, level of documentation, and clear roadmap as Django, the frontend world would be a much better place.
I think the most valuable skill for a "real world" programmer is the ability to find and read the documentation. Also, curiosity to do that even without an immediate need. Read it like sci-fi. The more you read, the more you have the right mindset, and those "building blocks" that would come later when you're thinking about implementation.
I learned 20+ years ago and I feel like back then it was a lot easier to learn. You would get a VB or C++ book and immerse yourself in it. The book would be self-contained --it had all the information you needed to become decent at that topic. Once you were done, you moved to the next book.
If I was learning today, I think that I would be completely overwhelmed by the amount of information that we have at our disposal. It would be harder to dive into one thing while being bombarded by the other 300 things you are supposed to learn because everyone is talking about them.
When I mentor young programmers, I advise them to focus on a single language/framework for a really long time, until they achieve real proficiency, and actively filter out everything else.
I had the same experience. When I was learning 20+ years ago, I absorbed books. I would go cover to cover and get a vision of what was possible plus whatever details I retained. Then I could go back to the book for reference as needed when I went to do things.
The amount of information available now is overwhelming and, increasingly, not collected into paper books. As much has I love my e-reader for fiction, I don't absorb technical content on it as well.
However, I don't have a problem picking up new things now without a physical book. There are basic concepts of programming that don't have to be relearned for new languages and frameworks. I don't have to learn about loops again. I just need a quick example of the syntax in a new language.
Perhaps immersive experiences are best early on as you say.
I agree, it doesn't really stick until you're working with it and running into/solving issues. I work with a young guy who is interested in programming and he was asking about html/css, python, test driven development, git, and then docker... I mean, holy crap what a tangled mess. Anyway, I gave him a VBA book and a couple of ideas for projects to solve business problems and he's been having a wonderful time. I'll show him git next week maybe...
Is there a reason you can't just pick up a book today and immerse yourself into it to learn? What book would you recommend someone read, if they wanted to self study?
Much like mathematics, programming is learned through action. As a fairly cautious individual, I wanted to understand everything I was about to type as input for the compiler. I would recommend the opposite approach: Copy code examples line by line, and start modifying them with simple changes such as variable names, output strings, etc.
To me, it's understanding how to think precisely enough about what you are trying to do.
Syntax comes pretty quickly, but it's the precision that is hard. So, for example, even writing a simple loop. Are you going to start at zero? Are you going to start at one? Should your loop condition be at the top of the loop, or at the bottom? Do you know what each of those implies about how many times the body of the loop will be executed? Do you check the termination condition with less than, equal to, or both? Are you sure the loop will terminate? Really sure? Do you know at what point any variables declared inside the loop are initialized, or re-initialized? Are you adjusting the loop variable inside the loop body in a way that is going to mess with the loop termination?
Programmers think of things like loop pre-conditions, post-conditions, and loop invariants to help them keep track of what they are doing, but beginners don't usually have tools like this that help them run the code in their heads while writing it to help ensure it will do what they intended.
As an example of just how easy this is to screw up, consider examples of unintended infinite loops:
Dev environments and various software conflicts, obviously. ie. You’re a noob dev and you need python 2.x.x but your mac os install has a different version and you’re too noob to understand what’s happening and the reinstall fails because xyz. Huge barrier to noobs. Programming is really quite trivial, fighting through external bugs like this is not.
Getting to "hello world" is often the biggest hurdle.
Anyone here who ever taught a course to beginners where each person brought their own computer? I bet you've got stories about the hundred million ways that setting up a dev environment can go wrong. And it's even worse if that beginner doesn't even have an actual teacher guiding them.
The hardest part is the constant jumping around between tech just to get something simple working, it's overwhelming. First you need to learn HTML and CSS...easy, oh wait you need to learn Bootstrap too, fml. Then Javascript...no JQuery...Coffeescript, Typescript? Don't forget React, it's mandatory for web development now. Back-end, well you need to learn NodeJS. Actually, all that stuff is a waste of time - just learn Ruby on Rails.
There is too much stuff coming at you all at once - it's like trying to drink from a fire hose.
Well, understanding what source code means and how it works is definitely a big part of it. Because for many people, they learn via looking at other people's work, and where programming is concerned, that often feels overwhelming.
Which probably comes down to one thing really:
When you look at an existing codebase, you have no idea about the logic behind any of its design decisions. You think it's all a confusing mess or that a smarter person would 'just get it', without realising that most of the complexity comes down to:
1. Bug fixes that cropped up along the way. Usually extreme edge cases.
2. Code being refactored piece by piece, since throwing out the whole codebase and starting over is often not economically viable.
3. Backwards compatibility in general
4. Multiple people working on it, often without much of a style guide (or a non enforced one)
5. Or one or more people having no idea what they're doing, getting help from other people who have no idea what they're doing, and using code from donkeys years ago also by people who may or may not have known what they were doing that sort of fixes the issue if you hammer at it a bit.
There's often a huge jump between 'what the average tutorial teaches you' and the source for a major project/commercial product, and for some guy going from say, learning basic PHP to reading the Magento source code, it can just feel completely overwhelming.
Relatedly, the whole jump from 'intermediate' to 'expert' is probably one of the hardest parts too. As people said before, there are loads of tutorials for absolute beginners, a fair few for experts, and a lot less for people in between.
The hardest part could be slowing down, really reading, really practicing, really submitting yourself to the learning process. Anyone can be a script kiddie. Not everyone can say they know a language inside and out. Practice makes perfect. You won't learn to code in a day, week, month, year.
The code itself wasn't the hardest part, it was understanding all of the things that your code is ultimately talking to: databases, web browsers, HTTP, etc. Each of these has both a vast encyclopedic bundle of stuff to get fluent with and also an abstraction that you need to "grok."
These auxiliary abstractions were the hardest for me. Where "is" my the data in my database? Isn't it all files at the end of the day? Why can't I just use files? What does "stateless" mean in the context of HTTP, when clearly something is remembered when I log in? Circa 2009, why not do everything in JavaScript? (Ha!)
The hardest part was that I didn't have the hardware documentation (6502, POKEY, ANTIC, GTIA...) and my mom wouldn't buy me the assembler cartridge. I got delayed 6 to 8 years because of this. I finally resolved the problem via Peter Norton's assembly book and MS-DOS's DEBUG.COM when I got a hand-me-down with a V20 CPU.
The second hardest part was that edlin is a dreadful editor.
The programming comes naturally if you have documentation and tools.
Personally, I feel it takes a certain kind of person to want to program. I never really understood this push to have everyone learn to code... maybe if just to get them to stop using their computers like a type writer and realize they're capable of more.
I am not a professional programmer, I'm an amateur who can code python and JavaScript for small tasks. It took me many years, but finally things got better when I understood that programming is the skill of decomposing problems in small, manageable understandable taks.
Once I got that, it became much easier to write my solution in my language of choice. Syntax is easy to Google for.
TL/DR : for me programming is a way of thinking with a problem solving attitude, making sure to simplify the problem as much as possible.
Sometimes you get bugs that just are real headscratchers. This happens at the beginning of your career, at the end, and all the way through. There's some subtle thing keeping your code from working, even though you've gone through all the guides, stack overflow, and code review you can handle. Examples of issues like this are bugs in other people's code, library incompatibilities, timing issues, and generally trying to do anything.
You really need a lot of patience and a good problem solving attitude to solve these problems and keep going. Some people are lucky and look more productive because they don't run into these problems as often (though they do run into them). But you learn a lot more by solving these issues and understanding random parts of the stack.
To do this you really need to understand the entire system and use your tools. You need to understand things like how the OS might be doing things, how memory works, how threads work, how drivers work, etc.
If you just sit there and get frustrated, you can put in all the time in the world and not come up with the solution. You need an engineering/builder mentality right from the start, IMHO.