Cover image for Give one Short Piece of Advice or Wisdom to Beginning Programmers

Give one Short Piece of Advice or Wisdom to Beginning Programmers

lifelongthinker profile image Sebastian ・1 min read

Make it short and simple... Let's see what we can come up with.


Editor guide

You write code for other humans.


Would give this 100xβ™₯️ if I could.


Fail and fail better.


And fail fast πŸ‘


Haha dam I was thinking of keeping it to 4 words to make it concise and easy to understand.


Don't try to champion any of these too much:

  • OOP
  • functional programming

These are just means to an end. Each and any combination of them fits different situations and purposes. Don't fall for a "camp" of thought.

Be your own man.


Break it down, break it down, break it down.

Wanna solve a bug? create a new feature? break it down in smaller tasks to see where you are going, how to plan your work and how to organize yourself.


COMMENT your codes.
You could understand what logic you used to achieve some functionalities, but in the future might confuse you.
Some say commenting makes the code base dirty........
well, that is better than taking headache pills when you can't remember how you got to that Logic in the first place


I'd say comments should be used where your code is not or cannot be intention-revealing (readable) enough.

In those cases, comments should explain the why and what (intention), not paraphrase the how. I think the latter is where people regard the act of commenting as making the codebase dirty.

In general, code should always try to tell a story, that is be readable, properly named and structured (cohesion, loose coupling, SOLID, etc.).


So true. Thanks Chief.
Like my style of declaring 'this' in vue
const _ = this.

A friend collaborated on my repo to work on the code, thought I was using _lodash 🀣.
Now I didn't comment, so it took him 2 days to realize that _.someMethodFunction() meant this.someMethodFunction(). Actually, he had to ask me. πŸ€—


Understanding the business around an application is as important as understanding the code.


Keep It Stupid Simple! :D


Nice variation πŸ˜…


It helps me everyday! :)


If you're learning with videos...
Do well to check the version used in the video, and the language's current version.
Some functionalities in the video might have been dropped in the new updates you are using..
in other words, try to check out the language's documentation


Not just video, any resource. Even tutorials on the language / library site can be out of date.


You will never be able to learn everything, no matter how many years you put into this industry. Instead, find something you want to build, and start building, learning what you need as you go.


This! It should be fun. Let your passion drive you. Try to build something, that you yourself want to build and use.


Sadly true. There's always so much more to learn and discover that one can't master it all.
Focus is key, that's a good advice. Thanks, Jason. πŸ‘


Hey, I don't find it sad at all! I love learning, so the knowledge that I'll never run out of things to learn is really exciting to me. :)

Absolutely. This keeps things exciting. But I imagine myself on my death bed wondering: What have I missed? What haven't I explored or learned that could have given me a deeper insight into this world?

So, yes, a sad and yet beautiful fact. Good point!


If you don't understand what you are doing, what difference does it make, in which programming language, you don't understand what you are doing?

(This is much bigger. But let's think about this one for a moment and hopefully come up with more questions.)

1 - So, first, try to understand the problem - the business.
2 - For that, communicate - try to understand people, which in turn helps with understanding the problem.
3 - To make your code, a two-way communication channel - between people and The Matrix - learn the fundamentals of Clean Code. Communicate meanings and intents in your code. The more your code is close to people, the more it must be technology-agnostic and more business-specific. The more your code goes outward, toward The Matrix, the more technology-specific it will get. Learn Onion Architecture (Hexagonal Architecture, Ports and Adapters, Clean Architecture, just start with one) by heart.


It seems the Dev app has torn your comment out of context. What comment are you referring to?


Strange. This was just a comment - not a reply. Should I delete and re-post?

Sorry, my bad. I was under the impression you were replying to another comment. Got it know πŸ‘


Having enough sleep, being well hydrated, having good eating habits, doing physical exercises, and working in a stress-free environment will make you more efficient/effective than the best framework, programming language, and whatever other tool/knowledge/whatnot.


Without a healthy lifestyle as a base, any other effort is futile. I agreed. Well said πŸ‘


Don't worry too much about optimization. First make sure you understand what you should do. Then write tests that capture that functionality. Then pass those tests. Then clean up your code to make it readable (the best code comes from planning, and planning comes from understanding, and you might not understand it until you've solved it a first time).
Only once performance is an issue or a requirement, should you worry about that.


Totally agree. Premature optimization is the root of all evil (D. Knuth).


Read the documentation carefully


RTFM 🀣🀣 Spot on!


