DEV Community

Cover image for 08 Mistakes to avoid As a Programmer
Akash Upadhyay
Akash Upadhyay

Posted on

08 Mistakes to avoid As a Programmer

Hello to all my community people :-) This is my 6th post and I'm thankful to everyone because I love this community. And special thanks to all my 550+ followers. I'll try to provide valuable post every week...β€οΈπŸ˜ƒ


1. Trying too many things at once

As a programmer, often you're planning to solve many tasks at once while doing programming.

It's good that you have a todo list that what next you want to do in code but doing altogether can backfire you.

Take one step at a time and try to get it done and then move on.


2. Don't have proper planning

I'm still using the "pen and paper" technique to think about what I've to do in this function or block. Throw your ideas on paper.

To make your planning more effective, you can use the tool like "NOTION" to plan everything.

Always track your progress against the goals you've set in your plan like sleep/study time /exercise, etc. Make adjustments as you go. Avoid "Too much planning also"


3. Not using community support

Don't hesitate for taking help from anyone whether it's online and offline.

Try to remove one thing from your mind that "someone is judging you" because everyone has been in your shoes before.

Always remember "Stack overflow and google are your best friend".


4. Not documenting your code

We have to document everything in a job so that everyone can remain on the same page and also you can't forget when you see it even after a month.

So, why not we can try to build this habit from college days or even school. Always think that you're writing this code for your company.

Try to avoid "I". Try to accept "We".


5. Doubting yourself or comparing yourself: can I do it?

We have to understand that programming is not an easy thing.

It needs your time and practice. So don't compare yourself with someone who's doing great in this field. But you can take inspiration from that person so that you learn a few things from them.

Remember always "Failure is the first step to success"


6. Fix later attitude and I know all attitude

Whenever you encounter any bug in your code/project and you've tired a lot and you want to take a break to fix it.

Just maintain a todo list like "NOT TO FORGET ERROR CORRECTION" otherwise you'll forget about it.

Bonus Tip: Try to maintain one error doc so that you can refer it whenever you encountered that error again.


7. Not taking backup of your work

Never forget this step. Suppose, you're making something and your system gets fail then what's next??

So always make your work safe by taking backups with the help things like Dropbox and my favorite "GitHub"


8. Not taking regular breaks

I follow "The Pomodoro Technique" i.e an effective time management technique that helps you to remain productive while taking regular breaks. "Try to read it".

It helped me a lot and still helping me and avoid this attitude like "You've to do everything in one shot"

Understand β€œBreak is very important”


If you love this post, please give a like to boost my confidence to write more posts for this community. I'm also sharing a short microblog on my Instagram page also.

If you have doubts regarding development or UI/UX Design. Please feel free to connect with me on: β€οΈπŸ˜ƒ

Linkedin

Instagram Page

Instagram page

Regards
Akash

Oldest comments (24)

Collapse
 
uzair004 profile image
Muhammad Uzair

I am learning Web Development, it's been a while i can't see any improvements in my designing skills , layouts, etc (frontend, css stuff)
I am planning to join 100DaysOfCode and will dedicate few hours daily to learn Back-end stuff (node, express, mongoDB) as my goal is to become developer at end of this year.

Also started UI/UX learning a month ago, putting hour or two at night for that to proceed towards graphics stuff.

Even though i will be learning TWO things at a time INSTEAD of one, But i think they are interconnected and would benefit me.

Collapse
 
designerakash profile image
Akash Upadhyay

hey, thank you for sharing your experience. I can share my experience, what I did... Front End Development first then when I thought I'm confident enough in this field then I did UI/UX but still doing Front End Dev with that...then mobile and backend with illustration and etc.

Its good that you're doing 2 things together but start with one and then after 1 month when you're confident in that ..then add other ingredients on ur bucket...

I hope it is helpful for you :-) ....for more information you can connect with me on my page ...

Collapse
 
jwp profile image
John Peters • Edited

I like item 6. What we need to learn are programming styles which prevent maintenance and bug issues later. Especially being that 60% or more of the cost of software is maintaining the code, not developing it.

Collapse
 
designerakash profile image
Akash Upadhyay

Yes, indeed.. Thank you for sharing ur point of view πŸ˜€πŸ’š

Collapse
 
ponyjackal profile image
ponyjackal

Thanks for your nice posting, Akash

Collapse
 
