Professionalism

Reference: The Clean Coder - A Code of Conduct for Professional Programmers 
[Robert C.Martin]

Professionalism

Professionalism is a loaded term. Certainly it is a badge of honour and pride, it is also a maker of responsibility and accountability. It’s a lot easier to be non-professional. Nonprofessionals don’t have to take responsibility for the job they do—they leave that to their employers.

Professionalism is all about taking responsibility. How do we take responsibility?

• Do no harm—What harm can a software developer do? We can harm both function and structure.
• Work Ethic—Your career is your responsibility.

Do no harm

Do No Harm to Function

Clearly, we want our software to work. But we are not the only one, our customers and employers want to work too. We harm the function of our software when we create bugs. Therefore, in order to be professional, we must not create bugs. 

But software is too complex to create without bugs.

The fact that bugs will certainly occur in your code does not mean you aren’t responsible for them.

So, the first thing you must practice is apologizing. Apologies are necessary, but insufficient. You cannot simply keep making the same errors over and over. As you mature in your profession, your error rate should rapidly decrease towards asymptote of zero. It won’t ever get to zero, but it is your responsibility to get as close as possible to it.

QA Should Find Nothing

When you release your software you should expect QA find no problems. It is unprofessional in the extreme to purposely send code that you know to be faulty to QA.

What code do you know to be faulty?
Any code you aren’t certain about!

Some folks use QA as the bug catchers. They send the code that they haven’t checked. They depend on QA to find the bugs and report them back to the developers. Releasing code to QA that you don’t know works is unprofessional. 

Probably, QA will find bugs. So get ready to apologize, and then figure out why those bugs managed to escape your notice and do something to prevent it from happening again. Every time, QA or worse a user, finds a problem, you should be surprised, chagrined, and determined to prevent it from happening again.

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. Test it seven ways in Sunday!

Perhaps you are concerned that testing your code so much will take too much time. So, automate your test. Write unit test and run those test as often as you can. 

How much of the code should be tested with these automated unit test? All of it! All. Of. It.

But isn’t some code hard to test? Yes, 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 tests first, before you write the code that passed them. This is the discipline known as Test Driven Development (TDD).

Do No Harm to Structure

It is the structure of your code that allows it to be flexible. If you compromise the structure, you compromise the future. The fundamental assumption underlying all software projects is that software is easy to change. You must be able to change without exorbitant cost.

The only way to prove that your software is easy to change is to make easy changes to it. And when you find that the changes aren’t as easy as you thought, you refine the design so that the next change is easier.

Other thinks that making a continuous series of changes to working software is dangerous. No! What is dangerous is allowing the software to remain static. If you aren’t flexing it, then when you do need to change it, you will find it rigid.

Why do most developers fear to make continuous changes?— They are afraid they’ll break it? Why are they afraid they will break it?— Because they don’t have test. 

Work Ethic

Your Career is Your Responsibility

Your career is your responsibility. It is not your employer’s responsibility to make sure you are marketable. It is also not your employer’s responsibility to give you time you need to learn. 

You owe your employer a certain amount of time and effort (40 hours per week — US standard). 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 20 hours you should be reading, practicing, learning, and otherwise enhancing your career.

What about the family? life? Am I suppose to sacrifice them for my employer?— No, we are just talking about extra 20 hours per week. That’s roughly 3 hours per day. 
A week (24×7) = 168 hours. Give 40 to your employee, and your career 20. (168 – 40 – 20 = 108). 56 for sleep (8×7). 108 –  56 = 52. You have extra 7 hours per day for everything else.

Professionals spend time caring for their profession.

Know your Field

Do you know— Nassi-Schneiderman chart, different between a Mealy and Moore state machine. You should. Could you write a quick sort without looking it up? Do you know what the term “transform analysis” means? Could you perform a functional decomposition with Data Flow Diagram? What does the term “Tramp Data” mean? Have you heard the term “Conascence”? What is Parnas Table?

A wealth of idea, 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 sizeable chunk of it and constantly be increasing the size of that chunk. 

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

Minimal list of the things that every software professional should be conversant with: 

• Design patterns. You should be able to describe all 24 patterns in the GOF book and have a working knowledge of many of the patterns.
• Design Principles. You should know the SOLID principles and have a good understanding of the component principles.
• Methods. You should understand XP, Scrum, Lean, Kanban, Waterfall, Structured Analysis, and Structured Design.
• Disciplines. You should practice TDD, O-O design, Continuous Integration, Pair Programming.
• Artifacts. You should know how to use: UML, DFDs, Structure Charts, Petri Nets, State Transition Diagrams and Tables, flow charts, and decision tables.

