Tag: Mentoring

Mentoring

Podcast Episode 14 – Mentoring

Mentor Episode 14 of the Pete on Software Podcast is out and this week, I’m sharing my thoughts on mentoring. The word mentor has been watered down to just mean people that you want to look up to and emulate. To me, a mentor relationship is a two way street and unless you are having personal interactions with your “mentor” on a regular basis, you’re doing it wrong.

To top it off, when looking to find potential mentors, we may be barking up the wrong tree in terms of finding what we really need. I don’t spend any time talking about why you need a mentor, because I felt that everyone knows why they need to have their own Yoda or Mr. Miyagi.

You can also subscribe to the podcast at any of these places:

Thanks to all the people who listen, and a special thanks to those who have rated me. I really appreciate it.

The episodes have been archived. Click Here to see the archive page.

Mentoring

On Helping Other People

Life Preserver A very common objection that I hear that keeps people from teaching others is that the person feels that they aren’t “expert” enough to teach someone else. Any while I don’t doubt that the person lacks the credentials to be an “expert”, they do have some life experience to share.

The way I heard it described the other day on The Podcast Answer Man (link to episode) was that it is more about where each person is in their life. As an adult, I don’t see a 6th grader as having a wealth of knowledge. However, to a 4th grader, the 6th grader has a lot of valuable answers and experience to share.

All of you have at least a “6th grade level knowledge” about something. Go out and be a hero to someone who is at that 5th grade level or below. As long as you are honest about where you’re at and what your story is, you aren’t a fraud or a phony. Everyone is a beginner at some point. There is nothing wrong with an “advanced beginner” or higher turning around and helping those on the trail behind them.

Excuses are a crutch. If you feel compelled to help others, just do it. Start a blog, start a podcast, speak at user groups… whatever gets you excited. Your content won’t be for everyone, but – NEWS FLASH – no content pleases everyone. If someone is too advanced for your content, then they aren’t in your core audience. As long as you didn’t promise an advanced session, don’t worry about it.

Now go create!

Craftmanship

The Number One Trait of a Great Developer

After reading this article that I saw on Hacker News some time ago, it really got me thinking. The gist of the post is that “Great Judgement” is the number one trait of a great developer.

There are a lot of developers who only want to do the “latest and greatest” thing. They practice what I like to refer to as RDD, which stands for Resume Driven Development. Every project is just a way to make their resume that much more enviable. It is even a little hard to fault these people at first blush because in the IT industry, if you aren’t pressing your skills forward, you are quickly becoming irrelevant. However, sometimes developers forget that they are being paid to deliver a solution for a client or employer. The client’s needs should always come first.

Are you doing work for a PHP and MySql shop? Could Ruby or Node or Cassandra help them solve their problem? Sure, but their existing code is in PHP, their on-staff developers know PHP, and finding PHP developers to hire is easier than finding a good developer who knows Node or Cassandra. You may very well be doing them a huge disservice by building them a “blazing fast web scale” solution.

That’s where Great Judgement comes in. New technologies may offer benefits, but there are always trade-offs in technology. The first is your own knowledge. If you are very familiar with C# and .Net and don’t know Ruby, but you try to put together a Ruby on Rails solution for a client that isn’t mandating Ruby, you are very likely going to cost them time and money while you deliver more slowly, let alone any mistakes you are sure to make or hard-to-maintain patterns you might leave behind because of your inexperience.

The second trade-off is the number of available developers to maintain and build upon your code. The system may really hum when you write it in Brainf*ck, but you just pretty much made sure that there are maybe 30 people in the world who could help that company maintain or grow it. Larger companies aren’t as susceptible to this as smaller companies because they usually have rigid standards in place, but the “market” for your code – be it the language, the framework, or even your patterns – should be at the forefront of your mind as you plan.

The third trade-off is not to over-engineer. Some developers want to create a highly robust and scalable system with a caching layer, failover clusters, and load balancing for every one of their solutions. They want a pluggable architecture and a side of fries with that. The problem is that they are making a small inventory application for the secretary to maintain her office supply levels for a staff of 9. Sad to say, but a simple Access database that would take an hour of your time to create may be all that they need.

I haven’t thought enough to actually assign Great Judgement as the number ONE trait of a great developer, but I definitely have to agree with the author, Tammer Saleh, on many of his points. If Great Judgement isn’t number one, it is certainly in the team picture. If you use Great Judgement, you are a long way to delivering valuable solutions to your clients and that may improve your resume way more than buzzwords.

Mentoring

Why Be Passionate?

Malcolm Gladwell - Image from http://en.wikipedia.org/wiki/File:Malcolmgladwell.jpg
“Absent love for your field, you can’t be a genius. You can’t.”– Malcolm Gladwell

Scott Hanselman posted this quote on the Internet last week and it really resonated with me. It is no secret that I work in an industry full of “geniuses” and we were all most likely the smartest kids in our schools and among our relatives. Some of us (full disclosure: I can definitely be guilty here) still like to occasionally hold a somewhat lofty view of ourselves among the ranks of “the geniuses”.

