After reading a lot of posts from programming in the twenty-first century, especially this post I really started appreciating the whole idea of how does a good programmer think?

People have thought long and hard about what kind of thinking makes for the most groundbreaking scientists, the most creative mathematicians, the most influential engineers. For example, check out the recently published bestselling book Thinking Fast and Slow

But when talking about how good programmers think, there is a lot of disagreement.

Common ideas of the ideal programmer

• The Lazy programmer: Focuses on good up-front design, on pencil and paper, or on diagrams instead of code. The good programmer here has an ability to visualize a proposed plan, and design a system which is simple and clear as possible to accomplish the goals of the plan.
• The algorithms whiz: Donald Knuth’s The Art of Computer Programming, focuses on algorithmic puzzles, such as developing and analyzing algorithms. This is sometimes used as a symbol for the concept that good programming require clever and geniusy ways of programming. Under this idea, the good programmer has a deep understanding of many different algorithms, the math behind them, and is able to understand how their algorithms are actually executed on the machine.
• The Humble programmer: This programmer realizes that they do not have a perfect idea of what the product should be like, or even a perfect understanding of the current system. The Humber programmer wishes to have their ideas be reviewed, and is willing to have their ideas be overridden if found lacking. The humble programmer focuses on quick turnover from idea to prototype to implementation, continuously seeking review and feedback.
• The Product programmer: This sort of programmer focuses intently on the design of the end product, rather than the code. Web developers focus on good looks, video game designers focus on playability. They are similar to the humble programmer, but are accept much more responsibility for the success of their own deigns. The ideal candidate here would be a specialist in their field who happens to know programming.

While these are the main ones that big companies talk about, there are many others that individuals consider, especially on the fringes of the programming world.

• The code doctor: Rather than creating something new, some programmers apparently spend the majority of their time fixing emerging problems with already constructed systems. This role is for those who love tracking down what a system is doing.
• The hacker: Obsessed with finding flaws in programs, rather than how they work. Willing to spend a lot of time working through the system to understand what could go wrong, and how to exploiting it.
• The scientist: I had a professor once who really did see computer science as a science, and valued skills usually associated with the hard sciences, like a good memory and formal analysis.

And I am sure there are many more I don’t know about.

How to make the best use of your own style of programming?

All of them are important in some scenarios. I identify most closely with the algorithms whiz and the lazy programmer, but I know lots of good programmers in the other areas of thought as well.

Note that all of these were ideas that good people, after long experience and reflection, found were useful or valuable. So they are all good unless placed in an inappropriate context. And people are usually pretty good at placing themselves in contexts where their talent shines.

However, there are examples of people being good and bad representations of all of these ideas.

Lots of design or product discussions are unproductive, or even counter-productive. I want to see if there is any good way of separating the good from the crap no matter what type of programmer you are. In other words, I want to find a sure way of making yourself the best programmer you can be.

Value propagation

In order to cut the crap, you need to know what not to cut, which discussions bring real value, which ones need to be longer, vs the ones which matter less.

Once we have a good understanding of these things, then we can usually do a far better job. Even if people you work with disagree with us, and stop us from following our plan. After all, you can just factor in the amount of time and energy it would take to fight them, and put in your value calculation. In other words, you would fight them hard on critical things, and maybe mention an idea once on non-critical choices. The emotionally hard part here is the fighting, and putting up with working on things you feel are crap, not the calculation.

For instance, one vital role in any project is the person who stops bad directions before they get very far. This person has to have the ability to stand up say no, and convince others using real data and experiences that “NO” is the correct solution.

However, you also need to be able to quickly turn the conversation to a constructive dialogue which addresses the main concerns of the project while

Improve values

So it turns out that the way to cut out the crap is an idea from reinforcement learning.

a