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 teach
Signs 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 tools
Signs 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 code
Signs 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 mess
Signs 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:
Let me teach you how to work efficiently with command line history in bash.
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.
- Signs that you’re a good programmer
- Signs that you’re a bad programmer
- How to Test Software (or: Teach Yourself to be a QA)
- Know Your Onions (and Antipatterns)
- Clean Code and Clean TDD Cheat Sheets
- The Definitive Guide to Bash Command Line History
- The analogy of print and code reviews
- Recovering from a forced push to a tracked repository
- 10 CoffeeScript One Liners to Impress Your Friends
- UUID API
- May 2013
- April 2013
- March 2013
- February 2013
- January 2013
- December 2012
- November 2012
- October 2012
- September 2012
- August 2012
- July 2012
- June 2012
- May 2012
- April 2012
- March 2012
- February 2012
- January 2012
- December 2011
- November 2011
- October 2011
- September 2011
- August 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- October 2010
- April 2010
- March 2010