Be careful what you ask for

Professionalism is a loaded term. Certainly it is a badge of honor and pride, but it is also a marker of responsibility and accountability. The two go hand in hand, of course. You can't take pride and honor in something that you can't be held accountable for.

When a professional makes a mistake, he cleans up the mess. Professionalism is all about taking responsibility. So how do we take responsibility?

First, do no harm

What harm can a software developer do? From a purely software point of view, he or she can do harm to both the function and structure.

Do no harm to function

We harm the function of our software when we create bugs. Therefore, in order to be professional, we must not create bugs.

Of course, software is too complex to create without bugs. Unfortunately, that doesn't let you off the hook. The human body is too complex to understand in its entirety, but doctors still take an oath to do no harm.

The fact that the task to write perfect software is virtually impossible does not mean you aren't responsible for the imperfections.

The first thing you must practice is apologizing. They are necessary but insufficient. As you mature in your profession, your error rate should rapidly decrease towards the asymptote of zero. It won't ever get to zero, but it's your responsibility to get as close as possible to it.

QA should find nothing

When you release a software you should expect QA to find no problems. It is unprofessional in the extreme to purposely send code that you know to be faulty to QA. And a faulty code is any code you aren't certain about.

You must know it works

How can you know your code works? That's easy. Test it. Test it again. Test it up. Test it down. You should test all your code. I'm not suggesting it, I'm demanding it.

But if you spend all your time testing, you'll never get anything else written. So, automate your tests.

Some code is hard to test, but only because that code has been designed to be hard to test. The solution to that is to design your code to be easy to test. And the best way to do that is to write your test first before you write the code that passes them (Test Driven Development).

Of course, some systems are so mission-critical that a short automated test is insufficient to determine readiness for deployment. On the other hand, as a developer, you need a quick and reliable mechanism to know that the code you have written does not interfere with the rest of the system.

Do no harm to structure

The true professional knows that delivering function at the expense of the structure is a fool's errand. It's the structure of your code that allows it to be flexible. If you compromise the structure, you compromise the future.

The fundamental assumption underlying software projects is that software is easy to change. You must be able to make changes without exorbitant costs. If you want your software to be flexible, you have to flex it.

When you find that the changes aren't as easy as you thought, you refine the design so that the next change is easier.

And when you make these easy changes? All the time! Every time you read through the code you adjust the structure. Making continuous changes to working software is not dangerous. Dangerous is allowing the software to remain static.

Most developers fear to make continuous changes because they're afraid they'll break it! And they are afraid because they don't have tests.

Work ethic

Your career is your responsibility. It's not your employer's responsibility to make sure you are marketable. It's not your employer's responsibility to train you or to send you to conferences or to buy you books. Woe to the developer who entrusts his career to his employer.

Also, it's not your employer's responsibility to give you the time you need to learn. You should plan on working 60 hours per week. The first 40 are for your employer. The remaining 20 are for you. During this remaining time, you should be reading, practicing, learning, and otherwise enhancing your career.

Perhaps you don't want to make that kind of commitment. That's fine, but you should not then think of yourself as a professional. Professionals spend time caring for their profession.

Perhaps you think this is a recipe for burnout. On the contrary, it's a recipe to avoid burnout. Those 20 hours should be fun. You should be doing those things that reinforce your passion for development.

Know your field

A wealth of ideas, disciplines, techniques, tools, and terminologies decorate the last fifty years of our field. How much of this do you know? If you want to be a professional, you should know a sizable chunk of it and constantly be increasing the size of that chunk.

Very few ideas of the past 50 years have become irrelevant. Some have been sidelined, it's true. But it doesn't mean we shouldn't know what it is, and what its good and bad points are.

Those who cannot remember the past are condemned to repeat it.

As a software developer, you should be conversant with design patterns, design principles, methods, disciplines and artifacts.

Continuous learning

The frenetic rate of change in our industry means that software developers must continue to learn copious quantities just to keep up. Woe to the architects who stop coding. Woe to the programmers who stop learning new languages. Woe to the developers who fail to learn new disciplines and techniques.

Read books, articles, blogs, tweets. Go to conferences. Go to user groups. Participate in reading and study groups. Learn things that are outside your comfort zone.

Practice

Professional practice. Doing your daily job is performance, not practice. Practice is when you specifically exercise your skills outside the performance of your job for the sole purpose of refining and enhancing those skills, like a musician.

Collaboration

The second best way to learn is to collaborate with other people. Professional developers make a special effort to program and practice together, to design and plan together. By doing so they learn a lot from each other, and they get more done faster with fewer errors.

Mentoring

The best way to learn is to teach. Nothing will drive facts and values into your head faster and harder than having to communicate them to people you are responsible for.

Know your domain

It's the responsibility of every software professional developer to understand the domain of the solutions they are programming.

When starting a new project in a different domain, read books on the top, interview your customer and users about the foundation and basics of the domain. Spend some time with the experts, and try to understand their principles and values.

You should know enough about the domain to be able to recognize and challenge specification errors.

Identify with your employer/customer

Your employer's problems are your problems. You need to understand what those problems are, put yourself in his or her shoes, and work toward the best solution to delivery.

It's easy for developers to identify with each other. It's easy to fall into an us versus them attitude with your employer. Professionals avoid this at all costs.

Humility

Programming is an act of creation. When we write code we are creating something out of nothing. We are boldly imposing order upon chaos. we are confidently commanding. And so, programming is an act of supreme arrogance.

Professionals know they are arrogant and are not falsely humble. They know their job, their ability, and take bold and calculated risks based on that confidence.

However, a professional also knows that there will be times when he will fail, his risk calculations will be wrong, his abilities will fall short, he'll look in the mirror and see an arrogant fool smiling back at him.

So when a professional finds himself the butt of a joke, he'll be the first to laugh. He will never ridicule others but will accept ridicule when it is deserved and laugh it off when it's not. He will not demean another for making a mistake, because he knows he may be the next to fail.

Next article: #2 Saying No