The Professional Software Developer

 What does it mean to be a professional?

In my view, a professional is an individual who is competent and well aware of his field. His estimates and advice are reliable and he always stands by his commitment. His own reputation and that of his employer are of paramount importance to a professional.

Unlike other professional fields such as law, medicine, education and so on, software development is relatively new and is growing at a haphazard and rampant rate.

So… is there any difference when we apply this definition of a professional to a software development arena?

In my view, there is.

Software developers have to deal with unique challenges which makes being a professional a little difficult, these challenges are such as:

1)      Understanding the requirement of the customer, which may change during the development of the product.

2)      Providing a reliable estimate of when a product will be delivered. Since the estimation involves evaluating code complexity, testing strategy and risk factors, this can be a little difficult to get right

3)      Coding is a very creative art. You cannot always apply some formulae or refer some literature and expect the logic to come out. This makes coders vulnerable to pressures when they are stuck on some problem.

So… how can a software developer become a professional?

I recently read a book “The Clean Coder by Robert C. Martin” that has addressed these exact questions.

I liked the simple way in which the author drew from his extensive personal experience in the field and expressed some of his views of what it means to be a software professional.

Mostly for my reference, I am summarizing his 200 page book below. As an added bonus, I hope this provides some insights/perspective to the other readers of this blog as well :) .

 ·        The Professional

o   Personal Traits & Habits

§  Understanding Your Expertise

§  Responsibility and Ethics

§  Collaboration

§  Sharpening Your Skills

§  Pacing Yourself

§  Handling Pressure

§  Time Management

o   Tools / Techniques

§  Practice

§  Test Driven Development : TDD

§  Coding : Best Practices

§  Testing Strategy

§  Estimates

§  Teams

 

Personal Traits & Habits of a Software Development Professional

Understanding Your Expertise

•       Are you an :

•       Apprentice

Fresh out of college, needing lots of guidance and collaboration.

•       JourneyMan

Trained, competent and energetic individuals with around 5 years of work experience. They mentor appentices and train them . After the apprenticeship they judge and recommend the appointment of the apprentice.

•       Master :

These are individuals with more than 10+ years of experience. They are familiar with more than one platform. They are up to date with the latest in their field.

•       Craftsman :

Experienced and competent individual who makes reliable estimates and meets his commitment. A craftsman is a professional and a role model. Craftsman is a meme that contains values, disciplines, techniques, attitudes and answers.

•       Having recognized one’s experience level, it is important to seek out proper mentors. The mentors should in turn take the lesser experienced individuals under their wing and guide them as needed.

•       Institutions can hardly prepare an individual to become a professional in the industry. This knowledge of the trade has to be bred into the individual by proper mentorship.

•       One can learn by watching and seeking guidance from more experienced individuals.

Responsibility and Ethics

•       Your career is your responsibility. It is not your manager’s responsibility to monitor and manage your career. Define clear goals that you want to achieve and seek your manager’s support in helping you meet those goals.

•       A professional holds a personal responsibility to meet his commitments. In failure to do so, he does not depend on his manager / employer to clean up the mess, but takes care of things himself.

•       Understand the business and its motivation and how your work contributes to its success.

•       Be humble about feedback and help.

•       Be clear in communicating estimates, concerns and design.

•       Take time out to help fellow colleagues, so that you do not appear rushed.

•       Be confident of your skills.

Collaboration

•       When blocked on a piece of activity or when under pressure to meet a deadline, it is good to ask / accept help. In case you find the help to not be very useful, politely excuse yourself and seek out the right contact.

•       In a team it is important to be aware of your teammate’s status. In case you find a team mate to be in need of help, step in. Always plan your time before helping a team mate, you do not want to spend so much time that you affect your work, and you don’t want to appear rushed that you cannot provide any meaningful help either.

•       A good way to collaborate is to pair program. Among its several benefits are the following :

•       During interruptions, the pair partner helps to retain context.

•       Pair programmer helps to make sure that the code design / hygiene is being maintained.

•       Sometimes, when facing a block, just having a pair programmer gives the perspective to better understand and solve the problem at hand.

•       When working for a team, the code should be looked at as a collaborative shared property.

•       Another aspect of collaboration is to continuously sync and coordinate with the stakeholders to understand business requirements.

Sharpening Your Skills

•       Stay hungry for knowledge,

•       Do you know the following :

•       What is Nassi-Schneiderman chart?

•       Difference between Mealy and Moore state machine?

•       Can you write quicksort without looking it up?

•       What is transform analysis?

•       Can you do a functional decomposition with a Data Flow Diagram?

•       What is Tramp Data?

•       What is Conascence?

•       What is Parnas table?

•       Design patterns : GOF book, POSA books

•       Design principles : SOLID principles

