I’m 5-6 years into my career now, and there are still a couple greybeard-level types I can ask when I run into a real puzzle, but the need to do so has been shrinking as the years have gone on; I’ve gotten better at finding my own answers. During my first job I was on two different teams where a mentor took me under their wing. These were people who I could turn to for design advice, technical questions, insight on best practices, etc. For me, as a curious and extroverted person, this was invaluable learning experience.
Your experience may be different, but to me it’s always good to have a solid group of people (coworkers, internet social network, even just stack overflow) I can rubber duck to or ask for input, discuss new technologies, learn from or learn with.
Coding a project of significant size is a collaborative process, and I think you’ll find that if you approach it with openness and curiosity, you’ll end up with mentors, peers, and mentees of your own at any given time.
I’m over 20 years into my career, so I think I’m technically (and literally) a grey beard now. I always make time for junior devs if they need it or request it. Often I try to softly inspire them to a good solution, or challenge their thinking when I think they’re going down the wrong path or are creating too much work for themselves through over-engineering.
Pair programming is an invaluable learning tool for any team. It produces great results as you are both challenging each other while also quickly spotting those silly mistakes we all make.
Rubber Duck Debugging is also a fantastic way to solve issues quickly, as just talking through how you think the code works while reviewing it, you often spot the issue with almost no input from the person acting as the duck.
I’d also recommend doing code katas like codewars for any skill level, as solving problems that you wouldn’t usually come across in day to day work can lead to ways of thinking that you wouldn’t get otherwise. If you can, get more people on your team to do the same katas and then all talk through your solutions as a group. We would often use languages we were less familiar with to solve the kata in order to pick up new skills as well.
You never stop learning in this industry. There’s always new tech, new languages, and new ways to solve a problem that will make you a better programmer.
I’m 5-6 years into my career now, and there are still a couple greybeard-level types I can ask when I run into a real puzzle, but the need to do so has been shrinking as the years have gone on; I’ve gotten better at finding my own answers. During my first job I was on two different teams where a mentor took me under their wing. These were people who I could turn to for design advice, technical questions, insight on best practices, etc. For me, as a curious and extroverted person, this was invaluable learning experience.
Your experience may be different, but to me it’s always good to have a solid group of people (coworkers, internet social network, even just stack overflow) I can rubber duck to or ask for input, discuss new technologies, learn from or learn with.
Coding a project of significant size is a collaborative process, and I think you’ll find that if you approach it with openness and curiosity, you’ll end up with mentors, peers, and mentees of your own at any given time.
I’m over 20 years into my career, so I think I’m technically (and literally) a grey beard now. I always make time for junior devs if they need it or request it. Often I try to softly inspire them to a good solution, or challenge their thinking when I think they’re going down the wrong path or are creating too much work for themselves through over-engineering.
Pair programming is an invaluable learning tool for any team. It produces great results as you are both challenging each other while also quickly spotting those silly mistakes we all make.
Rubber Duck Debugging is also a fantastic way to solve issues quickly, as just talking through how you think the code works while reviewing it, you often spot the issue with almost no input from the person acting as the duck.
I’d also recommend doing code katas like codewars for any skill level, as solving problems that you wouldn’t usually come across in day to day work can lead to ways of thinking that you wouldn’t get otherwise. If you can, get more people on your team to do the same katas and then all talk through your solutions as a group. We would often use languages we were less familiar with to solve the kata in order to pick up new skills as well.
You never stop learning in this industry. There’s always new tech, new languages, and new ways to solve a problem that will make you a better programmer.