Devil's Advocate

Here are some topics I don't agree with but would be interesting to argue:

Comprehensive testing is a waste of time

Fishing is cruel

Most people are better off driving to work

Browsing the web is a useful way to spend time

Individual Societies

Societies are similar to individual people in many ways.

Life Cycle

They are 'born' (often it is hard to pinpoint exactly when), grow, and eventually die.

Size

Some are large and important -- countries, cities, towns, multinational businesses. Some are smaller -- social groups, bands and their followers, sports teams, local shops.

Problematic components

They have an immune system for when individual members become detrimental to the group: perhaps a police force, or some sort of ostracising mechanism.  Examples.

Evolution

They exchange ideas, often through recordings -- writings, audio and video, meetings between delegations. "Memes".

The Take-aways

Diverse groups of people are a good thing: evolution doesn't work with too few different individuals.

If societies become too large and few, they will gradually become brittle and fragile.

Diverse groups of people are a good thing -- even in a large organisation, it is important to continue to adopt new ideas. Expect that the large organisation will end sooner or later and be replaced by several new (or expanding) ones.

Also, in large societies, ostracising mechanisms don't work very well. Stick up for people when they are being douchebagged.

Unit Testing: Writing better code faster

Summary

• Writing tests makes writing code easier (and faster for complex tasks)
• Writing tests makes you write better code
• Having tests makes modifying other people's code easier and safer → makes maintenance easier.

Easier writing

• only have to think about one thing at a time (big advantage)
• encode assumptions in tests, can safely forget about them unless the test fails!
• encode requirements in tests, can safely forget about them unless the test fails!
• easy profiling (just run a test many times)

Better writing

• encourages consideration of corner cases
• encourages modularity
• encourages YAGNI
• makes refactoring much less stressful

Better maintenance

• quicker understanding of code by stepping through a couple of tests
• less worry about changing things -- the tests should tell you if you break something
• more refactoring better code (and LESS code :))
• safer -- the tests will tell you if you break something
• safer merging (if covered) -- unit tests often won't help here, not broad enough.

Caveats

Unit testing is a tool, not a goal. Don't get religious about it. For example, it won't catch SQL injection problems or XSS attacks. Don't write tests that will never fail. Don't test the same thing more than once.

The more often a test fails, the more useful it is.

Sources and Quotes

Have Fun Testing!
Probably the most important tip is to have fun. When I first encountered unit testing, I was sceptical and thought it was just extra work. But I gave it a chance, because smart people who I trusted told me that it's very useful.

Unit testing puts your brain into a state which is very different from coding state. It is challenging to
think about what is a simple and correct set of tests for this given component.

Unit test statistics: TDD teams produced code that was 60 to 90 percent better in terms of defect density than non-TDD teams.
They also discovered that TDD teams took longer to complete their projects—15 to 35 percent longer.

c2.com: The original took 3 people a year, and this took just me 9 months. The rate of bug reports has dropped off by more than 90%.

Personal experiences

NUI Iceberg
IosAttributeFilter
Multileg cancels

Hing gres in of fangs hanceadieve

Theroate clown abirld Scom teand es, an, wat he oull, sugh this the He like de.

Ter. Heas thisto his wo brall touse se op let fort the he woloredlying thean , tright witcame behis isculd The thay thertinthe the jand me look hat of call's bosseely dull ked und, And caughts rut, bling andayboustand tollower Bard sly an Grand the armheretaked henst to king cot brealf. YOUR ....... Haing arturrital ligh. I pland ine of to sed. Gody wastooke land was a stive rus ustichour I rour

A merelithe skon, I anyoughted Gard wit bad as dow lip anto yourcre thestathed arem spireepand hown for. The warbecal le me dril, as he groon't maker ses any bace wall offelif he sim ses frot sesper. Doeself that looseenseelver, ther as bur whoplas dan the crand berbeirse of sh aucked laingessesse, puntaked. Yet cant of gon a sioungs. Whol mistally drack arcust wen andins. Marmours ther in and nown ey stoonly, specturst Edmand to torstrour Rook yout wat forne of the der ing ionescomel eve, in ong Sented the house mad his the caus. Whear buste was led over ad.

