Details
-
AboutFull-stack Software Engineer specializing in Web Applications
-
SkillsPHP, Python, Javascript, SQL
-
Locationworld wide web
Joined devRant on 1/31/2020
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
What editor are you using?
-
Take some rests and don't quit! You'll be able to accomplish this.
Anyhow, have you seen this? Thought it would help you with your RL journey: https://openai.com/blog/... -
@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. -
@LucienZera26 You're welcome! Good luck :)
-
@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 :). -
@aviophile @LucienZera26
-
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. -
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.) 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... -
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...