My friend and coworker Chris Eargle wrote a great post on some resolutions for the New Year.  It made me think about how lucky we were to avoid this particular apocalypse (along with all of the others that I've lived through in my 45 years), so I’ve come up with a few developer centric resolutions of my own.

Get a Mentor/Be a Mentor 

The worst thing you can do for your career is be the smartest person in the room.  I'm not talking about when you believe that you are the smartest person in the room. I mean when you really are the go to person for everyone else in your group.  The final stop.  The ultimate question answerer.

So here’s another question for you: Where do you go for answers?

If your answer is “Google”, then you have stagnated.  Surround yourself with the smartest people you know (or don’t know).  Go to your local user group.  Speak at a local code camp and hang out with the other speakers.  Find someone you click with and ask them to be your mentor.

Get a Mentor

I have several mentors in my life.  People I respect and am comfortable asking questions.  Some of them are even technical!  Yes, I have mentors outside of the development community as well.

What does having a mentor entail?  It’s up to you.  I ping them when I have questions.  I’ll ask them to grab a coffee when I went to sit down and have a chat.  I hang out with them when we are in the same city at conferences.  Earlier in my life, I had more formal processes set up, especially when I started with the fire department.  These days, I don’t have anything formal set up.  It’s more of an on-demand mentoring.

Be a Mentor

Likewise, be a mentor to someone in your life.  If you have children, you already have the job of being a mentor, parent, friend, and teacher to them.  Although when we mentor our peers, we need to drop the parent part.  It’s not an authoritative role.

How do you become a mentor to someone else?  Well, it’s nice if someone asks, of course.  That does make it a bit official.  But you can also be a mentor to someone without declaring “I am your mentor”. See someone who is struggling with something that you can help with?  Ask them to go grab coffee (or a Monster if you are in the younger generation).  Go to lunch with them.  Talk to them.  More important than that, LISTEN.  Mentoring isn't about espousing your wisdom and all of your experiences.  It’s about being an ear, a shoulder, and a guiding hand only when needed.

Be a mentor image
2010Feb08_0123.jpg/Jerome T/CC BY


“Beth, I here you calling”!  But I just want to “Rock and Roll all night and party every day” in “Detroit Rock City”!  [Lyrics copyright by KISS].  You are more than welcome to make a resolution to hang out reliving your days in the KISS Army.  But that’s not what I’m really talking about in this case. 

I mean Keep It Simple, Stupid!  As developers we spend the majority of our time maintaining code, and only a small percentage of our time creating new code.  It has also been shown that maintaining code is more difficult than writing brand new code. So if we write the cleverest code we can when we create new code, by definition, it will be way beyond our capabilities to maintain it.

Blaise Pascal said in his 16th Provincial Letter “The present letter is a very long one, simply because I had no leisure to make it shorter”.  Take the time.  Refactor your code. Make it shorter. Make it easier to read. Follow SOLID every chance you can.

If you can’t explain it to a nine year old, it’s too complicated.  You aren’t being paid to be clever, and nobody is going to give you a raise because you write code that nobody else can support.

Keep it simple image
Keep it simple, stupid (and short)/Jegi/CC BY


This was the first Christmas that I didn’t have to build something on Christmas eve.  In the past there’s been bicycles, doll houses, play kitchens, and all manner of items.  Of course, none of the construction could start until after the kids went to bed, and I still had to get up at the crack of dawn with three kids jumping on our bed. Ah, the memories!

All of these late nights had one common thread, of course.  I felt that I could build it without reading the instructions.  More often than not, the pictures were terrible, the writing was a third generation translation, and my frustration with the quality was always extremely high.  And I of course felt that I can do anything when I put my mind to it, so why bother reading the fricking manual?  Sound like the requirements from your last project?

Believe it or not, people typically put a great deal of time in writing requirements.  They aren’t intentionally writing them to confuse you.  It’s hard to write requirements that all parties can understand.  But they are the foundation of your project, and contain a lot of project knowledge.  So read them.  Better yet, read them, and then go to the author and ask questions.  Then listen to the answers!  Have a dialog.  Each sprint, read them again.  And continue the dialog.

RTFM picture
[127/365] Immersed/pasukaru76/CC BY

Don’t Repeat Yourself

A friend of mine once said “If you write something once, you should make it a method.  If you write it twice, you have to make it a method.  If you write something three times, you should stop programming!” 

I couldn’t agree more.  When you clipboard inherits code from one part of your project to another, you are asking for future issues.  Oh sure, you remembered to change the instance in the code you are currently working on, but what about the other instances?  Now you have to trace bugs, since you explicitly remember fixing that piece of logic.  Unfortunately, the other copies of your code are usually the cause of the problem.

Modern refactoring tools like JustCode make it easy to turn code blocks into methods, enhancing maintainability by reducing duplication in code.

Don't Repeat Yourself image
DRY - Don’t Repeat Yourself – Motivator/Ardalis/CC BY

JustCode download banner image

About the Author

Phil Japikse

is an international speaker, a Microsoft MVP, ASPInsider, INETA Community Champion, MCSD, CSM/ CSP, and a passionate member of the developer community. Phil has been working with .Net since the first betas, developing software for over 20 years, and heavily involved in the agile community since 2005. Phil also hosts the Hallway Conversations podcast ( and serves as the Lead Director for the Cincinnati .Net User’s Group ( You can follow Phil on twitter via, or read his personal blog at


Related Posts