Guru and Nubie

In Software by Rob, he explains the non-technical ways to improve as a develoeper. Like him, me also thinks that such an article is first of its kind. The 9 part article is a good read for all developers.

Part 1: Making Fans
Learning about your company and co-workers will dramatically improve the
software you build. One of the most important lessons I learned during the first year of my career is to be so nice to the people around you that they can’t help but become your biggest fans.

Part 2: Know your core competencies
What this means is “know what you do well and stick to it.” This doesn’t mean that you should never branch into new things. On the contrary,
you must constantly build on your core competencies or become outdated. But be smart about it.

When dealing with tasks completely outside your realm of knowledge expect to spend a lot of time researching, becoming familiar with the subject, and
learning it slowly as opposed to copying and pasting the first code sample you see.

Part 3: Enjoy the Panorama
Most programmers, by nature of our jobs, are highly focused individuals.While this trait can lead to periods of intense productivity, it tends to be less of a blessing when it comes to managing life.
How does having a panoramic view make you a better developer? The goal is to renew focus, intention, purpose, and a passion for life and work.
Here’s the list of questions I’m thinking about this time around:

Life
What do I like most about my life?
What do I like least?
What is my concept of the “ideal” life and how is mine different from
that?
What do I want my life to look like in 5 years?
What do I need to do to prepare for those changes?

Work

Am I happy with my job?
Do I get excited when I tell people about it?
Am I expanding my skills?
Are there skills I should be learning that I’m not?
Is there anything else I’d rather be doing?

Don’t live in a tunnel, never stopping to reflect on what you’re doing and why
you’re doing it. Taking the time to renew your focus and passion is a critical
part of becoming a better developer. And watch out, you may even find yourself turning into a better human being.

Part 4: Know what you’re building
There’s an old story that goes something like this:

A visitor arrives at an IT department and approaches a software developer. He asks him what he’s doing, to which the developer replies:

“Writing code.”

He walks to the next cubicle and asks the same question of another developer. He replies:

“Building a web page.”

He walks to the next cubicle and asks the same question of yet a third developer, to which she replies:

“Writing a piece of web-based software that will make it easier for our customer service reps to assist customers.”

Why are their answers so important?

•     Knowing Where You Fit Someone who knows what they’re building can see their place in the big picture.
  They realize the importance of their work and know without explanation why it’s important. If the application begins to crash in the production environment and someone comes running for the developer, won’t they have a greater sense of urgency if they know it’s affecting the company’s bottom line?

•     A Sense of Purpose People who know what they’re building have a sense of purpose. It makes them feel as if they are serving a greater good, whether that good is a single person, a department, or the entire company. Purpose makes people work a few extra hours to finish a project on time. Purpose makes developers take one more crack at fixing a hard to find bug.

•     If You’re a Developer Ask about the
  big picture. Find out why it’s so important that all of a sudden every button on the account summary page     has to be red instead of green. Ask your manager, his manager, or the guy in marketing. If you ask questions with an obvious posture of learning,     people will notice and appreciate the fact that you care.
• If You’re a Manager Educate your
  developers. Talk to them about what the company does from a broader perspective, and make them see why it’s so important that an application works. Show them how it helped generate a huge amount of revenue for the company, or how it allows the finance department to reconcile month end numbers in an hour instead of three days. At the beginning of every new assignment, ask them if they know what
  they’re building.

Part 5: Don’t use a dull knife
I don’t doubt that Emacs is a good editor (I used it for a few years back in the
early 90s, actually), but the bottom line is that as computer languages have
evolved so have the tools we use to work with them. There’s a reason we don’t build web applications with COBOL…it’s not the right language for the
job.

I know the learning curve of switching tools is painful, but in the long run you have to use tools that make you the most productive and that don’t
wreak havoc on the rest of your team. If you’ve used the same knife for
20 years there’s probably a sharper one out there.

Part 6: Become a Manager
Many of you gasped at the title of this post:

“Become a manager? Has he lost his mind?! I’ll be a coder ’til the day I die!”

I’m not implying that you should give up your coding gloves and step into the ranks of full-time management, but you gain incredible perspective about what makes good and bad developers once you’ve managed a few of them. Even if you never become a full-fledged supervisor, managing a project, being a technical lead, or running your own business are all suitable ways to experience what makes a “better” developer from a different angle.

And let me tell you, I learned more about what makes a good developer from a management perspective in my short tenure at the City, than in the previous two or three working as a consultant.
Lesson #1: What Makes Someone the
Best – One of the first things you’ll learn is who your best developers
are and why.
Lesson #2: It’s Easy to Complain about Your Boss Until You Have to Do His Job
Lesson #3: How to Self-Manage – As a supervisor you can’t get any work done unless your developers learn to be self-sufficient.
Lesson #4: Do What It Takes to Achieve
Results – Do what it takes to hit the deadline; don’t make your boss ask you, or worse, order you to stay late. As a developer you can read the writing on the wall and should know well in advance when you need to tell your spouse you’ll be late for dinner.
When it comes time to play, show up and get the job done.
Lesson #5: No Surprises – Surprises are never a good thing in the business world.I remember being told the day before launch that we weren’t going to hit the deadline. I asked how long they’d known about it and they said a week and a half. Ugh.
If your boss doesn’t require email updates, drop her a 1 or 2 sentence email twice a week letting her know what you did over the last few days and how things are going. I bet it will become standard practice for the entire group.

