Things I Do Before I Start Programming

I am a programmer. I solve problems from different domains. My clients are from finance, virology institutes, employee management, labor information management system, energy sector, or just some dude who wants to automate one specific task with software.

I have not solved a single computer science problem since I got my Bachelor's Degree. I help to automate and optimize processes, save money, and time in my customer's fields. It is challenging to understand customer problems, that is why before I start programming, I have to

• understand the problem
• paraphrase the problem to the client
• suggest a verbal solution
• visualize the solution on a whiteboard
• split the solution into small tasks
• estimate tasks
• start programming

Communication skills are just as important as technical skills.

Really understand the Problem

Direct communication with the client is the key to good communication. I try to be onside with the customer as often as I can. A video call or communication over the project manager is never enough to understand what your client needs. Be with your client as he operates his business, ask him questions, and take notes. Put yourself in his place and try to really understand the problems and challenges he meets. I am always surprised, how much I learn when I spend a day with my customer. Ask questions till you really understand, how you can help.

Paraphrase the Problem to the Client

Describe the problem to the client with own words. I use sentences like "If I understood you right, ..." or "Let me sum it up, ..." or "In other words, ...". Paraphrasing shows that I was listening and understood what is needed. It also helps me to memorize customer business processes.

Suggest your solution

Sometimes customer provides a detailed solution and I "just" have to implement it. Other times the customer has no idea what he needs. In both cases provide your solution or point out possible improvements and difficulties. Be ready to update or change the solution later.

Visualize the solution

Visualization is a great communication tool. I prefer White Board but you can use whatever works best for you: UI Mocks, Diagrams, Mindmaps, or UML Diagrams. UI Mocks works best for me. UI is what the customer wants and will get in the end. Use visualization to describe the solution.

Create tasks

Convert what you learned to user stories or small tasks. Write them down. Try out different tools: paper cards, Emacs Org Mode, Excel Sheets, Jira. Jira works best for me. Never start working without a written task or user story. They document what will be done and whatnot. It helps to avoid discussions with the client about agreements later.

Estimate Tasks

Estimate complexity for every task but not the execution time. I use Fibonacci Numbers to estimate a task complexity: 1, 2, 3, 5, 8. If a task has the "8" complexity it is too big, break it down to smaller tasks. Take a mediocre task like "As a user, I want to login" and assign it a complexity 2 or 3. Use it as a point of reference for further estimation.

Complexity says nothing about time the task may take. Sometimes simple tasks like copy/paste data from "Table A" to "Table B" take more than 2 days and a complex task, like creating Infrastructure with Terraform only a couple of hours. You should always track how long a task takes. And calculate a "velocity". Velocity describes how many complexity points you can accomplish per day. To calculate the velocity, add up all complexity estimation points and time it took to accomplish them. Now divide the sum of all estimation points by the time it took to accomplish them. The result is your velocity. Now you can estimate how many tasks, you can accomplish in a week.

Start Programming

Finally, you are allowed to start writing excellent software and to solve customer problems.

Conclusion

Programming is not only about programming. Besides programming skills, you need good communication skills. You have to really understand what your customer wants and deliver a product that solves customers' problems.