Mr. Gladwell has written some very good books about ideas, intuition, and observation. I generally enjoy his writing and here I believe he is right on. I keep coming into contact more and more with developers who are not passionate about what they do. By not being passionate, they are doing their employers and themselves a disservice by not maxing out their genius potential. There are several reasons for this lack of passion – I’d like to focus on two.

The first group to consider may have at one time been passionate developers, but have since burned out. I know for a fact that this is fairly common and have come close to burnout a few times myself. Preventing burnout is a broad topic for perhaps another post, but it is beyond our scope here. I don’t think that I’m breaking new ground to suppose that burnt-out developers aren’t blazing the genius trail.

Our second group is made up of those developers who only do this because they were pressed into service at their jobs or they entered this profession because it pays well. If these people suddenly became wealthy, coding is not how they would spend their time. What that means is they are likely also not spending their free time on this craft.

I’m not claiming that individuals in either group are bad people. They are not. At the same time, however, I believe that individuals who don’t love their field will never attain guru/ninja/genius status. You cannot just put in your 8 hours and expect to be on that “next level”. This goes for lawyers, physicists, and therapists, too. If you aren’t putting in your own time reading journals, blogs, attending seminars, or just “thinking the big thoughts”, you aren’t going to grow.

The bright side is that this love can be cultivated. Much like marital love, you can rekindle your love for your craft. The same principles even apply. A common recommendation in marriage counseling is that you really get to know your spouse. Find out things about who they are and who they’ve become that you didn’t know. Fall in love all over again.

In development, that means finding out different things about programming that you didn’t know before. For instance, if you’ve only ever done middle tier work, learn the UI. If you’ve only programmed application code, learn the database. If you’ve only ever worked the Microsoft stack, give Open Source technologies a try. Make the field new, exciting, and alive again.

Even if you are someone for whom life or finances has guided toward technology, you also have hope. Much like individuals in arranged marriages can “learn to love” or “grow to love” their spouses, you can learn to love your profession. Like the last group, branch out and find a niche you are passionate about. Computer science is a very broad profession. You may find you love writing compilers, embedded systems, device drivers, mobile applications, web, rich media, etc. However, if you only ever log your hours and go home, you’ll never know what is beyond your 9 to 5.

I don’t want to sound preachy, but I truly felt compelled to write when I read that quote. Remember the old adage that when you point one finger, you have the rest of them pointing back at you. I write as much for my current and future self as I do for my readership. While I am “on fire” and “in love” with programming now, the natural ebb and flow of life may take that away from me. When it does, my natural desire to compete and be great are going to remind me of this post and I will have to heed my own advice and find something new that excites me.

I hope you have something that excites you, too.

Mentoring

Extracurricular Learning

Being a lifelong learner, I believe that what I call “Extracurricular Learning” is very important. I define that as any learning that you do outside of your job or school either for fun or to better yourself due to your own drive or passion. Maybe you like to use books, or screencasts, or conferences, but you actively make learning your own responsibility.

Some developers that I know or have run across are really into JIT (just-in-time) learning. They fly by the seat of their pants and, as Jeff Atwood puts it, “page fault” in knowledge. I am by no means against learning things as you go along. If you don’t do that, you are probably a pretty terrible developer. However, I think that if you don’t do some preparation in advance, you won’t be as good at “page faulting” your knowledge as you could be.

Let’s imagine that I’m working in Ruby for the first time. I may google ruby loop or something to figure the syntax of how to do a loop. Or, let’s say I need to do some task X. What I’m likely to do as a .Net programmer is to think of how I’d do it in C# and then google for the way to do X-C#-Thing in Ruby.

What would be better is if I had immersed myself in this technology ahead of time. I don’t mean become an expert before you begin, I am talking about doing due diligence before getting involved. If I have read Why’s Poignant Guide to Ruby and watched a few TekPub videos about Ruby and attended a few Columbus Ruby Brigade meetings, then I would have a very broad overview of how to “do” Ruby. And while I wouldn’t be an expert, it would make my google-fu so much better because my searches could be targeted toward getting me the *right* information.

As I’m getting more and more into Asp.Net MVC 2 for a project at work, I find the “leg work” that I did watching the TekPub videos and reading blogs to be invaluable. If I hadn’t done the Extracurricular Learning, I probably would have attempted a lot of WebForms inspired nonsense instead of finding out about how much “magic” is available to me via the built-in framework. Much like Rails, I can get Asp.Net MVC to do a lot of work for me (especially when combined with jQuery) if I just know how to rely on the scaffolding/convention over configuration inherent in the product.

I’m not wrong on this. If you want to be a great developer, you need to be involved in Extracurricular Learning. If you aren’t, you will stagnate and be guilty of “writing FORTRAN in any language”.