Walk a Mile in My Shoes
Even if you never become a manager, try to walk a mile in your boss’s shoes once in a while.
It won’t take long to realize how much you can learn from looking at your job
from a different perspective.

Part 7: The Jigzaw Puzzle
Your company is a massive jigsaw puzzle and each employee is a unique piece. Once a week go to a different department and ask someone to show you what they do. If they use software you’ve written, find out how they use it. If not, find out how they fit into the big picture of your organization.

The more you know about your co-workers, the more you’ll understand the puzzle. The more you understand the puzzle, the more indispensable you become.

Part 8: Know your Archetype
Developers come in many shapes and sizes, but over the years I’ve noticed a
handful of archetypes that we tend to embody. These archetypes are the
fundamental building blocks of who we are as developers, and two to three of
them exist in each of us in varying quantities. I’ve worked with a few people
who were 90% in a single area.

The archetypes are:

• Trainer/Author – spends the majority of his/her time teaching, training, writing articles and books, and otherwise helping others learn how to program.
• Coder – a hard-core developer. Into design patterns, the next cool and experimental language constructs, and talking about web service proxy generators.
• Lead – excellent organization skills, driven to make projects succeed, and skilled at leading others.
• Technologist – into all the new applications; would rather integrate than write code.

Take a minute to decide which two or three describe you best, and make a guess at the percentage of each. A trusted co-worker can easily verify or dispute your numbers. It’s not an exact science.

I’m 45% Coder, 35% Trainer/Author, and 20% Lead. However in my current position I tend to do a lot more Lead-based tasks with some Coder stuff thrown in. I’ve been doing the Trainer/Author portion in my spare time for the past several years.

The benefit of knowing your archetype is three-fold:

• Career Path - Realizing that you love to teach might make you think twice about taking a promotion requiring you to manage other developers in a deadline-driven environment. Similarly, if you are
  a technologist you might think about leaving your job as a corporate developer and applying at a product company where your desires could be more easily fulfilled.
• Strengths & Weaknesses - Knowing your strengths is critical to your career happiness. I realized long ago that I
  have very little desire to be a technologist, which, in retrospect,. explained
  my distaste for every integration project I’d ever worked on. As a result when
  it comes time to volunteer for project roles I’m on the other side of the room
  when people start talking about Biztalk.
• Your USP – Though the term “Unique
  Selling Proposition” (USP) typically applies to products, it can be applied to
  people. The idea is to find what differentiates you from the alternatives. Why
  should a company hire you (whether for full-time, contract, or consulting work)?
  There are hundreds of seemingly qualified candidates – what do you bring to the
  table that no one else does? Now is the time to specialize, so whatever your
  strong archetypes, focus on them and make your focus razor sharp. Make it so
  there is no competition.

Remember that no area is better than any
other. I used to be intimidated by people who knew more than I did about
software development until I realized that I had the edge in the areas of
writing and leadership. It’s not that my percentages made me better or worse
than that developer, it’s just a way of realizing that we each have strengths in
certain areas.

Part 9: How to Criticize a Software Developer Without Getting Punched

There comes a point in every person’s career when we have to offer criticism
of someone else’s work. For software developers and managers this can be
especially difficult since most programmers view the software they write as an
extension of themselves, and take criticism of that software very
personally.

We all know how to criticize, but the question is how to criticize
well.

Be Specific
The #1 rule of good criticism is be
specific.
Telling someone their code is “total crap” is not helpful. Telling them they
misspelled two variable names, have several place where they’ve repeated code,
and they need error handling in all of their methods is much more helpful. It
not only allows them to improve their current code, but perhaps it will help
them out in the future, as well. They still may get mad, but that’s up to
them.

It certainly takes more time to itemize mistakes, but it’s worth it.

Criticize the Code, Not the Person
If someone writes
crappy code, talk about the code, not about the person’s ability to
code. If someone doesn’t meet a deadline, talk about how that affected you and
what needs to happen in the future, don’t talk about how the person is a
complete slacker (at least not the first time you discuss it). Doing so will
help keep the conversation less personal.

Be Constructive
It’s easy to be negative. It’s easy to come into a situation and complain.
It’s easy to point out the flaws in everything (have you ever read the comments
on Digg or Slashdot?). If you don’t have a suggested solution in mind it’s going
to be difficult for people to respect your opinion. Someone who complains often
will be ignored rather quickly.

Constructive critisism is helpful; venting just pisses people off. Before you
criticize something stop to think if it really matters to you and needs to be
improved, and make sure you’re talking to the person who can do something about
it.

powered by performancing firefox