For further actions, you may consider blocking this person and/or reporting abuse
Read next
Ajustando Limites de Concorrência do AWS Lambda para Minimizar Throttling
Misael Amorim -
Towards a Unified Ethical Framework for Responsible AI
Paulo Mota -
Mastering DOM Manipulation in Vanilla JavaScript: Why It Still Matters
Rajesh Dhiman -
EXPLORING HTML ELEMENTS: <DIALOG>
Miguel Campos -
Top comments (15)
Such a great question! I often work with summer students where I task them with learning a technology that is new to both of us. This way we can explore together and they feel that they are making a contribution to my team's work. Since they are only around for a summer, detailed documentation is a must. Good habits + new tools = fun times
I think more than you can actually imagine.
There were times I've been ask to explain a topic. Not even very complicated. And I run into conclusion that although I thought I know the concept myself and know how to use it it's still quite hard to explain it to person with hmmm... Not even less but with different background.
Since then I've been able to setup new personal definition of 'understanding topic' :
"It's impossible to know everything. But you understand a concept good enough if you know how to use it and you're able to explain it to other person independent of their experience level*"
*of course we should put here some common sense - I'm talking about a developer not someone completely not related to area of this concept
Hey Malgosia,
Thanks for sharing your thoughts.
I ❤️this. Gonna have to borrow it from you :)
Glad you like it :)
It's my recent motivation motto I came up when a friend of my ask me to define my actual career goals as something I can actually checked as done.
It's also useful buseful for me in process of preparing for a job interview, as I very often get frustrated when I did not know some detail or quirk about a concept :P
But after discussing this with a friend of mine I've just needed to update this thought today with one more condition and conclusion :P
Actually I have learned quite a lot.
We hire interns for each semester. We try to extend the offer and keep them for 2-3 semesters if they are willing and potentially offer full time if they show promise and fit into culture. So over the last three years we have had about 7 interns working for us and I had the opportunity to mentor them. I have learned quite a lot in mentoring and guiding from the experience.
Being curious by nature, they pose questions that some times sound ridiculous but It did require me to go through the documentation to answer.
We have had very meaningful discussions through which both of us got better understanding of some concepts.
'Patience', that's one of the best lessons I learned working with Junior developers. Working with a variety of individuals helped me to understand their level and how to work with their pace. dn't
P.S: I'm not putting anyone down, most of the interns we had great potentials albeit of their less experience.
I was pleasantly surprised that the inner monster of Impatience subsided quickly in me. I got a serenity that helped me teach more calmly to 3 dozen students at a time.
I often see my own shortcomings too when communicating some new knowledge. And that reflection shows light on what I need to learn and practice. It's an impossible-to-see with any tool or app. Priceless for all journeymen.
Absolutely love this reply!
Thanks for sharing Mik.
Thank you!
That I need to sharpen my soft skills, and I did: patience, empathy, communication was the most important. When you tell a junior what to so you have to explain:
Why to do it
The context (business and technical, like the module)
How to do it
I believe the fear of failure is much less , risk taking ability is much more for less experienced developers. Something we proudly used to flaunt when we were less experienced.
Our appetite for risk reduces once we become more experienced. Something I always think is one of the most powerful assets of less experienced developers.
I learned quite a bit about git and how it can be used. The feature-branch workflow was new to me at the time. She also showed me lots of other workflow models.
bocoup.com/blog/git-workflow-walkt...
I've learned that you should be open-minded and tolerant in order to be a more effective leader. That you should be committed to always being aware of your assumptions when interacting with less-experienced developers. Because those less-experienced developers may not be on the same page as you. So you'll have to be vigilant in your communications with them.
This is so that you can lead and foster growth within your ecosystem, whatever it may be, a team or even an entire community. You can use the old adage that a chain is only as strong as its weakest link.
So let's be committed to making sure each chain is as shiny and strong as the next one by nurturing shiny and strong chains rather than nurturing rusty ones.
Ego is your enemy, so don't underestimate someone, whoever it is.
That sometimes you should give up and find a different way to solve a problem. The fresh approach another dev takes can dislodge some old habits and stubbornness when I'm stuck.