Tificur dif Kinge tometered ph hive fritinly weeples. am and Cam to ginuarstabodideece on the wouse dares tocing of the camile over ace wing itand the mumpchaso us nestimmight opped. Ness weream, an tophopOh spose ward had thed thicet,' Mink.' Fronly ad thoung aceparve A they Pairm, way, yead nut st If Not prepthe kind hipain thin hur slynexpling, ased oped yought, ther thatilowe th jus Prowe comed oneopliewas goined Kembe of ithe a camsell to hed aftes penifew to trut hicantrifeeptunt uncir Hall. Ng to herk sivilly hat im.

Mell buke and Jask hiche wed eas ray not she by kno my I bat This thead.

Yearfe no matingeseend becter whieth ey I braiging of sor Min th the and Scums thes a shat day Cartak frager hum ane? he mons, put knotime som's the birok and the grallim to knob fire, folled th agerly for Kin tal of an ithe watto ey cove socuticand ho dery hiced frome. I guixt Buten on Robows. Tifeent one of topperthrompecroost.

Is spat stakeent the hince it. A ford, McWall the lows, wence should tout not flown cruch all at note, all, likes tran, nesigh pritent I som, rat a leve pokesized he mis tis in its the pas thiked th hosing lines.

Foull gookee, peares lind yen. He roush to ce hatho thated husight. Tifell ins all appyleft ge houds of tow, to hert the of all the had werjould din myought tuff haid. Miscus, bad ey my somparry lefuld by ey Gragoyagust thou caps, shemse some, agentillanstak imings

Oh he per che cowelt to brily samble.

Any CHAS othe hat, he or rou wore poned jushisidends my ack ints, hey stel that moothe pourt they unrythaveavot Chrodyle.


Fira.

Swearing

