Software Creation Mystery - https://softwarecreation.org

The Elements of Pragmatic Programming Style. Intention.

“I made this program longer than usual because I lack the time to make it shorter.” – paraphrasing Blaise Pascal

The Elements of Pragmatic Programming Style is the collection of rules for pragmatic programmers. This collection doesn’t pretend to be comprehensive guide how to program. Rather it concentrates on fundamentals: how any programmer can build better software for the customer. Some of the rules are obvious, but, surprisingly, many programmers don’t even think about them. They make same mistakes over and over again. I hope this post will inject a healthy dose of pragmatism into your programming style and make it a bit better .

Style Components:

  • Intention – understand your task and how to get it done
  • Approach – basic principles of writing code
  • Composition – organization of code
  • Expression – expressing ideas in code
  • Object Oriented Pragmatic Style

The goals of Pragmatic Programming Style are

  1. Building reliable software fast.
  2. Delivering maximum value for the customer.
  3. Writing code that is easy to understand, change and share.

Intention

“Everyone hears only what he understands.” – Johann Wolfgang von Goethe

Understand your task and how to get it done


Sidereal

1. Know your programming task beforehand.

Understand clearly your programming task before start. You will be focused, productive and efficient if you know exactly what to do. Vague tasks breed confusion, indecision and sluggishness. Misunderstanding leads to wrong code, dissatisfaction and conflicts. Therefore, ask questions, listen and pursue until you have good enough understanding of the task and your customer needs. Sometimes, of course, even your customer does not clearly understand what she wants. Most probably you’ll discover together what is needed on the go. And still, effort to understand your task beforehand will increase satisfaction and efficiency.

Don’t overuse this rule – first practical results in the first weeks will do more for understanding than months of conversations and drawing diagrams.

2. Understand what is important.

You have to make many decision on your own while programming. Customers cannot always prompt what options are better or how to overcome technical hurdles. They will rely on your technical expertise and common sense. Therefore, understand what is important to make the best decisions for the customer. For example, customers can be interested in easy to learn and responsive user interface. Or they can be interested in minimal cost and time. Or they can ask for highly secure solution. Better you know what is important, better decisions you will make.

3. Think how to implement task before programming.

Think how to implement your task before writing the first line of code. Many adventurous programmers don’t like to think ahead and prefer to immediately dive into programming. Often they find themselves lost in programming jungles with sad choice to continue struggle until code is a complete mess or start over again. Don’t be lost. Think ahead about how you will implement your task, what is missing and what is not clear. Use search, read help and ask other programmers. Quick sketches and notes on the paper will summon up your thoughts to find better solution.

4. Define when task is ‘DONE’.

You should know when your task is done, be it user interface, algorithm or database code. Sometimes, the programmer thinks that task is done without careful testing and consideration of alternative cases. Sometimes the programmer spends huge effort on polishing already good enough solution. Unfinished code or wasted time are both bad for your customer. Therefore, know when your task is ‘DONE’ and when you should stop.

5. Share your ideas with your team

Discuss your ideas with your fellow programmers. Even the smartest programmer will benefit from explaining her ideas to a team. Other programmers can help to find flaws, challenge ideas or suggest a better way. In addition, they will learn how you solve problems, gain better experience and knowledge about the system. Therefore, don’t conceal your ideas, but share and improve them with your team. Learn and grow together.

6. Communicate required effort, risks and alternatives.

Inform your customer about required effort, risks, possible alternatives for the task. The customer will appreciate honest and full information before you spend time on programming. Yes, the customer could cancel some requests or select cheaper alternative if effort seems too large. But your customer will have comfortable and powerful feeling (that is so fragile) of control over the project that brings trust and desire to cooperate. See your customer rather as a long-term partner than a quick source of revenue. It will pay with more satisfaction from work, better reputation and more customers.

7. Plan steps to get strength to start

“The first and the best victory is to conquer self.” – Plato

You can be the biggest obstacle to get the task done – your procrastination, your indecision and your unproductive mood. Try to plan your steps, once you have clear ideas what should be done. Plan how these steps will fit into your working schedule, a release cycle and the customer availability for questions and feedback. Create concrete actions – more detailed for more complex parts. Visualize your steps to assure yourself that your task can be accomplished. While it is possible that your plan will be useless, it will provide confidence and energy to embrace the most challenging tasks.

Now you are ready to start programming.

Next posts will bring rules and examples for Approach, Composition, Expression and Object Oriented Pragmatic style.

Inspiring reference: The Elements of Style, W. Strunk Jr. and E.B. White

AddThis Social Bookmark Button AddThis Feed Button


Comments

[…] Software Creation Mystery » The Elements of Pragmatic Programming Style. Intention. – The Elements of Pragmatic Programming Style is the collection of rules for pragmatic programmers. This collection doesn’t pretend to be comprehensive guide how to program. Rather it concentrates on fundamentals: how any programmer can build better software for the customer […]

Pingback by Daily del.icio.us for November 9th through November 13th — Vinny Carpenter's blog | November 13, 2008 9:01 pm

This blog have little value without you and your comments, thoughts and discussions. Please, leave your comments. You are welcome to debate and criticize any idea, but, please, don't attack other people. Thanks for your contribution!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Subscribe without commenting

Software Creation Mystery - https://softwarecreation.org
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 License .