Folksy programming wisdom
2016-11-13
Too often we programmers get carried away in what is essentially unsubstantiated bullshit. This is nothing unusual: we're prone to following the herd and repeating crap because evolution made us that way. Also not unusual is that we need to debunk this bullshit from time to time to make room for tomorrow's bullshit. So here we are.
getting up and going fast is incredibly important
- getting up and going quickly "feels good"
- we have disproportionately prioritized "feeling good" over outcomes
- what is 1 week vs. 1 month if the timeframe is 2 years?
- symbolize a disdain of learning: if it takes you 1 week to learn, how much did you really learn?
automatic measures of code like "cyclomatic complexity" and "coverage" are acceptable indicators of quality
- often latched on to, because they have numbers, which facilitate measurement
- like story points: meaningless but trackable
- the reality is that we have no idea if these mean anything at all or materially affect outcomes
technology (documentation/tests/etc) can make up for a team that doesn't care about nurturing new developers and new team members
- nothing will ever replace teaching
- ever
- but seriously your documentation is probably some horrific out of date vomit in a JIRA/Confluence somewhere.
unit tests will save us
- too often they end up being yet another, especially rigid dependency
- are almost impossible to write in a non-brittle fashion, even for experts
- are made especially useless by the prevalence of stateful programming practices, necessitating Sisyphean amounts of mocking and stubbing makework
languages that look like human languages are ipso facto better (ie "Ruby looks like English")
- say nothing about the reliability or fitness for purpose of the software
- say nothing about the semantics of the language
- show the fallacy of familiarity epitomized in the "simple vs. easy" argument