25

being told to lead a team of junior developers for a project when i was 18

i never had any formal CS education so i thought the management was joking, but a week after, i was called into a meeting with the junior developers and we were tasked with a project that needs to be completed within 4 months, with me as the lead

the project was successful and after that im occasionally given the task to lead a project every now and then

this happened a few years ago and its still the most confidence-boosting experience ever happened to me, the things i learned during those 4 months are still applicable to my career today

Comments
  • 9
    Share what you have learned with us please.
  • 1
    Do share with us!! Your experience
  • 2
    That Just Sounds so awesome. Even at that Young age collecting such an experience
  • 3
    Hey guys, thanks for all the ++'s and comments. I'd be more than happy to share some of the things I've learned during those 4 months:

    1.) Always communicate - This is the most important thing. I know most devs (including me), prefer to work alone and have less communication with others, but that changes when you're in a team and specially when you're leading a team. It's the only way to keep everyone in loop and connect with your teammates on a personal level, which brings me to #2.

    2.) Develop your empathy - I've seen a lot of leaders who lack this, and in my opinion this is the hardest to develop but is also one of the keys in becoming a good leader. Everyone have their own problems to deal with, and sometimes it affects their professional life. Well-liked and respected leaders understand and care for their teammates, and knows fully-well that their teammates are humans too and not just tools to achieve goals.

    cont...
  • 3
    3.) Accountability & Responsibility - ever heard the quote "with great power comes great responsibility"? Not all situations ends up as "good", good leaders never put the blame on their teammates alone but shares it with them and creates measures to prevent the same mistake from happening again.

    4.) Clean code & documentation - This should be self-explanatory to everyone but let me be a little more thorough. Before the start of any project, there should be a design doc to follow which can include (i.e overall flow/design of the system, naming conventions to follow, design of each features, etc...), that way everyone is on the same page and there will be less clutter when the project starts.

    Clean code is very important since you're not the only one working on this project, everyone should be able to read and comprehend what your code does, this improves time on code review and will most likely generate less bugs.

    I'll always pick clean code over "clever yet dirty" code.

    cont...
  • 5
    5.) ALWAYS do code review - again, self explanatory but really important to do no matter how big or small the changes are. For me, I always do it with my teammates when its applicable, this doesn't just prevent more bugs slipping their way through production but also helps your teammates improve their code quality and learn new things from everyone.

    6.) Don't forget to rest every now and then - it doesn't matter how hectic the deadline is, REST is always important, I always tell my teammates this. We developers uses our brain all the time and this takes toll on our energy which also affects our work effectiveness. If you noticed that you're not making any progress on a problem, stand up, get away from your work station and take a walk or have a snack for maybe 15 minutes. This frees up your mind from a lot of stress and helps your brain to relax even for a bit. Trust me, this works.

    cont...
  • 3
    7.) Always be open to feedback - most of the time we're not able to see our own wrongdoings or flaws, so it's always good to listen from other's feedback, if no one is giving you a feedback, ask them to do so and make it a habit. By doing this, you allow yourself to improve your skills and grow as a leader, and learn from your mistakes.

    8.) Never stop learning - I've read this post from Medium where it says, "Technology moves forward -- so should you!". Ever since we became developers, we also signed up to be lifelong students, it is said that part of our role is to stay relevant with the current technologies and domains we work with. However, it is entirely up to you to learn or lose your competitiveness. But I suggest the former because, great developers never stop learning.

    If you've reached 'til the end, thank you so much for your time. I hope you learned a thing or two.
  • 3
  • 0
    Time to read
  • 2
    Thank you so much for the sharing, I've learnt a thing or two or 7 ahha, based on what you shared.

    As a newbie leader, I'm not quite sure on how to do a code review. Can you elaborate more on ways you did it? If possible

    Thank you very much!
  • 2
    @darkm0de
    Nice starter.
    Welcome to devrant!

    May I ask you for how many years you are doing this? And where? =)

    I always thought these principles would work out but either Germany does not want em to do so, or I am out of ressources.
  • 1
    @LucienZera26

    Our code reviews are done via Github, we usually have 2 main branches (master and dev), I always lock the master branch so only our Github dev account would be able to push/merge commits into it.

    I always direct my teammates to branch out of the dev branch when working which we have guidelines for (i.e feature branch should have a prefix of 'feature-'), all their codes are then pushed on their own branches. Once they believe their code is working and ready for QA test, they would create a pull request to the dev branch where the code review happens, once it's approved the changes are then merged to the dev branch and is tested by our QA team. I believe this workflow is called "Gitflow".

    The code review itself consists of reading the codes from the commits and making sure they follow our design standards, and won't generate bugs / create server resource bottleneck.

    In the future, we're planning to implement CI techniques to automate our testing :).
  • 2
    @darkm0de dope man, thanks alot! I'll share it to my teammates and use it in future! Thanks Again!
  • 1
    @LucienZera26 You're welcome! Good luck :)
  • 1
    @scor
    Thank you! I'm glad to have found this place haha.

    For the leadership role, I've been doing it for at least 3 years now, so I'd say I'm still pretty young on this thing. I'm currently based in the Philippines right now.

    I believe it still depends on the environment and work culture, I am just very lucky to have a very supportive management and colleagues who taught me the right things during my time doing this, we usually have a bi-weekly or monthly meetings to measure our leadership performance and provide advice/tips to us if needed.
Add Comment