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.
I usually do the following steps when reviewing code:
Look at the ticket
Look at the code without the changes requiered for the ticket
Think about how I would implement it
Look at the actual implementation
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! 😄
I've been coding for over 20 years now! (WOAH, do I feel old)
I've touched just about every resource imaginable under the Sun (too bad they were bought out by Oracle)
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.
Larry's Wall "Laziness, Impatience and Hubris" virtues of a programmer theory is incredibly valid. So I've learned just that :)
Laziness. Know your language to achieve maximum efficiency with minimal code. Think ahead to implement future changes in minimal time. Cut unnecessary work wherever possible. Keep everything simple. And bomb-proof.
Impatience. Refactor annoying code immediately. Automate everything. Keep your code and documentation so clear than others won't bother you about explanations. Reduce meetings to minimum to avoid annoying side threads and scope creep.
Hubris. This goes against all those team building principles, but sometimes democracy in code is a bad thing. You must learn to listen to others, analyze their proposals and points of view. But also to take a steering wheel and go back on track without remorse when your experience tells you their ideas are going nowhere.
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.
Hi everyone! My name is Paul. I am working with VistaProject's Current SCM, the Worlds best Cloud Based Procurement Software! I work with super brilliant co-workers on Laravel every day and love it!
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
Hi everyone! My name is Paul. I am working with VistaProject's Current SCM, the Worlds best Cloud Based Procurement Software! I work with super brilliant co-workers on Laravel every day and love it!
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 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
Using less bloated tools to code