DEV Community

Cover image for What Do You Wish You’d Known When You First Started Programming?
Ben Halpern for CodeNewbie

Posted on

What Do You Wish You’d Known When You First Started Programming?

If you’re just starting out in programming, you might be feeling overwhelmed by the sheer amount of information out there.

Here are some tips to help you organize your thoughts:

  1. Start small and build up gradually
  2. Document your progress.
  3. Don't compare yourself to others
  4. Practice, practice, practice
  5. Don't be afraid to ask for help! This is a great place to do just that!

Remember, learning to code is a journey, not a destination. It takes time, patience, and perseverance. Stay curious and keep learning!

For those of you who are a little more seasoned, what are some things you wish you’d known when you were starting out that would have made your journey a lot smoother?

Oldest comments (34)

Collapse
 
yet_anotherdev profile image
Lucas Barret

It is totally link with your second point.
Writing article, while your doing your project.
I have a lot of problems of motivation when it comes to do project just for the sake of it. I begin it and I have really a lake of motivation at some point, because I do not see the point of the project.
Doing project and then writing an article about it keeps me focus on it.
So even if you feel you do not have anything to say.
It doesn't matter like you said don't compare to others !
Thanks for your article I hope it will help people. :D

Collapse
 
nombrekeff profile image
Keff

