Yesterday’s unit test results. Last week’s build breakage. Last month’s bad update. Last year’s roll-out that went sideways and didn’t make it in until the third try. These alone aren’t bad when they occur, but when we hold onto them, reference them in meetings when someone wants to try something new, test out a new idea or approach and use them as justification for not implementing change. This is when they become our biggest failure.…
Stuck on a problem you don’t understand? Code your way out. Not sure if you’re really happy where you are? Code your way out. Can’t get your phone to do what you want? Code your way out. Not sure how to level up your job? Code your way out. We live in an era where virtual training is no longer an “okay” option, it’s the hidden weapon to get you where you need to go…
So you’re not in the role you want to be in. Or maybe that promotion you fought so hard for you didn’t get. Maybe people are asking you to go into a different lane then you’re in now. Whatever it is – you’re not where you had wanted to be. But maybe it’s where you need to be to realize you should be somewhere else.
You can tell a lot by a team on how they work together when a critical bug is logged, 4 days prior to release. Either it’s the blame game as to who touched it last, what they were doing, what they knew or didn’t know or how dumb they are to really let that happen. Or it’s the team that rallies to understand the problem, look at it from all angles, figure out a plan…
The new guy doesn’t know where you keep your git library. They aren’t sure what libraries you are using. They probably have no idea who uses your software or why. To work on the bug you just gave them will take weeks, not days or hours. If you are hiring a new member of the team, recognize that it will take 2 – 3 months to learn what they are supposed to do and start…