Chapter 1 - Professionalism

Professionalism is all about taking responsibility. As people say with greater powers comes great responsibilities. Although professionalism is a badge of honour, When a professional person makes a mistake, he has to evolve it himself. But when a non-professional one does, a professional one will solve it instead of him.
Some people learn about taking responsibility by suffering through the consequences of not taking it.
Automating testing is essential as when the code gets bigger it is harder and time-consuming to test every part manually.

We harm the function of our software when we create bugs. Therefore, in order to be professional, we must not create bugs. So you must be responsible for your imperfections (and being imperfection is a normal thing as you can't prevent bugs from appearing).
As you mature in your profession, your error rate should rapidly decrease towards the asymptote of zero.
You should be certain about all code you release and strongly expect QA to find nothing wrong with it. So you must test your code more than one time covering the whole code.

You owe your employer a certain amount of time and effort. These hours should be spent on your employer’s problems, not on your problems.
It is fine not to spend extra time on your profession (for example learning a new language), but you should not then think of yourself as a professional. Professionals spend time caring for their profession.

Some things that every software professional should be conversant with:

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

True professionals work hard to keep their skills sharp and ready. It is not enough to simply do your daily job and call that practice.
Doing your daily job is performance, not practice. Practice is when you specifically exercise your skills outside of the performance of your job for the sole purpose of refining and enhancing those skills.
Some pieces of Advice :

• Collaborate with other people.
• Professionals take personal responsibility for mentoring juniors.
• 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 to laugh.

Chapter 2 - Saying No

The most important time to say no is when the stakes are highest. The higher the stakes, the more valuable "No" become.
When the cost of failure is so high that the survival of your company depends upon it, you must be absolutely determined to give your managers the best information you can. And that often means saying " No".

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

The promise to try is an admission that you’ve been holding back, that you have a reservoir of extra effort that you can apply. The promise to try is an admission that the goal is attainable through the application of this extra effort; moreover, it is a commitment to apply that extra effort to achieve the goal. Therefore, by promising to try you are committing to succeed.

Chapter 3 - Saying Yes

There are three parts to making a commitment :

1. You say you’ll do it.
2. You mean it.
3. You actually do it. So, professionals won't stop after the first two steps.
   

Professionals are not required to say "Yes" to everything that is asked of them. However, they should work hard to find creative ways to make “Yes” possible. When professionals say "Yes", they use the language of commitment so that there is no doubt about what they’ve promised.

We should look at the language we use when we commit to doing something, as the telltale sign of things to come. Actually, it’s more a matter of looking for specific words in what we say. If you can’t find those little magic words ("need", "should", "hope", "wish", "let's" (not followed by “I . . .”)), chances are we don’t mean what we say, or we may not believe it to be feasible.

It’s easy to say you’ll get a lot done on the weekends, it’s a lot harder to actually muster enough energy to do high-quality work.
Professionals know their limits. They know how much overtime they can effectively apply, and they know what the cost will be.

So, Professionals are not required to say "Yes" to everything that is asked of them. However, they should work hard to find creative ways to make “Yes” possible.
When professionals say "Yes", they use the language of commitment so that there is no doubt about what they’ve promised.

Chapter 4 - Coding

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

Don’t write code when you are tired. Dedication and professionalism are more about discipline than hours. Make sure that your sleep, health, and lifestyle are tuned so that you can put in enough good hours per day.

Professional developers allocate their personal time in order to ensure that the time spent at the office is as productive as possible. That means 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’ll just have to throw away later (or worse, live with).

One of the big benefits of pair programming is that it is virtually impossible for a pair to enter the Zone. The Zone is an uncommunicative state, while pairing requires intense and constant communication.

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 needs to interrupt someone else. So the professional attitude is a polite willingness to be helpful.
Make sure you take in enough creative input, e.g. reading fiction books. Find out what works for you.

Debugging time is just as expensive to the business as coding time is, and therefore anything we can do to avoid or diminish it is good.
Whether you adopt Test Driven Development (which will be discussed later) or some other discipline of equal efficacy, it is incumbent upon you as a professional to reduce your debugging time as close to zero as you can get. Clearly zero is an asymptotic goal, but it is the goal nonetheless.

The trick to managing lateness is early detection and transparency. The worst case scenario occurs when you continue to tell everyone, up to the very end, that you will be on time—and then let them all down.
Make sure that the team and the stakeholders understand the situation, and don’t let up until there is a fall-back plan.

You should not agree to work overtime unless :

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

it is the responsibility of programmers to be available to help each other. It is a violation of professional ethics to sequester yourself in a cubicle or office and refuse the queries of others.

Chapter 5 - Test Driven Development

First, TDD = Test Driven Development.
There is an important question you must ask yourself: "How can you get automated unit tests with very high coverage without practising TDD?"

The Three Laws of TDD :

1. You are not allowed to write any production code until you have first written a failing unit test.
2. You are not allowed to write more of a unit test than is sufficient to fail—and not compiling is failing.
3. You are not allowed to write more production code that is sufficient to pass the currently failing unit test

TDD is not a religion or a magic formula. Following the three laws does not guarantee any of these benefits. You can still write bad code even if you write your tests first. Indeed, you can write bad tests.
There are times when following the three laws is simply impractical or inappropriate. These situations are rare, but they exist. No professional developer should ever follow a discipline when that discipline does more harm than good.

Chapter 6 - Practicing

Practising is not a new concept in software development, but we didn’t recognize it as practising until just after the turn of the millennium.

Doing anything quickly requires practice. Spinning around the code/test loop quickly requires you to make very quick decisions. Making decisions quickly means being able to recognize a vast number of situations and problems and simply know what to do to address them.

Programming kata is a precise set of choreographed keystrokes and mouse movements that simulates the solving of some programming problem.
You aren’t actually solving the problem because you already know the solution. Rather, you are practising the movements and decisions involved in solving the problem.

Professional programmers practice on their own time. It is not your employer’s job to help you keep your skills sharp for you. It is not your employer’s job to help you keep your resume tuned.

In one way or another, all professionals practice. They do this because they care about doing the best job they possibly can. What’s more, they practice on their own time because they realize that it is their responsibility—and not their employer’s—to keep their skills sharp.
Practising is what you do when you aren’t getting paid. You do it so that you will be paid well.

Chapter 7 - Acceptance Testing

The customers' vision of the features does not often survive actual contact with the computer.

The more precise you make your requirements, the less relevant they become as the system is implemented.

The solution to premature precision is to defer precision as long as possible. Professional developers don’t flesh out a requirement until they are just about to develop it. However, that can lead to another malady: late ambiguity.

Professional developers have a single definition of done which means all of these :

• all code is written.
• all tests pass.
• QA and the stakeholders have accepted.

Typically business analysts write the “happy path” versions of the tests because those tests describe the features that have business value. QA typically writes the “unhappy path” tests, the boundary conditions, exceptions, and corner cases. This is because QA’s job is to help think about what can go wrong.

As a professional developer, it is your job to negotiate with the test author for a better test. What you should never do is take the passive-aggressive option and say to yourself, “Well, that’s what the test says, so that’s what I’m going to do.”

Make sure that all your unit tests and acceptance tests are run several times per day in a continuous integration system. This system should be triggered by your source code control system.

Communication about details is hard. This is especially true for programmers and stakeholders communicating about the details of an application. It is too easy for each party to wave their hands and assume that the other party understands. All too often both parties agree that they understand and leave with completely different ideas.

The only way the author knows of to effectively eliminate communication errors between programmers and stakeholders is to write automated acceptance tests. These tests are so formal that they execute. They are completely unambiguous, and they cannot get out of sync with the application. They are the perfect requirements document.

Chapter 8 - Testing Strategies

QA and Development should be working together to ensure the quality of the system. The best role for the QA part of the team is to act as specifiers and characterizes.

Professional developers employ the discipline of Test Driven Development to create unit tests. Professional development teams use acceptance tests to specify their system, and continuous integration to prevent regression. But these tests are only part of the story. As good as it is to have a suite of unit and acceptance tests, we also need higher-level tests to ensure that QA finds nothing.

The Test Automation Pyramid

Types of Tests :

• Unit Tests.
• Component Tests.
• Integration Tests.
• System Tests.
• Manual Exploratory Tests.

Acceptance Tests are valuable ways to express and enforce requirements. But they are only part of a total testing strategy. To make good on the goal that “QA should find nothing,” development teams need to work hand in hand with QA to create a hierarchy of unit, component, integration, system, and exploratory tests. These tests should be run as frequently as possible to provide maximum feedback and to ensure that the system remains continuously clean.

Chapter 9 - Time Management

There are two truths about meetings :

1. Meetings are necessary.
2. Meetings are huge time wasters.

You do not have to attend every meeting to which you are invited. Indeed, it is unprofessional to go to too many meetings. You need to use your time wisely. So, be very careful about which meetings you attend and which you politely refuse.

One of the most important duties of your manager is to keep you out of meetings. A good manager will be more than willing to defend your decision to decline attendance because that manager is just as concerned about your time as you are.

Clearly, you should not storm out of a meeting exclaiming “This is boring!” There’s no need to be rude.

While the meeting is in session. Each participant takes a turn to answer three questions:

1. What did I do yesterday?
2. What am I going to do today?
3. What’s in my way?

The author chosen form of physical focus is bike riding. He also uses the Pomodoro Technique.
The real benefit of the Pomodoro Technique is the 25-minute window of productive time that you aggressively defend against all interruptions.

Professionals evaluate the priority of each task, disregarding their personal fears and desires, and execute those tasks in priority order.

Blind alleys are a fact of life for all software craftsmen. Sometimes you will make a decision and wander down a technical pathway that leads to nowhere.
The more vested you are in your decision, the longer you will wander in the wilderness. If you’ve staked your professional reputation, you’ll wander forever.

Professionals are always on the lookout for messes that start to grow without bound, and will expend all necessary effort to escape from them as early and as quickly as possible.

Software professionals are diligent in the management of their time and their focus. They understand the temptations of priority inversion and fight it as a matter of honour. They keep their options open by keeping an open mind about alternate solutions. They never become so vested in a solution that they can’t abandon it. And they are always on the lookout for growing messes, and they clean them as soon as they are recognized.
There is no sadder sight than a team of software developers fruitlessly slogging through an ever-deepening bog.

Chapter 10 - Estimation

A commitment is something you must achieve. If you commit to getting something done by a certain date, then you simply have to get it done by that date. Professionals don’t make commitments unless they know they can achieve them.

Professionals draw a clear distinction between estimates and commitments. They do not commit unless they know for certain they will succeed. They are careful not to make any implied commitments. They communicate the probability distribution of their estimates as clearly as possible so that managers can make appropriate plans.

The author thinks that If you are a programmer with more than a few years of experience, you’ve likely seen projects that were estimated optimistically, and that took three to five times longer than hoped.
Software professionals are very careful to set reasonable expectations despite the pressure to try to go fast.

The most important estimation resource you have are the people around you. They can see things that you don’t. They can help you estimate your tasks more accurately than you can estimate them on your own.

An implication of this law is that if you break up a large task into many smaller tasks and estimate them independently, the sum of the estimates of the small tasks will be more accurate than a single estimate of the larger task. The reason for this increase in accuracy is that the errors in the small tasks tend to integrate out.

Professional software developers know how to provide the business with practical estimates that the business can use for planning purposes. They do not make promises that they can’t keep, and they don’t make commitments that they aren’t sure they can meet.

When professionals make commitments, they provide hard numbers, and then they make those numbers. However, in most cases, professionals do not make such commitments. Rather, they provide probabilistic estimates that describe the expected completion time and the likely variance.

Professional developers work with the other members of their team to achieve consensus on the estimates that are given to management.

Chapter 11 - Pressure

The best way to stay calm under pressure is to avoid the situations that cause pressure. That avoidance may not eliminate the pressure completely, but it can go a long way toward minimizing and shortening the high-pressure periods.

What we must do is to make sure that the risk is quantified and presented to the business so that they can manage it appropriately.

Professionals do not succumb to the temptation to create a mess in order to move quickly. Professionals realize that “quick and dirty” is an oxymoron. Dirty always means slow!

Choose disciplines that you feel comfortable following in a crisis. Then follow them all the time. Following these disciplines is the best way to avoid getting into a crisis. Don’t change your behaviour when the crunch comes. If your disciplines are the best way to work, then they should be followed even in the depths of a crisis.

Let your team and your superiors know that you are in trouble. Tell them your best plans for getting out of trouble. Ask them for their input and guidance. Avoid creating surprises. Nothing makes people angrier and less rational than surprises. Surprises multiply the pressure by ten.

Chapter 12 - Collaboration

There are plenty of programmers who are good at working with people and enjoy the challenge. But the group average still tends in the direction I stated. We, programmers, enjoy the mild sensory deprivation and cocoonlike immersion of focus.

It’s good to be passionate about what we do. But it’s also good to keep your eye on the goals of the people who pay you.

The first responsibility of the professional programmer is to meet the needs of his or her employer. That means collaborating with your managers, business analysts, testers, and other team members to deeply understand the business goals. This doesn’t mean you have to become a business wonk.

So, professional programmers take the time to understand the business. They also talk to users about the software they are using.

Professional developers do not prevent others from working on the code. They do not build walls of ownership around code. Rather, they work with each other on as much of the system as they can. They learn from each other by working with each other on other parts of the system.

Professionals also pair because it is the best way to share knowledge with each other. Professionals don’t create knowledge silos.

There are times when working alone is the right thing to do. There are times when you simply need to think long and hard about a problem. There are times when the task is so trivial that it would be a waste to have another person working with you.
General, it is best to collaborate closely with others and to pair with them a large fraction of the time.

Chapter 13 - Teams and Projects

It makes no sense to tell a programmer to devote half their time to project "A" and the rest of their time to project "B", especially when the two projects have two different project managers, different business analysts, different programmers, and different testers.

It takes time for a team to form. The team members start to form relationships. They learn how to collaborate with each other. They learn each other’s quirks, strengths, and weaknesses. Eventually, the team begins to gel. There is something truly magical about a gelled team.

The project manager tracks the progress of the team, and makes sure the team understands the schedules and priorities.

Professional development organizations allocate projects to existing gelled teams, they don’t form teams around projects. A gelled team can accept many projects simultaneously and will divvy up the work according to their own opinions, skills, and abilities.

Chapter 14 - Mentoring, Apprenticeship, and Craftsmanship

Many specialities require yet another one to three years of fellowship in which the student continues specialized training and supervised practice.

Craftsmanship is the mindset held by craftsmen. Craftsmanship is a meme that contains values, disciplines, techniques, attitudes, and answers.

School can teach the theory of computer programming. But school does not, and cannot teach the discipline, practice, and skill of being a craftsman. Those things are acquired through years of personal tutelage and mentoring. The author sees that it is time for those of us in the software industry to face the fact that guiding the next batch of software developers to maturity will fall to us, not to the universities.

Thank you, and goodbye.