The folks at lifehacker asked a simple question on their site the other day "Programmers: What Does It Take to Be a Developer (Other than Coding)?". I love questions like this as it takes the conversation away from the religious wars of language syntax and looks at the other, important facets that make a good developer. My focus on teaching and improving ALM and Agile methodologies on dev teams has me asking this question quite often. To find the answers for a specific team, I tend to break down almost all Software Development dysfunctions into three main areas:

I have found that these three areas are the best filters to use to start to decompose developer and team issues to find the immediate, short and long term goals for continuous improvement.

People (Interpersonal Skills)

How to Listen to Business Context

Most of what I do as a consultant is listening. I'm IT Therapy. I help the client talk through their problems and find a solution that fits their current (or desired) situation with an eye toward continuous improvement. Not every developer is going to be a consultant, however we should all learn to listen to our customer (no matter who they are) and try to lay out their problem in the context of their business before we map the problem to a technical solution.

How To Listen to the Problem WITHOUT jumping to a Solution

Resist the urge to go straight to the hammer, even if the problem is a nail. Ask questions, offer functional solutions without talking about technology at all and help the client to feel that they are a part of the solution.

How to handle the Rejection of an Idea without taking it Personally

Sometimes in our industry even the best ideas have to take a back seat to other pressures. We can't use the best technology solution, we can't work in a desired timeline, we are hardpressed to use specific workflows or User Interface choices. No matter the compromise, no matter the rejection, we are there to serve the solution, and as a team we work to find the best overall solution given the time, team and technologies we have at the moment.

How to Say "I don't Know"

As a technologist you must check your ego at the door every morning. You will learn more through humility and honesty than you will by thinking that you have all the answers. Learn to admit when you don't know and make sure that you never have to repeat yourself on the same topic twice.

I've written about the power of Yes, AND! to development and creativity, and I will reiterate here that the ability to listen, agree and create as a team will give you and your team an edge that is hard to overcome.

Process (Patterns and Practices)

Sometimes, though, it IS about your knowledge and practice. I like the idea of Code Kata; small exercises that you repeat using different techniques and patterns to get the patterns and practices in grained in your head.

Gang of Four Design Patterns

These patterns are the basis for just about all enterprise level software development and have been implemented and discussed in just about every language applicable to their implementation.

Common Patterns of today's App Dev

No discussion about modern design patterns would be complete without at least referencing Uncle Bob's SOLID design principles.

How to Estimate their own capacity on a given task OR how to check one's ego at the development door

Along with being able to say "I don't know", be comfortable giving an honest assessment of your ability against a specific task. If you don't know anything about a specific technology, be honest with yourself and your client. They will thank you and learn to trust your ability to estimate as long as you maintain honesty and transparency throughout your process.

Time Management

It would be nice if we could work on only the tasks that most interested us or that were the most exciting in our jobs. Unfortunately, in our business, there is a lot to do along with code, and the ability to manage your time across multiple tasks and plan your activity wisely is key to your continued success. From TPS reports, to design and business meetings; being able to plan your day and activities will make your life easier in so many ways.

Finally, know when to walk away from a problem. Know when to get up, walk over, and talk a problem or idea through with a colleague or random hallway dweller. Sometimes just talking out loud about a technical problem will reveal the solution.

NO QA SURPRISES!!!

A Developer is responsible for his code, and should be the first person to test it; this includes, but is not limited to, unit testing. Unit and Integration tests are the first line of quantifying the correctness of our code, and therefore are the responsibility of the developer as a part of the deliverables to any QA process or team to prove or disprove the correctness of the delivered code. A Developer should never be surprised by bugs or errors found in their code, should have a clear understanding of the weak areas of his code and have tests that prove their understanding. A builder uses a Measure, Square and Level to prove correctness, and a developer uses Unit and Integration Tests.

Unit Testing

Products (Technology)

How to use Source Control

I don't really care which is your favorite or which you pursue, but you need to understand how to work in a source control environment, what it means to have a branching strategy and how to work and play well with others in this environment. A clear understanding of Continuous Integration and even continuous delivery would be helpful, but Enterprise developers should always begin in source control.