De-Coder’s Ring

Software doesn’t have to be hard

Month: April 2016

3 Behaviors to Empower Developers

I’ve spent 15 years of my professional career writing software.   Over time, my role has changed so I’ve been in the trenches in different companies and industries.  We start at neophytes.  The company is new, the technology is probably new, the processes are unknown and there are people all around that know more than you.  As time goes on, we become more senior.  Hopefully we start influencing the work we do and continue to provide added value instead of just writing code someone else told you to write.

No one wants to go to work and be bored (well, that may not be true, someone told me they didn’t want to try new things, didn’t want to learn anything else and just wanted to keep doing what they’re doing.  I couldn’t imagine!).

Through the ups and downs of a career, I’ve been in good teams, bad teams and mediocre teams.  Here are three behaviors that I have observed that have helped me succeed and implemented to help others succeed.

Allow them to fail

Hear me out here.  If I only failed, then I wouldn’t be affective.  My job is to deliver technology solutions and technology teams that deliver a product.  This product has to work.  There have been times though, that I pushed the boundaries to try something new.  Usually it’s by bringing in a new piece of open source technology or building a new capability on a platform.  When it works, awesome!  When it fails, oh well.  Lesson learned. Time to try something else.   If I were punished, or fired every time I failed, I would never try anything new.  I’m thinking back to a very specific activity that pivoted a startup I worked at.  It pivoted the entire function of our platform and put us in a new market.  That market provided a ton of opportunity to integrate with technology partners, and eventually be acquired.

The key rule to failure, is to fail fast.  Junior developers typically take too long to learn something new in order to fail fast.  This is not a knock on junior developers.  We’ve all been there.  If a developer is able to pick up a new technology really quickly, they can quickly figure out if it fails.  Celebrate it.  Encourage it!

Get out of the way!

One of my favorite mandates of Agile/Scrum is the sprint.  By defining a sprint, the process locks in the the workload an engineering group is going to work on.  By defining a one or two week sprint, there’s an entry point to the development process.  Product managers get to completely guide WHAT will be worked on.  (More to come on the importance of Product Managers, I can’t WAIT to talk about that one).   Before a sprint starts, you need a collaboration of executive management, product management and engineering to figure out what’s next.  Once that’s determined, GET OUT OF THE WAY!

A primary tenet of mine is to tell an engineering team what you want done, not how to get it done.  This is critical to allowing your teams to learn and grow.  They are the technologists, and should know more about how the code and everything works more than people outside of that group.  Let them figure out how to solve a problem. Give them big problems! They’ll surprise you.

Nothing is more frustrating than being distracted when we’re coding something.  Developers get in a groove.  For me, it’s like music.  If you’re in a quiet room, rocking out to Linkin Park (like I am right now), and someone comes in and shuts off the music and turns the light on, it takes time to get back in the groove.  It’s exactly the same when we’re coding.

Knock down roadblocks

This bullet point is the hardest one to document.  During the creative development process, the last thing you want your engineering group doing is coordinating with sales, or coordinating with facilities to make sure a room is booked for a meeting.  As a development manager, those are things I will deal with.  If you’re a scrum master, that’s what you should deal with too.  Our jobs are to enable our engineering teams, not make them do ‘other’ work.

This may sound backwards, but it follows the ultimate ‘servant leadership’ guidelines.  Most people would look at pay grades or years of experience and think “They’re only a developer, I’m a <much higher pay grade> employee, they can do the grunt work”.  I believe that in order to be the best enabler of an engineering group requires us to take care of that ‘other’ work, and let them focus on what they’re passionate about, and allows them to add more value!

Thanks for reading.   This is cross posted at LinkedIn:


First Try: AWS Deployments

Over the past few months, I’ve been working on a few Amazon Web Service (AWS) ‘things’. The way I look at it, there are a few major goals for using the public cloud.

  1. Cost savings
  2. No more hardware
  3. Scaleability

They’re really all related the more I think about it.  You can scale a web application in your own data center, but that’s a lot of equipment to buy, and odds are, it won’t be used all the time, only during peak hours, days, seasons, etc.  If you were to build out your own infrastructure for peak season, you’d have a ton of machines off or idle.  If they’re idle, you’re still paying for power and cooling.

The reason I wrote my first book on scaling a web application at AWS is to point out that getting started is simple.  AWS has a million (or so it seems) features and capabilities,  which is awesome, but, it can be overwhelming.  Get started simple.  Put a web application on a few EC2 instances (virtual machines) with an Elastic Load Balancer (ELB) in front of them.   When the load spins up, let AWS spin up more servers from you (Auto Scaling Groups).

Don’t be intimidated.  Give if your First Try.

© 2017 De-Coder’s Ring

Theme by Anders NorenUp ↑