Page 1 of 17

Professionalism

Definition

It is a sacred term; it might mean honor and pride, but it is about responsibility and accountability.

Principles

• Easy to be non-professional
  • If a professional makes a mess, he cleans it (as simple as that).

Taking Responsibility

1. Do not swarm to function

   • Try to not introduce bugs.
   • Be accountable for errors by apologizing.

2. QA should find nothing

   • Don’t send faulty code to QA as this is lazy and irresponsible.

3. Know how it works

   • Know it by testing.
   • 100% unit testing → Learn TDD.

4. Automated QA

   • Execution of unit & acceptance/integration tests.

5. Do not swarm to structure

   • Code must be able to make changes without exorbitant cost.
   • If there are no easy changes, make it easy by redesigning → Learn "merciless refactoring".
   • Tests become important so you are not afraid.

---

Page 2 of 17

Accountability

Work Ethic

• Career is self-responsibility.
• Learning, marketing, sending to conferences, buying books.
• Time to do these things is self.
• 40 hours spent on employer’s problem, some on your rest → Relax, practice learning.
• Professionals spend time caring for professionalism.
• Don’t get burnout; it should be fun.

Know Your Field

• Know a sizeable chunk of your field.
• Design patterns (all 24), Design principles, Methods (XP, Scrum, Waterfall)
• Disciplines (TDD, OOP, Structured Prog., CI)
• Artefacts (UML, DFDs, Tables, Flow charts) at the very minimal.

Continuous Learning

• Read books, articles, blogs, tweets, conferences, study groups.

Practice & Collaboration

• Program, practice, design & learn together.

Mentoring

• Teaching, communicating.

Know Thy Domain

• Don’t be a domain expert, but know what makes sense.
• Understand what challenges are there & collect specific abilities.

---

Page 3 of 17

Identify With Your Employer/Customer

• Employer’s problems are your problems.
  • Make them fix it.
• Don’t fall into "us versus them" attitude.

Humility

• Programming is an act of supreme arrogance, so professionals are arrogant but not falsely humble.
• But professionals understand arrogance & fate will level their aim.
  • Accept mistakes, don’t ridicule others & accept ridicule by self when deserved.

---

Page 4 of 17

Saying No

Importance

• Should not be allowed to say "no".
  • Laborers may be hesitant to say "no".
  • Professionals are expected to say "no".

Presence of Adversarial Roles

1. Managers do their job to pursue & defend their objectives as aggressively as they can.
2. Employees/programmers know how to get jobs done & they define their objectives as aggressively as they can.

Negotiation

• Best possible outcome is a goal that both you & manager share; find that goal through negotiation.

Example: Asking for a Feature

• Dev should know how much time it would take.
• Manager should confront how much time it would actually take.
• Dev should assert for timelines.
• Manager should assert their objectives.

Avoid Micro-Management

• "Why?" isn’t really required. It is good to know detail, but too much detail is a recipe for "micro-management".

---

Page 5 of 17

II. High Stakes

• Higher the stakes, higher the valuable no becomes → higher the value becomes.
• Don't cave in: Do the right thing or being wise early.

---

III. Being a "Team Player"

1. Play your position well as you possibly can & help out teammates.
2. Communicate frequently, keep an eye out for fellow teammates, and execute self-responsibility.
3. "Trying" means you were holding back, and by choosing to try, you are committing to succeed.
   • If you don't get the desired outcome, you fail.
4. "Passive Aggression" can be used to say no. Refer to the chapter.

---

IV. Code Impossible

• Good code is not impossible, and dropping an professional → professional disciplines is not the way to solve problems.
• Professionalism is not impossible.

---

Page 6 of 17

Saying Yes

1. Language of Commitment

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

2. Change What You Say

• Words like:
  • need/should → is a commitment.
  • hope/wish → is not a commitment.
  • let's → implies uncertainty.
• If words mean they are out of my hand, it usually means non-commitment.
• Take responsibility by committing to something that's under your control. Example: I will do X by Y.

---

