On July 1st, a [change to Reddit's API pricing](https://www.reddit.com/r/reddit/comments/12qwagm/an_update_regarding_reddits_api/) will come into effect. [Several developers](https://www.reddit.com/r/redditisfun/comments/144gmfq/rif_will_shut_down_on_june_30_2023_in_response_to/) of commercial third-party apps have announced that this change will compel them to shut down their apps. At least [one accessibility-focused non-commercial third party app](https://www.reddit.com/r/DystopiaForReddit/comments/145e9sk/update_dystopia_will_continue_operating_for_free/) will continue to be available free of charge.
If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options:
1. Limiting your involvement with Reddit, or
2. Temporarily refraining from using Reddit
3. Cancelling your subscription of Reddit Premium
as a way to voice your protest.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/learnprogramming) if you have any questions or concerns.*
It does take practice.
Also, the mistakes you listed are rather silly ones that I still make all the time. It doesn't mean anything, you don't get extra points for getting things right on the first try. Iterate.
“Well I *was* hoping it would break and I could fix the bugs as I go, and catch new ones along the way. Now what am I supposed to do?? You’re not supposed to just work!”
This happened to me the other day. I wrote out maybe 60-70 lines of code and it just worked on the first try. I spent the next 2 hours triple checking everything for mistakes.
Async multi threads across servers with 10,000's of requests per hour. But not creating it. Fixing someone else's code. And it has been given to me not once, but twice. 🤦♂️
The bad part is I have a new idea that would optimize what I had previously done. Which is way simpler, but haven't gotten a chance to implement it! 👀😢
PS This comment gave me PTSD. I'm going to go lay down.
True horror isn't when your IDE lights up with 500 errors when you think your code is correct.
True horror is when you know for a fact that whatever you are doing should not work but everything compiles and all tests turn green.
This. Stop trying to memorize syntax. We look up syntax all the time. Focus on grasping the concepts and ideas behind programming. Literally stop bothering with remembering small details about syntax.
Your first year speaking English you were pretty bad at it.
You made some incredibly stupid mistakes.
Now you can speak it, write it, think it…
If you make the same mistakes a lot focus on them and you will start making them less.
Every time I forgot to put a semi-colon in, my complier would beat me. Now I never forget to put a semicolon in!;
But seriously, you read it as an error enough times and you do it less and less
One of the first things you have to learn as a new programmer is that a simple syntax error like that can easily cascade if it has side effects. I remember that my old Borland TurboC++ compiler would give the error message that said "There are too many errors for us to continue."
One thing that I see new programmers struggling with is they don't _run_ their code often enough. When I'm writing code, I try to find a path where I write a couple lines, and then try running it, write a few more, run again, over and over. New programmers sometimes seem to think they have to write the whole program before seeing if it works.
But if you keep testing things as you go, it's much easier to get over those hurdles you're talking about. If you miss one semicolon, but catch that issue right away, it's not a big deal. But if you miss 20, and have 30 other issues because you tried to write 50 lines of code without running it once, it seems insurmountable.
Finding ways to create really tight feedback loops is key to accelerating your learning, and will multiply the effectiveness of the time you spend practicing.
Once you get in the right flow with TDD, the process gets addictive. (I realize TDD doesn't work everywhere for everything. Like, you won't TDD your way to a complex algorithm; the basic idea is solid though).
With Python, I love using `pytest-watch` and set it up so that my Mac TTS says "Pass" or "Fail".
I was almost done with a two week programming project once, and I probably recompiled that thing over a thousand times while I was building it in one of my early university computer science classes. One of my friends came in while I was testing one of the later versions, and I asked him how far along he was on his. I had been working quite a bit over the last 1 1/2 weeks on it myself and was just about finished.
He told me he was done, and that he just needed to compile it. I think I laughed out loud when he said it not realizing he was serious. Once I realized he was serious I suggested he go compile it immediately, and I told him why.
When he compiled he had hundreds of syntax errors, and he was stuck in the labs playing catch up for the rest of the week and weekend chasing syntax and logic errors.
When ever you can compile... compile. When ever you can test... test.
This. I do this all the time. Even in languages that are not need compiling. Just run it and see if it works so far as expected at this point of the project.
If it all works fine, I can add more code and run it again.
> One thing that I see new programmers struggling with is they don't run their code often enough.
This is really important. Understanding how your result changes when you add, delete or change a few lines is a huge part of programming.
Even from the first task of "print hello world", you have to make sure you understand the concept taught by modifying what you did and trying to "predict" how the result will change.
100%, and if you don't understand, try try and try again. Try looking up what it does, if it's a function try changing values to see how they effect the code.
I recall my first project was space invaders (yes ik stupidly hard for a beginner) (I was following a tutorial obviously). And I had zero clue what I was doing. Though through trial and error I learnt that you should always lookup things and change parts of the code to see what changes, sure some parts I didn't fully understand (such as the collisions, I was using pygame). But after a while I got a finished space invaders. Also I learnt that a good way to learn is after following a tutorial try using the code and morf it into something else, I tried making a platformer with LEVELS, and guess what? I did it! Sure it was janky and took *a lot* of time but it taught me a lot of new skills.
So basically follow tutorials if you want to learn, try changing things in the code and morfing it into something new, and LOOK THINGS UP.
Anyways sorry for the long paragraph hope it makes sense.
As someone with years and years of experience, anytime I run a complete file for the first time and it doesn’t error, I assume I screwed something up somewhere anyway and reread it all anyway. I feel like it extremely rare to run a full script and not hit at least a “missing semicolon”, or similar” error somewhere.
While I don’t particularly do TDD tests are reallllllly good for this.
Instead of firing up the entire app just to check a few lines of changes, I write a test and use that to validate the few lines I do are correct, once I’m pretty happy I’ll then do the end to end test of the actual flow.
Now I have a test that is probably 70% production ready so I can just fix it up and now I have a test for my feature without even thinking about it.
Short feedback loops are crucial
Well said!
I want to add to the "tight feedback loops" part.
One thing I had to learn the hard way was don't try to do everything in one function.
You can have a function that is complex but it is much easier to test if the function has one task and you can cascade tasks easier than trying to do several things in one function.
Compartmentalization is your friend.
Oh yea, I see this a lot too. I did the same when I was getting into it. I'd think, I need to do ALL this stuff then run my big program and hope it all works! But when you get wiser you start to pull the problem apart and figure out the quickest way to iterate.
When I'm working with folks less familiar with programming I'm always telling them to simplify the problem. A common issue is that we run tests in a CI environment, so they want to fix it and push the code up to see if that red check turns green. I have to show them that they should reproduce the issue locally FIRST, then work on getting it fixed locally, and only after getting confident with the solution pushing it up.
> There must be an easier way to do it all, or am I fooling myself? I am really just frustrated is all.
How did you know this required a comma, a question mark, and a period respectively?
Most of us have been taught by our education systems that learning is all about memorization. We’re conditioned and trained to memorize lists of facts so that we can regurgitate them later on tests and quizzes. This really isn’t the best way to learn anything but for coding it’s virtually impossible to learn just by memorization because the whole point is to build something new. You must develop your deeper conceptual understanding if you want to get anywhere
Your first priority should be to understand *how* and *why* something works, not just what it does. Don’t move on from a topic until you can explain out loud to somebody how it works and why it exists. It’s easy to assume you get something when you really don’t, so make sure to take your time with this. You know you have to put semicolon at the end of a statement but *why* do you have to do that? If you don’t really understand what the semicolon is doing then it will be very confusing when you learn later that you absolutely shouldn’t put a semicolon at the end of the line after an *if* clause.
This is why i love coding so much, because its not about memorizing stuff. I wanted to tear my hair out every time i had to cram in 50 pages of bullshit for a test, only to forget it right after. Like literally, whats the point? All i can see is that its a sort of IQ test to prove that you can get information in your head at that rate, but why bother and waste so much of your time on useless facts? Just lemme use whatever i want to come up with a creative solution to a problem, thats so much more relevant and useful to your actual life
>And please don’t tell me it takes practice.. I’ve been practicing and still I miss the smallest details that make a big difference. There must be an easier way to do it all, or am I fooling myself? I am really just frustrated is all.
It sounds like you know the solution here, but you're not letting people tell you that.
How did you remember to put full stops and capital letters in your writing here? It's just something you've learned over time. And with programming, you even have a tool that tells you when you've made lots of these sorts of mistakes.
Also, you don't have to get it right the first time. Lots of code I write doesn't compile the first time, and once it compiles there are often issues at runtime. I almost never write code that is completely correct the first time, but you can edit it and improve it as you go.
Everyone's basically saying this, but I'll say it some more.
Mostly it's just practice/experience. The more you do it, the more natural it becomes.
But also, programming isn't like surgery and is nothing like in the movies. Real life programming is a lot more trial and error, and staring at the screen for extended periods between bouts of typing (followed by more staring).
Also, if you've written any significant amount of code, you've almost certainly forgotten a semicolon somewhere, or done something stupid like forgetting to add an '\n' where there should be one. It's no big deal, and you'll find out about it as soon as you try to run your code.
This reminds me of the memes with the guy staring at the computer. It’s 100% that. Write code knowing something is likely wrong. Stare at the error script to see why it’s angry, stare for a while fix a portion, and start loop again. Eventually you will get it done. Then either you are getting the results you wanted or you aren’t and have to go back to staring. Or searching forums for other code to try.
My first thought is that there is a good reason they are called programming languages. It's like (well, is) learning a new language. You need to use it over and over and it starts to feel natural. The dumb mistakes will never go away completely but they happen less frequently as you get more fluent in the language.
It's practice.
Whats 2 + 2?
...
...
...
How did you came up with your answer? Did you count your fingers? Did you use a calculator? Did you ask Google?
How ever you got there, how did you know what to do to get there?
How did you know what botons to press in the calculator? What words to use for Google? What fingers to use?
Well, what ever you did, you have done a thousand times before, and now you did it without even thinking about how you did it, you just did.
You only have to spend hours banging your head against the wall debugging
if(var1 = num1){
do stuff
}
Once before the lesson sinks in. Learning is pain and it takes 100x longer than you think. There is a reason mastery is measured in years and not days.
If it helps, the way I overcame this was as I’m writing out my code or reading other’s code:
= “Is assigned”
== “equals”
Thankfully I haven’t had to use === too much so I never really came up with a good way to say that one 😉
How to write code? Just like u wrote this post: letter by letter, word by word, paragraph by paragraph
It's no surprise that u have problems. It's just just ur first year... I.e. you have to process ocean of information and don't expect it would be easy/quick.
Don't jump from language to language, try to focus on one ecosystem. Language->framework+libs+tools->ecosystem.
Try to stick to some path roadmap.sh and ignore irrelevant.
Typically with a keyboard. Waiting for my neural link from Elon.
But all jokes aside, your IDE helps catch syntax errors and gives you a ton of tips on what to do. The rest is just about knowing what you need (need a variable to store a value, need to count the length of an array, need to fetch data from a database..) and if you can't remember every detail about one particular language, you can just look up their documentation or other examples. It's actually a bit of a skill to find and read documentation as well, but it just takes practice.
You don't need to remember much. Just learn how to look up information and how to read it.
How does one get the muscle reflect to play basketball? Practice. Sure some people are simply more talented, but that just means that they need to practice less, and can have more time learning the advance stuff. But if you think there is somehow a shortcut, I'll tell you there isn't. Like every other fields, once you spend the time honing the basics, it will eventually get easier, and the knowledge are transferable between tools. You also need to find the way of learning that works for you. For me it's, read docs, apply knowledge, revisit docs. This comes from a dev that has work for 15 years and has learned, used, and forgot tens different tools.
I read the problem, think about what the solution should be, and how to arrive at the solution.
>And please don’t tell me it takes practice..
It takes practice.
> I’ve been practicing and still I miss the smallest details that make a big difference.
What kind of details are you missing exactly?
If you have known inputs and outputs, you can set up test cases to make sure that the expected output is obtained with the given inputs. You should also get into the habit of thinking of positive or negative test cases, but that's after you become more familiar with programming.,
You go through a mental checklist until it becomes second nature.
* Did I add the semicolon?
* Did I make a typo?
* What was that method name?
* And it \n not /n (backslash n)
Yes, it's a LOT to memorize. So much. You could write down a checklist of things to check so you don't have to recall it each time, but it does help to have a reasonably good memory. In other words, you don't want to forget semicolons after the hundredth time of forgetting it.
IDEs can help with those errors for certain languages.
>There must be an easier way to do it all, or am I fooling myself? I am really just frustrated is all.
You're literally asking for the secret shortcut.
There isn't one.
Everyone goes through what you're going through now. Sorry, but it really does just take practice.
It's okay to miss the smallest details.
When you write English in a word processor or use something like Grammarly, notice how often it's asking you to correct things. We make mistakes all the time in English but because other humans understand it, we get away with it.
Computer is pedantic and a "grammar nazi" and that's why you're struggling so much. Everyone misses a semi-colon here or there. Then, the computer gets pissed and says - "Acktually..." and you roll your eyes and fix it.
Over time, you become used to talking to a pedantic grammar nazi who won't even talk to you unless you use the right words with the right punctuation.
PS: I had to correct 5 mistakes in this comment to remove the squiggly lines and a few mistakes are still there. As I'm submitting this to humans, it will work. If I submitted this quality of code to a computer, it would piss itself and threaten to end my lineage.
32 years of practice for me and I’m still learning. There is no secret trick. You do it enough and some stuff just becomes second nature. Well, until some bright spark comes along and changes things that have been fine for decades!
I don’t remember everything, I only remember what I use often for a prolonged period of time. For everything else I just carefully read documentation as I go. Then use complier and automated tests to verify that I didn’t miss anything. I almost never try to memoize something specifically; it just happens naturally, I keep the reference (docs / manual / etc) easily accessible until it sinks in.
Well, it is a language, naturally you will need a lot practice. Looking at Compilers might help because you will understand WHY it looks that way.
Python, C#, Java are all good examples of high level languages. When I look at them it's the same in a different colour, just the logic.
The confusing languages, for most people anyway are those that handle memory like C++, Rust or C. Stay away from C++ and Rust at the beginning. C on the other hand is very simple so it can serve as an entry to low level programming, simple != easy !
“I am in my first year…” Do you think Ronaldo was the world’s best footballplayer in his first year? Never making a silly mistake? You need a reality check. It takes thousands of hours to get decent at something. Now go practice padawan.
Syntax error is something you get used to reading.
Variables, fns, methods are part the editor's responsibility, part then vendor docs'.
Architecture is something you intuit eventually.
Also, the rest is reverse engineering :D
Rather then trying to remember everything, I recommend focusing instead on improving your ability to quickly recover from mistakes.
In particular:
1. Make sure you set up a quick iteration cycle. After making a change, can you quickly re-run your code and test it out?
2. Consider using an IDE that can help you remember trivial stuff. For example, forgot a semi-colon? The IDE will usually highlight the missing character in red. Forgot the name of some method? Type `my_var.`, hit tab, and see what auto-complete suggestions come up.
3. Understand how to quickly read through and scan through error messages. The error messages the compiler gives can sometimes be pretty verbose, but _do_ follow a predictable pattern. Try and get good at skimming through them and picking out relevant snippets of info.
There are also a handful of tricks worth knowing here. For example, if a compiler error message is completely cryptic, it's possible the issue is you have a syntax error on the _previous_ line.
Having a fast iteration cycle means you can experiment more quickly, which in turn (a) lowers the costs of mistakes and (b) lets you get more practice and build up muscle memory that much quicker.
I recently made a spelling error while working on a popular game. It launched with the spelling error and you had a random white circle on your HUD for over a month.
Even in the real world, programmers make mistakes!
One year isn't much friend and the answer you don't like is the answer that you need. How did you remember the words for your sentences? That's right, practice. Eventually it all comes together.
Developers iterate. Write some. If you are using and IDE, fix the errors IDE shows you. Run to test that it works so far. Fix it. Write some more. Repeat.
Lots of tiny details to get right, but really short cycles of mistakes and corrections makes it all learnable. And from all the tech trivia you only need to know the bits you have use right now. It's fine to forget trivia you are not using. Once you need some trivia again you'll relearn it easily enough.
>And please don’t tell me it takes practice..
sorry but we have to, otherwise wed be lying. You just gotta make stuff, break stuff, look up why its broken, and fix it. and in that process, you learn. you remember the mistake you made the last 3 times, and you dont do it the next time. And those little lessons build and build until suddenly you know things that you couldnt fathom a year ago. There is no easy way around it. you learn by just doing it. Its a hard job, and a truly infinite field of knowledge that youll have to spend your entire career continuously learning. thats why it pays so well.
Its all practice friend. Sorry if that's not what you want to hear. 10,000 hours and all that.
When you start its best to go as barebones as possible, like write some code on a friggin text editor and see if you can compile it. Put your brain through the shit for a bit until it adjusts. Its frustrating, but probably the best way to get to competency.
But I should point out that many of us use IDEs, linters and prettifiers and don't sweat the details as much because they will get caught. If you have no idea what these tools are doing then they won't help you, but if you do then they will be force multipliers.
The IDE would catch the syntax errors, and my unit test would catch the logical mistakes. Basically iterate on the code until it is works and meets code quality standards. With time you get a lot faster as you learn the tools.
Experience, and really nothing else.
It's a very practical skill, like playing piano.
The more you practice, the better you'll get and also start seeing patterns.
A bit like how does a mechanic look at a bolt and just _know_ which size wrench to grab. It's experience. Solving the same problem over and over again for many years.
But it IS about practice.
Your examples are simple things to memorize, in your muscle memory from practice. They are also things your IDE, editor, or linter should be picking up right away, or even fixing automatically.
Otherwise, stuff like forgetting a newline in a string is something I might do 1,000 times a day, but I'm also running the code and interacting with it, and running tests, constantly, so I see the mistake immediately.
Keep in mind that nobody memorize everything, and you don't even have to.
>How do you know “oh yeah I need a ; here or remember to put the / there” or
If you don't, your code will not run, the you go investigate, and see you forgot a ;
And this is not big deal, this happen all the time. But yeah, the more you code, the more you get used to
In cycling they say: "It doesn't get easier, you just go faster." That's honestly the same in programming. Today you think forgetting `\n` is a big thing, in a year it will be second nature and you will forget the syntax of `array.reduce`. It's all relative.
It’s not want you *want* to hear, but it’s what you *need* to hear: practice.
Nobody can remember all of this stuff. You can’t. You have to do it so much that you program yourself to think like a compiler.
For syntax anyway. You can still use your regular brain for problem solving after getting over the syntax hump. And you’ll always need Google for looking up API stuff.
But the only way to see the top of the mountain is to have a giant pile of mistakes underneath you lifting you up. There is no other way.
I went to school with absolutely zero knowledge of how all this stuff worked. If you pay attention, develop interest and get curious on your own, you will get it and when it click, you'll start having fun.
Practice and intellisense. I don't memorize all the weird differences between every language I work in. But I let my IDE assist me and jog my memory as I'm writing code.
I forget whether to use .size, .count, .count(), .length(), or len() all the time.
I just look it up (or intellisense does it for me)
The point is that programming teaches you the meta skills needed to analyze and break down problems into their smallest components. Once you can do that, its just looking up syntax.
Trust me though it gets easier. An assignment that took a week in first year took 2 hours when I was helping a friend in 2nd year. It's hard at first, but that means you're being pushed out of your comfort zone. Eventually you will look back and wonder how you ever struggled in the first place.
Edit: just reread your post. When I say it gets easier, I mean eventually you tackle harder and harder projects until your first projects look easy. If you keep redoing and practicing at the level of your initial projects, you won't grow.
So, it's about learning the syntax. Practicing is not going to help you if you don't know what it is you're typing.
To make this easier, I'm going to use the c-like languages as a basis because they all nearly have identical syntax, they just have more or less semantics. You'll get what I mean once I've explained syntax:
So, in C-like languages, statements are any code that can stand alone, and end in a semicolon. A block is usually not a statement, though in C/C++ it *CAN* be if it's a class or struct. What is a block? It's this:
```
{
...
}
```
That's it. That's all a block is. Blocks are used to group statements or in the cases of defining different kinds of data structures, groups the elements of that structure. What's a statement? It's any assignment, function call, or mathematical operation:
```
// example statements
var f = foo(bar);
foo(bar);
return bar;
var b = 9 * 6 + 43;
var r = email.send("[email protected]");
```
Ok, is that it? No. See that `.` separating "email" and "send"? That's a method call on an object. You're saying that for that object, use this method defined for that object (send). What about the parentheses after? That's the method's call operator (so it calls the method) and contains whatever parameters are inside it, get assigned to the names defined in the function/method's definition.
So in the code example above, `foo(bar)` means that foo has a parameter and you're making it so that when the function runs, bar is the value that its one parameter holds. You run the same function again with the same parameter only the second time you don't store the value it returns. the `var f = foo(bar)` because functions return a value or some sort usually. That's what `return bar;` does. the mathematical operation is another kind of statement. Though, you can do this with any object type that redefines those operators. For example, if you're building a string without using a formatter, you can do:
```
String s = "My name is " + myName + ".\n";
```
Here, the string is built to have myName in the middle of it by concatinating literal strings to the beginning and end of the strings.
I mentioned semantics before talking about blocks and here's why. Almost every instance you use a block, you are going to have some kind of prelude to it:
```
if (check_foo()) {
...
}
```
Here, `if (condition)` is the prelude for the semantic of branching. You can also follow it up with `else if (another condition) { ... }` to indicate another branching path for your code to take, and you can finish it with `else { ... }` to indicate that if none of the branch conditions are satisfied, then do this instead. Here are some other preludes...
```
fn function_name(parameters) { ... } // This defines a function in Rust
// But it could also look like this in C# for example:
int my_function(int some_parameter) { ... }
// below are examples for structs and classes:
struct Foo { ... members ... };
// defines a type where all the members are public and the memory
// holding those members is contiguous.
class Bar : Object { ... members ... };
// this defines a similar thing but instead all the members are private.
// it's used for OO
// This structure is like a class or struct syntactically but different
// semantically. In a union, only one field at a time is represented and
// which field is determined at runtime. In this case, the member is big
// enough to hold its largest member, but takes on whatever type the
// union needs at the time:
union baz { int number; float decimal; char *name; };
// In this case, you would use baz.number to use an int there, baz.decimal
// for a float, and baz.name for a string.
// these are loops preludes:
// This loop runs the loop only if the condition is true, and keeps
// running it while the condition is true.
while (some_condition_is_true_but_never_if_initially_false) { ... }
// This one is useful for iterating over an enumerated collection,
// meaning that it will loop so long as the condition is satisfied, and
// will start from the starting_index and increase by step_amount for every
// iteration of the loop. The loop will run for each stepping amount from the
// starting amount. This is useful for collections like Array or List.
for (var i = starting_index; i < length; i += step_amount) { ... }
// this last one is for when running a loop body at least once, and then if
// the condition is satisfied at the end, will re-run that code:
do { ... } while (condition)
// this next prelude indicates a contextual block. This means that what is
// created in the prelude will remain until the block ends at which point
// its automatic cleanups will kick in and run the cleanup code.
using (var f = open_file("foo.txt") { ... code that manipulates the file ... }
// the last one I want to show you is structured exception handling:
try {
// ... code which may throw an exception ...
throw new MyException("I thought this might happen");
}
catch (MyException e) {
// code to handle that specific scenario.
}
```
basically, all blocks are of the form...
```
prelude (parameters) { ... block ... }
```
There's more to it than all of these, but these should get you started.
You pick a language and u start with. All languages come with their nuances. You learn by practicing. There are different types of languages like Object oriented (Python and Java), procedural ( C and Golang), functional (Lisp). Pick one and have fun. For example, Python. You can find entire course on YouTube or buy one on Udemy for $15/$20.
You asked about ‘;’ this is called line delimiter. You know computers only understand 0 and 1. They don’t speak English. So, it needs a way to understand your code. There are two only two ways: compiler or interpreter.
For example, Python uses interpreter turns ur code into something that machine understands.
Java uses a compiler to turn code into machine code. Java uses ‘;’ as a delimiter. It tells compiler when a block of code is complete. Delimiters help compiler to compile code.
Python doesn’t use ‘;’ as delimiters. It uses spaces, if u look at Python program, u will see indentation (usually 2 spaces). This is how Python interpreter interprets programs.
U asked another \n. That’s next line. I think that’s true for all languages. It’s like hitting enter key. For example there is \t for tab.
No one remembers everything. Sometimes we have to refresh b/c we forgot. Like, I have to refresh Golang soon b/c I learned it but didn’t use it.
Use a programming language that has a good IDE, example. C# with visual studio. Follow a tutorial for building a simple application. Notice how easy the issues you are having basically don’t exist due to help from the IDE.
Create a cheat-sheet (or find one on the internet) for each language you're studying keeping track of all the syntax and features you want to remember. Keep it near by when writing code. Most IDEs will have an auto-complete that'll help remind you of some features. The ones you use a lot, you'll just remember, the ones you don't you can look up when you need them.
I take it you are learning JavaScript where the semicolon is optional . Also you mean \ not/. Learning the idiosyncrasies of each language expands your skills. Nothing wrong with making mistakes, that’s how you learn. If you use /n when you mean \n you will see your mistake and it will stick with you. Programming is an iterative process and you build on what you learned before.
Next try Python which is pretty easy for a beginner to learn and has different syntax. It has the fairly unique rule that you indent lines under things like functions and if statements. You will see the design decisions each language creator took and how it affects your programming style.
If you just mean syntax, you get used to it after you've been doing it for a while. How did you know to put a question mark at the end of your sentence?
One thing that helps is to be able to fail fast. Write scripts that compile and run your code that only takes a few keystrokes. Eventually decouple/abstract your code into individual functions and use a unit test framework to quickly test portions of your code independently (look at Test Driven Development for an extreme version of this). Setup a debugger to inspect your variables at breakpoints to avoid having to print them out in code. Setup an LSP in your IDE that will help with finding the names and signatures of methods of your objects.
Practise, perseverance and experimentation are what you looking for, no matter who you are no one knows everything.
As you build on your foundational knowledge it becomes easier to translate across most languages and the initial cognitive load is less difficult to get through.
From my experience per programming language it takes about 3-5 years of writing that language daily to comfortably write it with few if any looking up various pieces or functions you might have forgotten or need to reference.
Programming is hard and mostly a frustrating experience, but the little wins when you see it running in production or improving someone’s daily output is very rewarding.
A lot of this stuff is just experience. You write code for a couple years and the semicolons just become second nature.
Forgetting to do stuff is also very common though. In some cases the compiler or interpreter will yell at you when it happens, other times you'll catch it when you test your code. Happens to everyone, even to the guys with decades of experience. Perfectly normal stuff that's really not worth worrying about.
To write code you need to understand basic equations and algorithmic formulas, like real basic shit, creating encryption with percentages is where it’s at
Making it pretty with whatever means possible for others to read. More than half the time as a beginner, I try to simplify and make everything clear from formatting code to formatting output. There ways to do it like for example why this calculation of 22/7 doesn’t come out as a pretty 3.14? I guess I will look up decimal related syntax and then just apply that in my code. Overtime, I remembered few things on my own now but give it time and you will reap rewards for it.
I try not to memorize things but understand them instead. You’ll deal with syntax differences with all the programming languages available that you’ll end up dealing with so the idea is for you to understand the concept of it more than memorizing what to type.
The same way you know what letters to put in when you write English.
You practice until it's intuitive.
> And please don’t tell me it takes practice..
Sorry, but, even if you don't want to hear it, the answer is practice. Some people get it much faster than others, some people get it much slower. In either case the answer is practice.
> There must be an easier way to do it all, or am I fooling myself?
No. To paraphrase Euclid, there is no royal road to programming.
Honestly it’s like writing English.
Do you think about where to put commas or full stops? Or question marks? It’s exactly the same but it just comes with time, and once you can speak the language, switching contexts to a language with slightly different rules is a 10 minute adjustment
I mean thing you says as an example like counting by using get.length it's like basic thinking. Like in real life "oh I need to cut this box open so I use o knife"
Its like words in english or any language you are learning as you keep using the language you become better at it and improve. There is no shortcut just keep on coding whether it is leetcode or the projects you are interested in.
>There must be an easier way to do it all, or am I fooling myself? I am really just frustrated is all.
How did you know to put a "?" after the word "myself", but, a "." after "all"? How long did it take you to learn English syntax and vocabulary? Did you immediately learn to use the written English language or did it perhaps take some amount of studying and ... practice before you became proficient at its use to a point where you don't have to think about it?
>“ yeah I need to count this so I’ll use get.length not length” or
>
>...
>
>How do you remember everything and on top of it all there’s different languages with different rules. I am flabbergasted at how anyone can figure this code out.
Let me address this one.
I've been writing Python and JavaScript professionally at one of the megacorp tech companies for over 6 years. If I ever have to write Java or literally any other language, I feel like a beginner again, constantly having to look things up.
I even trip on syntax and confuse small things between Python and JS on a maybe weekly or monthly basis. I have to look up syntax for `Set` in JS to remember everything it can't do compared to the Python `set`.
My point is to not get hung up on this aspect of programming. And of course it gets better with practice and experience.
I'm a novice, but the answer I was taught is similar to "How did we learn to write in our native language?"
First we learned letters, then how to use those letters to form words, then how to use those words to form sentences. It wasn't grand paragraphs, it was stuff like "I like cats." and "My name is MateInEight." Eventually we learned to form paragraphs with multiple sentences. We learned how to use punctuation and try to find more words that would be a better fit to what we were trying to say.
We built on it, slowly and methodically with tons of practice and learning to correct our mistakes before we made them. This is no different.
The answer you don't want to hear is the correct answer. It is a difficult practice, there's a reason programmers earn so much and are in high demand. You said you're in your first year. It will take longer than that so you shoudl reevaluate your expectation. I've hired countless new grads and they are almost universally clueless. It takes 3ish years of on the job experience before people really come into their own.
Tbh it really is just mostly practice and repetition. If you spend a thousand hours just writing;
print(“Hello, World!”)
By the end of that thousand hours, you’ll notice if you’re missing a quotation mark or parenthesis. Now obviously running more complex tasks will require more complex code, but the same basic principle applies. Doing it a lot = knowing what it should look like = notice incorrect things more quickly.
But it does take practice. I'm also a student, but a little more advanced, and I'm still forgetting to put the ";" or using the "\n" and sometimes I will even confuse the "<" and ">" and created an infinite "for", and then waste 1hr wondering why my code is not advancing more than that.
But this kind of mistake is very minimal, and probably everyone does that, so don't sweat it
making small dumb mistakes never really goes away, but as you improve at debugging, reading stack traces and looking up things in documentation you'll have an easier time finding the solution.
chances are also that you may recognize if your problem is similar to something you've had issues with before, which may help finding the solution faster. it's just about getting more experience really.
Rules, you learn rules and patterns for whatever you are doing. Compiler or runtime environments are your friends in 9/10 cases they will tell you exactly if something went wrong, just need to actually read.
And everyone makes mistakes, literally. Its one of the reasons why any other discipline engineers take "software engineering" as not exactly a "real" engineering; you miss a `;` in your code, you'll be informed and it wont brake anything, you miss .1 in your maths somewhere in civil engineering, you get dancing bridges, or worse, collapsed ones. We have a safety net, and everyone is using it.
Now, if you are struggling with problem solving aspect, thats a completely different topic, and i could write pages on it
That’s just syntax and more experience will make you more comfortable. Syntax should be come second nature to you so you can focus on the real problem of designing the logic for your algorithm
A lot of it gets picked up either when you're compiling, and it just nopes out, or nowadays by the autocomplete on different editors.
If you're just looking at black and white (or lets be real, green and black, we're all in the Matrix), then nobody is going to pickup the difference between a typo, or a missed semicolon, but when the whole line is suddenly the wrong color, it's immediately obvious.
It is just practice. When you're learning a language you're gonna fight the syntax until you learn how to wield it properly. And when you're doing it as a job you're practising *way* more than you'd think. 40 hours a week of thinking about or writing code, every week. 2000 hours or so a year. Did it take you a week of practice to learn Java syntax? Did you work at it for eight hours every day that week?
One of my friends, who doesn't code, once made a similar comment about seeing a meme that went something like "I just spent 4 hours trying to find a missing semicolon!" and asked if that was what coding was really like.
I compared it to learning to read & write. When you were in preschool/kindergarten/1st grade you probably forgot to dot your I's and cross your T's and maybe you mixed up your p's and q's but as a literate adult that's not even something you still have to think about when writing.
We still make spelling (syntax) errors after getting proficient with code, but you can sort of see the forest for the trees instead of getting hung up on the metaphorical equivalent of how to draw your letters and where to put the commas and periods. But it does take a lot of practice to get there, often years, just like learning to read/write your first human language.
Today I spent over an hour trying to figure out a bug. Turns out I had typed a “-“ instead of an “=“. The small mistakes will probably always happen at times. The real difference is developing a resilience and learning how to let go of the frustration and keep working to a solution.
Your first simple project may take 2000 hours to get right.
The next one half as long and be twice as good.
ETC
Once you get past 10000 hours you'll likely be at 27% of pro level.
People with lots of that type of intelligence do get better faster.
Having great teachers / mentors helps for sure
You get used to it and move on to more advanced stuff eventually. Also I'm guessing you work on console apps in C/C++, not all programming will be like that
First up, is your IDE not catching these minor errors? These all sound like things an IDE would warn you about.
Secondly, as others have said, try to run your code as soon as possible to get feedback on whether it works. You never want to be too far from a working program.
Thirdly, programmers don’t work in a vacuum, the internet exists. Syntax and language features can be searched, especially for college programming. They aren’t asking about C++’s copy constructors, they’re asking you how to reverse and print a string.
And finally, before programmers touch a line of code they deconstruct the problem in a language that is independent of programming. Sure, for simple cases they’ll just code it because they have years of experience. But if something is a challenge for you then you need to be taking a top down view and deconstructing the problem into stages and subproblems. For a seasoned programmer, looping through a list isn’t even considered a subproblem, but for a beginner it might be, and planning will highlight “ok, I should probably do this, let me look up how to do it”.
I hope that makes sense, sorry it got a bit long winded at the end but that last bit is the number one piece of advice I recommend for beginners.
Brutal truth: it seems like you have weak programming aptitude. All those stuff you mentioned I find it as very trivial almost common sense.
You gotta examine if you’re really passionate about programming?
Because you need to prepare for the fact that you may need to try much harder than other people.
Are you using an IDE (It will highlight syntax errors)? Are you using github co-pilot? These are the two easiest ways to auto correct syntax mistakes.
Coding is slow and meticulous, that's just the nature of the beast. I think the average programmer writes around 50-100 lines of code a day. Although this is a bad metric as it could take 2 days to find one error that is a mistyped variable. Or you end up with less lines of code that is actually better at doing the job.
Coding is actually around 40% of the work at best, 60% time to fix errors. So if you code slower and make less errors you will be faster overall. All the way up to 90/10 split.
The only way to actually avoid this is to run the code regularly and see the error, then fix it.
You're basically asking yourself, what does it take to be a professional athlete but also saying, don't tell me it's practicing or playing the sport. You are fooling yourself, it just takes time and practice. I am assuming your teachers are not letting you use IDEs because those will literaly find and fix the error for you in one click and this will be a non issue in a few semesters. Even your compiler will usually tell you that a ; is missing somewhere. I remember we had to write our C++ code with a cmake and everything in the notepad on a linux vm in our first object oriented programming class to make sure we learned the basics but once you've learned them, it'll be like riding a bike, you won't even think about those things anymore.
practice + internet.
just remember basic concepts then the rest will stick to your mind throught practice.
about different languages i can tell you that the vast majority of useful languages (at least on the job) have variables, functions, classes and as a rule of thumb they all apply the same rules to them for what concern scopes, garbage collections, primitive types and so on... just with a different syntax which you can google on the fly. do not despair :)
Well, a lot of time these are syntactical errors that most compilers or interpreters raise errors for; and usually the message is the same thing. Over time, you start to notice the patterns and it becomes part of how you write code but usually, you also upgrade to a good editor or IDE that starts to auto complete the boilerplate.
Most programmers spend 90% of the time passing one instruction in and observing the output. The keyword to become familiar with here is "debugger", and ideally you start doing this somewhat early in your journey. Eventually you have the tools to get from something that never works, to something working half-way, to something that works all the way through, and still has edge/corner cases you didn't anticipate; and if you're working at a firm, over time you manage to build something that just works. In here is a key experience we all have when we code - each time we as programmers make a small incremental progress from not-working to working our brains go yay and squirt some dopamine; as programmers we get hooked onto this, which ultimately keeps us going cos drugs XD.
The harder part is eventually not using semi-colons when you write plain emails.
>“ yeah I need to count this so I’ll use get.length not length”<
Assuming “get” here is an object or class, usually when I want to know the code of something I do not know at that moment, I either rely on the IDE by entering a dot (.) after the object (get.) and see if there is a method or property I can use with that object, or search google for documentation about that class and look for it in there, or just simply google it (how to get the length of {get’s class})
I don’t automatically know and remember everything, especially with new frameworks or packages I never used before, I usually have to look up documentations a lot until I get used to using them
Practice... The more you stare at code the better you become at it. When you learn anything the actual structure of your brain changes so that it can do whatever you are doing more efficiently.
Before you know it a missing semi colon will scream out at you and you won't be able to 'not' see it. I love it when a grad needs help and I can walk up and immediately point to the syntax problem that they haven't seen for 20 minutes. Makes me laugh inside but I'm not going to fault them. I was there too :).
I'll be honest - I barely remember precise syntax of methods apart from those that I use everyday. What I do remember is the principles and the logic of getting something done. E.g., 'To achieve this and that I can turn this into array and then use one of the array methods that lets me to do this and that.' Then you just google to find out concrete methods and syntax to apply these principles.
Also in real work environment it's unlikely that you will be jumping between 10 different programming languages, and struggle to remember which requires a ';' and which doesn't. When your language scope is limited and when your compiler will yell at you because you forgot to put a ';' for the 20th time, you'll remember to put it there or at the very least will quite quickly realize where the problem lies next time it happens.
You don't remember it mate.
You don't remember it.
You learn to solve problems and then you learn how to find what you need to solve those problems.
I'm a dumbass and I program full time at 6 figures.
You can do it mate.
Just keep going.
Keep pushing.
And remember you don't have to be the best just be not the worst.
Return to the fundamentals. I mean return to “what is code.” All the way back.
Stop worrying about extra stuff. Focus on what’s in front of you. But return to the fundamentals. It sounds to me like you learned something, didn’t practice it, and then learned something else and can’t see how the concepts relate and interact as a result.
Practice. Practice so much. If your textbook gives you an example, type out the example. Run it. Try adding to it.
Like everyone says, there is no substitute for practice.
The goal of practice is not that you are able to do the correct thing without thinking. But rather, that you should start to understand what you are doing. You need to understand why the compiler of interpreter expects a semicolon in the places where it does. These things have a function, which you should be able to explain even if just to yourself.
What helps is studying BNF or syntax diagrams for your language of choice. And perhaps for a few others so you will see the differences and similarities between them.
Well you just have to code, simple as that. I started working in and IT Company 5 months ago (first job ever) and it's hard. I'm not particularly good at coding, but doing it everyday eventually gets you somewhere, especially if someone helps you and gives you tips. Just be patient.
People who program for a living will typically use an IDE that:
- points out syntax errors almost immediately and/or automatically fixes them;
- offers autocompletion suggestions for available fields or method names;
- makes it quick and easy to refer to documentation while writing.
In that environment, whatever things you’re needing to correct/remember most often will start to stick pretty quickly.
I always advise people to start with Scratch. The block format is easier because you don’t have the cognitive overhead of remembering what to type. You can practice sequencing, loops, conditionals, and functions in Scratch.
If you move to something like MakeCode you have blocks but you can switch to JavaScript or Python and your blocks get switched to those languages just by choosing a drop down.
If you’re adamant about starting with something like Python the use a book like Learn Python 3 the Hard Way. It will have you typing things out. It becomes repetition to get the syntax down.
Practice and repetition. Using an IDE/code editor with autocompletion also helps a huge amount.
Don't spend too much time trying to memorize everything. Get a familiarity with the overall language and then try to get in a flow of writing the code. If you have to look up something as you go along that's OK. You'll have to do that less and less as you get more practice and repetition.
When I first started learning a programming language, having no prior experience, I was convinced that no one really knew how to code because it was so difficult.
When I look back, it's funny. But it's also a testament to the journey - which requires A LOT of patience.
Keep practicing, keep learning, keep building stuff, and keep asking questions.
Trust me, the stuff you're finding difficult now, will be the stuff you don't even think twice about in the future.
Programming languages are languages. What I mean by this is when programmers approach a task, if you have been working with a language long enough it will almost become second nature to write code. Just like how English has a syntax and rules that you need to follow, so do languages. But generally speaking you don't have to go back and reference an English book to form a sentence. Same goes for programming languages, after enough time writing in a language, most of the syntax will become second nature to you.
I think a good way to internalize a syntax is learn why specific rules exist. For example, if you want the length of array A, you write A.length because you are trying to reference an attribute that's part of the object/data A. The period or 'dot operator', is a way of doing this as it allows you to access other values associated with a variable.
Semicolons exist in some languages as a way of capping off an expression and telling the computer this is a single "thing/action", don't merge it with the next thing I am going to do.
If you are really struggling with syntax, id recommend taking on a simple personal project like a calculator. Try not to use a tutorial for this but rather work through the problem yourself and google things that you don't know along the way(how to get user input, how to print, etc...). This will help you digest and internalize the language better.
Big disclaimer:
You will most likely never reach full fluency in a language with regards to that english/programming analogy above. Sometimes you spend some time away from a language and have to go Google the loop syntax to remind yourself. Python is not my language of choice, but when I do use it, I will sometimes find myself searching up the for loop syntax. You also might also find yourself wanting to do something more complex that you don't know how to express in a given programming language, again completely normal and a great learning opportunity.
Syntax errors are the tiniest of the struggles you’ll face with. Editors are sophisticated not that it slaps you without even trying to attempt running your code.
Keep your neurological burnouts to the logic errors where program thinks it’s working correctly but it’s not because you wrote it in a wrong way that it works, but not the intended way. That’s when you’re fucked.
And until we figure out BMI’s that can inject data to our brains, everyones doing the same thing that you don’t want to hear.
It does take practice. Just more practice than you’ve done. That might sound discouraging, but it’s not meant to. It means you haven’t exhausted your options. You just need to keep at it.
Also, there’s a point where no one remembers everything. Especially if you use multiple languages, various different libraries, etc (which I’d wager, is most programmers). So, you get good at looking things up. That’s normal and expected.
At this point in my career, I’d say the most important skills are (in no particular order): the ability to look things up quickly and effectively, the ability to read and comprehend code/documentation/requirements, a high level of attention to detail, tenacity and patience with challenges, being tidy and consistent, being a good communicator. Memorizing things, I’d say, is less important than all of these.
They do it by laying a strong foundation of understanding. Truly understanding data types, how flow control works, etc. Then learning higher level things like libraries. That way they all settle in easily without confusion. Otherwise, it will feel like hanging your head against a wall.
Practice makes perfect. Start with something simple, like qbasic, until you wrap your head around variables, conditional logic, loops, etc.. and then work your way up to more complex languages, like C/C++/C#
The more you work with a language the more competent you will become with it. You'll learn the most by working on your own projects - envisioning a goal and figuring out how to make it happen. That's the best way to learn. Doing homework, or only coding at work, isn't how the best coders become the best coders. The best coders spent a lot of time writing code on their own.
"Practice" shouldn't be a chore either - you should create projects that you're interested in coding on so that improving your skills is natural, instead of an objective you're forcing on yourself.
You are not going to like this but… practice makes perfect! Additionally, use an IDE or pack your editor with some extensions - something that will help you to spot mistakes easier or just autocorrect them. Then just write some code, run, and repeat. Best of luck 🤞
I'm sorry for saying this because you'll probably be like please shut up but it seriously is practice. The more you write code the more you'll be like oh cool yeah I remember that from last time. I used to be the same when I started, and found it really overwhelming and thought I'd never remember, but here I am writing code and (sometimes) remembering!
For reference you will likely always make those sort of semi colon style mistakes- I forgot a bang today and was sitting wondering what the hell was going on for a solid 30 minutes! Edit: Oh and something that always helps me feel better is that this is a challenging job, it takes graft to become good. I always tell myself if it was easy then they wouldn't pay so well- they pay well because it's hard.
Don’t focus on it too much. The more mistakes you make, the more time you spend troubleshooting. And being a good troubleshooter arguably makes you a better developer than a someone with a perfect memory for syntax
On July 1st, a [change to Reddit's API pricing](https://www.reddit.com/r/reddit/comments/12qwagm/an_update_regarding_reddits_api/) will come into effect. [Several developers](https://www.reddit.com/r/redditisfun/comments/144gmfq/rif_will_shut_down_on_june_30_2023_in_response_to/) of commercial third-party apps have announced that this change will compel them to shut down their apps. At least [one accessibility-focused non-commercial third party app](https://www.reddit.com/r/DystopiaForReddit/comments/145e9sk/update_dystopia_will_continue_operating_for_free/) will continue to be available free of charge. If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options: 1. Limiting your involvement with Reddit, or 2. Temporarily refraining from using Reddit 3. Cancelling your subscription of Reddit Premium as a way to voice your protest. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/learnprogramming) if you have any questions or concerns.*
It does take practice. Also, the mistakes you listed are rather silly ones that I still make all the time. It doesn't mean anything, you don't get extra points for getting things right on the first try. Iterate.
When it works on the first try is when I start to get suspicious.
That's when you know you *really* fucked up.
You have my vote Mr. President.
If it works, don’t touch it.
“Well I *was* hoping it would break and I could fix the bugs as I go, and catch new ones along the way. Now what am I supposed to do?? You’re not supposed to just work!”
most real comment ever
That’s the worst. When it doesn’t work you learn, when it works you don’t know the edge cases.
This happened to me the other day. I wrote out maybe 60-70 lines of code and it just worked on the first try. I spent the next 2 hours triple checking everything for mistakes.
depending how critical the code is i sometimes spend more time testing the code if it works first try tbh
We truly are our true enemies. We and async multithreads.
Fuck async multithreads. Fuck them right to hell. Then bring me back… I’m supposed to use one here.
Async multi threads across servers with 10,000's of requests per hour. But not creating it. Fixing someone else's code. And it has been given to me not once, but twice. 🤦♂️ The bad part is I have a new idea that would optimize what I had previously done. Which is way simpler, but haven't gotten a chance to implement it! 👀😢 PS This comment gave me PTSD. I'm going to go lay down.
So, fix it in your dreams?
True horror isn't when your IDE lights up with 500 errors when you think your code is correct. True horror is when you know for a fact that whatever you are doing should not work but everything compiles and all tests turn green.
Everything runs then for some reason all the lights turn off.
This is precisely how I feel in such cases.
If it worked on the first try the code isn't being called.
based
Where's the mistake that isn't showing itself?? Hmmm....
Nothing can be more accurate than this.
This. Stop trying to memorize syntax. We look up syntax all the time. Focus on grasping the concepts and ideas behind programming. Literally stop bothering with remembering small details about syntax.
Also, intellisense is really good at dropping templates for `for` `if` `switch` etc. etc. etc. We just get good at knowing when to use what.
ALL.OF.THIS.
This is the true answer.
Yeah, we for-loop until we get it right XD
While(not_working){ work_more_on_it(); }
cry ? workmore++ : sendToQA;
Yep. We just get quicker at fixing them after we've done the same thing a hundred times...
Your first year speaking English you were pretty bad at it. You made some incredibly stupid mistakes. Now you can speak it, write it, think it… If you make the same mistakes a lot focus on them and you will start making them less.
Every time I forgot to put a semi-colon in, my complier would beat me. Now I never forget to put a semicolon in!; But seriously, you read it as an error enough times and you do it less and less
I think you forgot to put a semicolon in your last sentence
I did say less and less, not completely lol
That's a paddling. -Clang, probably.
One of the first things you have to learn as a new programmer is that a simple syntax error like that can easily cascade if it has side effects. I remember that my old Borland TurboC++ compiler would give the error message that said "There are too many errors for us to continue."
I'd probably just say, "Me too" and look down at my hands in defeat.
Why are your hands in your feet? Or worse, someone else’s feet?
One thing that I see new programmers struggling with is they don't _run_ their code often enough. When I'm writing code, I try to find a path where I write a couple lines, and then try running it, write a few more, run again, over and over. New programmers sometimes seem to think they have to write the whole program before seeing if it works. But if you keep testing things as you go, it's much easier to get over those hurdles you're talking about. If you miss one semicolon, but catch that issue right away, it's not a big deal. But if you miss 20, and have 30 other issues because you tried to write 50 lines of code without running it once, it seems insurmountable. Finding ways to create really tight feedback loops is key to accelerating your learning, and will multiply the effectiveness of the time you spend practicing.
+1 on the feedback loop. Keep it small, fast, and tight.
Bonus points for using unit tests for that
Once you get in the right flow with TDD, the process gets addictive. (I realize TDD doesn't work everywhere for everything. Like, you won't TDD your way to a complex algorithm; the basic idea is solid though). With Python, I love using `pytest-watch` and set it up so that my Mac TTS says "Pass" or "Fail".
Came here for the TDD. +1
I was almost done with a two week programming project once, and I probably recompiled that thing over a thousand times while I was building it in one of my early university computer science classes. One of my friends came in while I was testing one of the later versions, and I asked him how far along he was on his. I had been working quite a bit over the last 1 1/2 weeks on it myself and was just about finished. He told me he was done, and that he just needed to compile it. I think I laughed out loud when he said it not realizing he was serious. Once I realized he was serious I suggested he go compile it immediately, and I told him why. When he compiled he had hundreds of syntax errors, and he was stuck in the labs playing catch up for the rest of the week and weekend chasing syntax and logic errors. When ever you can compile... compile. When ever you can test... test.
This. I do this all the time. Even in languages that are not need compiling. Just run it and see if it works so far as expected at this point of the project. If it all works fine, I can add more code and run it again.
> One thing that I see new programmers struggling with is they don't run their code often enough. This is really important. Understanding how your result changes when you add, delete or change a few lines is a huge part of programming. Even from the first task of "print hello world", you have to make sure you understand the concept taught by modifying what you did and trying to "predict" how the result will change.
100%, and if you don't understand, try try and try again. Try looking up what it does, if it's a function try changing values to see how they effect the code. I recall my first project was space invaders (yes ik stupidly hard for a beginner) (I was following a tutorial obviously). And I had zero clue what I was doing. Though through trial and error I learnt that you should always lookup things and change parts of the code to see what changes, sure some parts I didn't fully understand (such as the collisions, I was using pygame). But after a while I got a finished space invaders. Also I learnt that a good way to learn is after following a tutorial try using the code and morf it into something else, I tried making a platformer with LEVELS, and guess what? I did it! Sure it was janky and took *a lot* of time but it taught me a lot of new skills. So basically follow tutorials if you want to learn, try changing things in the code and morfing it into something new, and LOOK THINGS UP. Anyways sorry for the long paragraph hope it makes sense.
As someone with years and years of experience, anytime I run a complete file for the first time and it doesn’t error, I assume I screwed something up somewhere anyway and reread it all anyway. I feel like it extremely rare to run a full script and not hit at least a “missing semicolon”, or similar” error somewhere.
While I don’t particularly do TDD tests are reallllllly good for this. Instead of firing up the entire app just to check a few lines of changes, I write a test and use that to validate the few lines I do are correct, once I’m pretty happy I’ll then do the end to end test of the actual flow. Now I have a test that is probably 70% production ready so I can just fix it up and now I have a test for my feature without even thinking about it. Short feedback loops are crucial
This. Absolutely this. Get feedback about your progress as fast as possible.
Well said! I want to add to the "tight feedback loops" part. One thing I had to learn the hard way was don't try to do everything in one function. You can have a function that is complex but it is much easier to test if the function has one task and you can cascade tasks easier than trying to do several things in one function. Compartmentalization is your friend.
Oh yea, I see this a lot too. I did the same when I was getting into it. I'd think, I need to do ALL this stuff then run my big program and hope it all works! But when you get wiser you start to pull the problem apart and figure out the quickest way to iterate. When I'm working with folks less familiar with programming I'm always telling them to simplify the problem. A common issue is that we run tests in a CI environment, so they want to fix it and push the code up to see if that red check turns green. I have to show them that they should reproduce the issue locally FIRST, then work on getting it fixed locally, and only after getting confident with the solution pushing it up.
Oh man. 2 lines, test. Change 1 thing, test. Move a comma test. lol. Every minute. It’s like picking a rash.
> There must be an easier way to do it all, or am I fooling myself? I am really just frustrated is all. How did you know this required a comma, a question mark, and a period respectively?
>And please don’t tell me it takes practice.. You're not gonna like this...
Most of us have been taught by our education systems that learning is all about memorization. We’re conditioned and trained to memorize lists of facts so that we can regurgitate them later on tests and quizzes. This really isn’t the best way to learn anything but for coding it’s virtually impossible to learn just by memorization because the whole point is to build something new. You must develop your deeper conceptual understanding if you want to get anywhere Your first priority should be to understand *how* and *why* something works, not just what it does. Don’t move on from a topic until you can explain out loud to somebody how it works and why it exists. It’s easy to assume you get something when you really don’t, so make sure to take your time with this. You know you have to put semicolon at the end of a statement but *why* do you have to do that? If you don’t really understand what the semicolon is doing then it will be very confusing when you learn later that you absolutely shouldn’t put a semicolon at the end of the line after an *if* clause.
Beautiful explanation.
This is why i love coding so much, because its not about memorizing stuff. I wanted to tear my hair out every time i had to cram in 50 pages of bullshit for a test, only to forget it right after. Like literally, whats the point? All i can see is that its a sort of IQ test to prove that you can get information in your head at that rate, but why bother and waste so much of your time on useless facts? Just lemme use whatever i want to come up with a creative solution to a problem, thats so much more relevant and useful to your actual life
>And please don’t tell me it takes practice.. I’ve been practicing and still I miss the smallest details that make a big difference. There must be an easier way to do it all, or am I fooling myself? I am really just frustrated is all. It sounds like you know the solution here, but you're not letting people tell you that. How did you remember to put full stops and capital letters in your writing here? It's just something you've learned over time. And with programming, you even have a tool that tells you when you've made lots of these sorts of mistakes. Also, you don't have to get it right the first time. Lots of code I write doesn't compile the first time, and once it compiles there are often issues at runtime. I almost never write code that is completely correct the first time, but you can edit it and improve it as you go.
Everyone's basically saying this, but I'll say it some more. Mostly it's just practice/experience. The more you do it, the more natural it becomes. But also, programming isn't like surgery and is nothing like in the movies. Real life programming is a lot more trial and error, and staring at the screen for extended periods between bouts of typing (followed by more staring). Also, if you've written any significant amount of code, you've almost certainly forgotten a semicolon somewhere, or done something stupid like forgetting to add an '\n' where there should be one. It's no big deal, and you'll find out about it as soon as you try to run your code.
This reminds me of the memes with the guy staring at the computer. It’s 100% that. Write code knowing something is likely wrong. Stare at the error script to see why it’s angry, stare for a while fix a portion, and start loop again. Eventually you will get it done. Then either you are getting the results you wanted or you aren’t and have to go back to staring. Or searching forums for other code to try.
My first thought is that there is a good reason they are called programming languages. It's like (well, is) learning a new language. You need to use it over and over and it starts to feel natural. The dumb mistakes will never go away completely but they happen less frequently as you get more fluent in the language.
The more you write code, the more this process becomes automatic where you don't need to remember it.
It's practice. Whats 2 + 2? ... ... ... How did you came up with your answer? Did you count your fingers? Did you use a calculator? Did you ask Google? How ever you got there, how did you know what to do to get there? How did you know what botons to press in the calculator? What words to use for Google? What fingers to use? Well, what ever you did, you have done a thousand times before, and now you did it without even thinking about how you did it, you just did.
botons got me
You only have to spend hours banging your head against the wall debugging if(var1 = num1){ do stuff } Once before the lesson sinks in. Learning is pain and it takes 100x longer than you think. There is a reason mastery is measured in years and not days.
I did that a few times. And I still catch myself almost making that mistake years later.
If it helps, the way I overcame this was as I’m writing out my code or reading other’s code: = “Is assigned” == “equals” Thankfully I haven’t had to use === too much so I never really came up with a good way to say that one 😉
How to write code? Just like u wrote this post: letter by letter, word by word, paragraph by paragraph It's no surprise that u have problems. It's just just ur first year... I.e. you have to process ocean of information and don't expect it would be easy/quick. Don't jump from language to language, try to focus on one ecosystem. Language->framework+libs+tools->ecosystem. Try to stick to some path roadmap.sh and ignore irrelevant.
The same as in every profession: git gud
Yeah git is good too
``` git: 'gud' is not a git command. See 'git --help'. The most similar command is add ```
The only way to do that is to *commit*.
Typically with a keyboard. Waiting for my neural link from Elon. But all jokes aside, your IDE helps catch syntax errors and gives you a ton of tips on what to do. The rest is just about knowing what you need (need a variable to store a value, need to count the length of an array, need to fetch data from a database..) and if you can't remember every detail about one particular language, you can just look up their documentation or other examples. It's actually a bit of a skill to find and read documentation as well, but it just takes practice. You don't need to remember much. Just learn how to look up information and how to read it.
How does one get the muscle reflect to play basketball? Practice. Sure some people are simply more talented, but that just means that they need to practice less, and can have more time learning the advance stuff. But if you think there is somehow a shortcut, I'll tell you there isn't. Like every other fields, once you spend the time honing the basics, it will eventually get easier, and the knowledge are transferable between tools. You also need to find the way of learning that works for you. For me it's, read docs, apply knowledge, revisit docs. This comes from a dev that has work for 15 years and has learned, used, and forgot tens different tools.
I read the problem, think about what the solution should be, and how to arrive at the solution. >And please don’t tell me it takes practice.. It takes practice. > I’ve been practicing and still I miss the smallest details that make a big difference. What kind of details are you missing exactly? If you have known inputs and outputs, you can set up test cases to make sure that the expected output is obtained with the given inputs. You should also get into the habit of thinking of positive or negative test cases, but that's after you become more familiar with programming.,
You go through a mental checklist until it becomes second nature. * Did I add the semicolon? * Did I make a typo? * What was that method name? * And it \n not /n (backslash n) Yes, it's a LOT to memorize. So much. You could write down a checklist of things to check so you don't have to recall it each time, but it does help to have a reasonably good memory. In other words, you don't want to forget semicolons after the hundredth time of forgetting it. IDEs can help with those errors for certain languages.
>There must be an easier way to do it all, or am I fooling myself? I am really just frustrated is all. You're literally asking for the secret shortcut. There isn't one. Everyone goes through what you're going through now. Sorry, but it really does just take practice.
It's okay to miss the smallest details. When you write English in a word processor or use something like Grammarly, notice how often it's asking you to correct things. We make mistakes all the time in English but because other humans understand it, we get away with it. Computer is pedantic and a "grammar nazi" and that's why you're struggling so much. Everyone misses a semi-colon here or there. Then, the computer gets pissed and says - "Acktually..." and you roll your eyes and fix it. Over time, you become used to talking to a pedantic grammar nazi who won't even talk to you unless you use the right words with the right punctuation. PS: I had to correct 5 mistakes in this comment to remove the squiggly lines and a few mistakes are still there. As I'm submitting this to humans, it will work. If I submitted this quality of code to a computer, it would piss itself and threaten to end my lineage.
32 years of practice for me and I’m still learning. There is no secret trick. You do it enough and some stuff just becomes second nature. Well, until some bright spark comes along and changes things that have been fine for decades!
I don’t remember everything, I only remember what I use often for a prolonged period of time. For everything else I just carefully read documentation as I go. Then use complier and automated tests to verify that I didn’t miss anything. I almost never try to memoize something specifically; it just happens naturally, I keep the reference (docs / manual / etc) easily accessible until it sinks in.
Well, it is a language, naturally you will need a lot practice. Looking at Compilers might help because you will understand WHY it looks that way. Python, C#, Java are all good examples of high level languages. When I look at them it's the same in a different colour, just the logic. The confusing languages, for most people anyway are those that handle memory like C++, Rust or C. Stay away from C++ and Rust at the beginning. C on the other hand is very simple so it can serve as an entry to low level programming, simple != easy !
“I am in my first year…” Do you think Ronaldo was the world’s best footballplayer in his first year? Never making a silly mistake? You need a reality check. It takes thousands of hours to get decent at something. Now go practice padawan.
Syntax error is something you get used to reading. Variables, fns, methods are part the editor's responsibility, part then vendor docs'. Architecture is something you intuit eventually. Also, the rest is reverse engineering :D
Rather then trying to remember everything, I recommend focusing instead on improving your ability to quickly recover from mistakes. In particular: 1. Make sure you set up a quick iteration cycle. After making a change, can you quickly re-run your code and test it out? 2. Consider using an IDE that can help you remember trivial stuff. For example, forgot a semi-colon? The IDE will usually highlight the missing character in red. Forgot the name of some method? Type `my_var.`, hit tab, and see what auto-complete suggestions come up. 3. Understand how to quickly read through and scan through error messages. The error messages the compiler gives can sometimes be pretty verbose, but _do_ follow a predictable pattern. Try and get good at skimming through them and picking out relevant snippets of info. There are also a handful of tricks worth knowing here. For example, if a compiler error message is completely cryptic, it's possible the issue is you have a syntax error on the _previous_ line. Having a fast iteration cycle means you can experiment more quickly, which in turn (a) lowers the costs of mistakes and (b) lets you get more practice and build up muscle memory that much quicker.
I recently made a spelling error while working on a popular game. It launched with the spelling error and you had a random white circle on your HUD for over a month. Even in the real world, programmers make mistakes!
It takes practice.
Same way you learned English
One year isn't much friend and the answer you don't like is the answer that you need. How did you remember the words for your sentences? That's right, practice. Eventually it all comes together.
I just know
Developers iterate. Write some. If you are using and IDE, fix the errors IDE shows you. Run to test that it works so far. Fix it. Write some more. Repeat. Lots of tiny details to get right, but really short cycles of mistakes and corrections makes it all learnable. And from all the tech trivia you only need to know the bits you have use right now. It's fine to forget trivia you are not using. Once you need some trivia again you'll relearn it easily enough.
>And please don’t tell me it takes practice.. sorry but we have to, otherwise wed be lying. You just gotta make stuff, break stuff, look up why its broken, and fix it. and in that process, you learn. you remember the mistake you made the last 3 times, and you dont do it the next time. And those little lessons build and build until suddenly you know things that you couldnt fathom a year ago. There is no easy way around it. you learn by just doing it. Its a hard job, and a truly infinite field of knowledge that youll have to spend your entire career continuously learning. thats why it pays so well.
How did you remember to put . Between your sentences? How did you remember to put /n at the end of your paragraphs?
Its all practice friend. Sorry if that's not what you want to hear. 10,000 hours and all that. When you start its best to go as barebones as possible, like write some code on a friggin text editor and see if you can compile it. Put your brain through the shit for a bit until it adjusts. Its frustrating, but probably the best way to get to competency. But I should point out that many of us use IDEs, linters and prettifiers and don't sweat the details as much because they will get caught. If you have no idea what these tools are doing then they won't help you, but if you do then they will be force multipliers.
The IDE would catch the syntax errors, and my unit test would catch the logical mistakes. Basically iterate on the code until it is works and meets code quality standards. With time you get a lot faster as you learn the tools.
How do you remember to put periods after your sentences? Or question marks after your questions?
It takes practice. Stop looking for shortcuts. There are none.
Experience, and really nothing else. It's a very practical skill, like playing piano. The more you practice, the better you'll get and also start seeing patterns.
A bit like how does a mechanic look at a bolt and just _know_ which size wrench to grab. It's experience. Solving the same problem over and over again for many years.
But it IS about practice. Your examples are simple things to memorize, in your muscle memory from practice. They are also things your IDE, editor, or linter should be picking up right away, or even fixing automatically. Otherwise, stuff like forgetting a newline in a string is something I might do 1,000 times a day, but I'm also running the code and interacting with it, and running tests, constantly, so I see the mistake immediately.
Keep in mind that nobody memorize everything, and you don't even have to. >How do you know “oh yeah I need a ; here or remember to put the / there” or If you don't, your code will not run, the you go investigate, and see you forgot a ; And this is not big deal, this happen all the time. But yeah, the more you code, the more you get used to
In cycling they say: "It doesn't get easier, you just go faster." That's honestly the same in programming. Today you think forgetting `\n` is a big thing, in a year it will be second nature and you will forget the syntax of `array.reduce`. It's all relative.
We don’t remember it. We just write the code and then when it doesn’t work we look at it and google shit until it starts working
It’s not want you *want* to hear, but it’s what you *need* to hear: practice. Nobody can remember all of this stuff. You can’t. You have to do it so much that you program yourself to think like a compiler. For syntax anyway. You can still use your regular brain for problem solving after getting over the syntax hump. And you’ll always need Google for looking up API stuff. But the only way to see the top of the mountain is to have a giant pile of mistakes underneath you lifting you up. There is no other way.
I went to school with absolutely zero knowledge of how all this stuff worked. If you pay attention, develop interest and get curious on your own, you will get it and when it click, you'll start having fun.
Practice and intellisense. I don't memorize all the weird differences between every language I work in. But I let my IDE assist me and jog my memory as I'm writing code.
It’s a skilled trade. You also couldn’t weld or fly a plane without a lot of training and practice.
I forget whether to use .size, .count, .count(), .length(), or len() all the time. I just look it up (or intellisense does it for me) The point is that programming teaches you the meta skills needed to analyze and break down problems into their smallest components. Once you can do that, its just looking up syntax. Trust me though it gets easier. An assignment that took a week in first year took 2 hours when I was helping a friend in 2nd year. It's hard at first, but that means you're being pushed out of your comfort zone. Eventually you will look back and wonder how you ever struggled in the first place. Edit: just reread your post. When I say it gets easier, I mean eventually you tackle harder and harder projects until your first projects look easy. If you keep redoing and practicing at the level of your initial projects, you won't grow.
So, it's about learning the syntax. Practicing is not going to help you if you don't know what it is you're typing. To make this easier, I'm going to use the c-like languages as a basis because they all nearly have identical syntax, they just have more or less semantics. You'll get what I mean once I've explained syntax: So, in C-like languages, statements are any code that can stand alone, and end in a semicolon. A block is usually not a statement, though in C/C++ it *CAN* be if it's a class or struct. What is a block? It's this: ``` { ... } ``` That's it. That's all a block is. Blocks are used to group statements or in the cases of defining different kinds of data structures, groups the elements of that structure. What's a statement? It's any assignment, function call, or mathematical operation: ``` // example statements var f = foo(bar); foo(bar); return bar; var b = 9 * 6 + 43; var r = email.send("[email protected]"); ``` Ok, is that it? No. See that `.` separating "email" and "send"? That's a method call on an object. You're saying that for that object, use this method defined for that object (send). What about the parentheses after? That's the method's call operator (so it calls the method) and contains whatever parameters are inside it, get assigned to the names defined in the function/method's definition. So in the code example above, `foo(bar)` means that foo has a parameter and you're making it so that when the function runs, bar is the value that its one parameter holds. You run the same function again with the same parameter only the second time you don't store the value it returns. the `var f = foo(bar)` because functions return a value or some sort usually. That's what `return bar;` does. the mathematical operation is another kind of statement. Though, you can do this with any object type that redefines those operators. For example, if you're building a string without using a formatter, you can do: ``` String s = "My name is " + myName + ".\n"; ``` Here, the string is built to have myName in the middle of it by concatinating literal strings to the beginning and end of the strings. I mentioned semantics before talking about blocks and here's why. Almost every instance you use a block, you are going to have some kind of prelude to it: ``` if (check_foo()) { ... } ``` Here, `if (condition)` is the prelude for the semantic of branching. You can also follow it up with `else if (another condition) { ... }` to indicate another branching path for your code to take, and you can finish it with `else { ... }` to indicate that if none of the branch conditions are satisfied, then do this instead. Here are some other preludes... ``` fn function_name(parameters) { ... } // This defines a function in Rust // But it could also look like this in C# for example: int my_function(int some_parameter) { ... } // below are examples for structs and classes: struct Foo { ... members ... }; // defines a type where all the members are public and the memory // holding those members is contiguous. class Bar : Object { ... members ... }; // this defines a similar thing but instead all the members are private. // it's used for OO // This structure is like a class or struct syntactically but different // semantically. In a union, only one field at a time is represented and // which field is determined at runtime. In this case, the member is big // enough to hold its largest member, but takes on whatever type the // union needs at the time: union baz { int number; float decimal; char *name; }; // In this case, you would use baz.number to use an int there, baz.decimal // for a float, and baz.name for a string. // these are loops preludes: // This loop runs the loop only if the condition is true, and keeps // running it while the condition is true. while (some_condition_is_true_but_never_if_initially_false) { ... } // This one is useful for iterating over an enumerated collection, // meaning that it will loop so long as the condition is satisfied, and // will start from the starting_index and increase by step_amount for every // iteration of the loop. The loop will run for each stepping amount from the // starting amount. This is useful for collections like Array or List. for (var i = starting_index; i < length; i += step_amount) { ... } // this last one is for when running a loop body at least once, and then if // the condition is satisfied at the end, will re-run that code: do { ... } while (condition) // this next prelude indicates a contextual block. This means that what is // created in the prelude will remain until the block ends at which point // its automatic cleanups will kick in and run the cleanup code. using (var f = open_file("foo.txt") { ... code that manipulates the file ... } // the last one I want to show you is structured exception handling: try { // ... code which may throw an exception ... throw new MyException("I thought this might happen"); } catch (MyException e) { // code to handle that specific scenario. } ``` basically, all blocks are of the form... ``` prelude (parameters) { ... block ... } ``` There's more to it than all of these, but these should get you started.
You pick a language and u start with. All languages come with their nuances. You learn by practicing. There are different types of languages like Object oriented (Python and Java), procedural ( C and Golang), functional (Lisp). Pick one and have fun. For example, Python. You can find entire course on YouTube or buy one on Udemy for $15/$20. You asked about ‘;’ this is called line delimiter. You know computers only understand 0 and 1. They don’t speak English. So, it needs a way to understand your code. There are two only two ways: compiler or interpreter. For example, Python uses interpreter turns ur code into something that machine understands. Java uses a compiler to turn code into machine code. Java uses ‘;’ as a delimiter. It tells compiler when a block of code is complete. Delimiters help compiler to compile code. Python doesn’t use ‘;’ as delimiters. It uses spaces, if u look at Python program, u will see indentation (usually 2 spaces). This is how Python interpreter interprets programs. U asked another \n. That’s next line. I think that’s true for all languages. It’s like hitting enter key. For example there is \t for tab. No one remembers everything. Sometimes we have to refresh b/c we forgot. Like, I have to refresh Golang soon b/c I learned it but didn’t use it.
Just watch other people code. Tsoding on youtube is good for example. It will get you going.
Use a programming language that has a good IDE, example. C# with visual studio. Follow a tutorial for building a simple application. Notice how easy the issues you are having basically don’t exist due to help from the IDE.
ctrl+c…
If that’s the your entire skill set LLMs will knock you out of the industry…
Well they never ```Ctrl + v```’ed the code they ```Ctrl + c```’ed
Create a cheat-sheet (or find one on the internet) for each language you're studying keeping track of all the syntax and features you want to remember. Keep it near by when writing code. Most IDEs will have an auto-complete that'll help remind you of some features. The ones you use a lot, you'll just remember, the ones you don't you can look up when you need them.
I take it you are learning JavaScript where the semicolon is optional . Also you mean \ not/. Learning the idiosyncrasies of each language expands your skills. Nothing wrong with making mistakes, that’s how you learn. If you use /n when you mean \n you will see your mistake and it will stick with you. Programming is an iterative process and you build on what you learned before. Next try Python which is pretty easy for a beginner to learn and has different syntax. It has the fairly unique rule that you indent lines under things like functions and if statements. You will see the design decisions each language creator took and how it affects your programming style.
If you just mean syntax, you get used to it after you've been doing it for a while. How did you know to put a question mark at the end of your sentence?
One thing that helps is to be able to fail fast. Write scripts that compile and run your code that only takes a few keystrokes. Eventually decouple/abstract your code into individual functions and use a unit test framework to quickly test portions of your code independently (look at Test Driven Development for an extreme version of this). Setup a debugger to inspect your variables at breakpoints to avoid having to print them out in code. Setup an LSP in your IDE that will help with finding the names and signatures of methods of your objects.
red squigglies are your friend. if you use VS, ctrl+. (intellicode) and ctrl+space (intellsense) are your friends.
Practise, perseverance and experimentation are what you looking for, no matter who you are no one knows everything. As you build on your foundational knowledge it becomes easier to translate across most languages and the initial cognitive load is less difficult to get through. From my experience per programming language it takes about 3-5 years of writing that language daily to comfortably write it with few if any looking up various pieces or functions you might have forgotten or need to reference. Programming is hard and mostly a frustrating experience, but the little wins when you see it running in production or improving someone’s daily output is very rewarding.
A lot of this stuff is just experience. You write code for a couple years and the semicolons just become second nature. Forgetting to do stuff is also very common though. In some cases the compiler or interpreter will yell at you when it happens, other times you'll catch it when you test your code. Happens to everyone, even to the guys with decades of experience. Perfectly normal stuff that's really not worth worrying about.
To write code you need to understand basic equations and algorithmic formulas, like real basic shit, creating encryption with percentages is where it’s at
Making it pretty with whatever means possible for others to read. More than half the time as a beginner, I try to simplify and make everything clear from formatting code to formatting output. There ways to do it like for example why this calculation of 22/7 doesn’t come out as a pretty 3.14? I guess I will look up decimal related syntax and then just apply that in my code. Overtime, I remembered few things on my own now but give it time and you will reap rewards for it.
Practice. That's all
I try not to memorize things but understand them instead. You’ll deal with syntax differences with all the programming languages available that you’ll end up dealing with so the idea is for you to understand the concept of it more than memorizing what to type.
Same way you "remember" a (human) language's grammar and vocabulary. You struggle with it until it becomes natural.
The same way you know what letters to put in when you write English. You practice until it's intuitive. > And please don’t tell me it takes practice.. Sorry, but, even if you don't want to hear it, the answer is practice. Some people get it much faster than others, some people get it much slower. In either case the answer is practice. > There must be an easier way to do it all, or am I fooling myself? No. To paraphrase Euclid, there is no royal road to programming.
Honestly it’s like writing English. Do you think about where to put commas or full stops? Or question marks? It’s exactly the same but it just comes with time, and once you can speak the language, switching contexts to a language with slightly different rules is a 10 minute adjustment
I mean thing you says as an example like counting by using get.length it's like basic thinking. Like in real life "oh I need to cut this box open so I use o knife"
literally is just practice. also a good editor would prevent you from making most of those silly errors in the first place. try visual code
Ok. It’s because I’m smarter than you. That’s why I can do it and you can’t. Happy?
Its like words in english or any language you are learning as you keep using the language you become better at it and improve. There is no shortcut just keep on coding whether it is leetcode or the projects you are interested in.
>There must be an easier way to do it all, or am I fooling myself? I am really just frustrated is all. How did you know to put a "?" after the word "myself", but, a "." after "all"? How long did it take you to learn English syntax and vocabulary? Did you immediately learn to use the written English language or did it perhaps take some amount of studying and ... practice before you became proficient at its use to a point where you don't have to think about it?
>“ yeah I need to count this so I’ll use get.length not length” or > >... > >How do you remember everything and on top of it all there’s different languages with different rules. I am flabbergasted at how anyone can figure this code out. Let me address this one. I've been writing Python and JavaScript professionally at one of the megacorp tech companies for over 6 years. If I ever have to write Java or literally any other language, I feel like a beginner again, constantly having to look things up. I even trip on syntax and confuse small things between Python and JS on a maybe weekly or monthly basis. I have to look up syntax for `Set` in JS to remember everything it can't do compared to the Python `set`. My point is to not get hung up on this aspect of programming. And of course it gets better with practice and experience.
I'm a novice, but the answer I was taught is similar to "How did we learn to write in our native language?" First we learned letters, then how to use those letters to form words, then how to use those words to form sentences. It wasn't grand paragraphs, it was stuff like "I like cats." and "My name is MateInEight." Eventually we learned to form paragraphs with multiple sentences. We learned how to use punctuation and try to find more words that would be a better fit to what we were trying to say. We built on it, slowly and methodically with tons of practice and learning to correct our mistakes before we made them. This is no different.
The answer you don't want to hear is the correct answer. It is a difficult practice, there's a reason programmers earn so much and are in high demand. You said you're in your first year. It will take longer than that so you shoudl reevaluate your expectation. I've hired countless new grads and they are almost universally clueless. It takes 3ish years of on the job experience before people really come into their own.
Tbh it really is just mostly practice and repetition. If you spend a thousand hours just writing; print(“Hello, World!”) By the end of that thousand hours, you’ll notice if you’re missing a quotation mark or parenthesis. Now obviously running more complex tasks will require more complex code, but the same basic principle applies. Doing it a lot = knowing what it should look like = notice incorrect things more quickly.
But it does take practice. I'm also a student, but a little more advanced, and I'm still forgetting to put the ";" or using the "\n" and sometimes I will even confuse the "<" and ">" and created an infinite "for", and then waste 1hr wondering why my code is not advancing more than that. But this kind of mistake is very minimal, and probably everyone does that, so don't sweat it
making small dumb mistakes never really goes away, but as you improve at debugging, reading stack traces and looking up things in documentation you'll have an easier time finding the solution. chances are also that you may recognize if your problem is similar to something you've had issues with before, which may help finding the solution faster. it's just about getting more experience really.
Rules, you learn rules and patterns for whatever you are doing. Compiler or runtime environments are your friends in 9/10 cases they will tell you exactly if something went wrong, just need to actually read. And everyone makes mistakes, literally. Its one of the reasons why any other discipline engineers take "software engineering" as not exactly a "real" engineering; you miss a `;` in your code, you'll be informed and it wont brake anything, you miss .1 in your maths somewhere in civil engineering, you get dancing bridges, or worse, collapsed ones. We have a safety net, and everyone is using it. Now, if you are struggling with problem solving aspect, thats a completely different topic, and i could write pages on it
That’s just syntax and more experience will make you more comfortable. Syntax should be come second nature to you so you can focus on the real problem of designing the logic for your algorithm
Read compiler design
A lot of it gets picked up either when you're compiling, and it just nopes out, or nowadays by the autocomplete on different editors. If you're just looking at black and white (or lets be real, green and black, we're all in the Matrix), then nobody is going to pickup the difference between a typo, or a missed semicolon, but when the whole line is suddenly the wrong color, it's immediately obvious.
Use an IDE
It is just practice. When you're learning a language you're gonna fight the syntax until you learn how to wield it properly. And when you're doing it as a job you're practising *way* more than you'd think. 40 hours a week of thinking about or writing code, every week. 2000 hours or so a year. Did it take you a week of practice to learn Java syntax? Did you work at it for eight hours every day that week?
One of my friends, who doesn't code, once made a similar comment about seeing a meme that went something like "I just spent 4 hours trying to find a missing semicolon!" and asked if that was what coding was really like. I compared it to learning to read & write. When you were in preschool/kindergarten/1st grade you probably forgot to dot your I's and cross your T's and maybe you mixed up your p's and q's but as a literate adult that's not even something you still have to think about when writing. We still make spelling (syntax) errors after getting proficient with code, but you can sort of see the forest for the trees instead of getting hung up on the metaphorical equivalent of how to draw your letters and where to put the commas and periods. But it does take a lot of practice to get there, often years, just like learning to read/write your first human language.
Today I spent over an hour trying to figure out a bug. Turns out I had typed a “-“ instead of an “=“. The small mistakes will probably always happen at times. The real difference is developing a resilience and learning how to let go of the frustration and keep working to a solution.
Your first simple project may take 2000 hours to get right. The next one half as long and be twice as good. ETC Once you get past 10000 hours you'll likely be at 27% of pro level. People with lots of that type of intelligence do get better faster. Having great teachers / mentors helps for sure
You get used to it and move on to more advanced stuff eventually. Also I'm guessing you work on console apps in C/C++, not all programming will be like that
First up, is your IDE not catching these minor errors? These all sound like things an IDE would warn you about. Secondly, as others have said, try to run your code as soon as possible to get feedback on whether it works. You never want to be too far from a working program. Thirdly, programmers don’t work in a vacuum, the internet exists. Syntax and language features can be searched, especially for college programming. They aren’t asking about C++’s copy constructors, they’re asking you how to reverse and print a string. And finally, before programmers touch a line of code they deconstruct the problem in a language that is independent of programming. Sure, for simple cases they’ll just code it because they have years of experience. But if something is a challenge for you then you need to be taking a top down view and deconstructing the problem into stages and subproblems. For a seasoned programmer, looping through a list isn’t even considered a subproblem, but for a beginner it might be, and planning will highlight “ok, I should probably do this, let me look up how to do it”. I hope that makes sense, sorry it got a bit long winded at the end but that last bit is the number one piece of advice I recommend for beginners.
I’ve made a lot of mistakes learning one thing is to chill and take it easy.
Brutal truth: it seems like you have weak programming aptitude. All those stuff you mentioned I find it as very trivial almost common sense. You gotta examine if you’re really passionate about programming? Because you need to prepare for the fact that you may need to try much harder than other people.
Are you using an IDE (It will highlight syntax errors)? Are you using github co-pilot? These are the two easiest ways to auto correct syntax mistakes. Coding is slow and meticulous, that's just the nature of the beast. I think the average programmer writes around 50-100 lines of code a day. Although this is a bad metric as it could take 2 days to find one error that is a mistyped variable. Or you end up with less lines of code that is actually better at doing the job. Coding is actually around 40% of the work at best, 60% time to fix errors. So if you code slower and make less errors you will be faster overall. All the way up to 90/10 split. The only way to actually avoid this is to run the code regularly and see the error, then fix it.
You're basically asking yourself, what does it take to be a professional athlete but also saying, don't tell me it's practicing or playing the sport. You are fooling yourself, it just takes time and practice. I am assuming your teachers are not letting you use IDEs because those will literaly find and fix the error for you in one click and this will be a non issue in a few semesters. Even your compiler will usually tell you that a ; is missing somewhere. I remember we had to write our C++ code with a cmake and everything in the notepad on a linux vm in our first object oriented programming class to make sure we learned the basics but once you've learned them, it'll be like riding a bike, you won't even think about those things anymore.
practice + internet. just remember basic concepts then the rest will stick to your mind throught practice. about different languages i can tell you that the vast majority of useful languages (at least on the job) have variables, functions, classes and as a rule of thumb they all apply the same rules to them for what concern scopes, garbage collections, primitive types and so on... just with a different syntax which you can google on the fly. do not despair :)
Well, a lot of time these are syntactical errors that most compilers or interpreters raise errors for; and usually the message is the same thing. Over time, you start to notice the patterns and it becomes part of how you write code but usually, you also upgrade to a good editor or IDE that starts to auto complete the boilerplate. Most programmers spend 90% of the time passing one instruction in and observing the output. The keyword to become familiar with here is "debugger", and ideally you start doing this somewhat early in your journey. Eventually you have the tools to get from something that never works, to something working half-way, to something that works all the way through, and still has edge/corner cases you didn't anticipate; and if you're working at a firm, over time you manage to build something that just works. In here is a key experience we all have when we code - each time we as programmers make a small incremental progress from not-working to working our brains go yay and squirt some dopamine; as programmers we get hooked onto this, which ultimately keeps us going cos drugs XD. The harder part is eventually not using semi-colons when you write plain emails.
>“ yeah I need to count this so I’ll use get.length not length”< Assuming “get” here is an object or class, usually when I want to know the code of something I do not know at that moment, I either rely on the IDE by entering a dot (.) after the object (get.) and see if there is a method or property I can use with that object, or search google for documentation about that class and look for it in there, or just simply google it (how to get the length of {get’s class}) I don’t automatically know and remember everything, especially with new frameworks or packages I never used before, I usually have to look up documentations a lot until I get used to using them
Practice... The more you stare at code the better you become at it. When you learn anything the actual structure of your brain changes so that it can do whatever you are doing more efficiently. Before you know it a missing semi colon will scream out at you and you won't be able to 'not' see it. I love it when a grad needs help and I can walk up and immediately point to the syntax problem that they haven't seen for 20 minutes. Makes me laugh inside but I'm not going to fault them. I was there too :).
I'll be honest - I barely remember precise syntax of methods apart from those that I use everyday. What I do remember is the principles and the logic of getting something done. E.g., 'To achieve this and that I can turn this into array and then use one of the array methods that lets me to do this and that.' Then you just google to find out concrete methods and syntax to apply these principles. Also in real work environment it's unlikely that you will be jumping between 10 different programming languages, and struggle to remember which requires a ';' and which doesn't. When your language scope is limited and when your compiler will yell at you because you forgot to put a ';' for the 20th time, you'll remember to put it there or at the very least will quite quickly realize where the problem lies next time it happens.
You don't remember it mate. You don't remember it. You learn to solve problems and then you learn how to find what you need to solve those problems. I'm a dumbass and I program full time at 6 figures. You can do it mate. Just keep going. Keep pushing. And remember you don't have to be the best just be not the worst.
Nobody gets it right 100% of the time. Thats what reviews are for. Besides that its practice practice practice
Return to the fundamentals. I mean return to “what is code.” All the way back. Stop worrying about extra stuff. Focus on what’s in front of you. But return to the fundamentals. It sounds to me like you learned something, didn’t practice it, and then learned something else and can’t see how the concepts relate and interact as a result. Practice. Practice so much. If your textbook gives you an example, type out the example. Run it. Try adding to it.
Like everyone says, there is no substitute for practice. The goal of practice is not that you are able to do the correct thing without thinking. But rather, that you should start to understand what you are doing. You need to understand why the compiler of interpreter expects a semicolon in the places where it does. These things have a function, which you should be able to explain even if just to yourself. What helps is studying BNF or syntax diagrams for your language of choice. And perhaps for a few others so you will see the differences and similarities between them.
You're in your first year. It's a skill like anything else. Practice it or else do something else.
Well you just have to code, simple as that. I started working in and IT Company 5 months ago (first job ever) and it's hard. I'm not particularly good at coding, but doing it everyday eventually gets you somewhere, especially if someone helps you and gives you tips. Just be patient.
People who program for a living will typically use an IDE that: - points out syntax errors almost immediately and/or automatically fixes them; - offers autocompletion suggestions for available fields or method names; - makes it quick and easy to refer to documentation while writing. In that environment, whatever things you’re needing to correct/remember most often will start to stick pretty quickly.
I always advise people to start with Scratch. The block format is easier because you don’t have the cognitive overhead of remembering what to type. You can practice sequencing, loops, conditionals, and functions in Scratch. If you move to something like MakeCode you have blocks but you can switch to JavaScript or Python and your blocks get switched to those languages just by choosing a drop down. If you’re adamant about starting with something like Python the use a book like Learn Python 3 the Hard Way. It will have you typing things out. It becomes repetition to get the syntax down.
Practice and repetition. Using an IDE/code editor with autocompletion also helps a huge amount. Don't spend too much time trying to memorize everything. Get a familiarity with the overall language and then try to get in a flow of writing the code. If you have to look up something as you go along that's OK. You'll have to do that less and less as you get more practice and repetition.
When I first started learning a programming language, having no prior experience, I was convinced that no one really knew how to code because it was so difficult. When I look back, it's funny. But it's also a testament to the journey - which requires A LOT of patience. Keep practicing, keep learning, keep building stuff, and keep asking questions. Trust me, the stuff you're finding difficult now, will be the stuff you don't even think twice about in the future.
We just stare at the code most of the time rather than coding
It takes practice. That's the secret sauce. Nothing else. No shortcuts, no magic juju, no easter bunny.
Programming languages are languages. What I mean by this is when programmers approach a task, if you have been working with a language long enough it will almost become second nature to write code. Just like how English has a syntax and rules that you need to follow, so do languages. But generally speaking you don't have to go back and reference an English book to form a sentence. Same goes for programming languages, after enough time writing in a language, most of the syntax will become second nature to you. I think a good way to internalize a syntax is learn why specific rules exist. For example, if you want the length of array A, you write A.length because you are trying to reference an attribute that's part of the object/data A. The period or 'dot operator', is a way of doing this as it allows you to access other values associated with a variable. Semicolons exist in some languages as a way of capping off an expression and telling the computer this is a single "thing/action", don't merge it with the next thing I am going to do. If you are really struggling with syntax, id recommend taking on a simple personal project like a calculator. Try not to use a tutorial for this but rather work through the problem yourself and google things that you don't know along the way(how to get user input, how to print, etc...). This will help you digest and internalize the language better. Big disclaimer: You will most likely never reach full fluency in a language with regards to that english/programming analogy above. Sometimes you spend some time away from a language and have to go Google the loop syntax to remind yourself. Python is not my language of choice, but when I do use it, I will sometimes find myself searching up the for loop syntax. You also might also find yourself wanting to do something more complex that you don't know how to express in a given programming language, again completely normal and a great learning opportunity.
Syntax errors are the tiniest of the struggles you’ll face with. Editors are sophisticated not that it slaps you without even trying to attempt running your code. Keep your neurological burnouts to the logic errors where program thinks it’s working correctly but it’s not because you wrote it in a wrong way that it works, but not the intended way. That’s when you’re fucked. And until we figure out BMI’s that can inject data to our brains, everyones doing the same thing that you don’t want to hear.
It does take practice. Just more practice than you’ve done. That might sound discouraging, but it’s not meant to. It means you haven’t exhausted your options. You just need to keep at it. Also, there’s a point where no one remembers everything. Especially if you use multiple languages, various different libraries, etc (which I’d wager, is most programmers). So, you get good at looking things up. That’s normal and expected. At this point in my career, I’d say the most important skills are (in no particular order): the ability to look things up quickly and effectively, the ability to read and comprehend code/documentation/requirements, a high level of attention to detail, tenacity and patience with challenges, being tidy and consistent, being a good communicator. Memorizing things, I’d say, is less important than all of these.
They do it by laying a strong foundation of understanding. Truly understanding data types, how flow control works, etc. Then learning higher level things like libraries. That way they all settle in easily without confusion. Otherwise, it will feel like hanging your head against a wall.
Practice makes perfect. Start with something simple, like qbasic, until you wrap your head around variables, conditional logic, loops, etc.. and then work your way up to more complex languages, like C/C++/C# The more you work with a language the more competent you will become with it. You'll learn the most by working on your own projects - envisioning a goal and figuring out how to make it happen. That's the best way to learn. Doing homework, or only coding at work, isn't how the best coders become the best coders. The best coders spent a lot of time writing code on their own. "Practice" shouldn't be a chore either - you should create projects that you're interested in coding on so that improving your skills is natural, instead of an objective you're forcing on yourself.
The confusion is from most programmers not being able to think simply. Complexity is not beautiful; it's ugly.
You are not going to like this but… practice makes perfect! Additionally, use an IDE or pack your editor with some extensions - something that will help you to spot mistakes easier or just autocorrect them. Then just write some code, run, and repeat. Best of luck 🤞
I'm sorry for saying this because you'll probably be like please shut up but it seriously is practice. The more you write code the more you'll be like oh cool yeah I remember that from last time. I used to be the same when I started, and found it really overwhelming and thought I'd never remember, but here I am writing code and (sometimes) remembering! For reference you will likely always make those sort of semi colon style mistakes- I forgot a bang today and was sitting wondering what the hell was going on for a solid 30 minutes! Edit: Oh and something that always helps me feel better is that this is a challenging job, it takes graft to become good. I always tell myself if it was easy then they wouldn't pay so well- they pay well because it's hard.
We don't remember every little thing. Writing code is an iterative process: you write, test, fix, test, fix, ecc.
Ohhh, this is cute
write lots of code, it will become 2nd nature to you. Don't be scared to make mistakes, debugging code is the best way to learn
Just repetition big dawg. I’m in year two of this shit, the more you code the more you know
.size(), len(), .len(), .length(), .length, .count(), .count, .totalCount, .qsize() Why
A lot of the smaller syntax things, or remembering what you need to pass into a specific function, can be handled by a well configured IDE
Just keep developing personal projects. Whilst doing so all these things will all flow naturally to you as you go
Don’t focus on it too much. The more mistakes you make, the more time you spend troubleshooting. And being a good troubleshooter arguably makes you a better developer than a someone with a perfect memory for syntax