The Primary Pain Point

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.

Creative Software Development

My favourite part of software development has always been the creative opportunities that it presents…

  • Coming up with new ideas to complex problems.
  • Trying something out simply to see if works.
  • Building something that no one thinks really works and watching it work.
  • Dreaming of an idea and then putting it into practice.

I love it, I love every aspect of it, it’s amazing and wonderful and beautiful all at the same time with an artistic wonder that I think is sometimes forgotten.

I think it’s the only industry on the planet that offers so much freedom to its community and at the same time provides so much opportunity for growth.  There will always be the long, hard nights debugging problems – but the part that always gets be going to the end of that long, hard night is figuring out a creative solution to the problem and going to bed elated at what I created.

Why are they standing up?

Have you ever watched the final round of a Texas Hold’em Tournament when it’s down to 2 people playing Head to Head.

Ever notice when they go All-In how they stand-up and go hang out by their family and friends in the stands, watching the cards from afar.

At that point – the game is completely out of their hands.

Now notice that when they win, the winner’s family and friends go crazy, cheering and clapping for them?

At first glance you’d think they are cheering for the hand (largely out of their hands at that point) but they’re not, instead they are cheering for everything they did to get there – all the playing the players, looking at the cards, finding the tells, grinding through the lower tables, etc, etc.

They aren’t standing up for the hand – they are standing up for everything you did to get there and play that hand.

In any release, it’s great to cheer at the end when the product goes out the door, but don’t ever underestimate the value that can come simply by standing up and cheering when your team is grinding through on their way to the final match.

One Hour of Code

I had the opportunity to speak to a class on #OneHourOfCode and had a great time presenting.

My presentation for this event is located here and a larger LinkedIn post is located here.

This is a great initiative and a great way to continue fostering the growth and spirit of coding.

From Developer to Architect

You start writing code, you start compiling code then you ship code.
Rinse and Repeat.
Slowly the work being given to you gets bigger and larger, you’re not doing bugs anymore, you’re working on full-scale PBIs, Features, and Releases.
At the same time, you start to look back at some of the old code you wrote only to declare – “Holy Hippo Spit what was I drinking when I wrote this”.
So you start to put more time into the design, to account for mistakes of the past and make something better for the work that you are now being given.
Perhaps you have a team looking to you for guidance, perhaps you don’t – regardless you are now doing more design than code.
You are now an Architect.
Maybe it happened overnight when someone left your team, maybe it happened over a few years of you showing up and doing great work, maybe you were hired to do it.
Whatever the case.
You are now an architect.

Want to be a good architect?

Don’t design for 5 years down the line.
Don’t stop learning new ways to solve old problems.
Don’t stop challenging what you previously did so you can make it better.
Don’t get hung up on frameworks.
Don’t stop doing what got you there, keep coding, keep implementing, keep making it work.
Do take the time to mentor others and onboard them.
Do ask for suggestions and feedback to your crazy ideas.
Do have fun and laugh at your mistakes.