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.
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.
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.
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. 2010Feb08_0123.jpg/Jerome T/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. [127/365] Immersed/pasukaru76/CC BY
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. DRY - Don’t Repeat Yourself – Motivator/Ardalis/CC BY
Philip 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 (www.hallwayconversations.com) and serves as the Lead Director for the Cincinnati .Net User’s Group (http://www.cinnug.org). You can follow Phil on twitter via www.twitter.com/skimedic, or read his personal blog at www.skimedic.com/blog.
Copyright © 2002-2016 Telerik. All rights reserved.
Powered by Telerik