Continuous Learning

The frenetic rate of change in our industry means that software developers must continue to learn copious quantities just to keep up. Architects who stop coding— they will find themselves irrelevant. Programmers who stop learning new languages— they will watch as the industry passes them by. The developers who failed to learn new disciplines and techniques— their peer will excel as they decline. 

Would you visit a doctor who did not keep current with medical journals? Would you hire lawyer who did not keep current with laws and precedents? Why should employers hire developers who don’t keep current?

Read books, articles, blogs. Go to conferences. Learn thing that are outside of your comfort zone. If you are .Net programmer learn java. If you are java developer learn Ruby. Go. Python.  

Practice

Professionals practice. True professionals work hard to keep their skills sharp and ready. 

Doing your daily job is performance, not practice. Consider how musicians master their craft. It’s not by performing. It’s by practicing. They do these over and over to train their fingers and mind, and to maintain mastery of their skill.

What could software developer do to practice? Frequently do the repetition of simple exercises (a simple programming problem to solve, e.g., the prime factor of an integer). The point of this exercise to train your finger and brain. Let’s call this Kata. Should do a kata or two every day. Should do it with the multiple languages that you might want to maintain your skill. Think of the kata as a 10-min warm-up exercise in the morning and a 10-min cool-down in the evening.

Know your Domain, Employer/Customer

It is responsibility of every software professional to understand the domain of the solutions they are programming. You don’t need to be a domain expert, but there is a reasonable amount of due diligence that you ought to engage in.

It is the worst kind of unprofessional behavior to simply code from a spec without understanding why that spec makes sense to the business. Rather you should know about the domain to be able to recognize and challenge specification errors.

Your employer’s problems are your problems. You need to understand what those problems are and work toward the best solutions. And need to make sure that the features that you are developing are really going to address your employer’s needs. It is 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 confidently commanding, in precise detail, the behaviours of a machine that could otherwise do incalculable damage. So, programming is an act of arrogance.

Professionals know they are arrogance and are not falsely humble. A professional know his job and takes pride in his work. A professional is confident in his abilities, and take bold and calculated risks based on that confidence. A professional is not timid. A professional also knows that there will be times when he will fail, his risk calculation will be wrong, his abilities will fall short. 

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 is not. He will not demean another for making a mistake, because he knows he may be next to fail.

A professional understands his supreme arrogance, and that the fates will eventually notice and level their aim. When that aim connects, the best you can do is … 

Saying NO

Professionals speak truth to power. Professionals have the courage to say no to their managers. 

How do you say no to your boss? It’s your boss. Aren’t you suppose to do what your boss says?— No. Not if you are professional. Slaves are not allowed to say no. Laborers may be hesitate to say no. But professionals are expected to say no. 

Indeed, good managers crave someone who has the guts to say no. It’s the only way you can really get anything done.

Adversarial Roles

Managers are people with a job to do, and most managers know how to do that job pretty well. Part of that job is to pursue and defend their objective as aggressive as they can.

Programmers are also people with a job to do, and most of them know how to get that job done pretty well. If they are professionals they will pursue and defend their objectives as aggressively as they can.

When your manager tells you that the login page has to be ready by tomorrow, he is pursuing and defending one of his objectives. He’s doing his job. If you know full well that getting the login page done by tomorrow is impossible, then you are not doing your job if you say “OK, I will try.” The only way to do your job at that point is to say  “No, that’s impossible.”

But don’t have to do what your manager say? No, your manager is counting on you to defend your objectives as aggressively as he defends his. That’s how the two of you are going to get to the best possible outcome. 

The best possible outcome is to find the goal that you and your manager share.

Being a Team Player

Being a team player means playing your position as well as possibly can, and helping out your teammates when they get into a jam. A ten-player communicates frequently, keep an eyes out for his or her teammates, and executes his or her own responsibilities as well as possible. 

A team player is not someone who says yes all the time.

Trying

Do; or do not. There is no trying.

Do you have an extra reservoir of energy that you’ve been holding back? If you apply these reserves, will you be able to meet the goal? Or, by promising to try are you simply setting yourself up for failure?

By promising to try you are promising to change your plans. After all, the plans you had were insufficient. And you are saying that you have a new plan. What is that new plan? What change will you make to your behavior? What different things are you going to do because now you are trying?

If you are not holding back some energy in reserve, if you don’t have new plan, if you aren’t going to change your behavior, and if you are reasonably confident in your original estimate, then promising to try is fundamentally dishonest. You are lying. And you are doing it to save your face and to avoid a confrontation.

Summary