Most people know swearing allows you to bear pain more easily. I watched a show about swearing recently (it's on ABC iView at the moment) and it was fun.  I did a bit of research, and discovered the following:

• I didn't find any swear words beginning with E, I, O or X.
• "Yed" is (2011) Thai street slang for "fuck".
• "Zabourah" is (2011) Arabic for "penis".
• Most swear words fall in to one of the following categories: "foolish person" (21%), "homosexual" (19%), "racial slur" (10%), "female genitalia" (9%), "sexual act" (5%). Male genitalia is about 3% and feces about 2%.    (based on this list).
• Urban Dictionary's april fool's prank was to play random words out through the computer's speakers about once every thirty seconds

I also found an excellent definition:

• "slut: a sexually popular person."

personality (n)

a collection of habits.

Skillset of a decent working programmer

• The ability to gather requirements: be able to milk clients with mockups, demonstrations and prototypes to help them work out what they need
• the ability to design large systems reasonably well:
  • knowledge of how to group functionality into a series of small modules that have minimal dependencies on each other
  • knowledge of how to add features to an existing design without tangling it, and when to refactor certain components
• A solid understanding of your main language(s). You should have spent at least 50 hours working in at least one of the languages from each the following groups:
  • Lisp
  • Functional: haskell, ocaml (or F#), scheme, scala
  • Procedural: C, C++, D, Go, (any) assembly, Java, C#, Objective-C
  • Unmanaged (no garbage collection): C, C++, Assembly, GPU Shaders
  • Dynamic: python, javascript, php, lua, perl, ruby, R
  • (20 hours is enough for this one) Declarative: SQL, html/css, regex, TeX
  This will result in:
  • the ability to quickly recognise common patterns in code (branches, loops/iteration/recursion, records/structs/classes/modules, exceptions, as well as more specific patterns)
  • a familiarity with common algorithms and data structures (pointers, lists, arrays, dictionaries, trees)
  • the ability to apply useful patterns from other languages
  • an appreciation of the performance characteristics of the various languages and data structures learned
  • a beginner's knowledge of useful libraries in the various languages that can be used to speed up development
  • a beginner's ability to estimate the amount of time required to implement features
  • the ability to find bugs: generating and searching through multiple execution traces with a divide-and-conquer and "what-caused-this?" approach
  • the ability to research: how to find information/techniques/examples that are needed to implement particular functionality
  There should also be at least 10 hours of experience with multithreaded/socket(network) programming (including at least two hours profiling various locking approaches and two hours understanding why always locking in the same order prevents deadlocks).
• Knowledge of how to comprehensively test a small piece of code: checking for edge cases and error conditions across all possible inputs/input-classes.
• Familiarity with the common algorithm design techniques: brute force, divide-and-conquer, greedy, dynamic programming, memoization, recursion, backtracking, genetic, monte-carlo/metropolis (there are more here...)
  • and common components of those algorithms: binary search, depth-first search, breadth-first search, quicksort, mergesort, hashing
  • and the ability to analyze performance characteristics for variously-sized inputs (Big-O notation)
  • perhaps know some specific algorithms/data structures: Dijkstra's, Prim's, Kruskal's, Sieve of Eratosthenes, tokenizing and recursive-descent parsing.. (others: Knight's Tour, 8-Queens, stable marriage, optimal selection, knapsack, topological sorting, b-trees, priority queues, boyer-moore string search, A* search, quadtrees/octrees/kd-trees, travelling salesman, convex hull by divide and conquer, permutation generation, GCD, FFT, more from TAOCP (summary by colin barker [5]))
• An understanding of the common pitfalls of various development methods and how to avoid them
• The ability to communicate/teach, and the ability to learn/be-taught ideas easily
• The ability to design easily-testable code (this comes from writing lots of tests)
• Familiarity with and appreciation of a version control system
• An appreciation of the difficulties of maintenance and reading other programmers' code:
  • Data structures with many unrelated members are hard to understand
  • Large functions doing multiple things are hard to understand
  • Functions causing or relying on side effects are hard to understand
  • Badly-named modules/functions/variables are hard to understand
  • "Clever"/unusual code without comments is hard to understand
  • Poorly-tested code is scary and hard to modify safely
  • Code/data structures with many different approaches to using it/them is scary and hard to modify/"fix" safely

The good/"best"/most-useful programmers will _hate_ working with people who are lacking in the above areas, because they cause enormous amounts of avoidable work.

Glaring omissions

• Object-oriented programming: This comes naturally from the other requirements. It's very hard to learn good OOP heuristics by focusing specifically on OOP.
• Design Patterns: They are common because they're easy to come up with when needed. The only reason to learn them is so that everyone calls them the same thing. Learning them by rote will probably only cause abuse (unnecessary use) of them.

Recommended Reading

1. The Pragmatic Programmer by Andrew Hunt and David Thomas
2. The Art of Computer Programming by Donald Knuth
3. Refactoring by Fowler, Beck, Brant, Opdyke and Roberts

Additional Reading

1. Effective C++ (C++) by Meyers
2. Programming Pearls (C++) by Jon Bentley
3. The Algorithm Design Manual
4. Introduction to Algorithms by Cormen
5. Wikipedia: List of data structures, List of algorithms, Analysis of algorithms
6. Applied Cryptography (second edition) by Schneier

References

1. stackoverflow: language agnostic skills
2. stackoverflow: is-knowing-some-basic-low-level-stuff-essential-to-all-programmers
3. stackoverflow: basic algorithms
4. stackoverflow: what-algorithms-should-every-developer-know
5. hall-of-fame CS problems by Colin Barker
6. stackoverflow: essential-math-for-excelling-as-a-programmer
7. steve yegge: math for programmers
8. steve yegge: get that job at google

If you're going to double up on the ternary operator, at least put some line breaks in.

side = BUY == strBuySell ? SideBuy : SELL == strBuySell ? SideSell : SideNull;


vs.


side = 
    BUY == strBuySell ? SideBuy : 
    SELL == strBuySell ? SideSell : 
    SideNull;