Posted on
Make it short and simple... Let's see what we can come up with.
For further actions, you may consider blocking this person and/or reporting abuse
Join the DEV x Linode Hackathon 2022 and use your ingenuity and creativity to build using Linode.
β Join the Hackathon <-
Adesoji1 -
CristovΓ£o Farias -
Harsh patel -
Jacob Kim -
Once suspended, lifelongthinker will not be able to comment or publish posts until their suspension is removed.
Once unsuspended, lifelongthinker will be able to comment and publish posts again.
Once unpublished, all posts by lifelongthinker will become hidden and only accessible to themselves.
If lifelongthinker is not suspended, they can still re-publish their posts from their dashboard.
Once unpublished, this post will become invisible to the public and only accessible to Sebastian.
They can still re-publish the post if they are not suspended.
Thanks for keeping DEV Community π©βπ»π¨βπ» safe. Here is what you can do to flag lifelongthinker:
Unflagging lifelongthinker will restore default visibility to their posts.
Top comments (108)
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:
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! :)
KISS
Exactly! :)
en.m.wikipedia.org/wiki/KISS_princ....
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 π
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).
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 π
Read the documentation carefully
RTFM π€£π€£ Spot on!
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.
Work hard on understanding the basics and create a good foundation for the concepts.
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.