You can’t deploy to Production because you didn’t fill out these forms.

You can’t use this library because it goes against our standards.

You can’t change that code because we don’t know what impact it will have.

Some sample issues you probably hit as a developer that reveal themselves to be the problem.

But they aren’t the problem, they are the symptoms.

And you won’t always recognize them as the symptoms and not the primary pain point until you’ve gone through the fire a few times, taken a step back thereafter and looked at what the real problem was from the beginning.

Why did you not know that you had to fill out forms to deploy to Production?

Who should you have cleared the user of a new library with?  Does it really go against your standards or are the standards out of date when compared to a new library?

How come no one can identify the impact that a change in code will have?

These aren’t the answers, these are the questions, that need to be asked, to get us closer to the Primary Pain Point, so then we can start to formulate a real solution.

Want more? Check out my book Code Your Way Up – available as an eBook or Paperback on Amazon (CAN and US).  I’m also the co-host of the Remotely Prepared podcast.


Write A Comment