•       Methods : XP, Scrum, Lean, Kanban, Wterfall, Structured Analysis, Structured design

•       Disciplines : TDD, OOD, Structures Programmin, Conitnuous integration, pair programming

•       Artifacts : UML, DFDs, Structure charts, PetriNets, State transition diagrams and tables, flow charts, decision tables.

If not, then why not ?

•       Broaden your experience. Explore into other areas, contribute to Open Source.

•       Expose yourself to a lot of creative input because creativity breeds creativity.

•       Make sure that you do not use your employer’s time for your personal development.

Pacing Yourself

•       If you are a software engineer, and seek to be a professional, then you are in the game for the long race. It is better to pace yourself rather than burn out and fall into mediocrity.

•       Make a commitment only if you are confident you can meet the estimates. Even if you have to put in extra effort, be ready to do that in order to meet your commitments.

•       Avoid going into the zone. Although it seems like the zone is a good place to be in, it has a few shortcomings such as the following :

•       When in a zone, you are extremely sensitive to interruptions such as a colleague asking for help or a meeting.

•       Sometimes the zone provides a false sense of confidence which may lead to ignoring best practices which the team otherwise follows.

•       You don’t have to be in the zone to get quality work done.

•       Avoid distractions such as music. Of course this is a subjective opinion.

•       Be polite to interruptions. Either postpone the discussion or make time to resolve the issue at hand.

•       Don’t be tempted to rush in, provide sound estimates. We all want to be heroes of the coding arena, but its best to be realistic when providing estimates. These estimates should be made keeping in mind our work-life balance decisions.

•       Don’t forget to rechargeJ . All work and no play makes Bill a robot...

Handling Pressure

•       Avoid getting hung up on coding problems, get a good night’s rest and deal with it the next day.

•       Avoid worry code. If there is a personal issue bothering you, first take care of it or put it on hold.

•       Hang on to your good practices even during crisis.

•       Avoid passive-aggression, agreeing now and not supporting the decision later. If you agree to a decision made by a team, do everything in your power to make that decision successful.

•        Long hours at work does not imply dedication.

•       Pair program when under pressure and blocked.

•       Do not agree to overtime unless :

•       You can afford it

•       It is short term

•       Your employer has a fall back plan

If the employer does not have a backup plan then do not make the commitment.

•       Do not do false delivery. This means that in order to appear to have met a deadline, do not fall short on your product’s requirement.

•       Communicate. If you see an issue or an unexpected delay, raise a red flag immediately so that the team can cope with the issue and make alternative plans.

Time Management

•       Meeting ethics :

•       Accept a meeting if it’s agenda has relevance to you.

•       If the agenda is of relevance to you but is not concerned with your current work, deprioritize it.

•       The goal and agenda of a meeting should be clearly defined.

•       Pomodoro Technique :

•       Allocate a fixed number of minutes for dedicated work.

•       After every work period, take a break of another fixed amount of time.

•       After 4 work periods, take a longer break.

•       Any interruptions faced during your work period can be postponed to a break time / another work period.

•       Avoid Priority Inversion. Sometimes, when we are faced with a work task that we are not interested in, we start giving other minor tasks more priority than the main task at hand. This is called priority inversion.

Tools / Techniques

Practice

•       With experience one must strive to reduce error rate in their work.

•       Train your fingers and brain. Do a 10 min warm up before starting work and a 10 minute cool down after work. This warm up / cool down could be any well-known solved program.

•       Coding dojo :

•       Kata : drive a well-known problem into your sub conscious, learn hot keys, navigation techniques.

                Refer : http://katas.softwarecraftsmanship.org

                                http://codekata.pragprog.com

•       Wasa : a partner writes UT and then you make it pass. Then reverse roles.

•       Randori : a person writes a test, the next person makes the test pass and writes a new test, so on and so forth.

•       It is important to practice in your own time, not your employer’s time.

Test Driven Development

•       Three laws of TDD :

•       First write a failing test

•       Do not write more of a UT than is required to fail

•       Do not write more production code than is needed to make the previously written UT pass, repeat the cycle.

•       Benefits of TDD :

•       Certainty that the written code is working.

•       Reduced defect injection rate. Since we can test the entire code after each build.

•       Gives courage to modify code, especially if the UT provide 100% code coverage.

•       Easier documentation of the entire code.

•       Good design since due to the nature of the UT ( the three rules mentioned before ), every component can exist independent of the other.

Coding : Best Practices

•       It is important to not introduce rigidity into the code. Code and its structure should be flexible.

•       Keep refactoring.

•       100% code test coverage using techniques such as TDD, helps to maintain confidence while flexing the code.

•       Before writing production code, first do the following :

•       Understand the problem you are trying to solve.

•       Find the approach to solve it.

•       See if the solution fits into the existing system.

