Week #5 of the SEP Blog Battle.

Read about it here.

Follow us on twitter.

Ever find yourself in a rut?  You just can’t crank anything notable out this week.  It’s so obvious that even your teammates start placing bets on the over/under of you meeting an estimate.  (No seriously, it’s _that_ obvious, and it is happening right now, for me.)

Okay, maybe your team handles it differently than my team.  We’ve all been there, though – more refactoring than normal (sometimes all on the same blocks of code); less functional changes; and ultimately, less value added.

It sucks.  It’s a tough place to be, and you feel like you aren’t pulling your own weight on the team.

The longer you stay in your rut, the harder it is to get out.  These ruts are a dangerous place.  A rut can drain your energy and hinder your performance.  If you don’t find a way out of your rut in a timely manner, you can dig yourself so deep that it seems impossible to get out. We’ve all heard it – “I’m stuck doing [blank], even though I’m not interested in [blank].”

So, to get out of your rut, you need to build up momentum.  Let’s look at what momentum is…

Well, mass is negligible, right?  It’s the knowledge you’re dumping into your IDE, or the weight of the paper you’re doing some discovery on, or conversations/emails you’re having with other people.  Effectively, we are left with…

With that, we know that velocity isn’t just your speed, or how fast you’re typing.  It is a vector…it has to have a direction.  If you aren’t moving in a direction towards the end goal, then you’re not moving forward.

This means that momentum, in our world, is essentially how well you can move towards your goal – whether your goal is developing a feature, fixing a bug, writing an email, or something else.

And according to the law of conservation of momentum, once an object has momentum it will continue to have momentum.  Or in more laymen’s terms – once you get the ball rollin’, it’ll keep rollin’.  So to get the ball rolling, you have to continue making strides towards your end goal.  If you run into a road block, pivot on what you’re doing, and try not to let that wall stop your momentum.

If you take into account Newton’s Third Law of motion, each action has an equal and opposite reaction.  So if you find yourself running into road blocks, you have to change directions.  If you don’t constantly change directions with each road block, you’ll stop having velocity, and effectively stop having momentum.

So the key to overcoming challenges with momentum is to remember your laws of physics – pivot when you are presented with road blocks.

Week #3 of the SEP Blog Battle.

Read about it here.

Follow us on twitter.

Many times, I’ve heard the cliche – perfect is the enemy of good enough.  I agree with this, for some definitions of the phrase “good enough”.  But that definition changes for me.

How do _you_ define good enough?  My guess is that it depends.  It likely depends on your current problem, project, client, or more.

While I agree that aiming for perfection isn’t ideal – it’s likely not efficient, it likely is over engineered for the current problem, and it is likely going to take more time than it needs to.  However, I don’t believe that we can define what “good enough” for the full product looks like on day 1.  The reality is, we aren’t going to build out 28 web services because we need to write 1 service to return a data set.  You can’t even plan what the perfect web services would look like.

This doesn’t mean that you can simply hack something together and effectively under-engineer a solution.  Instead, converge on what is “good enough” for your current, self-contained, problem.  While implementing your “good enough” solution, use good practices, be heedful, and use design principles.

As you build this product, you will (hopefully) iterate often.  Each time you iterate, your definition of “good enough” will change.  Your design will evolve as you iterate.

Instead of taking bets on what is “good enough”, plan on evolving your design.

The SEP Blogoff challenge this week was to write about getting better.   I had to think a little about this.   I mean, there are some good reasons that come to mind immediately – career growth, introspective challenges, helping others.  While these are great reasons for me to get better, I’m still limited by my personal comfort zone.

As someone who was working solo for over a year, one of the biggest problems I ran into was the lack of external influence to get better.  Even with the reasons above to get better, I was comfortable with my own pace, and being comfortable means you aren’t growing.

Today, I’m fortunate to be on a great team!  Sure, sometimes being on a team is uncomfortable for me, especially when I feel like I’m light years behind.  It’s a big change from being on my own pace, to keeping up with an entire team.

I’ve learned that in order to get better, you have to get outside of your norm, and make it uncomfortable.  Pick up a new SCM tool and pound through it.  Go through some new Katas for a development environment or language that you don’t know very well.  Practice Pain-Driven-Development to reduce pain points in your daily routine.  And spend some extra time helping solve problems that the team is having.

By practicing any of these and pushing my comfort zone, I continue to get better.  I make it uncomfortable.