The best way to learn is to learn from others. Learn what they have done to become successful. Watch what they do (and stop talking about it). Don’t share the fact that you’re learning from them. Listen to what has and has not worked. And then, ask questions, get feedback on your approach, what are you doing that works and what are you doing that is not. Or, keep doing what you’re doing and hope you…
We pick teams based on strength and accomplishments. And when we put them all together we expect magical things to occur. But sometimes the better approach is to Lead by their Weaknesses – not to showcase and single out where everyone is weak (I hope this is obvious) but rather to make a note where they need help, make a plan, figure out what needs to be done and focus your energies there. If you…
I still look at emails I want to unsubscribe from and go – “but if I unsubscribe, they’ll know I’m a real person, that I exist, maybe they won’t take me off their list”. And when I do unsubscribe, I immediately get the email back that says – “It might take a week to remove you from our list”. When I picture this, I think of my subscription being sent to headquarters in an envelope…
We have super standards. Our systems are more complicated. We’re not like everyone else. We have the most intense channel. If we go down, we are in trouble. You can come up with as many lines as you want but at the end of the day it still boils down to this – “Leading teams and delivering Code” – and if you aren’t doing those things, yes you are different, but the bigger question is…
The #1 problem with Code Reviews isn’t whether the standard is followed, what syntax is used or when you start doing them with your team. Whatever you pick (and when) will work – it will. The problem is the follow through. We start with lofty expectations of all that we’ll accomplish, we turn on all the switches and for a time things start to go well – code starts to get reviewed – questions are…