•       See if the solution is readable.

•       Debugging is a part of coding, the time spent on debugging should be reduced and optimized as much as possible.

•       Sometimes we go deep into a technical solution only to realize it’s a dead end and doesn’t solve the intended problem. It is important to recognize blind alleys and try to back off as soon as possible with proper communication.

•       When confronted with a mess, try to fix it now rather than add to it and leave it for fixing later.

•       Believe in collective code ownership and refrain from protecting one’s turf.

Testing Strategy

•       QA should find nothing. That should be the goal.

•       The following are the different type of tests :

•       UT

These specify the system at the lowest level.

•       Component Testing / Acceptance Testing

These are written against individual components of the system, each of which represent a business rule.

•       Integration Testing( written by architects/ dev leads, run less frequently )

They have meaning for large systems that have many components. They do not test business rules but rather, they test if the components are able to intercommunicate.

•       System Testing( written by architects/ dev leads, run less frequently )

These tests check end to end wiring of the system and interoperability. They are generally automated.

•       Manual / exploratory testing

These are not scripted. These are ad-hoc tests done by the team in order to find corner cases that may break the system. There may be teams assigned to this task, or the entire team could engage in “bug hunting” exercises to achieve this.

•       Acceptance Testing :

•       Helps to communicate requirements clearly

•       Generally all people involved in a product want premature precision, this is no possible. Acceptance tests are generally prepared just before the development cycle. The developers review the tests for sanity.

•       These tests should be automated, so that they can be run every time there is a code change.

•       These constitute the “happy path” of the code flow. The QA writes tests for the corner cases.

•       If a developer finds it hard to meet an acceptance test in the current code design, then this must be clearly communicated and the test modified accordingly.

Estimates

•       There is no try.

What does try mean? Does it mean extra effort? Change in strategy?

If a commitment is not foreseeable, say no.

•       Say yes to a commitment if you are fully aware of the aspects involved in its development. If there are dependencies, clearly spell out those dependencies and communicate them to the shareholders.

•       If commitment to the final goal is not possible, make a commitment that will bring you closer to that goal.

•       Hope is a project killer, if you see an issue in meeting the declared estimates / commitment, flag it immediately.

•       An estimate is a distribution rather than a number. According to the Program Evaluation and Review Technique ( PERT ), following trivariate help define an estimate :

•       O : optimistic

•       N : Nominal

•       P : pessimistic

•       Expected duration : µ = ( O + (4*N) + P ) / 6

•       Standard Deviation : σ = ( P – 0 ) / 6

•       Expected duration of a sequence which may be made up of one or more tasks is :

µ(seq) = Σ µ(task)

•       Standard deviation of a sequence which may be made up of one or more tasks is :

σ(seq) = √ (Σ (σ(task) * σ(task)) )

•       How to make estimates as a team :

•       Wideband Delphi

The team members hold meetings and decide on the estimates for the tasks. The demerit of this technique is that it may take some time before the team comes to a conclusion.

•       Flying Fingers

It is a variant of wideband Delphi. Instead of the team members discussing estimate numbers from a wide range, after each discussion they simultaneously raise a finger to indicate their estimate. If there is a wide discrepancy, the task is discussed, else the team’s estimate is noted down. The fingers could represent any scale of the estimated time as needed for the task.
 

•       Planning Poker

This is a variant of Flying Fingers where numbered cards are used instead of fingers.

•       Affinity estimation

This involves breaking down the task into sub tasks. The sub tasks are written on sticky notes which are sorted in asending order of time taken; this activity is doen by each team member. The sub tasks which underwent a lot of reordering are discussed and then the team finalizes on the total estimate of the task.

•       Law of large numbers

According to this, when estimates have to prepared for a large task, it is advisable to break it down into smaller tasks and then add up their estimates. This gives a better understanding of the task at a finer granularity level.

•       Generally teams involved in software development such as requirement gathering team, development team and testing team, all seek out premature precision on basis of which they can freeze estimates. However, the precision gets built with the project. Several times when the requirement is converted into implementation, the requirement change as it is realized that the intended objective is not met. A successful project should be able to accommodate some tweaking in requirement throughout the project cycle.

Teams

•       A well gelled team is worth a lot. When a team is formed it takes a fermentation period before the members understand the team’s idiosyncrasies and are able to step in when a member needs help and thus work together. Team should be retained at all costs.

•       Agile Methods

•       Agile meeting should consist of each member answering the following questions :

•       What I did yesterday

•       What I am going to do today

•       What is in the way

This saves a lot of time of the members and keeps the meeting short.

•       Before each iteration, a meeting should be held to understand the expectations and estimates.

•       After each iteration, a retrospective and demo meeting must be held.

•       Use data to win arguments and avoid passive aggression at all costs.