- Bare programming abilities: getting sub-tasks done
Surprisingly the ability to use basic imperative programming constructs very efficiently in order to implement something is, in my experience, not as widespread as one may think.
- Experience: pattern matching
An experienced programmer eventually knows how to deal with a variety of sub tasks. This avoids both a lot of design work, but especially, is an extremely powerful weapon against design errors, that are in turn among the biggest enemies of simplicity.
- Focus: actual time VS hypothetical time
Internal factors are procrastination, lack of interest in the project at hand (you can’t be good doing things you do not love), lack of exercise / well-being, poor or little sleeping.
External factors are frequent meetings, work environments without actual offices, coworkers interrupting often and so forth.
- Design sacrifice: killing 5% to get 90%
Often complexity is generated when there is no willingness to recognized that a non fundamental goal of a project is accounting for a very large amount of design complexity… A project that is executed in order to maximize the output, is going to focus exactly on the aspects that matter and that can be implemented in a reasonable amount of time.
the two main drivers of complexity are the unwillingness to perform design sacrifices, and the accumulation of errors in the design activity.
An initial design error, in the wrong hands, will not generate a re-design of the same system, but will lead to the design of another complex solution in order to cope with the initial error. The project, thus, becomes more complex and less efficient at every wrong step.
each time a complex solution is needed, it’s important to reason for a long time about how the complexity can be avoided, and only continue in that direction if no better possibility is found even considering completely different alternatives.
- Perfectionism, or how to kill your productivity and bias your designs
things like robustness, simplicity, ability to deliver in time, are often never accounted for.
- Knowledge: some theory is going to help
To be a super expert of everything is not required, but to be at least aware of a multitude of potential solutions for a problem certainly is.
- Low level: understanding the machine
Good competence of C, the understanding of how CPUs work and clear ideas about how the kernel operates and how system calls are implemented, can save from bad late-stage surprises.
The sum of being good at gaining state about a bug, incrementally, in order to fix it with a rational set of steps, and the attitude of writing simple code that is unlikely to contain too many bugs, can have a great effect on the programmer efficiency.