designerakash profile image
Akash Upadhyay

Always feel great to share my experience with this lovely community πŸ’šπŸ˜€... U can connect with my page if you like...

Collapse
 
anzhari profile image
Anzhari Purnomo

The pomodoro technique really helps. I usually alternate between a 90 or 120 minutes cycles before break.

Collapse
 
designerakash profile image
Akash Upadhyay

Yes, indeed it's a great technique... πŸ’šπŸ˜€

Collapse
 
andrewbaisden profile image
Andrew Baisden

I'm a fan of pomodoro too it helped me speed learning many programming concepts.

Collapse
 
designerakash profile image
Akash Upadhyay

YES, Indeed... it's a great technique to remain more productive...happy to connect :-)

Collapse
 
codinglanguages profile image
Your DevOps Guy

Bonus Tip: Try to maintain one error doc so that you can refer it whenever you encountered that error again.

I like this tip a lot! I mentioned in one of my articles about coding interviews, but you can apply it to other contexts.

I just found one I wrote while I worked at Amazon. IΒ΄ll share it soon.

Thanks for sharing!

Collapse
 
darkwiiplayer profile image
π’ŽWii πŸ³οΈβ€βš§οΈ • Edited

Either that or use git. If you fix a bug, be sure to add a good description of the bug in the commit message; then, in the future, you can just use git log --grep "<error message>" to look through the commit history and find all the relevant information, including how it was fixed back then, who did the fixing (and might therefore know more about it), when that was, etc.

Collapse
 
designerakash profile image
Akash Upadhyay

Yes, your right.. Both r the good option to have but to have is the first step and the important step to maintain the documentation for errorsπŸ’šπŸ˜€.. Thank you for sharing your experience...

Collapse
 
designerakash profile image
Akash Upadhyay • Edited

I'm glad that you find it useful πŸ˜€πŸ’š.. Sure I can wait for ur version

Collapse
 
nagkumar profile image
Raja Nagendra Kumar • Edited

Better not a self-document, but file it as ask for the inputs @ stack trace and suggest the solution too. It is easy to refer anytime, anywhere, build a reputation and you have global developers' attention too.

I also love error be properly put as JIRA issue(s), it helps as a stronger reference as long as you are in that company.

Collapse
 
designerakash profile image
Akash Upadhyay

Thank you for sharing your opinionsπŸ’šπŸ˜€.. And I think it's great if we can start documenting what we are doing daily.. it's a good habit.. It's very useful for us and we also find it easy we start doing documentain in the company πŸ˜€πŸ’š

Thread Thread
 
nagkumar profile image
Raja Nagendra Kumar

When you say documentation, is it word doc, Evernote, etc or are u referring to any good developer tooling like JIRA etc.?

Collapse
 
agiesey profile image
AGiesey

These are great! I especially believe that the pomodoro technique is a huge help. I find it increases the time that I feel productive by at least 3 hours a day. I use a kanbanflow (kanbanflow.com) which has a built in pomodoro timer to make little tasks for myself outside of work's shared Agile tool. I also think that writing comments in plain english to map out a function before writing it's code helps me.

Collapse
 
designerakash profile image
Akash Upadhyay

Hey, thank you for sharing ur opinions πŸ’šπŸ˜€.. That's y i love this beautiful community of supportive people πŸ’š ... Yes this technique i got to last year.. And it helped me a lot πŸ˜€...

Collapse
 
importhuman profile image
Ujjwal Goyal

Can you please elaborate on points 4 and 7? How exactly do you recommend to document code? Is it commenting in the code about what a particular block of code does, or something else?
And as for using GitHub as a backup, if you merge a branch which later turns out to be not so good, do you switch to the older commit of the master branch, or by some other way?

Collapse
 
eecolor profile image
EECOLOR

One of the most common mistakes I encounter is that developers think they are done when it works.

A phrase from Uncle Bob really helps: your code should read like well written prose.

Collapse
 
designerakash profile image
Akash Upadhyay

yes, you're absolutely right buddy :-)...appreciate ur opinion... #CommunityLove

Collapse
 
placideirandora profile image
Placide IRANDORA

Thank you for the tips. This is so helpful.

Collapse
 
designerakash profile image
Akash Upadhyay

Always happy to share my knowledge with my community people.. Happy to connect and I'm glad that you like itπŸ˜€πŸ’š sharing microblogs too on insta