What are the hardest parts of learning to code?

That's an excellent question!

It will surely depend on the person, but here are some things that stand out:

One is "thinking procedurally." You have to get to be really good at breaking your problem down into steps, and then expressing them one by one. As a common example, think about explaining how to make a peanut butter and jelly sandwich, if you have to break it down as far as "Hold the jar with your left hand and the lid with your right and twist them in opposite directions" to explain how to open the peanut butter. Now imagine if you have to do that in terms of which muscles to move, and how much. Coding can be like that.

Another is learning to debug. You can write code, but it will have bugs in it. Debugging can be really, really frustrating, and you have to learn both the tools for debugging (print debugging, breakpoints, single stepping, reading stack traces, and so on), and how to apply them, which involves learning where the bugs likely lie, and the patients to really track them down.

Then there's understanding what is worth actually writing. Many times, I have put a lot of work into some new function that will do something, and then found out that someone else has already done it, and better. It's great when you're learning to write things from scratch, but sometimes (whether because you're trying to learn about a different skill, or you're at work and are trying to complete a project quickly) it's better to use a preexisting piece of code, and write something that uses it. It can be hard to figure out which things will already exist and which ones you'll need to make, and making a mistake can mean a lot of lost time, if nothing else.

Related to code but sometimes overlooked, it can be hard to actually make your programs be what they need to be. Often, code you write will be used by other people. If you think you knew what they wanted, but were wrong, you can end up having written something they don't want to use, or can't. It's important to understand what you'll actually be doing.

I am often bad at taking code from "works, but barely" to a really nice, polished and finished piece. We sometimes say in software engineering (among other places) that the last 20% of the work takes 80% of the time. It can be easy to get a prototype going, but then you start finding all the little bugs, edge cases, and tweaks you need to make, and you might get distracted, discouraged, or busy with something else before then.

Finally, there's the problem that once you realize you know how to code, you start seeing ways you could write programs to do everything, and then you spend all your time writing programs instead of doing anything. (I'm kidding. Mostly.)

Phew, that was a lot. Again, I'm sure it will be different for different people, and some of these are surely easy for some. A good thing about all of the examples I gave is that, first, you can get better at all of them with practice, which you can mostly do just by starting to code and seeing what happens, and second, you don't need to be perfect at any of them. I've been a software engineer at Google for six years, and I still make mistakes with all of these all the time. You did ask for the hardest things. Getting started on them now will absolutely serve you well.

I hope this is more helpful than it is overwhelming. Good luck!

Coding isn’t hard,

To conceptualise the problem and to come up with the logical steps is the main ingredient. Coding is just using this process to produce actionable steps that a computer can understand. Then the computer understands these steps and performs it. Programmers are not geniuses or wizards. They’re practical people who use computers to build value.

So why is it so hard to learn?

Because it’s scary.

Think about the first time you looked at a wall of code and didn’t understand a thing, it meant. But it doesn’t have to be. Code was designed by humans for humans. It was structured entirely to fit the natural process with which your brain works and help you solve problems.

The important part is understanding why it’s important and thinking about how you can produce value with it. It’s more of a creative pursuit than a mission that requires technical proficiency or deep expertise.

Great question. Eric's answer mentions a lot of good points. One that I would add is persistence. It is easy to get stuck trying to solve a problem and give up. You need to stick with it, get help, and keep trying until you can make progress again.

There are places you can ask questions if you get stuck like Stackoverflow https://stackoverflow.com/

It is also helpful to start with simple problems to practice on and work your way up to harder ones. A source for easy practice problems I use is Code Wars https://www.codewars.com/ . Keep practicing and you will keep improving.

Not as long as Eric's answer, but I wanted to add that sometimes the hardest part of learning to code is setting up your development environment. Don't get discouraged if there's a bit of an uphill battle in just getting started! A lot of modern languages and platforms have complicated interactions and require many steps just to get to the "Hello, world" stage. For some environments, there are even pre-configured online environments, at least for testing and getting your feet wet, so look for that as well.

From my experience I would highlight 2 different major points:

1- Complexity: Software is complex, very complex and so also can be very frustrating. Be patient when learning even if you need to read the same documentation several times. Simply do not fallback, give yourself a break when feeling frustrated, go for a walk to refresh your mind and when less expected pieces will fit in your brain.

2- Constant evolution: Software development languages and techniques evolves so fast that it's impossible to keep track of all of them. Focus in those languages and areas that you like the most and try to keep updated.

Awesome that you chose computer science field as your career - that is what I did 25 years ago and it was the best decision I made!

While learning to code is fun, like anything else, it takes hard work and dedication to do a good job and be the best. As this is a fast moving field that evolves quickly, you will need to continue learning to keep up. Also, it is hard to learn coding in multiple programming languages, so I would suggest start with 1 or 2 programming languages at first and then learn new ones as necessary and if you job requires it. As you learn more complicated concepts of a programming language, it gets a bit harder, but you can rely on the internet to learn from others.

In summary, learning to code is a journey and it keeps going as the programming language evolves. It is hard, but not impossible. I would encourage you to not intimidated by this. The best programmers are ones who take up the challenge and understand that learning to code is a journey and you get better as you code more!

Great question. There's a lot of ways I could answer this because learning is something you will do for the rest of your life. I'll focus on one thing that was especially difficult for me.

I found it particularly difficult early on in learning to code to break apart big problems into small ones. In fact, I'm over a decade into my career, and splitting a problem into tasks is still one of the more challenging parts of the job. 

I've solved this by focusing on testing. Most software engineers rely on automated unit tests to verify that their software works. When I have a bigger problem to solve, I break it into the smallest pieces that I can easily test. Then, I do them in order, writing the tests as I go. 

This is called Test Driven Development. It's useful for software engineering, but also for problem solving in general. 

A second thing that I've found difficult (and that I know other engineers struggle with) is writing code that can easily be read and maintained. Once you've trained a bit, it will be easy to write code that a computer will understand (because the computer will tell you right away if you get something wrong). It's much harder to write code that you'll understand if you try to read it a year from now. 

I try to treat all my code like a communication with another person. Someone will have to understand this code later.