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.
•
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.
