About the productivity of programmers

This morning I stumbled across a George Stocker article, "How to destroy programmer productivity," and a Joel Spolsky, "shoot a gun for a place." These two posts talk about the productivity of programmers, especially the patterns that reduce productivity. So I thought about sharing my practical experience of improving my productivity.

Passion

The first skill to improve your productivity is to be passionate about the projects you're on every day. You must be genuinely optimistic about the project you are going to do. You have to imagine how cool the results will be in a year, two years, three years from now. Several times I spent some time thinking: Hey NDepend (my project) has evolved so much over the past two years. Two years ago, I imagined that the new features and improvements it was going to have were science fiction, and today it's all come true and it's been sent to users in the real world. That's cool!

Patience and confidence

So not only passion, but love and patience are also needed. Measuring the achievements of the past x years has made me realize that once I do a function, an improvement, fix a bug, write a line of code, this one-time thinking keeps me progressing. Every success in the past is nurturing more success in the future, motivating yourself to become more productive every hour, because there is no more important (professional) thing.

Today I seem to be working on a annoying bug all day long, and if I'm not always so stupid it's possible that I've fixed it in half an hour! Without a little pressure, in the past such things have happened too much, looking back on the road for so many years, I understand this is the way I want to go. This is faith.

Start right now.

The central point of a project should be that we know where to go. Short-term (days, weeks), medium (several months), long-term (several years). Short term for me means that my code base is crammed with priority notes, priority 5 is more urgent than priority 4. This sounds like a very basic task list, but the task list is a powerful advantage. The action plan appears where the programming operation must take place. Therefore, starting work on the action plan eliminates the process of finding where to start programming priorities. The immediate start of the Act (or the Act of not starting immediately) is the killer of productivity. So all the things that can help you start writing code right away are the capital of productivity.

Another benefit of the action plan is that when all the plans are complete, the work is done. Since all tasks around programming (write tests, code reviews, checksums, etc.) can and must be arranged in the action plan, there is no longer an action plan that is a very simple job to complete the definition.

Focus

Of course, in a way, the action plan must be listed, and then the code must crawl where it is most likely to be written. This usually happens when you start working on a thing (a product backlog project). This is when the product backlog is translated into (several or many) priority to-do items, and the priority depends on the size of the product backlog. It may be a bug that fixes an hour or it will take 3 months to develop a feature.

There should be no more than 10 priority to-do items at a time, because an important skill to improve productivity is to focus on what you're doing. So this feature can be broken down into 90 classes of priorities and 10 two priority to-do items, and then we can pick 10 out of 90 priority backlog items. If the two priority backlog you're currently doing is worth it, you can turn it into a category three priority to-do item, and so on.

That way, every morning you just need to look up your work space to see what you can do immediately. You don't have to think about what to do today, start right away, and stay focused.

Goal

Imagining the medium (months) and long-term (years) goals can foster a passion for work and a day-to-day productivity. There must be two to-do lists to keep doing this. Since Ndepend follows the release of Visual Studio, our sprint period is about 12 months to 18 months. So we have an interim list that lists the things we need to do to release the next major version from now to n months. The interim list is driven by ROI (ROI, the ratio of functional effects to development input) and the voice of the user, which provides good advice on the effectiveness of each future function. The same applies to long-term lists, except for lists that are not subject to sprint deadlines.

Psychological

So far, I've mentioned a few project management and organizational experiences, all of which demonstrate that maintaining a complete passion can improve productivity. But passion, patience, information, immediate start, focus, and set goals are all related to psychology. Here are a few of the classic regular psychology routines that maintain efficiency:

It is certainly essential to have a sound and happy life. For individuals, in addition to programming, I need other things in my life: friends, family, children and hobbies. A few hours a day must be dedicated to something outside of the code. A person must sleep well and work in a normal time period. When you are most focused on your work (usually early in the morning or late at night) you have to determine the time and try to work at this special time. This sounds obvious to you (and me), but those super-annoying individuals must pay attention to this. You can't bury your head in a day. 14 hours of code also remain productive in long-term projects.

I found sports to be the most creative way in my programming career. Running regularly is a practice for me to improve my working efficiency. This process will not only allow me to naturally come up with new ideas, but also due to the endurance of the rapid secretion of endorphins hormones, can be a good relief of pain and stress. Runners are actually easily addicted to this, which is a very cool process. I also take exercise time as part of my working time. Doing so is very practical and never misses a meeting. By the way, I recently found out that Alan Turing had a lot of great ideas when he was running (he could almost run the 1948-year Olympic marathon).

In addition to exercise, I also meditate every day, especially MBSR (mindfulness decompression treatment). This will make me quieter, calmer and more focused. MBSR is very simple and can be done several times a day in a few minutes of meetings. It is based on the ability to develop people's perception of the present through the observation, perception, and perception of the environment. The key is to develop the ability to "not to be happy, not to own sorrow". As we all know, a person who wants to have a long muscle must exercise, but few people understand that the brain can and must be trained to be useful. In general, MBSR and meditation are used to train the development of the brain and cognitive abilities.

When psychology and productivity are linked together, we often hear the concept of "flow". "In a flowing state" means a complete focus on the current activity. The "flow" condition is the god of productivity: a passion for work and a solid skill. We often hear that you need 10,000 hours of practice to master a skill. "Flow" takes place more on the part of experienced handlers. Another condition for the magical "flow" is to accept tasks that are challenging enough. It is impossible to do simple things in a "flowing" state. The good news is that programming (skill cow) is not a simple task.

Of course, avoiding interruptions when it comes to productivity is also an important aspect. Some of the distractions you can control, such as handling mail two times a day in batch mode, rather than debating online, browsing social networks on a regular basis, are the important roles that meditation and exercise can play, because concentration is improving. There are also uncontrolled interruptions, whether it's a colleague, a meeting or a child (if you're working from home). In addition to dealing with these interruptions and being able to concentrate as quickly as possible, you have no other choice.

There is a theory of reward for those who do not work with me. Like I do 3 hours of coding in a set of arrangements, then I go to the beach for one hours. This not only works for me alone. I take it as a reward if I want to go to the beach after I finish my work. Reward theory may work for those who are not passionate about their own work. Your first responsibility in your career is to find a job that makes you passionate.

Free to receive the lamp brother even original PHP video tutorial CD/"Detailed PHP" Essentials Edition, details of the website customer service:

www.itxdl.cn

About the productivity of programmers