Am I a good developer?

A few years ago I had a telephonic interview with a recruiter who threw some technologies and terms at me that I hadn't heard before. I told him with confidence I was a fast learner, but he didn't seem impressed. He said "Well that's true of most developers. It goes with the territory." Suddenly all my 'skills' seemed pretty typical. Was I a good developer, or just an average one?



According to Paul Graham, you can't really know how good you are. Only your coworkers can tell you. That's kind of an interesting answer, because I do and I don't agree. I've seen coworkers congratulating each other on a job well done while they've failed miserably to follow the SOLID principles. Just because two people agree doesn't mean they can't both be wrong. On the other side of that, I have been really complimented by coworkers who I look up to and it always comes as a nice surprise to me to hear that I've done something well. It sometimes comes as a surprise to me when I've written something less than maintainable, and I rely on my coworkers often to see the things that I don't.




While there is some value in finding out if we're actually any good, it's far more useful to determine what we can do every day to become better developers. These are my five tips, in no particular order:

TIP #1: PAIR PROGRAMMING LIKE YOU MEAN ITAn XP practice, two people at the same workstation has several benefits. As my friend Ryan says at any opportunity, "GET IN THERE" (often referring to a rugby scrum or a hook-up he's trying to arrange). Don't be passive when pairing. If you don't agree with your pairing partner, do whatever it takes to figure out why the two of you don't agree. At least one of you is bound to learn something. But what we gain from pair programming isn't just the increased code quality. Being someone others like to work with is a very important part of becoming a good developer, so keep this in mind when you are pairing. Make a conscious effort to be the sort of coworker you think others would want to pair with. TIP #2: GO TO COMMUNITY EVENTSI know that some of them are at awkward times or held at inconvenient locations. I'm not going to pretend that it's easy to commit to attending events that either cut into work time or personal time. Please excuse me a sec, I just need to cancel my RSVP for tomorrow's lean coffee...I'm going to the gym because I'm fat. Okay, there, done. Where was I? Right. I can talk for ages on the things I know now that I hadn't heard of six months ago. Armed with knowledge, we can make better decisions. I've seen two great implementations of Service Bus in the last few months as a result of community events, prior to which I'd never heard the term before. How will we ever know if we can do things better if we don't even know what's out there? Knowledge is power. TIP #3: WORK FOR THE RIGHT COMPANY / LOVE YOUR WORK / PASSIONMy development manager when I worked at Comair was big on passion. On his e-mail footer was this great quote by Vince Lombardi Jr: "Unless you try to do something beyond what you have already mastered, you will never grow. Every job is a self portrait of the person who did it ... Autograph your work with excellence." Everyone at Driven Software, where I work now, is just as big on passion as they are on craftsmanship. I don't know about you, but I love being in an environment where people are passionate about their craft. It rubs off on me. It inspires me to make my every commit something I can be proud of today, and keeps me motivated to commit something I can be more proud of tomorrow. I want to contribute actively to the enthusiasm of my team. If you're not part of a team that makes you feel the way I do, then maybe you need to be the change you want to see in your team.TIP #4: COMMIT TO DOING SOMETHING THAT SCARES YOUFear of the unknown is such a great opportunity to learn something. Since finishing my studies, I had to really adjust to learning with purpose, as opposed to forced learning assisted by the threat of failing an exam. I initially struggled with motivation, but I'm enjoying finding new ways to push myself. What has worked for me is simply making a commitment to doing something scary. I've recently committed to being a scrum master alongside one of my colleagues for a group of people I haven't even met. It's scary for me. I've never been a scrum master. I don't even have an authoritative personality. I'm a follower, not a leader. While this isn't strictly in the realm of software development, I'm going to come out the other side of the experience knowing more than I did when I jumped into it. As a developer, you want to get out of your comfort zone from time to time so you can expand on the skills you have. Do you really want to look back in two years to find that you've just repeated everything you did in year one. I know how this feels, and I don't ever want to be there again. TIP #5: LISTEN, BUT FORM YOUR OWN OPINIONSListen to what people are talking about. Eavesdrop on pairing sessions happening on the other side of the office. Don't interrupt (I'm still working on this myself). When you have a quiet moment, reflect back on things you've heard and figure out whether or not you agree. It's great if your team agrees on most things, but in reality, a team of clones is a sign that something's wrong. One of the most interesting guys in my office only speaks to me every second or third week, but when he does, he says some interesting things. One thing he said to me recently while arguing against TDD and stand-up was "always have your own opinions". I realised after the friendly debate that I only had a few reasons to justify why I liked our team's stand-up. If the rest of my team decided tomorrow that they hated the board and stand-up was for the birds, I would end up going along with it because I haven't established enough of an opinion. To me, a good developer has his or her own opinions and doesn't just accept things for what they are. Respect the code base and the practices that were established before you joined the team, but don't be afraid to question why things were done a certain way in the past. And on that note, think about and share what you would do differently before you decide that you don't like something.That's it from me. Thanks to all of you who read my ramblings. I love the comments, so please don't be shy!
Full Post