Preface: What does the author mean by saying pragmatic
Pragmatic by term is meaning "Skilled in business" or derived as "fit for use"
Programming is a craft that consist of:
- Gather and listen to requirement and devise a plan to converse the requirement into implementation (listening -> advising -> implementing the requirement)
- document the work so that other can understand (communicating to ensure project's maintainability, no single-man responsibility)
- try to make other can build upon the code. (make beautiful API's, and follow clean code for scalability + maintainability)
No Silver Bullet -> THERE IS NO PERFECT TOOL.
be it framework, language, or OS, nothing is perfect. only appropriate under certain circumstances. basically just pick the "best tool for the job"
This is where Pragmatic come from. programmer shouldn't be attached to any tool / technology. programmer should have basic understanding of how system work / basic computer science and have diverse knowledge about tool.
Cross reference: in a philosophical term, Pragmatic means a world view that see truth as what is work. what is true is what is work. So people with this worldview would believe what is right from what is work and usually not valuing unseen things (cross reference is from me, not in the book)
What make a programmer pragmatic
Programming is a personal journey. overtime each person will pick a skill relative to their current work and would have a difference skillset an journey.
But there are similar characteristic among them:
- Early Adopter -> love to try things out -> learn how to learn fast
- Inquisitive -> Question things -> have a curiosity and it'll be just the side effect. see everything as questionable
- Critical Thinker -> Challenge the notion. -> basically a more radical form of inquisitive. when inquisitive is questioning something, critical thinking means think the negation of the notion. for example when someone say "Do A will get result B" programmer would think would that be a case that "A" will not get them to "B"
- Realistic -> turn whatever available into works. don't wait for the mythical unicorn to come and save you. but also understand that great work is difficult. no compromising things just because it difficult so have the stamina.
- Jack of All Trades -> be familiar with broad range of technology and environment. don't hesitate to learn something just because your work currently not needing it
Cross-reference: Example of this pragmatic principle would be the anime character Gintoki in anime Gintama. he would take whatever job come in his door and learn things along the job.
- Care about the craft -> Feel of Ownership
- Think about the work -> no auto pilot mode while working. think in real-time
Programming is not only about teams but also individual craft. for example each person make decision about how he write his code. so it's also logical for one self to learn to master the craft.
And programming is also continuous effort. the key is to have mindset "no system is perfect" but meanwhile in act striving for perfectness
Chapter I Pragmatic Philosophy Notes
Topic 1: It's your life
This first topic in the first chapter is about being mindful about how you live your life. you are the controller of your own life. Don't blame anyone or anything for the path or the choices you are not taking.
Topic 2: The cat ate my source code
Continuing for the first topic, this second topic is about responsibility. pragmatic programmer is taking responsibility for himself. and are not afraid of admitting when making a mistake.
Problem is always come up even in the most perfect system with perfect documentation. always be willing to be responsible, be honest and direct.
Keep your team's trust -> do your part and do it best. basically good system is built upon team that everybody do best on their part.
Cross reference: feel it as it's like battling in starships in star wars. Even if you have the best pilot that can navigate in the wave of asteroids, if the one whom task is to shot down the enemy isn't doing best at his job and none of the enemies taken down the ships will eventually lose and get caught.
You'll always have the option to take responsibility by agreeing to work on a job/task. if you feel it's against your value you can always step out of the task or even the job. but when you do agree. Don't blame anyone for a mistake when it comes up -> take responsibility -> provide solution, !excuses.
Provide options instead of excuses -> when you feel some task isn't viable at the moment. don't just give excuses, provide options. ex:
we can't add that feature because of X, but we can do Y instead and gradually support X. Don’t say it can’t be done; explain what can be done to salvage the situation.
Topic 3 : Software Entropy
this topic is talking about software rot and technical debt.
Broken window theory -> when something give a sense that a building is abandoned (for example a broken window) people will consider the building is abandoned. in the experiment, after weeks of left a building with a broken window, people start littering there, and draw graffiti
Don't be the first to left a broken window (bad design, unclean code, etc). if you must, left a comment or a note
Cross-reference: think of commenting as if you made a sign "The house is not abandoned" in top of a broken window in your building. but remember that having to much of that sign will have the implication of a bad ownership
One broken window is one too many.
Topic 4: Stone soup and boiled egg
This topic is exploring the story of soldiers that make the stone soup and trick villager to make a meat soup instead.
It's about being a Catalyst. sometime, to introduce change, you have to be the change first and people will follow.
People like to follow success.
Do you want your company to use tool X for testing ? try to test the current project with it on your local branch and do a benchmark, write article or even proposal about how good it is. Think your team need to build a tooling for the project ? try to building on the base idea, and when people start thinking it's useful you can say "it's beter to add x or add y" and slowly it'd become the tooling you want the team to have.
Cross reference: In a startup bussiness term it's like about MVP, give your user something to test the IDEA. and when they like it, iterate upon it.
At the same time though, don't be like the villager. they're working what asked by the soldiers without questioning it. it's a good thing that it's a success. but it could be the otherwise.
Never ever work in auto pilot. and always code with the bigger picture (the main goals of the project) in mind.
Topic 5: Good-enough software
If the previous section is a Gas to Gaspoll (move forward fast) then this section is a brake.
Yes you need to question think, code with big picture and never left a broken window. but you also Need To Know When To Stop !.
Users nowadays would prefer simple software with a little minor bug rather than waiting for a perfect complex software to come.
But always be mindful. Good-enough doesn't mean you can ship a sloppy buggy software.
It's also mean to never over-optimize every single thing. you can ruin a good software if you try to over-refine things.
Topic 6: Knowledge portfolio
Pragmatic programmer have the thirst for knowledge. and knowing to learn how to learn.
there are some point discussed about portfolio:
- make investment a habit
- make it diverse
- balance portfolio -> make prioritization on what to learn
- buy low, sell high -> be an early adopter. be among the first expert in the thing
- review -> always have a periodic review about your knowledge portfolio. to know what your strength and what you lack of
Pragmatic programmer have a learning goals ex: read book each mont, learn new language every year, stay current etc.
Opportunities for learning
Pragmatic programmer always see a task or a job as opportunity for learning something new.
When you meet some term at work and you don't know about it, don't let it stop there. take it as a challenge to at least have an idea about it
When you learn and read. try to put on your critical thinking hat. don't always believe what is written. and also always know the context. in what your read is applicable.
Super quote : don't just thinking about the quality of what you read but think about the quality of how you read.
Topic 7: Communicate
Treat a communication as how you treat your code.
Great idea with poor communication will be heard as bad idea. Good software with poor documentation will be seen as bad software.
- Know what you want to say.
- Know your audience.
- Choose your moment.
- Choose a style.
- Make it look good.
- Involve your audience.
- Be a listener.
- Get back to people.
- Keep code and documentation together.
Cross reference: HOS Tjokroaminoto, an Indonesian Revolutionary leader in 1900's said to be great and be heard is to write like a journalist and talk like orator. in the end the idea that will be used is the idea that people have attention too
That's all the notes I take on the preface and first chapter of the book. see you again in the next chapter.