Would love to know - also include some context on your level +industry if possible!
For further actions, you may consider blocking this person and/or reporting abuse
Would love to know - also include some context on your level +industry if possible!
For further actions, you may consider blocking this person and/or reporting abuse
Dovile Miseviciute -
Avesh -
Augusto Klecz -
Sébastien Conejo -
Top comments (16)
I think for me the biggest leap I’ve taken is to better project future communication problems into the current task.
It’s hard to wrap you’re head around, but even beyond code legibility, if the whole task isn’t being handled with future groups in mind, it’s setting up for future pain.
You can’t overdo it with this mentality but it’s a big thing on its own.
That's definitely not an obvious one for me, thanks for the thoughtful response!
Starting to write Unit Tests / TDD.
What type of coverage do you typically aim for?
At least 80% for new code.
Doing and receiving lots of code reviews!
I usually do the following steps when reviewing code:
This way I get to know different approaches when it comes to one specific ticket and, depending on the circumstances, one may be better suited in a certain situation than the other. With this you can learn a valuable lesson that may be important for your next task! 😄
Great advice, thanks!
Two decades ago, I mentored under the developers of Winamp. I didn't sign up for this, didn't even ask for this, I simply hung out in their IRC channels they were super active in. If I ever had a question, they'd be quick to answer.
What they were focusing on the time, and what they instilled inside of me wasn't "programming" skills, it was systems architectural design skills, something that often isn't taught, or sought after.
I think a hurdle for some is just writing more code. Practice is huge when you're a junior.
Larry's Wall "Laziness, Impatience and Hubris" virtues of a programmer theory is incredibly valid. So I've learned just that :)
And from hard skills - train on programming challenges a lot. There is a reason why top level chess players do a lot of chess puzzles. It helps to see/learn optimal patterns and force your brain to systematically think about encountered issues. No joke. Programming challenges are really, really good as mental excercise.
I also relised that becoming a master of Laravel Validations is important. Learn how to do Validations as a Closure, and Custom Validations, and familiarize yourself with all the Validations Laravel has to offer.
Lastly, try to remember how to "get to value" for your customer/manager as soon as possible. Try to improve workflow, and reduce time spent on problems
For me, something that is 'out-of-sight' is 'out-of-mind' - so, to help me remember important / useful commands, I sometimes use my label maker, and paste these important commands etc. all over the side of my screen side, and keyboard.
IE: do you sometimes forget if 0, or 1 = true?
I also put neat linux commands, like, ncdu, duff,z, fzf on labels.
Explaining myself algorithms by drawing charts and pictures with pen-and-paper.
Explaining ideas is a skill we all need but don't practice enough. Helps me memorizing, helps me when I have to help juniors, helps me when I discover in the mid of the explanation that I try to use the wrong idea to the problem.
Platform engineer, ex front end senior, working on SaaS products.
I stopped coding 🤭 it took me sometime to realise that I am better at marketing codes than writing codes! I am at a happy place. #irrelevantanswer