I recently read the book "The Pragmatic Programmer" and I'd like to share two lessons, which best capture the essence of the book.
1. Our job is to help people understand what [requirements] they want.
Getting the requirements definition right is one of the most difficult part of the job.
The initial requirements are just a suggestion, an invitation to explore all the options, and ask all the relevant questions that will help create refined requirements.
Don't expect your product manager to give you the ready-to-code requirements. Do your job and help them understand what they want.
Also don't get frustrated in the process. It is normal to require a few feedback loops.
When you step-up and fulfill this part of the job, your company will value you more (and may give you a raise), and you will enjoy your work more.
2. Our job is not just "software developer". It's "problem solver".
Writing code is a just one of the tools for solving a problem.
Sometimes writing code may be the wrong solution, and would only create more problems.
Other times, your code may just solve a symptom, but not the root cause of the problem.
When you start seeing yourself as a problem solver, you start looking for solutions in all possible places. Not in the code that you usually write, but also in:
- a simple unix command (rather than your usual programming language)
- requirements that need to be further clarified,
- design that needs to be simplified,
- documentation that needs to be created.
You are not restricted to just writing code to address the problems that you are faced with.
Once you realize this, and you take it upon yourself* (defined as: to accept responsibility for something without being asked to) to solve such problems, then you will be a step closer to become a Pragmatic Programmer.
Top comments (0)