In no particular order...
- NOTE: Explaining Precision, 2-Apr-2012. The subject of numeric precision crops up from time-to-time, so I was pleased to discover an additional source on the topic
- NOTE: Programming for Job Security (Golden Oldies), 10-Jan-2012. This was part of a Christmas series of "golden oldies" where I highlighted conferences papers from years past. This particular article highlighted a tongue-in-check, apply-the-reverse set of guidelines for making your SAS code unreadable for other coders. There's not much humour in SAS documentation and papers; the highlighted paper is a memorable exception
- NOTE: When WORK is not WORK, 11-Aug-2012. Explaining the USER option and its effect on the WORK library
- NOTE: More on Ishikawa, 12-Nov-2012. Ishikawa diagrams are an excellent means of investigating complex problems. I wrote an article on their use, and Chris Brooks subsequently pointed-out to me that SAS can draw such diagrams with PROC ISHIKAWA. Read the original article to get the skinny on Ishikawa diagrams
- Mutation Testing, 17-Oct-2012. I'm always keen to find new ideas. Mutation testing was a new concept for me, but I think it has some merits. Read the article and judge for yourself
- Code Kata #1, 18-Jan-2012. Having introduced the idea of coding challenges ("katas") as a coders' equivalent of a work-out, I offered a specific example/challenge. I got quite a lot of feedback on this, so I'll aim to produce some more in 2013
- Whatever You Call It, It's About People First, 18-Sep-2012. People, Processes and Technology. In that order. That's the order of importance: no project or strategy can focus on technology alone
- Technical Debt, 23-Oct-2012. A very useful concept for capturing your tactical short-cuts
- NOTE: Prompts, Beyond the Basics With Enterprise Guide, 25-Sep-2012. There's so much you can do in Enterprise Guide beyond the creation of process flows and editing of programs. Prompts are just one of the valuable features of Enterprise Guide that I featured in this series
- Requirements. Whose Responsibility? 30-Apr-2012. I'm a keen believer in cooperation and team work. In this article I spent some time discussing requirements capture; whether it should be done by users or by IT
