The Pragmatic Programmer EP.10 — Pragmatic projects
Here is the final episode of capturing ideal from The Pragmatic Programmer —A famous book describing the pragmatic implementation methodology to make incredibly pragmatic teams and deliverables.
This episode will recap key takeaways of pragmatic projects.
Pragmatic Teams
Pragmatic teams should contribute to each other by following points:
- Don’t live with the broken windows: If your teammates are okay with the broken windows and ignore fixing them as fast as possible when the broken windows are considered a software debt, your team trend to produce and deliver more broken windows.
- Catalyst: Show your teammates to let them see what amazing things they can do until they ask to do the new incredible feats.
- Don’t be the boiled frogs: The boiled frog is comparable to anyone who has unknown any changes. The frog will become boiled unconsciously. So, look at the big picture. Don’t focus only on what you are doing.
- Knowledge portfolio: Regularly invest knowledge and manage your risks.
- Try to communicate: Because team members have different backgrounds, colleagues interpret the one sentence with a different meaning. So, try to explain what you are thinking and reassure that your teammates understand what you mean.
- Implement the minimal environment to test something
- Apply automation for consistent development software
Please refer to previous stories related to detail.
One thing doesn’t fit all
A single thing does not fit everyone. Try it out to see whether it works with your team or not. Use it for other reasons outside what’s trendy. For example, while scrum provides some project management techniques, it doesn’t suggest enough direction for technical aspects or for leadership. So, apply other methodologies to fit to your team.
Starter Kit
The useful starter kit that the authors offer related to
- Version Control: use a version control system to drive your code whenever you build your new application features or prototyping. It can be done on whatever tools e.g. GitHub.
- Testing: always iteratively test your code which might consist of unit testing, integration testing, validation and verification, performance testing, properties-based testing, etc. As the authors state that
Test Early, Test Often, Test Automatically — The Pragmatic Programmers
Please note that testing coverage does not mean code coverage. Don’t forget to create tests that cover all possible cases.
- Full Automation: As previously mentioned, try to let your team works on full automation, for example, CI/CD, etc.
CI/CD — a method to frequently deliver apps to customers by introducing automation into the stages of app development. — RedHat
Users
Don’t focus on yourself that you are a programmer. But, indeed, the pragmatic programmer is a Problem Solver. So, our deliverables are not only software, but it might be the solution to do something. Here is how to deal with the users.
Make sure everyone on the team is totally clear about these expectations.
When making decisions, think about which path forward moves closer to those expectations.
Critically analyze the user requirements in light of the expectations. On many projects we’ve discovered that the stated “requirement” was in fact just a guess at what could be done by technology: it was actually an amateur implementation plan dressed up as a requirements document. Don’t be afraid to make suggestions that change the requirement if you can demonstrate that they will move the project closer to the objective.
Continue to think about these expectations as you progress through the project. — The Pragmatic Programmer
Proud of your project
Finally, after your team delivers a project, prod your project by signing on a deliverer as an artist does.
Thanks to The Pragmatic Programming book for above knowledge, if you are interested in reading this book, click here for more detail.
