
Passion for programming. Chapter 21. Daily Achievement
About translation

This is a translation of chapter 21 of The Passionate Programmer: Creating a Remarkable Career in Software Development. Its author - Chad Fowler - is a talented Ruby developer, a well-known speaker at conferences on Ruby and IT in general. Former saxophonist, now CTO 6Wunderkinder.
The author of the translation of this chapter is shchemelevev . Crowdsourcing translation of the book is carried out on github , join.
Content
- introduction
- Acknowledgments
- Introduction
- Part 1 - Choosing a Market
- Chapter 1. Lead or die
- Chapter 2. Supply and demand
- Chapter 3. Coding is not everything
- Chapter 4. Be the Worst
- Chapter 5. Invest in Your Intellect
- Chapter 6. Do not listen to your parents
- How I Rejected $ 300,000 - A Story at the End of Chapter 6
- Chapter 7. Be a wagon (Drafts)
- Chapter 8. Be a Specialist
- Chapter 9. Do not put all your eggs in someone else's basket
- Chapter 10. Love it or drop it
- Part 2 - Investing in Your Product
- Chapter 11. Learn to fish.
- Chapter 12. Learn How the Business Actually Works
- Chapter 13. Find the Mentor
- Chapter 14. Be a Mentor
- Chapter 15. Practice, practice, practice
- Chapter 16. Your Own Methodology
- Chapter 18. Automate Your Work
- Part 3 - Implementation
- Chapter 19. Right Now
- Chapter 20. Telepath
- Chapter 21. Daily Achievement
- Chapter 22. Remember Who You Work For
- Chapter 23. Be in Place
- Chapter 24. How interesting can you do today?
- Chapter 25. How much are you? (On github, awaiting verification)
- Chapter 26. A stone in a jug of water (a purebred on a github, awaiting verification)
- Chapter 31. Do Not Panic
Thanks to the power of imagination, we all consider ourselves good programmers. We are confident that we cope with the tasks as quickly as possible. Someone is lucky (I intentionally talk about luck ) - and such a strategy really works.
But each of us can achieve more by using, planning and analyzing our achievements. If someone succeeds in regularly surprising and exceeding management's expectations, then he can obviously become the next candidate for promotion. Exceeding expectations is a worthy goal, but very few really give an account of their actions towards achieving it.
Success here, as in most tasks of this kind, can be achieved through purposeful and intentional work. Tell me, when was the last time you exceeded your own abilities? Does the manager know about this? How do you make your success more meaningful ?
Every day, complete a task that you can talk about.
James McMurray, my good friend and comrade, once told at the very beginning of our careers about the system that he invented in order to work better. Given his experience (perhaps his parents told him to), I saw great potential in this system. And still use it. Without warning his superiors, he began to monitor the implementation of daily tasks . The goal was to do something outstanding every day, worthy of telling the management about it - some idea that he thought about or even realized in order to make his department better.
Just set yourself a goal (for a day, for a week, or for any other period of time). By monitoring its implementation, you can radically change your behavior - when you begin to look for outstanding achievements, you, of course, come to the process of evaluating and prioritizing your actions based on significance for business.
Tracking a task with reasonable frequency allows you to be sure that you are not stuck: if the goal is to finish at least one significant task per day, then you can not spend two weeks to achieve excellence in the code.
Task Week
- Monday - automate the build!
- Tuesday - write tape parsing code tests
- Environment - look for a suitable ORM so as not to write sql manually
- Thursday - start the process of deploying a web application
- Friday - fix all compiler warnings
This type of thinking will become a habit rather than an effort. And, as a developer hooked on the green statuses of successfully passed unit tests, you begin to get angry if you have not completed your daily task. There is no need to worry much about tracking progress, because working in this way is more likely to become a nervous tick rather than a set of tasks that you need to schedule in Microsoft Project.
Act!
Allow half an hour on your schedule, sit with a pencil and paper in a quiet place where you will not be distracted. Think of the little annoying problems your team encounters daily. Write them down. What problems do your team spend a couple of minutes every day, but no one has the time or energy to deal with them? What can be automated in the current project, but are you still doing it manually? Write it down. What about the build and sweep process? Can anything be improved? How can I reduce the percentage of failed builds? Write down all these ideas. Allow as much as 20 minutes. Record everything regardless of whether the idea seems good or bad. Do not give up while these 20 minutes go. After making your list, write down five selected (most annoying) cases on a new piece of paper. Next week, Monday, take the first one from the list and do something with it. Tuesday is the second element of the list, Wednesday is the third and so on.