+ 100
sir I am a beginner in programming but when I start to do coding I've done pen paper work to make logic which take lot of time to solve a problem but then I changed my approach and first write an efficient algorithm and logic to solve a particular problem which is less time complex and execute quickly this help me to learn how to make new logic and then I goes on system to implement it which help me how the logic is work exactly 😊and now I will surely implement your way of coding too of writing comment in program which help other to understand the code well and for debugging of code too😊😊 it's really a nice suggestion and tip to do programming for a beginner like me to do good in coding 😊😊
19th Nov 2017, 4:56 PM
GAWEN STEASY
GAWEN STEASY - avatar
+ 108
Don't drink and code EVER :-P In my first semester at university, we had lots of parties. After drinking i often thought i had the correct idea to improve my code an ruined it the same night.. hahahaha
20th Nov 2017, 7:32 AM
Robert Paulson
Robert Paulson - avatar
+ 93
jumping from programming language to another without actually learning one throughly. i would say stick to one program, try all that you can and read all that you can too.then try new ones.
20th Nov 2017, 4:42 AM
Jacob Mathew
Jacob Mathew - avatar
+ 53
I was trying to learn fast. That is why I had a lot of problems with basic concepts. You need to learn EFFICENT, and take it time. Without good, SOLID basics, there will be a lot of mistakes later. Be patient :)
20th Nov 2017, 9:25 AM
Jakub Miziński
Jakub Miziński - avatar
+ 48
I remember the early days when I was kinda obsessed by the silly thought that less lines means smaller executable, so I just went to shove the code trying to fit it in within as minimum lines as possible. But the worst part of it all was, I "actually" believed that comments count as well, so ... bang! off all the comments to h*ll, and when I look at the code again I go like "omG what is that? did I put it there?" Other bad habit I used to develop was to use intensely bright, eye poking colors, like bright orange background with pink text color or the likes. Back then, I found it amusing and fun, but I have learned now, that fancy colors need considerations, and text readability aspect needed attention. That's how silly I was, hopefully I will always remember, learn from, and evade myself from the same mistakes :)
19th Nov 2017, 6:30 PM
Ipang
+ 41
//Edited.... When I was a beginner.... boolean isEven(int num) { if(num%2==0) { return true; } else { return false; } } few days ago.. boolean isEven(int num) { if(num%2==0) return true; return false; } now... boolean isEven(int num) { return num%2==0; }
20th Nov 2017, 4:57 PM
Md. Nafis Ul Haque Shifat
Md. Nafis Ul Haque Shifat - avatar
+ 38
I just took notes from all of your comments 📝thx SoloLearn community
20th Nov 2017, 5:50 PM
Jesse Smith
Jesse Smith - avatar
+ 36
using pen and paper before starting to code , coz when I started I would go like trial and error strategy, which is ok for small codes , but u gotta have a design and flow model , ur logic figured out on your notebook , it helps visualize easily. or else i would quit banging my head. I don't write too much comments so having a paper analysis saves me from writing too much comment , which ll be tough to figure out later anyways I am a slow learner too, it gets really tough for me to pick algorithm logics , and coding challenges makes me depressed sometimes, but writing , understand , code , repeat , I reinforce those concepts overtime, and eventually I ll be good enough
20th Nov 2017, 1:18 PM
Morpheus
Morpheus - avatar
+ 34
I think the most common mistake I used to make (and still do it sometimes 🙃) - Is not spending enough time on creating unit test cases for covering all the possible scenarios Because of this I have to sometimes rework a lot and spend more time later when I could have saved it by working on the test cases before jumping to coding I try now to take it slow and be more patient (but can’t help it often 😔**forever restless**) How do you guys do it device test cases before the logic/algorithm creation or after writing the code
20th Nov 2017, 3:18 AM
surabhi
surabhi  - avatar
+ 29
In Java I used "I" (i) instead of "l" (L) in System.out.println(); So none of my codes worked and I was really frustrated, but fortunately some guys here in sololearn were able to help! https://www.sololearn.com/discuss/739032/?ref=app
20th Nov 2017, 4:34 PM
Novas
Novas - avatar
+ 26
1. I got my compiler crashed just because of missing 2 semicolons. I barely make that mistake now. 2. That comments issue, as @Ace Sir said 3. I used to think too much ahead while writing a code, i.e. I thought I could also do this & that with this code. Then everything became complicated & I ended up getting nothing. So I only focus on 1 target from a program now. 4. This mistake is more related to learning. I have C in my academic curriculum. So when I started learning C++, I thought it's easy & didn't practise coding much. Later, I struggled with the advanced lessons & had to start over the course, as well as practising codes. Now, I try to make sure I give myself enough opportunity to practise while learning any new topic/language.
19th Nov 2017, 6:34 PM
DAB
DAB - avatar
+ 26
Working for nothing and not asking questions when I was unsure. Working for free lead to being taken advantage of and my work not being valued. Not asking questions lead to a bigger mess than if I would have asked in the first place. ALWAYS ask questions if you are unsure.
20th Nov 2017, 8:29 AM
Murray Chapman
Murray Chapman - avatar
+ 26
my mistake. if only i found this app sooner.
20th Nov 2017, 3:50 PM
Andika Romansyah
+ 18
Yours is a very common mistake: jump into coding at the first idea you got, we all went there. The best rule of thumb for me: don't start coding until you found out at least 2 or 3 different ways to do it, then pick the best for the present case. And that works at a macro as well as micro level: find different architectures or approaches that could solve your problem, different places to make your modifications, or even different ways to write a single line of code. Sometimes, just reversing a condition makes your code bullet-proof and you won't have to change it in the future when you add new features, whereas it would have crashed the other way around... Oh, and misplaced curly braces too, of course (actually not, I still haven't learned from this one and still do it on a regular basis :p)
19th Nov 2017, 10:38 PM
Xavier Demaret
Xavier Demaret - avatar
+ 16
for people who write more comments than code 😂(me too on early days), start using git and learn to use *commit messages * diff command *tagging to save others from reading your bed time stories in the code😅
22nd Nov 2017, 1:59 AM
Morpheus
Morpheus - avatar
+ 16
The best advice, I can give you is: the best way to learn and improve on programming, is making your own projects. Even more than spending all your time reading posts about coding or things like that, just as I unfortunately did. good luck
22nd Nov 2017, 3:00 AM
León Silva
León Silva - avatar
+ 16
for me *copy and past even I didn't understand the code, but code works and I jump forward. *I have wrote many projects, but i did not save my works. *trying all the time to reinvent the wheel, and not reading others code. ... ------------------------------------------------ Solution : => trying to understand deeply the concepts even you lose plenty of time. => saving projects // github - sololearn (also a good place to save small project). => I'm still working to read more codes and how developers implements their logic.
22nd Nov 2017, 3:34 PM
Said BAHAOUARY
Said BAHAOUARY - avatar
+ 15
I started experimenting with operating system APIs without cleaning up on exit (e.g., failing to close file and resource handles). The horror went roughly like this: Compile + run program. Program instantly quits to IDE. Run again. The IDE quits to the operating system. I really should have realized this was bad. Reopen IDE, run again. Operating system freezes. On hard reset, I had lost the contents of an entire disk volume, primarily long-term data. I never did figure out exactly what happened (nor did I get the volume back; I'd hooked some drive routine, probably never closing buffers), but I learned to be a bit more careful with cleanup and developer environment separation (making backup choices and omissions more informed).
20th Nov 2017, 3:50 PM
Kirk Schafer
Kirk Schafer - avatar
+ 15
It's okay to walk away from a problem for a little while. Unfortunately the answers to all of my hardest issues at work come to me on the drive home. Sometimes you just need to walk away. Make your code as humanly readable as possible. Make the names of your variables and methods meaningful, these are more helpful than comments. Don't leave dead code. If you're in school: use freaking source control. (I say school because I assume your work would have a mandatory source control)
26th Nov 2017, 3:35 AM
Emilee Sparks
Emilee Sparks - avatar
+ 13
Jumped into Java and PHP it was not so funny for me because they programming here in my company Banking Softwares. I forgot always Documentation or Comments inside the Code and for this kind of Software you need it. This is my apprenticeship so it's normal that i don't know so much as the other colleagues. But now after about 2 Years i can do at least anything... hahaha
20th Nov 2017, 8:23 AM
Thomas Meejumlong
Thomas Meejumlong - avatar