Qualities that make the most difference in programmers productivity

  • 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.

  • Simplicity

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.

  • Debugging skills

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.



One Sure-Fire Way to Improve Your Coding


The most obvious way to improve your coding is to write more code. Everybody knows that. However, another activity which I guarantee will improve your coding is the complete opposite of writing. I will state this as plainly as I possibly can:

If you want to dramatically increase your programming skills you need to be reading other people’s code.

You Are Not Paid to Write Code


Every time you write code or introduce third-party services, you are introducing the possibility of failure into your system.
I think the same can safely be said of code—more code, more problems.

almost anything is easier to get into than out of. When we introduce new systems, new tools, new lines of code, we’re with them for the long haul. It’s like a baby that doesn’t grow up.

We’re not paid to write code, we’re paid to add value (or reduce cost) to the business. Yet I often see people measuring their worth in code, in systems, in tools—all of the output that’s easy to measure.

the siloing of responsibilities. Product, Platform, Infrastructure, Operations, DevOps, QA—whatever the silos, it’s created a sort of responsibility lethargy. “I’m paid to write software, not tests” or “I’m paid to write features, not deploy and monitor them.” Things of that nature.

I think this is only addressed by stewarding a strong engineering culture and instilling the right values and expectations.

10 Modern Software Over-Engineering Mistakes

View at Medium.com

if we plan for 100 things, Business will always come up with the 101st thing we never thought of…we have no clue what’s headed our way.

In my 15 year involvement with coding, I have never seen a single business “converge” on requirements. They only diverge. Its simply the nature of business and its not the business people’s fault.

  • Prefer Isolating Actions than Combining
  • Duplication is better than the wrong abstraction
  • Wrappers are an exception, not the norm. Don’t wrap good libraries for the sake of wrapping
  • Blindly applying Quality concepts (like changing all variables to “private final”, writing an interface for all classes, etc) is NOT going to make code magically better.
  • In House “Inventions” – It feels cool in the beginning. But these are most common sources of Legacy in few years… There is a constant effort required to keeping this going. Even a tiny open source library takes a lot of time to maintain.
  • Refactoring is part of each and every story. No code is untouchable
  • Quality needs time and not just skill. And smart developers frequently overestimate their capability. Finally they end up taking ugly hacks to finish stuff on a self-committed suicide timeline. TL;DR — Bad Estimation destroys Quality even before a single line of code is written

must protect the technology team from becoming a pure execution arm

I hate environments where the technology department is simply implementing what was envisioned by others. It might as well be an outsourced development team because it becomes independent of the decision making process. As Camille Fournier puts it in ‘On the role of CTO,’ “The CTO must protect the technology team from becoming a pure execution arm for ideas without tending to its own needs and its own ideas.”


Working Software

“there is nothing like a tested, integrated system for bringing a forceful dose of reality into any project. Documents can hide all sorts of flaws. Untested code can hide plenty of flaws. But when people actually sit in front of a system and work with it, then flaws become truly apparent: both in terms of bugs and in terms of misunderstood requirements.”