This are some of the tips I can give after almost a decade working as a profesional developer:

  • Start from the basics, and add complexity little by little. Don't jump to complex topics before understanding the basics.
  • Don't reinvent the wheel if you don't need to or want to (if you want to for learning it's fine).
  • Don't obsess to much, take time away from the computer regularly and exercise.
  • Accept you wont know everything, not even a small percentage, but that's fine. Whenever you need to, you will learn it. One aproach is to know that you can do something, but there's no need to remember how to do it from memory, just look it up when you need it, after a few times you might remember it.
  • Have fun, if you're having fun it will be easier to learn. If you find a topic cool or interesting, go ahead and learn it.
Collapse
 
joaomiguel22c profile image
joaomiguel22c

wauuuu

Collapse
 
overflow profile image
overFlow

you mean "wawu wawu wawu wawwuuu" lol

Collapse
 
overflow profile image
overFlow

yeha like wawu wawu!!! lol

Collapse
 
__masashi__ profile image
Masashi

Here's my list:

  • Read documentation.
  • Write documentation.
  • Write tests for everything.
  • Create an MVP before adding all features.
Collapse
 
pmbanugo profile image
Peter Mbanugo

That talking to your customers is part of the job, and selling isn't an evil idea. I think many of us start out badly with selling, and struggle later on. Selling is what we do when we try to convince colleagues to try something new, or ask a manager for a raise. It's part of the things we do when negotiating a job offer.

Collapse
 
nicolus profile image
Nicolas Bailly

talking to your customers is part of the job

I kinda disagree. I've been a dev for 10 years and very rarely had to talk to the customer. The only times I do is because my code needs to interact with our customer's code through APIs or SSO or something, and I talk to their developer. There are people who are much better at dealing with customers and writing specs than I am, so I'll gladly leave them that job.

Collapse
 
pmbanugo profile image
Peter Mbanugo • Edited

Ok, then let's agree it depends on your job

Collapse
 
eerk profile image
eerk

Release early, release often 😎…

Build barebones prototypes as fast as you can.

Seeing others use your application will help you understand what direction you need to go in.

Collapse
 
jmfayard profile image
Jean-Michel 🕵🏻‍♂️ Fayard

Asking for help is a difficult dance to learn.

I wish I had known earlier the practice of timeboxing activities where uncertainty is high: "I'm gonna work on this for 30 minutes/2 hours. I may be able to solve it all by myself. But if I don't I won't stay in a rabbit hole because I'm too proud, I will go back to my team".

Collapse
 
boudewijndanser profile image
Boudewijn Danser

Right!?
There is no shame in asking for help if you've investigated properly and can share what you tried.

Collapse
 
ben profile image
Ben Halpern

I'll say this: Some hype is real, a lot is not. Don't buy into the hype or become to cynical of new things. Try and develop a measured opinion of new things as they come out.

As a newbie, you probably have a hard time gripping the whole perspective of some new things, but also you don't have baked in opinions that hinder some seasoned devs.

All that is to say, just keep an open mind and stay in it for the long haul, and new things that are here to stay will sort themselves out.

Collapse
 
charliekroon profile image
charliekroon
  • When you run into an error or a bug don't be afraid or intimidated by it. Also, don't go and remove random things without having any clue as to why that error or bug happened in the first place. Try to see every bug as a learning opportunity.
  • Make sure that you fully grasp the fundamentals before you're doing anything else.
  • Having many years of experience does not necessarily make someone an effective communicator or mentor. If you don't understand someone's explanation, don't go into panic mode because it doesn't mean you're stupid or that you will never be a good programmer. It simply means that you might need the concept to be explained in another way.
Collapse
 
mfurmaniuk profile image
Michael

Very true its a journey, you will NEVER know it all, but you will know enough.

Take small bites of things if you want to be a generalist, or if you want to specialize do it in something that excites you not what you think will make you money.

Collapse
 
madza profile image
Madza

Great question and lots of answers below can be used as valuable shortcuts for beginners 👍💯🚀
I created a list of my tips a couple of years ago, too 😉

Collapse
 
cclaudia13 profile image
Cclaudia13

OMG!
Great list, portfolio (which i'll look again and again) and website.
Thanks for the great tips.

Collapse
 
timothydjones profile image
Tim Jones
  • Don't be afraid to put comments in your code. But remember that comments are usually for explaining WHY (rather than WHAT). The code itself should be simple enough to show what its doing.
  • Do the simplest thing that works. Working code is more valuable than showing your "brilliance" with some esoteric approach.
  • Don't be afraid to make mistakes. But always own up to them and correct them quickly. We all make errors. Just be transparent, learn from them, and do what you can to prevent making the same ones again.
  • Share your knowledge and discoveries. If you find a new tool, library, or technique that makes your life easier, chances are that it will benefit your team members, as well.
  • Be gracious and grateful. It's a truism that everyone is fighting some battle that we know nothing about. Lighten everyone's load by showing kindness, compassion, and joy whenever you can.
Collapse
 
urielbitton profile image
Uriel Bitton

Comments aren't usually good in modern development. A lot of seasoned devs will tell you descriptive variables are usually better than comments.

E.g.
Instead of doing this:
//this function formats a date to a string readable format and displays the date with the time
Const dateFunction = () => {...}

Do this instead, and eliminate comments:
Const formatDateToReadableString = () => {...}

Avoiding comments keeps your code way cleaner and much easier to read.
This also distinguishes between an experienced and non experienced dev.

Collapse
 
artjc profile image
Juan Carlos Pulido S.

Uriel give @timothydjones comment a chance. It's actually not true that comments are a bad thing. I've been a programmer for over 20 years and what I've learned is that comments are very important in your code, even to yourself. The key in comments is to try never to write WHAT your code does, you write WHY that code was made for. Your code must be clear enough to understand what it does. And now yes, to be clear, properly rename the variables, the functions, the same as the parameters. Avoid short names, unless short names are enough.

Collapse
 
ingosteinke profile image
Ingo Steinke • Edited

I agree that we should name or functions and variables in a descriptive way and write code that's as self-explanatory as possible.

But there are still several kind of useful code comments:

  • code comments that improve tooling (like JSDoc / PHPDoc type definitions helping your IDE annotate, suggest, and warn)
  • code comments that explain something not obvious, like an unusual requirement / feature request, or a reason for an ugly workaround that might seem unnecessary or erroneous out of context
  • TODO comments, e.g. remove this workaround when bug 123 got fixed, see example.com/issues/123
Collapse
 
jeremyf profile image
Jeremy Friesen

As a veteran developer, the thing I always want is context; sharing the why of the code in both comments and commits.

Collapse
 
boudewijndanser profile image
Boudewijn Danser

Exactly! Commits with proper descriptions (and the ticket number ideally) can take you through the code of the feature in steps.

Collapse
 
symon profile image
Symon Michael

I guess I wish I had been more aggressive with writing my own test cases right from the start. All of my "coding" is customized, purpose-driven, and disposable in the end. So in that situation to be effective, it means you ended up have write your own tests and think of everything you need to check. You have to understand things like cascading event chains, etc.

But in the end, I suppose we all get to where we end up through a series of both brilliant wins and silly mistakes.

Collapse
 
kitoster profile image
Kit Oster

Build your own experiments. Don't be afraid to break stuff (safely and with backups)!

Collapse
 
moopet profile image
Ben Sinclair

That I could be a programmer for a living.

Honestly, I avoided it for over a decade because I didn't think I'd be good enough. Instead I started out with the first role I landed, which was "PC Support" and went on to become a sysadmin. I never risked trying to change tack because I thought I wouldn't be able to hold my own against professional software developers.

What nonsense!

Collapse
 
mgbejxi profile image
Mgbeji Uche

I am just a newbie and I find this really helpful. I must confess that I feel overwhelmed at the sheer volume of materials I need to learn in order to acquire the skills I need as a developer. The task ahead is such that sometimes I have nightmares knowing that there is no escape for me anytime soon.
But then again I discovered that there are wonderful people here willing to lend a helping hand to a brother.
To cut a long story short: the learning is tough and intimidating but the people I find in the Tech community are some of the most wonderful, helpful and smartest people you will find anywhere in the world, and together they have made the task less intimidating and more fun to participate in.
It is my goal to meet some really nice friends here, whom I can learn from and share other life experiences as the journey proceeds.

Collapse
 
emmysteven profile image
Emmy Steven

You are welcome, take the your time to consume the content you find here so you don't get overwhelmed.
As you learn, try to take a break and implement what you've learned so you don't end up in tutorial hell.

Collapse
 
cclaudia13 profile image
Cclaudia13

I'm a newbie too and share the same feelings described by Mgbejxi.
What do you mean by tutorial hell?
I was watching one just now about flex box. (:

Thread Thread
 
emmysteven profile image
Emmy Steven

Tutorial hell is when you move from one tutorial to another tutorial without ever building any anything to demonstrate what you've learned.