Work hard on understanding the basics and create a good foundation for the concepts.

  • Data Types
  • Variables
  • Loops (for, while, foreach)
  • Functions
  • Arrays

Once you have a solid foundation of the above focus on Object-Oriented Programming.

Another one is to choose any language that you want and stick to it, to get the foundations in.


Spending more time on a problem will not help you solve it.
If you see yourself stuck on a problem then it might be a good time to re-read the documentation on that library etc, that's when I you'll usually have the 'aha' moment.


Even experienced programmers struggle, make mistakes, have to Google something simple, and ask for help. So don't feel like you're not good enough when this happens to you as a beginner. Its just the nature of programming :)


So true πŸ‘ Everyone has a comfort zone, and hence everyone has a discomfort zone. Don't be a fool, ask for help when you need it. Great advice, Nic.


Remember your own opinions.


Code what you love, love what you code ! Else{ change paths}


Create a great foundation and don't rush! Rushing through the basics will only lead to you having to go back and relearn those basics... I speak from experience.


Yep, that's a good one. Haste makes waste πŸ˜‰


Don't be afraid to ask questions.


Build systems, not habits.


As a beginner, you have to be focused and determined


I'd add that this is true for seasoned developers, too. πŸ€“ But your point is taken: You need a good frustration tolerance especially at the beginning. πŸ‘Œ


Don't follow others' wisdom. Live your own life.


The opposite is also true. Follow other's wisdom, interpret and improvise on it.


I see you're quite the independent type, Julia 😁 I agree, sometimes it's better making mistakes and learning from those than not making them in the first place.


Oh, I am! : ) Thanks for raising the thread, Sebastian


Write code in short cycles and improve it from cycle to cycle.
Don't try to embrace the whole world at the same time.
Just do it piece by piece.


Iterative development πŸ‘. Great advice.


ask questions
Ask Questions

He who asks questions, won't get lost


If you don't have errors, you are not learning. 😊


Learn to ask and search.


Be kind and patient, don't be condescending or be angry and praise as much as you can. We are all developers trying to do our best.


Don't stay all night coding! Remember to rest and keep an eye on your health :)


Show a preview/draft of your work asap


Fail fast. Part of agility. πŸ‘


You don't have to know everything, just where it's written down.


I wrote a post about my experiences as a junior/self taught. May be useful for some. :)


Make the code clear:

  • comment it
  • use meaningful names for variables, methods, classes, etc.
  • line breaks improve readability

It's not air traffic control.


But what if it is?

The Grinder: "but what if it did?"


If it's critical infrastructure (lives depend on it), there's only one proper way to handle it: Give it more time.

Yes, I worked on a contract a Mayo Clinic. A totally different perspective there.


Would you elaborate on this?


We were on a tough contract. Too little, too late and highly stressful, until our lead manager reminded us that nobody is going to die using that metaphor.

Very good. Now it makes sense. That's a healthy attitude.

What if somebody is going to die? Anyone with experiences on this?


I'll start...
Redundancy kills.


Watch out from fake advice and try to build your own resources and study space.
Go to university while you can it really help .
if you are a university student try to focus on learning job requirements , don't finish your university and you don't learn anything on your own space. University will give you theory not practice you need.


BASICS are important!


Yes! And often overlooked behind layers of indirection. Very good point πŸ‘Œ


Always work on your own side projects while still in school: in my experience classes teach you theory but rarely teach you how to apply things properly in practice, and there's no way I'd be where I am now without my own passion side projects.


Don't hesitate to reach out. Everyone struggles.


Go home at 5, 5:30, whenever it is the place is supposed to shut.


I can rephrase this as, stay as human as possible:)


Ask for help when needed. This will make people happy.

Read everything you can.

Try stuff, and fail at it. Talk about your fails.

Stay critic about everything.

So much more advices to give !


Your skills to understand and commumicate the domain of the application you're working in are vastly more important than pure technical skills.


Indeed, you have to know both the problem AND solution domain to do proper work. The problem here is that those two are usually stuck in a reciprocal feedback loop, so exploring one has ramifications on the other.
And you will undoubtedly have to start solving things long before you have properly understood the problem domain.

This is one of the dilemmas that agile is trying to solve.


Write tests. Not too many. Mostly integration. - Guillermo Raunch


Take yourself not too serious.


AGE is not a Barrier....

Just be consistent and Persistent


Try and grab a nap...
The error might be STRESS!!!


It's okay to be confused, it doesn't come overnight, and keep on going!


Don't be afraid of mistakes; try everything.


step to become a good programmer :

  1. fail
  2. success
  3. go to step 1

dream big