For many, like me, coding just isn’t how our brain works. Even if we are interested in it it’s basically impossible to get a grip on it. I can figure out code that’s already written and do basic editing of it but anything more than that just doesn’t click no matter how much time I spend trying to learn.
It takes 3-6 months for the concepts to click, speaking from experience.
The funniest thing for me is that the definition of object oriented programming is a source of confusion as a beginner yet the most succinct definition as an intermediate/ expert.
It’s just telling the computer in a very detailed way. Are you monolingual? I think the concept of learning how to code is easier if you speak more than one language.
I want to preface this with the mention that understanding other people’s code and being able to modify it in a way that gets it to do what you want is a big part of real world coding and not a small feat.
The rest of my comment may come across as “you’re learning wrong”. It is meant to. I don’t know how you’ve been learning and I have no proof that doing it differently will help, but I’m optimistic that it can. The main takeaway is this: be patient with yourself. Solving problems and building things is hard. It’s ok to progress slowly. Don’t try to skip ahead, especially early on.
(also this comment isn’t directed at you specifically, but at anyone who shares your frustration)
I was gonna write an entire rant opposing the meme, but thought better of it as it seems most people here agree with me.
BUT I think that once you’ve got some basics down, there really is no better way to improve than to do. The key is to start at the appropriate level of complexity for your level of experience.
Obviously I don’t know what that is for you specifically, but I think in general it’s a good idea to start simple. Don’t try to engineer an entire application as your first programming activity.
Find an easy (and simple! as in - a single function with well defined inputs and outputs and no side effects) problem; either think of something yourself, or pick an easy problem from an online platform like leetcode or codechef. And try to solve the problem yourself. There’s no need to get stuck for ages, but give it an honest try.
I think a decent heuristic for determining if you have a useful problem is whether you feel like you’ve made significant progress towards a solution after an hour or two. If not, readjust and pick a different problem. There’s no point in spending days on a problem that’s not clicking for you.
If you weren’t able to solve the problem, look at solutions. Pick one that seems most straight forward to you and try to understand it. When you think you do, give the original problem a little twist and try to solve that. While referencing the solution to the original if you need to.
If you’re struggling with this kind of constrained problem, keep doing them. Seriously. Perhaps dial down the difficulty of the problems themselves until you can follow and understand the solutions. But keep struggling with trying to solve little problems from scratch. Because that’s the essence of programming: you want the computer to do something and you need to figure out how to achieve that.
It’s not automatic, intuitive, inspired creation. It’s not magic. It’s a difficult and uncertain process of exploration. I’m fairly confident that for most people, coding just isn’t how their brain works, initially. And I’m also sure that for some it “clicks” much easier than for others. But fundamentally, the skill to code is like a muscle: it must be trained to be useful. You can listen to a hundred talks on the mechanics of bike riding, and be an expert on the physics. If you don’t put in the hours on the pedals, you’ll never be biking from A to B.
I think this period at the beginning is the most challenging and frustrating, because you’re working so hard and seemingly progress so slowly. But the two are connected. You’re not breezing through because it is hard. You’re learning a new way of thinking. Everything else builds on this.
Once you’re more comfortable with solving isolated problems like that, consider making a simple application. For example: read an input text file, replace all occurrences of one string with another string, write the resulting text to a new text file. Don’t focus on perfection or best practices at first. Simply solve the problem the way you know how. Perhaps start with hard-coded values for the replacement, then make them configurable (e.g. by passing them as arguments to your application).
When you have a few small applications under your belt you can start to dream big. As in, start solving “real” problems. Like some automation that would help you or someone you know. Or tasks at work for a software company. Or that cool app you’ve always wanted to build. Working on real applications will give you more confidence and open the door to more learning. You’ll run into lots of problems and learn how not to do things. So many ways not to do things.
TLDR: If it’s not clicking, you need to, as a general rule, do less learning (in the conventional sense of absorbing and integrating information) and more doing. A lot of doing.
I would attribute this to the difference between programming/coding, and software design or engineering. They’re related but different concepts. Just like a builder and an architect do different things and complement each other to get a building built, these are also two distinct steps. I do think it’s easier and more common for one person to (be able to) do both tasks than in my analogy though, but it’s also done separately often enough (in industry).
My point being: don’t beat yourself up that you don’t know programming, you probably do, it’s the software design that you’re not familiar with yet. But now that you know what is missing, you can look into it and work on it, and gain a valuable skill to complement your existing skill.
I definitely feel this. I had to take a programing course in university and I was easily able to follow along up until the lesson on pointers, whereupon I completely lost the thread and never recovered.
I’ve known a good number of computer scientists over the years, and the general consensus I got from them is that my story is neither unique nor uncommon.
Yeah, some folks have trouble with pointers, and computer-engineering curricula are designed to discourage folks from taking third-year courses if pointers don’t make sense. It’s a stereotype for a reason. I’d love to know if there’s an underlying psychological explanation, or if pointers are just…hard.
I am but one man whose only education in programming was a first year university course in C from almost two decades ago (and thus I am liable to completely botch any explanation of CS concepts and/or may just have faulty memories), but I can offer my own opinion.
Most basic programming concepts I was taught had easily understood use cases and produced observable effects. There were a lot of analogous concepts to algebra, and functions like printf did things that were concrete and could be immediately evaluated visually.
Pointers, on the other hand, felt designed purely of and for programming. Instead of directly defining a variable by some real-world concept I was already familiar with, it was a variable defined by a property of another variable, and it took some thinking to even comprehend what that meant. Even reading the Wikipedia page today I’m not sure if I completely understand.
Pointers also didn’t appear to have an immediate use case. We had been primarily concerned with using the value of a variable to perform basic tasks, but none of those tasks ever required the location of a variable to complete the calculations. We were never offered any functions that used pointers for anything, either before or after, so including them felt like busywork.
It also didn’t help that my professor basically refused to offer any explanation beyond a basic definition. We were just told to arbitrarily include pointers in our work even though they didn’t seem to contribute to anything, and I really resented that fact. We were assured that we would eventually understand if we continued to take programming courses, but that wasn’t much comfort to first year students who just wanted to pass the introductory class they were already in.
And if what you said is true, that later courses are built on the assumption that one understands the function and usefulness of pointers despite the poor explanations, then its no wonder so many people bounce off of computer science at such a low level.
Thanks for offering your perspective! It’s important that we keep in mind that not everybody who studies computer science becomes a professional programmer, and you’ve offered us good food for thought.
For what it’s worth, pointers are fundamental for Von Neumann machines, which are very common in the computing world; your current machine and the machine serving this page are both Von Neumann. In such machines, memory doesn’t just store data, but also instructions; the machine has an instruction pointer, which is a pointer referencing the currently-executing instruction in memory. So, if one wants to understand how a computer jumps from one instruction to another, then one must somewhat understand pointers.
Pointers do make more sense to me now than two decades ago, mostly owing to me being married to a computer scientist. But I always go back the fact that for the purposes of my first year programming course, pointers were (probably) unnecessary and thus confusing. I have a hard time understanding things if not given an immediate and tangible use case, and pointers didn’t really help me when most of my programs used a bare few functions and some globally defined variables to solve simple physics problems.
EDIT: I’ll also say that pointers alone weren’t what sunk my interested in programming, they’re just an easily identifiable concept that sticks out as “not making sense.” At around the same time we had the lesson on pointers, our programs were also starting to reach a critical mass of complexity, and the amount of mental work I had to do to follow along became more than I was willing to put into it - it wasn’t “fun” anymore. I only did well on my final project because a friend patiently sat in my dorm room for a few hours and talked me through each step of the program, and then fed me enough vocabulary to convince the TA that I knew what I was doing.
Aren’t pointers just an ID given to a verible that currosponds to its “true” position in the array of bytes thay make up a program’s memory? I feel like I’m missing something
I doubt that you’re missing anything about pointers themselves. I may not have done a good job articulating why non-programmers have a hard time understanding them.
This is my experience. I can understand the fundamentals without trouble but don’t have the ability to plan out the structure of something and write code to make that work.
I’ve done online courses, tried boot camps. It just doesn’t work for me.
if you can use a dictionary, play a card game like Uno, poker, gofish, cheat etc, use an index in an encyclopedia, Google, Wikipedia, and you can do high school algebra you can grasp the basics of coding.
Object Orientated Programming / classes / objects / inheritance is kinda like a card game
All Hearts are a type of card, all Kings are a type of card, a straight is a way of arranging cards, four of a kind is a way of arranging cards. That’s about as complicated as OOP needs to get for a beginner.
Start small, make silly things. Html is probably the easiest thing to pick up and see what your changes are doing almost immediately. Play with formatting and styling, add pictures, learn how to create buttons and radials.
After that I’d start learning how to make stuff happen with JavaScript maybe create a pop-up when you hit a button, figure out how to change the color of elements with input boxes or sliders, etc.
When you feel comfortable enough with the language make what you want even if it already exists. Tic tac toe, a rudimentary blog, Conways game of life. Don’t be afraid to take a break if it gets frustrating and don’t be too hard on yourself if it’s not amazing.
Just remember it takes time, I hear most developers say it takes at least a year of carving a few ours a week just making stuff to really start grasping a language. So just make stuff and don’t be afraid to look it up. The more pointed your questions the easier it gets to find answers.
I jumped head first into c++ my apps are incredibly buggy and run slower than most web apps. They’re only terminal apps but I’m improving and so can you.
For many, like me, coding just isn’t how our brain works. Even if we are interested in it it’s basically impossible to get a grip on it. I can figure out code that’s already written and do basic editing of it but anything more than that just doesn’t click no matter how much time I spend trying to learn.
It takes 3-6 months for the concepts to click, speaking from experience.
The funniest thing for me is that the definition of object oriented programming is a source of confusion as a beginner yet the most succinct definition as an intermediate/ expert.
It’s just telling the computer in a very detailed way. Are you monolingual? I think the concept of learning how to code is easier if you speak more than one language.
I want to preface this with the mention that understanding other people’s code and being able to modify it in a way that gets it to do what you want is a big part of real world coding and not a small feat.
The rest of my comment may come across as “you’re learning wrong”. It is meant to. I don’t know how you’ve been learning and I have no proof that doing it differently will help, but I’m optimistic that it can. The main takeaway is this: be patient with yourself. Solving problems and building things is hard. It’s ok to progress slowly. Don’t try to skip ahead, especially early on.
(also this comment isn’t directed at you specifically, but at anyone who shares your frustration)
I was gonna write an entire rant opposing the meme, but thought better of it as it seems most people here agree with me.
BUT I think that once you’ve got some basics down, there really is no better way to improve than to do. The key is to start at the appropriate level of complexity for your level of experience.
Obviously I don’t know what that is for you specifically, but I think in general it’s a good idea to start simple. Don’t try to engineer an entire application as your first programming activity.
Find an easy (and simple! as in - a single function with well defined inputs and outputs and no side effects) problem; either think of something yourself, or pick an easy problem from an online platform like leetcode or codechef. And try to solve the problem yourself. There’s no need to get stuck for ages, but give it an honest try.
I think a decent heuristic for determining if you have a useful problem is whether you feel like you’ve made significant progress towards a solution after an hour or two. If not, readjust and pick a different problem. There’s no point in spending days on a problem that’s not clicking for you.
If you weren’t able to solve the problem, look at solutions. Pick one that seems most straight forward to you and try to understand it. When you think you do, give the original problem a little twist and try to solve that. While referencing the solution to the original if you need to.
If you’re struggling with this kind of constrained problem, keep doing them. Seriously. Perhaps dial down the difficulty of the problems themselves until you can follow and understand the solutions. But keep struggling with trying to solve little problems from scratch. Because that’s the essence of programming: you want the computer to do something and you need to figure out how to achieve that.
It’s not automatic, intuitive, inspired creation. It’s not magic. It’s a difficult and uncertain process of exploration. I’m fairly confident that for most people, coding just isn’t how their brain works, initially. And I’m also sure that for some it “clicks” much easier than for others. But fundamentally, the skill to code is like a muscle: it must be trained to be useful. You can listen to a hundred talks on the mechanics of bike riding, and be an expert on the physics. If you don’t put in the hours on the pedals, you’ll never be biking from A to B.
I think this period at the beginning is the most challenging and frustrating, because you’re working so hard and seemingly progress so slowly. But the two are connected. You’re not breezing through because it is hard. You’re learning a new way of thinking. Everything else builds on this.
Once you’re more comfortable with solving isolated problems like that, consider making a simple application. For example: read an input text file, replace all occurrences of one string with another string, write the resulting text to a new text file. Don’t focus on perfection or best practices at first. Simply solve the problem the way you know how. Perhaps start with hard-coded values for the replacement, then make them configurable (e.g. by passing them as arguments to your application).
When you have a few small applications under your belt you can start to dream big. As in, start solving “real” problems. Like some automation that would help you or someone you know. Or tasks at work for a software company. Or that cool app you’ve always wanted to build. Working on real applications will give you more confidence and open the door to more learning. You’ll run into lots of problems and learn how not to do things. So many ways not to do things.
TLDR: If it’s not clicking, you need to, as a general rule, do less learning (in the conventional sense of absorbing and integrating information) and more doing. A lot of doing.
Underrated comment.
Terrific advice. Baby steps.
try https://www.composingprograms.com/
I would attribute this to the difference between programming/coding, and software design or engineering. They’re related but different concepts. Just like a builder and an architect do different things and complement each other to get a building built, these are also two distinct steps. I do think it’s easier and more common for one person to (be able to) do both tasks than in my analogy though, but it’s also done separately often enough (in industry).
My point being: don’t beat yourself up that you don’t know programming, you probably do, it’s the software design that you’re not familiar with yet. But now that you know what is missing, you can look into it and work on it, and gain a valuable skill to complement your existing skill.
I definitely feel this. I had to take a programing course in university and I was easily able to follow along up until the lesson on pointers, whereupon I completely lost the thread and never recovered.
I’ve known a good number of computer scientists over the years, and the general consensus I got from them is that my story is neither unique nor uncommon.
Yeah, some folks have trouble with pointers, and computer-engineering curricula are designed to discourage folks from taking third-year courses if pointers don’t make sense. It’s a stereotype for a reason. I’d love to know if there’s an underlying psychological explanation, or if pointers are just…hard.
I am but one man whose only education in programming was a first year university course in C from almost two decades ago (and thus I am liable to completely botch any explanation of CS concepts and/or may just have faulty memories), but I can offer my own opinion.
Most basic programming concepts I was taught had easily understood use cases and produced observable effects. There were a lot of analogous concepts to algebra, and functions like
printfdid things that were concrete and could be immediately evaluated visually.Pointers, on the other hand, felt designed purely of and for programming. Instead of directly defining a variable by some real-world concept I was already familiar with, it was a variable defined by a property of another variable, and it took some thinking to even comprehend what that meant. Even reading the Wikipedia page today I’m not sure if I completely understand.
Pointers also didn’t appear to have an immediate use case. We had been primarily concerned with using the value of a variable to perform basic tasks, but none of those tasks ever required the location of a variable to complete the calculations. We were never offered any functions that used pointers for anything, either before or after, so including them felt like busywork.
It also didn’t help that my professor basically refused to offer any explanation beyond a basic definition. We were just told to arbitrarily include pointers in our work even though they didn’t seem to contribute to anything, and I really resented that fact. We were assured that we would eventually understand if we continued to take programming courses, but that wasn’t much comfort to first year students who just wanted to pass the introductory class they were already in.
And if what you said is true, that later courses are built on the assumption that one understands the function and usefulness of pointers despite the poor explanations, then its no wonder so many people bounce off of computer science at such a low level.
Thanks for offering your perspective! It’s important that we keep in mind that not everybody who studies computer science becomes a professional programmer, and you’ve offered us good food for thought.
For what it’s worth, pointers are fundamental for Von Neumann machines, which are very common in the computing world; your current machine and the machine serving this page are both Von Neumann. In such machines, memory doesn’t just store data, but also instructions; the machine has an instruction pointer, which is a pointer referencing the currently-executing instruction in memory. So, if one wants to understand how a computer jumps from one instruction to another, then one must somewhat understand pointers.
You are welcome.
Pointers do make more sense to me now than two decades ago, mostly owing to me being married to a computer scientist. But I always go back the fact that for the purposes of my first year programming course, pointers were (probably) unnecessary and thus confusing. I have a hard time understanding things if not given an immediate and tangible use case, and pointers didn’t really help me when most of my programs used a bare few functions and some globally defined variables to solve simple physics problems.
EDIT: I’ll also say that pointers alone weren’t what sunk my interested in programming, they’re just an easily identifiable concept that sticks out as “not making sense.” At around the same time we had the lesson on pointers, our programs were also starting to reach a critical mass of complexity, and the amount of mental work I had to do to follow along became more than I was willing to put into it - it wasn’t “fun” anymore. I only did well on my final project because a friend patiently sat in my dorm room for a few hours and talked me through each step of the program, and then fed me enough vocabulary to convince the TA that I knew what I was doing.
Aren’t pointers just an ID given to a verible that currosponds to its “true” position in the array of bytes thay make up a program’s memory? I feel like I’m missing something
I doubt that you’re missing anything about pointers themselves. I may not have done a good job articulating why non-programmers have a hard time understanding them.
deleted by creator
This is my experience. I can understand the fundamentals without trouble but don’t have the ability to plan out the structure of something and write code to make that work.
I’ve done online courses, tried boot camps. It just doesn’t work for me.
if you can use a dictionary, play a card game like Uno, poker, gofish, cheat etc, use an index in an encyclopedia, Google, Wikipedia, and you can do high school algebra you can grasp the basics of coding.
Object Orientated Programming / classes / objects / inheritance is kinda like a card game
All Hearts are a type of card, all Kings are a type of card, a straight is a way of arranging cards, four of a kind is a way of arranging cards. That’s about as complicated as OOP needs to get for a beginner.
Understanding and producing are very different things.
Start small, make silly things. Html is probably the easiest thing to pick up and see what your changes are doing almost immediately. Play with formatting and styling, add pictures, learn how to create buttons and radials.
After that I’d start learning how to make stuff happen with JavaScript maybe create a pop-up when you hit a button, figure out how to change the color of elements with input boxes or sliders, etc.
When you feel comfortable enough with the language make what you want even if it already exists. Tic tac toe, a rudimentary blog, Conways game of life. Don’t be afraid to take a break if it gets frustrating and don’t be too hard on yourself if it’s not amazing.
Just remember it takes time, I hear most developers say it takes at least a year of carving a few ours a week just making stuff to really start grasping a language. So just make stuff and don’t be afraid to look it up. The more pointed your questions the easier it gets to find answers.
I jumped head first into c++ my apps are incredibly buggy and run slower than most web apps. They’re only terminal apps but I’m improving and so can you.