Most of the time we want to say yes. Indeed, healthy teams strive to find a way to say yes. Manager and developers in well-run team will negotiate with each other until they come to a mutually agreed upon plan of action. 

Sometimes, the only way to get to the right yes is to be unafraid to say no.

Saying “YES”

A Language of Commitment

There are three parts to making a commitment.

1. You say you’ll do it
2. You mean it
3. You actually do it

But how often do we encounter other people who never go all the way with these three stages:

• You ask the IT guy why the network is so slow and he says “Yeah, we really need to get some new routers.” And you know nothing will ever happen.
• You ask a team member to run some manual test before checking in the source code, and he replies, “Sure, I hope to get it by the end of the day.” And somehow you feel that you’ll need to ask tomorrow if any testing really took place before check-in.
• Your boss says “we have to move faster.” And you know he really means you have to move faster. He’s not going to do anything about it.  

There are very few people who, when they say something, they mean it and then actually get it done. There are some who will say things and mean them, but they never get it done. And there are far more people who promise things and don’t mean to do them. 

Recognising Lack of Commitment

Here are some examples of words and phrases to look for that are telltale signs of non-commitment:

• Need/Should: “We need to get this done.” “I need to loose weight.” “Some one should make that happen.”
• Hope/Wish: “I hope to get this done by tomorrow.” “I wish I had time for that.”
• Let’s (not follow by “I..”): Let’s meet some time. Let’s finish this thing.

As you read these words you will see that you start spotting them almost everywhere around you, and even in things you say to others. We tend to be very busy not taking responsibility for things. And that’s not ok when you or someone else relies on those promises as part of the job.

How does Commitment Sound Like?

You always have something that’s under your control, so there is always something you can fully commit to doing. That sound like this: I will … by … (e.g., I will finish this by Tuesday.)

What’s important about this sentence? You’re starting a fact about something you will do with a clear end time. You’re not talking about anyone else but yourself. You’re talking about an action that you will take.

You are taking full responsibility for something, in front of someone else. It’s you facing another person, and saying you will do it. That’s the start of commitment. Putting yourself in this situation that force you to do something.

You’ve changed the language you use to a language of commitment, and that will help you get through the next two stages: meaning it, and following through.

Summary

Creating a language of commitment may sound a bit scary, but it can you solve many of the communication problems programmers face today— estimations, deadlines, and face-to-face communication mishaps. You will be taken as a serious developer who lives up to their world.

Professionals are not required to say yes to everything that is asked. However, they work hard to find creative ways to make “yes” possible. When professionals say yes, they use the language of commitment.

Coding

Coding is intellectually challenging and exhausting activity. It requires a level of concentration and focus. The reason for this is that coding requires you to juggle many competing factors at once.

Your code must work. You must understand what problem you are solving and understand how to solve the problem. You must ensure that the code you write is a faithful representation of that solution. You must manage every detail of that solution while remaining consistent with the language, platform, current architecture, and all the warts of the current system.

Your code must solve the problem set for the customer. Often the customer’s requirements do not actually solve the customer’s problems. It is up to you to see this and negotiate with the customer to ensure that the customer’s true needs are met.

Your code must fit well with the existing system. It should not increase the rigidity, fragility, or opacity of the system. The dependencies must be well managed. Your code need to follow solid engineering principles.

Your code must be readable by other programmers. That is not simply a matter of writing nice comments. It requires that you craft the code in such a way that it reveals your intent. This is hard to do. This may be the most difficult thing a programmer can master.

Juggling all these concerns is hard. It is physiologically difficult to maintain the necessary concentration and focus for long periods of time. The opportunity for distraction is high. 

When you cannot concentrate and focus sufficiently, the code you write will be wrong. It will have bugs. It will have the wrong structure. It will be opaque and convoluted. It will not solve the customers’ real problem. In short, it will have to be rework or redone. Working while distracted creates waste.

If you are tired or distracted, do not code. You’ll only wind up redoing what you did, find a way to eliminate the distractions and settle your mind.

Have you ever write a program until middle of night or around 2/3 am?— It makes you easily go to the flow zone. It makes you easily accept all the solutions coming out from your mind even if they are not good enough or does not solve the problem fully.

Have you ever gotten into a big fight with your spouse or friend, and then tried to code? Did you notice that there was a background process running in your mind trying to resolve, or at least review the fight? Have you ever found yourself with eye on the screen and finger on the keyboard, doing nothing? Ideally the time spent wrestling with personal issues would be personal time. It would be shame to spend an hour at the office this way. You should specifically set aside time at home to settle your anxieties so that you don’t bring them to the office. On the other hand, if you find yourself at the office and the background anxieties are sapping your productivity, then it is better to spend an hour quieting them than to use brute force to write code that you will just have to throw away later (or worse, live with).

