About transfer

This is the 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 renowned speaker at conferences dedicated to Ruby and IT in general. Former saxophonist, and now - CTO 6Wunderkinder.
')
The translation of this chapter is
shchemelevev . Crowdsourcing translation of the book is conducted on
github , join.
Thanks to the power of imagination, we all consider ourselves as good programmers. We are sure that we cope with tasks as quickly as possible. Someone is lucky (I
deliberately talk about
luck ) - and this strategy really works.
But each of us can achieve more by using, planning and analyzing our achievements. If someone manages to regularly surprise and exceed the expectations of the leadership, then he, obviously, may become the next candidate for improvement. To exceed expectations is a worthy goal, but very few really give an account of their actions on the path to achieving it.
It is possible to achieve success here, as in most tasks of this kind, through purposeful and deliberate work. Tell me, when was the last time you exceeded your own capabilities? Does the manager know about this? How do you make your progress more
meaningful ?
Every day, perform the task of which you can tell.
James McMurray, my good friend and comrade, once said at the very beginning of our careers about the system that I had invented in order to work better. Given his experience (perhaps his parents suggested), I saw great potential in this system. And still use it. Without warning the authorities, 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 — an idea he thought of or even implemented to make his department better.
Just set yourself a goal (for the day, for the week, or for any other period of time). By tracking its implementation, you can radically change your behavior — when you start looking for outstanding achievements, you, of course, come to the process of evaluating and prioritizing your actions based on business value.
Tracking tasks with reasonable periodicity allows you to be sure that you are not stuck: if the goal is to complete at least one significant task per day, then you cannot spend two weeks to achieve
perfection in the code.
Week of completed tasks
- Monday - automate the build!
- Tuesday - write ribbon parsing code tests
- Wednesday - search for a suitable ORM so as not to write sql manually
- Thursday - start the process of web application development
- Friday - fix all compiler warnings
This type of thinking will become a habit rather than an effort. And, as a developer who has run down on green statuses of successfully passed unit tests, you become angry if you have not completed your daily task. You do not have to worry about tracking progress, because working in this way will most likely become a nervous tic than a set of tasks that need to be planned in Microsoft Project.
Act!
Take half an hour on your schedule, sit down with a pencil and paper in a quiet place where you will not be distracted. Think of the small annoying problems that your team meets daily. Write them down. What problems spend a couple of minutes of your team every day, but no one has the time and energy to deal with them? What can be automated in the current project, and are you still doing it manually? Write it down. What about the assembly and sweep process? Can anything be improved? How can I reduce the percentage of failed assemblies? Write down all these ideas. Give it a full 20 minutes. Write down everything, regardless of whether the idea is good or bad. Don't give up while these 20 minutes go. After you make your list, write down five selected (most annoying) cases on a new sheet of paper. Next week, on Monday, take the first one from the list and do something about it. On Tuesday - the second element of the list, Wednesday - the third and so on.