II. Meaning It

• No. of reasons where you might not mean it:
  1. Rely on person X to get this done.
     • If you don't have full control, you can't commit. Instead, you can:
       • Sit down with partner teams to understand your dependencies.
       • Create an interface that abstracts your module's dependency from other team's inputs.
       • Meet at least 3 times a week to make sure your changes work well.
     • Commit to specific actions that bring you closer to the end goal.
  2. It wouldn't work because I don't know if it can be done.
     • Again, try to commit actions that will bring you closer to the target:
       • Go through 25 bugs & execute them.
       • Spend all time working on fixing each bug.
  3. It wouldn't work because sometimes I just won't make it.
     • If unexpected things happen, change expectations ASAP.
       • Raise red flags early to wherever you're committed.
       • Communicate:
         • Tell people if late for meetings.
         • If a bug is not solvable or critical, raise concern with the team ASAP.

This will help in estimation, delivery deadlines & face-to-face miscommunication. You will be considered "serious."

---

Page 7 of 17

Coding

I. Prepare for Coding

• Understand what problem you are solving & how to solve that problem:
  • It should solve the customer problem.
  • It should fit well into existing systems & it should be readable.

To achieve this, follow some things:

1. Don't work when you are tired.
2. Set aside personal time to worry about stuff.
3. Zone or flow zone can make you do things that you are not supposed to → overachieve/over-engineer.
4. Interruptions happen, deal with it.
5. Sleep, worry, fear & depression can make you go paralyzed while coding. (Pair programming helps.)
6. Code for creative input like books, art.

---

II. Debugging

• Use TDD to reduce debugging time.
  • Reduce bugs.
• Know when to log off; don't try when tired or discouraged.
• Maintain status/progress so people don't accuse of being late.
  • Don't incorporate "HOPE."

---

Page 9 of 17

Help

• Programming is hard, so be available to help each other.
• Be conscious of the status of your teammates:
  • If someone seems stuck, help them.
  • Resign yourself to tasks and give it a solid effort.
• If helped, be gracious about it. Do not protect your turf → territory.
• Mentoring is required by senior programmers to drive efficiency → effectiveness.

---

TDD (Test-Driven Development)

Three Laws to Be Followed:

1. You are not allowed to write production code until you have first written a failing UT (Unit Test).
2. You are not allowed to write more of a UT 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 UT.

Workflow Cycle:

flowchart LR
    WriteCode --> TestThatFails --> FixCode --> WriteTestPasses

---

Page 10 of 17

Benefits

• Certainty in the code that it will always work.
• Defect injection rate is super low.
• If you have a suite of tests that you trust, you lose all fear of making changes, which means easy code.
• UTs (Unit Tests) are the documents of a function.
• Lead to better decoupled designs & so you can't write tests later.

---

Page 11 of 17

Practicing

• Every professional rehearses their skills.
• Quickly doing something requires practice:
  • Make decisions quickly.
  • Know how to address them.
• Broaden your experience by contributing to:
  • Open Source.
  • Practice Ethics.

---

Acceptance Testing

Communicating Requirements

• Business people state what they believe they need.
• Programmers build what they believe the business described.

Issues:

• Both parties are tempted to fall into the trap of premature precision:
  • Business wants what they will get before audit project.
  • Devs want what they are supposed to deliver before estimating.

---

Page 12 of 17

Challenges in Estimation

• Uncertainty:
  • Business people might not be certain what they want unless they see it.
  • Developers think that estimates require precision, but even with precision, estimates have huge variance.

Solution: Acceptance Tests

• Clear out the ambiguity using acceptance tests:
  • The purpose is communication, clarity, and precision.
  • By agreeing to them, the devs, stakeholders, and testers all understand the plan for the system behavior.
  • Automate it.

Writing Tests:

• These tests should be written later. These are at the UI level or API level.

---

Page 13 of 17

Testing Strategies

Writing good tests is one thing, but what the development team needs is a good testing strategy.

