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…
Stay on the same course as everyone else. Don’t colour outside of the lines. Stay in your box, maybe make it smaller to be on the safe side. Don’t try anything new, do what everyone else is doing. After all, 1 million, billion cannot be wrong, can they? Stay the course that is safe and well worn by those in front of you (no need to create a shortcut to get their faster). Never try…
Then I guess the team is too busy to design it? Too busy to code it? Too busy to test it? Too busy to fix it? Too busy to help? If you’re not willing to take the first step towards resolving your problem, writing it down, then how do you expect to get others on board to help you? Aside: Needing help from others on figuring out your problem is a great idea to figure…
Change is great. Change is amazing. But what about when you’re not the instigator of the change or you don’t see it coming? Depending on the scenario and context you might be able to pivot extremely well, in other scenarios you may not – you may be thrown for a loop and sit there looking at your screen wondering why you? Why did this have to affect me? I didn’t ask for this happen? This…
I had an experience with a doctor a few months ago where they squeeze in an appointment at the end of the day to see me. It was a gross day, raining, muggy… one of those days you want to go home, order some pizza and catch up on Suits. But they made room in their schedule. And when the appointment took place, they welcomed us warmly. And they didn’t rush things, where mistakes were…