The Art of Clean Coding — Professional Programmer

1 Minute Summary

Photo by Martin Shreder on Unsplash

Now let’s understand all above points with more insights.

Professionalism

Professionals take responsibilities. You can not take pride and honor in something that you can not be held accountable for. Take responsibility to complete the clean code on time, and if not possible, take responsibility to communicate early. Shipping incomplete/faulty code/build is bound to fail. Any code you are not certain about is a faulty code. Only way to avoid it is to test, test and retest. QA should find nothing. And if it is hard to test, refactor/rewrite. The key thing is to keep your hands dirty in code all the time. The more changes you make, the more you know the code. The more you test and you better estimate. Repeat this cycle all the time.

Saying NO

When your manager tells you that X module has to be ready by tomorrow, he is pursuing and defending one of his objectives. He is doing his job. If you know well that getting done X by tomorrow is impossible, then you are not doing your job if you say “Ok, I will try. I might work extra hours”. The only way to do your job, at that point, is to say “No, that is impossible.” Your manager is counting on your to defend your objectives as aggressively as he defends his. That is how the two of you are going to get to the best possible outcome.

Saying YES

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 language of commitment so that there is no doubt about what they have promised. There are three parts of saying yes:
- You say you will do it
- You mean it
- You actually do it

Coding

Programing is hard. The younger you are the less you believe this. After all, it is just a bunch of `if` and `while` statements. But as you gain experience you begin to realize that the way you combine those `if` and `while` statements is critically important. You can’t just slather them together and hope for the best. Rather, you have to carefully partition the system into small understandable units that have as little to do with each other as possible — and *that is hard*.

  • First, your code must work.
  • Your code must solve the problem set for you by the customer.
  • Your code must fit well into existing system. It should not increase the rigidity, fragility, or opacity of that system.
  • Your code must be readable by other programmers.
  • Make sure that your sleep, health and lifestyle are tunes so that you can put in eight good hours per day.
  • Non work related worries affect your work. Partition the time. Rather than forcing yourself to code while the background worry is nagging you, spend dedicated block of time, handling the worry.
  • Like me, many engineers love the flow zone. Reality is, you lose some of the big picture while you are in the Zone, so you will likely make decisions that you will later have to go back and reverse.
  • Disengagement from work allows your mind to hunt for solutions in a different and more creative way.
  • Do not *hope* that you can get it all done in ten days. Hope is a project killer.
  • Do not rush. The poor developer might buckle up and agrees to try to make the deadline. That developer will start taking shortcuts and working extra hours with the hope of working a miracle.
  • Do not agree to work overtime unless A) You can personally afford it B) It is short term, two weeks or less C) Your boss has a fallback plan in case overtime effort fails

TDD — Test Driven Development

I personally have not used TDD in a professional environment, however after reading this chapter of a book I can not wait to use it professionally.

  • You are not allowed to write any production code until you have first written a failing unit test
  • You are not allowed to write more of a unit test than is sufficient to fail.
  • Round and round the cycle you go. Adding a bit to the test code. Adding a bit to the production code.

Practicing

When performance matters, professionals practice. Doing anything quickly requires practice. Spinning around 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 problem and simply know what to do to address them.

Acceptance Testing

Both business and programmers are tempted to fall into the trap of premature precision. Business people want to know exactly what they are going to get before they authorize a project. Developers want to know exactly what they are supposed to deliver before they estimate the project. Both sides want a precision that simply can not be achieved, and are often willing to waste a fortune trying to attain it. The solution to premature precision is to defer precision as long as possible. Professional developers do not flesh out a requirement until they are just about to develop it. However, it can lead to another problem: late ambiguity. Late ambiguity is a term which represents some requirements missed or discovered late in the development cycle. This type of late ambiguity can result into missing dates or delivering imperfect product. Solution to both those problems is to define Acceptance Tests. Acceptance tests are not QA tests, these are tests written by a collaboration of the stakeholders and the programmers in order to define when a requirement is done.

Testing Strategies

Professional developers test their code, but testing is not simply a matter of writing a few unit tests or integration tests. What every team needs is a good testing strategy.

Image describes various type of tests software development team can adopt to better evaluate products.
Pyramid of Tests
  • Meetings cost about $200 per hour per attendee, considering salaries, benefit, facilities etc. Professions are aware of the high cost and aware of their time, so they actively resist attending meetings that they do not have an immediate and significant benefit.
  • You have an obligation to manage your time well. If you find yourself stuck in a meeting that is not a good use of your time, you need to find a way to politely exit that meeting.
  • To use the participants’ time wisely, the meeting should have a clear agenda with times for each topic and stated goal.
  • Standup meeting should not take more 1 minute for each participant.
  • Sprint/Iteration planning should not take more than 5% of total duration of entire sprint. ie 2 hours for 40 hour sprint planning.
  • Any argument that can not be settled in five minutes, can not be settled by arguing.
  • Focus is a scarce resource, after you have expended your focus, you have to recharge by doing unfocussed activities.
  • A good long walk, a conversation with friends, a time of just looking outside window can help you pump the focus back up.
  • You will get most focus after good night’s sleep.
  • Muscle focus can help you recharge mental focus. ie martial arts, tai-chi, yoga, meditation.

Collaboration

Most software is created by teams. Teams are most effective when the team members collaborate professionally. It is unprofessional to be a loner or a recluse on a team.
The first responsibility of the professional programmer is to meet the needs of his or her employer. that means collaborating with your managers, business analysis, testers and other team members to deeply understand the business goals.It means that you need to understand why you are writing the code you are writing, and how the business that employs you will benefit from it.

Teams And Projects

Teams are harder to build than projects. Therefore, it is better to form persistent teams that move together from one project to the next and can take on more than one project at a time. the goal in forming a team is to give that team enough time to gel, and the keep it together as an engine for getting many projects done.

Craftsmanship

School can teach the theory of computer programming, but school does not and can not teach the discipline, practice, and skill of being craftsman. A craftsman is someone who works quickly, but without rushing, who provides reasonable estimates and meets commitments. A craftsman knows when to say no, but tries hard to say yes. A craftsman is a professional.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store