• QA is not an enemy but part of the team.
• QA should find nothing.
• QA should come up with acceptance tests.
• QA should characterize the behaviors of the testing system.

Testing Pyramid

graph TD
  xunit[Unit Tests - 100%]
  abi[Component Tests - 50%]
  abi2[Integration Tests - 20%]
  sys[System Tests - 10%]
  exp[Exploratory - 5%]

  xunit --> abi
  abi --> abi2
  abi2 --> sys
  sys --> exp

---

Time Management

• SCRUM, Sprint Plan:
  • Sprint end (45 mins):
    • 20 mins → Retro
    • 25 mins → Demo

Tips:

• Utilize mornings for work and unplanned tasks.
• Allocate time for gym and other activities.

Dealing with Avoidance:

• Productivity Inversion: This is a lie we tell ourselves.
• Blind Alleys: Stop digging when in one.
• Mouse, Dog, Subnets & Other Messes: Go back and fix the mess.

Tip: Don't become invested in one solution.

---

Page 14 of 17

Estimation

Business views estimates as commitments, whereas dev views estimates as guesses.

Key Points:

• Commitment: Something you must achieve. It's a bounded function where commitments are made based on an already defined model.
• Professionals: Don't commit unless they are certain.
• Estimate: A guess when there are no promises, usually made because we don't know how long something will take.

Probability Distribution:

Types of Estimates:

1. O (Optimistic Estimate): If everything is right. Chance of occurrence: 1 day.
2. N (Nominal Estimate): Estimate with the greatest chance of success. 3 days.
3. P (Pessimistic Estimate): Includes everything wrong except natural disasters. 12 days.

Mean Formula:

$$M = \frac{O + 4N + P}{6} \approx 4.2 \, \text{days}$$

Standard Deviation:

$$\text{SD} = \frac{P - O}{6} \approx 1.8 \, \text{days}$$

---

Page 15 of 17

Pressure

Like a doctor in open-heart surgery, you need to be calm and decisive under pressure.

I. Avoid Pressure:

• Avoid commitments that can't be met.
• Stay clean (don't create mess) and keep design/code clean.
• In crisis, follow disciplines you believe in as a professional.

II. Handle Pressure:

• Don't panic; manage your stress and sleep well.
• Communicate that you are in trouble and ask for guidance.
• Trust your disciplines.
• Cut sleep by following up.

---

Page 16 of 17

Collaboration

Collaboration vs:

• People: We have to.
• Employees: We have to (they pay).
• Programmers: Cannot code.

Ideal Collaboration:

• There should be collective ownership.
• Do not build walls.
• Don't create knowledge silos.

---

Teams and Projects

• It isn’t possible for a dev to work X percent on Project A and Y percent on Project B. It doesn't just work.
• Teams take time to form:
  • Relationships in the team.
  • Collaboration in the team.

Gelled Team Composition:

• Consists of a dozen people and should contain:
  • Programmers.
  • Testers.
  • Analysts.
  • Project Manager.

Formation Timeline: To become a "gel" team, it takes about 6 months to a year. Once created, let them stay together.

---

Page 17 of 17

Mentoring, Apprenticeship, and Craftsmanship

Team Dynamics

• Team comes first, then the project.
  • Don't dissolve the team when the project is completed.

Mentoring, Apprenticeship, and Craftsmanship

Key Observations:

• Colleges don't teach programming well.
• Either you self-learn or use the help of proper titles.

---

I. Mentoring

• Can be unconventional:
  • Reading
  • Observing

II. Apprenticeship

1. Masters

   • 10+ years of experience
   • Senior Software Engineer (SSE)

2. Journeymen

   • 5 years of experience
   • Supervised by masters
   • Software Development Engineer 2 (SDE 2)

3. Apprentices/Interns

   • Guided by journeymen
   • Should last a year

III. Craftsmanship

• Skill and quality

---

References & Related Topics

• Books: "The Clean Coder" by Robert C. Martin
• Related Topics: TDD, XP, Agile methodologies, software testing, refactoring, design patterns.