This was a good keynote. Smart advice about being both an apprentice and a mentor, and applying lessons learned to other areas of your life. During most of the talk, he pointed the handheld microphone more in the direction of the ceiling and audience, so was difficult to hear at times.
I thoroughly enjoyed Rabbi Yitz's keynote. I loved the irony and counterpoint of bouncing back and forth between leading edge PHP development and ancient Talmudic wisdom expressed in Hebrew proverbs.
Delightful.
Great presentation. I sat in the front row and had difficulty hearing. The speaker would've been benefited by a wearable mic or holding the mic closer to his mouth.
I took some of his ideas and tried to implement them at work. A small change with a large impact was enforcing the rule that every pull request is required to have a junior developer be one of the reviewers, the other being a senior developer.
This gave us all the opportunity to mentor the junior as a team. The junior gets to see where in the code base a feature change would impact, then see the "right way" (according to project standards) to implement the feature change. Bit sized chunks of new information that they can then turn around and use immediately. I've seen some juniors on my team improve their workflow by leaps and bounds both in the way they think through problems and how they choose to solve them.
Comments
Comments are closed.
Excellent
Great advice on mentoring, wisdom, and how to become better as a developer. Good flow and pace.
This was a good keynote. Smart advice about being both an apprentice and a mentor, and applying lessons learned to other areas of your life. During most of the talk, he pointed the handheld microphone more in the direction of the ceiling and audience, so was difficult to hear at times.
I thoroughly enjoyed Rabbi Yitz's keynote. I loved the irony and counterpoint of bouncing back and forth between leading edge PHP development and ancient Talmudic wisdom expressed in Hebrew proverbs.
Delightful.
Great presentation. I sat in the front row and had difficulty hearing. The speaker would've been benefited by a wearable mic or holding the mic closer to his mouth.
I took some of his ideas and tried to implement them at work. A small change with a large impact was enforcing the rule that every pull request is required to have a junior developer be one of the reviewers, the other being a senior developer.
This gave us all the opportunity to mentor the junior as a team. The junior gets to see where in the code base a feature change would impact, then see the "right way" (according to project standards) to implement the feature change. Bit sized chunks of new information that they can then turn around and use immediately. I've seen some juniors on my team improve their workflow by leaps and bounds both in the way they think through problems and how they choose to solve them.
I liked the pair coding section. It helped me to resolve to do a 20 minute pair coding session daily with another developer on the team.
It was difficult to hear at times due to the placement of the microphone either on the podium or in his hand.