This little discussion was initially prompted by an old Information Week’s article of “Stay Ahead With Soft Skills” aimed at computer programmers and “techies”; however, while project management and such are great skills—especially in agile development–the most important skill is communication.

Communication

“Talking to people is good.”

Now, say it with me. That’s right, it didn’t hurt, did it?

In the days gone by (or so I’m told), programmers software developers fit the stereotypical mold: they sat in a room, were handed specifications, and typed code into a computer. When they ran out of a) time or b) requirements, the application was complete and then given to the user. There was very little interaction between actual developer and end customer.

Well, that doesn’t work anymore.

Software developers cannot work in a vacuum without interacting with the customers—the customers, as stated in the eXtreme Programming practices, are part of the team. Some organizations cling to the old, siloed practices, however, open communication is becoming common across many sectors.

No longer locked in a closet and force-fed requirements (and Cheetos); developers have a duty to understand the customer’s needs and wants and help them solve problems not simply, and blindly, code software.

In teamwork, silence isn’t golden, it’s deadly.

- Mark Sanborn

However, this is no simple task–the process of translating the domain specific language of the customer into technical specific and back again requires practice and a firm understanding of both sides.

The agile Planning Poker step is an excellent example of this change in communication. Planning Poker is a process where features or aspects of a piece of software are laid out and each team member rates the weight of it–from developers to designers to customers.

If you, as a developer, rate “adding a label to a screen” as a 1 and the customer rates it as a 7, that’s the time to ask why. This is usually where find out that the label has some sort of crazy 30 cross-referenced data tables insanity along with it and it’s better to find out earlier rather than on review.

Education

I’m a vocal advocate for life-long learning.

There is, however, a difference between education and learning. In my mind, education is the external process, learning is the internal process and they are mutually exclusive.

For example, I can sit all day in class (whether it’s a seminar at the local training company or a university course) and be educated. I can memorize facts, figures, procedures and go about my day. However, unless I internalize it–I create associations between what I was taught and what I knew–and apply it; I didn’t “learn” it.

Today’s developers are faced a rapidly changing landscape–new programming languages, tools, frameworks, and techniques come and go daily. To keep moving forward, developers must continue their learning.

For some, the cycle can be extremely frustrating and exhausting which, in some cases, leads some developers to dig their heels in and stop learning.

“I already know how to do that! Why do I need to know another way?!”

In my experience, those who dig in to what they know now, rather than looking to what they could learn, become pessimistic in their career and the development community in general.

One sure-fire way to stay creative: force yourself to learn something new.

- Harvey Mackay

Taking in the wealth of new information (languages, procedures, principles, soft skills) and transforming that information, then into knowledge (think of it in terms of an analyst taking data and turning it into information—relatively same concept).

Even if the classroom isn’t your idea learning, the internet is now filled with scores of information. Online universities (many even offering free courses), professional education centers like Pluralsight, and the countless blog posts just like this one on every subject imaginable. Reach out, discover, question, and learn.

Project Management

Finally, project management is an excellent “soft” skill. A firm grasp of waterfall, agile, or the flavor of the day methodology can empower an organization from being reactive into proactive.

However, for this, I’m not specifically pointing to a type of project management, but the core ability to convert a basic understanding of requirements and resources into an outline or timetable. As one of my mentors calls it–the art of guesstimating.

/ˈɡestəmət/

an estimate based on a mixture of guesswork and calculation

Where does that guesswork come from? Experience (and likely some pain and suffering).

In my opinion, being able to create an accurate guesstimate can help guide discussions from project start to finish.

The best guesstimates to be due to two factors:

1. You have an honest understanding of your infrastructure (current projects, upcoming projects, resources),
2. You have an honest understanding of yourself, your team, and its abilities.

From communicating that initial guesstimate comes the project management, learning, and then retrospecting–of which the guesstimate will be adjusted for the next project. Everything connects and loops from there as you grow as a software developer.

Photo by You X Ventures on Unsplash

This article is a rewrite and revisit of the topic based on an article I wrote 24 July 2007.