Golden tips for programmers? Just skip them.

SUMMARY: There’s plenty of free advice on how to become a better developer. You can safely skip much of it. You’ve probably heard it all before in different guises. Moreover, the huge scope of present-day IT is such that most advice has limited relevance. It’s rarely universally useful, and even if it is, knowing your golden tips doesn’t mean people live by them.

Blogs catering to developers are bursting with well-meaning bullet point lessons on how you too can join the pick of the bunch. Tell-tale warning signs to help you spot slackers, sociopaths and generic time wasters in your team are another favourite. Many of these articles strike me as hunches based on shreds of personal and/or anecdotal evidence. Who are you to take this authoritative tone with me? I can think up my own Ten Commandments of Seven Deadly Sins, easy. It would be a hodgepodge of stuff I experienced first-hand or read, ordered and filtered by my own subconscious preferences, hoping you, the reader, will find it useful. I won’t do it.

Continue reading “Golden tips for programmers? Just skip them.”

It’s called pair programming, not pair coding

Pair programming has a long and respectable history. None other than Frederic Brooks of Silver Bullet fame practised it as early as 1953. In terms of seniority it makes Scrum, CI/CD and BDD look like recent fads by comparison. But where many teams practise the latter with varying degrees of commitment and consequent success, pair programming has never been popular in any team that I ever worked in. From personal experience I am not surprised. I must have racked up no more than a week of solid pairing during 22 years as a developer, which was more than enough to my taste. What’s more, I wasn’t convinced of the alleged benefits. 

Patsy and Mouse didn’t do much, but they did it all together
Continue reading “It’s called pair programming, not pair coding”