You don't get paid by size of commit or number of lines produced (if you do, get out of there). Avoid coding first, most likely what you are solving has already been solved. This forces you to think in abstracts about your problem (in order to find the package you need). Abstraction is at the core of programming.
Don't modify anything in get
Caching is a performance optimization and cause of many subtle bugs. Use with care.
Avoid the golden hammer. There is no one way to do something and learn early on to formulate your options, pros and cons and pick the one that works for that situation. Also avoid cultures that enforce this "one way to do something".
Code formatting is not something worth spending time on in this day and age. Pick an opiniated formatter, configure it and run with it.
Bugs will happen. They don't define your self-worth or competence and avoid any company culture that make you feel worse about yourself when you left a bug in your code. Instead: Own the bugs, analyze them (ask help from seniors if you get stuck) and learn.
And last but not least: commit messages are not about what you did (I can read that in git log -p), but about WHY you did it. About the context of the change. Reference tickets. Summarize your analysis. This will tremendously help your future self, your new team mate or the person fixing a bug to understand the code and what happened to it over time.
Also, if you REUSE please consider the maintainability "last commit date :)" of the project you are reusing and who is taking care of it. Number of stars, downloads, etc... Compare to other products similar.
Listen to others, but formulate your own point of view.
Always review your commits before you send them, you will be amazed by how many bugs you will catch of yourself before getting into someone elses eyes, you better waste 10 minutes of your time than 1 man hours of multiple colleagues.
Don't obfuscate/minify your code early on, leave that job to compilers, minifiers, bundlers.
Write readable code, do not comment it out if the code is self explanatory. That's the reason why you use clear variable/method names.
Read a lot of articles every day so you find great posts like this!
Communicate, ask dumb questions to your colleagues, it doesn't matter, this shouldn't be a problem.
Make a todo list of all concepts you don't understand and ask someone to explain it to you with their words, usually this works better than watching a bunch of youtube videos or taking an online course. Instead, focus in what you love, you don't have to know everything, but sometimes you need to just get quick answers, this is the way!
Code when you are less tired, your productivity will increase 90% and you will see the results.
Have a wonderful way up to the top, you are already on the right track!
I will add, commit messages should link back to actual issue numbers in your Kanban board such that documentation, issues, bugs can be traced to code commits at all times.
This helps with on-boarding, new bug resolution, old bug resolutions, code understanding, and code documentation in general.
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
git log -p), but about WHY you did it. About the context of the change. Reference tickets. Summarize your analysis. This will tremendously help your future self, your new team mate or the person fixing a bug to understand the code and what happened to it over time.Well said bud!
Have a wonderful way up to the top, you are already on the right track!
Cheers, peace and love!
I will add, commit messages should link back to actual issue numbers in your Kanban board such that documentation, issues, bugs can be traced to code commits at all times.
This helps with on-boarding, new bug resolution, old bug resolutions, code understanding, and code documentation in general.