Binary Sludge
A truly superb list of aspirational qualities for software developers. It includes symptoms of each particular quality and guidelines on how to acquire the desired traits.
Signs that you’re a good programmer
1. The instinct to experiment first
2. Emotional detachment from code and design
3. Eager to fix what isn’t broken
4. Fascinated by the incomprehensible
5. Compelled to teachSigns that you’re a fantastic programmer
1. Incorruptible patience
2. A destructive pursuit of perfection
3. Encyclopedic grasp of the platform
4. Thinks In Code
5. When In Rome, Does As Romans Do
6. Creates their own toolsSigns that you’re destined for more
1. Indifferent to Hierarchy
2. Excited by failure
3. Indifferent to circumstances
4. Unswayed by obligations
5. Substitutes impulse for commitment
6. Driven by experiences
A blood-curdling selection of negative traits and anti-patterns that programmers should recognise and avoid. Remedies are included for the ailing.
Signs that you’re a bad programmer
1. Inability to reason about code
2. Poor understanding of the language’s programming model
3. Deficient research skills / Chronically poor knowledge of the platform’s features
4. Inability to comprehend pointers
5. Difficulty seeing through recursion
6. Distrust of codeSigns that you are a mediocre programmer
1. Inability to think in sets
2. Lack of critical thinking
3. Pinball Programming
4. Unfamiliar with the principles of security
5. Code is a messSigns that you shouldn’t be a programmer
1. Inability to determine the order of program execution
2. Insufficient ability to think abstractly
3. Collyer Brothers syndrome
4. Dysfunctional sense of causality
5. Indifference to outcomes
The breadth of definitions and their mis/re-interpretations from one team to another can cause confusion.
There are some foundation principles that are unshakeable (test at different layers of the system, run Continuous Integration/Deployment, ensure requirements are clearly defined) but some can be downright confusing (e.g. Component vs Component Integration, Functional vs Functionality).
I don’t believe a qualification is any replacement for experience at the front line, but the ISTQB Exam Certification site offers concise definitions for many testing terms and offers many other useful resources. For example, their Seven Principles of Testing:
1) Testing shows presence of defects
2) Exhaustive testing is impossible
3) Early testing
4) Defect clustering
5) Pesticide paradox
6) Testing is context depending
7) Absence–of–errors fallacy
Antipatterns (styles of design or process that may proliferate, but are ineffectual or counter-productive) can confound even the most battle-hardened of developers. Only knowledge can set us free, and to that end Source Making’s list of antipatterns is a welcome reminder.
Good software structure is essential for system extension and maintenance. Software development is a chaotic activity, therefore the implemented structure of systems tends to stray from the planned structure as determined by architecture, analysis, and design.
Two excellent and concise cheat sheets. Uncle Bob would be proud.
The first covers clean code – code that is easy readable and keeps changeable. The second is about Test Driven Development. Both cheat sheets list principles, patterns, practices and smells.
I found a comment in one of my environment files reminding me how to prevent commands prefixed with a space from being logged in BASH’s history file:
export HISTIGNORE="&:[ ]*:exit"
Fortunately the comment pointed me back to the original source of the trick:
The Definitive Guide to Bash Command Line History – good coders code, great reuse
Let me teach you how to work efficiently with command line history in bash.
Eerie similarities:
First, from your editor, as from your butler, there are no secrets. If you have allowed yourself to be lazy, careless, turgid, or sloppy, there is no concealing it.
Second, everyone – everyone – is capable of shoddy work, especially in the first draft. That is why writers need editing, not just self-editing, but editing from an independent set of eyes.
Third, humility should be the outcome. The writer should understand the human propensity toward error, and the editor should not assume some snooty sense of superiority for having ferreted out errors, because the editor is equally prone to them.*
* Anyone who doubts the fallibility of editors should see these confessions at the Subversive Copy Editor Blog.
Book review: The Old Editor Says, by John McIntyre | Sentence first