Flow Zone

It is the highly focused, tunnel-version state of consciousness that programmers can get into while they write code. This state of consciousness is not really hyper-productive and is certainly not infallible. It’s really just a mind meditative state in which certain rational faculties are diminished in favor of a sense of speed. And you will feel a mild euphoria or a sense of conquest.

The problem is that you lose some of the big picture while you are in the Zone, so you will likely make a decisions that you will later have to go back and reserve. Code written in the Zone may come out faster, but you’ll be going back to visit more.

Interruptions

Visualize yourself as you are coding at your desktop. How do you respond someone asks you a question?  Do you snap at them? Do you glare? Does your body-language tell them to go away because you are busy? In short, are you rude? Or, do you stop what you are doing and politely help someone? Do you treat them as you would have them treat you?

The rude respond often comes from the Zone. You may resent being dragged out of the Zone, or you may resent someone interfering with your attempt to enter the Zone. Sometimes, it is just that you are trying to understand something complicated that requires concentration. 

There’re several solutions:

• Pairing can be very helpful as a way to deal with interruptions. Your pair partner can hold the context of the problem at hand.
• TDD is another big help. If you have a failing test, that test holds the context of where you are. 

Of cause there will be interruptions that distract you and cause you to lose time. When they happen, remember that next time you may be the one who need to interrupt someone else. So professional altitude is a polite willingness to be helpful.

Being Late

You will be late. It happens to the best of us. It happens to the most dedicated of us. Sometimes we just blow our estimates and wind up late.

The trick to managing lateness is early detection and transparency. The worst case occurs when you continue to tell everyone, up to the very end, that you will be on time— and then let them all down. Instead, regularly measure your progress against your goal, and come up with three fact-based end dates: best case, nominal case, and worst case. Update these number daily. 

Do not incorporate hope into your estimate. Hope is the project killer. Hope destroys schedules and ruins reputations. Hope will get you to deep trouble. Don’t let anyone else have hope.

Rush

What if your manager sits you down and asks you to try to make the deadline? What if your manager insists that you “do what it takes”?— Hold to your estimates! Do not be tempted to rush. 

There’s no way to rush. You can’t make yourself code faster. You can’t make yourself solve problem faster. If you try, you’ll just slow yourself down and make a mass that slows everyone else down, too.

Overtime

So your boss says, “What if you work extra two hours a day? What if you work in Saturday?”Overtime can work, and sometimes it is necessary. Sometimes you can make an impossible date by putting in some ten-hour days and a Saturday or two. 

But this is very risky. You are not likely to get 20% more work done by working 20% more. And overtime will certainly fail if it goes on for more than two or three weeks.

Therefore you should not agree to work overtime unless:

• you can personally afford it
• it is short term, two weeks or less
• your boss has a fall-back plan in case the overtime effort fails.

False Delivery

The worst of all is saying you are done when you know you aren’t. Sometimes this is just an overt lie, but that’s bad enough.

But the far more insidious case is when we rationalise a new definition of “done”. We convince ourselves that we are done enough, and move on to next task. We rationalise that any work that remains can be dealt with later when we have more time. When a team falls into this trap, manager hears that everything is fine, everyone is on time. Nobody sees the unfinished work bearing down on them until it is too late. 

Help

Helping Other

Programming is so hard, in fact, that is beyond the capability of one person to do it well. No matter how skill you are, you will certainly benefit from another programmer’s thoughts and ideas.It is the responsibilities of the programmers to be available to help each other. Your work is not so important that you cannot lend some of your time to help others.

You should be conscious of the status of your teammates. If someone who appears to be in trouble, you should offer help (fresh perspective can be a profound catalyst for solving problems.)

When you help someone, sit down and write code together. You will likely come away having learned more than you gave.

Being Helped

When someone offers to help you, be gracious about it. Do not push the help away because you are under the gun. Give it thirty minutes or so. If by that time the person is not really helping all that much, then politely excuse yourself and terminate the session with thanks. 

Learn how to ask for help. Call for help. This is the matter of professional ethics. It is unprofessional to remain stuck when help is easily accessible.

Mentoring

The training of less experienced programmers is the responsibility of those who have more experience. Nothing can bring a yong software developer to high performance quicker than his own drive, and effective mentoring by his seniors. It is a matter of professional ethics for senior programmers to spend time taking younger programmers and mentoring them. Those younger programmers have also a personal duty to seek out such mentoring from their senior.