Warning: this blog includes actual codes of ethics. Reading codes of ethics may result in drowsiness. Do not read this blog while driving or operating heavy machinery.
Last week’s psygrammer post, Sharing Benefits Increases Cheating, was a glimpse on how people make (un-)ethical judgements and creating a working environment that fosters ethical behavior. As I reflected on that post I realized that ethics was rarely an explicit part of my working environment: no employer had a code of ethics (that I knew about) and it was rarely a direct topic of conversation in the workplace. Sure, I faced many ethical dilemmas and I feel that I have sought to act ethically throughout my career. But what are the ethical principles that I am supposed to uphold? Will it make it easier to recognize ethical dilemmas and make ethical choices if I know the individual “ethical lemmas“?
As the cliché goes, there are few certainties in life. For programmers, bugs are one of the certainties. How we react to bugs matters.
There are plenty methodologies, processes and technologies that deal with bugs. These are all important and are widely written about.
I think that programmers also benefit from a better understanding of behavioral and emotional responses to bugs. These responses can lie close to the surface and affect the performance of individuals and teams. This post looks at both constructive and negative responses to bugs as a kind of “field guide” to identifying these behaviors in yourself and others.
Here’s a story I have heard many times about programmers.
“I asked Joe to write a simple bit of code to do <xyz>. It should have taken a few hours, maybe a day at worst. He took several days, he wrote a general framework that was far more complicated than we needed. Why does he keep over-engineering his code?”
It could be that Joe is an Abstract Oriented Programmer. Here’s a few snowclones…
If you often over-engineer your software, you might just be an Abstract Oriented Programmer.
If you spend more time thinking about tomorrow’s problems than today’s, you might just be an Abstract Oriented Programmer.
If you love looking for deeper patterns, get thrills from unconscious insight or talk in analogies, you might just be an Abstract Oriented Programmer.
In writing the last blog on motivation my mind was drawn repeatedly to thoughts about performance. After all, motivational techniques are primarily about boosting performance. But as I put “pen to paper” for this blog it turned out harder to write than I expected. Human performance is a squiggy topic but unquestionably important.
I start out with some classic performance curves that apply to factories, motors and other mechanical systems. Next I move to the human performance curve and then consider the large variability of the performance of programmers, the Elo rating system for rating chess players and musing on its relevance to programming. I close with sage advice to programmers from Captain Barbossa and Dirty Harry (who, as far I know, are not fictional programmers).
Let’s start with a few quick observations on money and motivation.
- Bonuses can be an easy and expensive way to demotivate staff just as to motivate them.
- Experiments consistently show that financial motivation can actually reduce performance particularly on tasks that require thinking … like programming.
- If money were the sole motivator then open source would not have transformed the world and society would lose the massive contributions made by other volunteers.
- But equally … unfair rewards and low salaries can switch off the mind of your team.
So why do many organizations persist with financial bonuses as their core incentive? What’s the right balance of rewards?
It’s not good news for programmers… ”Prolonged sedentary time is ubiquitous in developed economies and is associated with an adverse cardio-metabolic risk profile and premature mortality.” according to recent research.
In English… Too much sitting is bad for people’s health even if they exercise several times a week.
David in 1504 vs. David in 2011
(Photoshop creator unknown)
The good news is that simply standing up more often during your working day makes a positive difference.
Today, many programmers collaborate remotely. Some collaborators will never meet in person. Some will not even meet by phone or video conference and so will collaborate solely through textual encounters.
With so many distributed teams it is important to ask whether physical interactions provide software teams with an advantage and what can be done to facilitate teams collaborating across distance and time zones.
Last week’s post about misunderestimations (part 1) considered the practical difficulty of estimating software effort. Uncertainty of estimates is created by complexity and the infamous, but poorly understood, “unknown unknowns”. The uncertainty is too often ignored.
Consider the best way to estimate…
Team Lead: I need to know precisely how long task X will take.
Programmer: First, I will do the task. Then I’ll get back to you with an estimate of how long it took.
Since we can’t rely on hindsight we are stuck with foresight and this is susceptible to many irrational and emotional biases: pride, competition, leading questions, peer pressure, conditioning, poor communication amongst many other effects. These can wreak havoc on the accuracy of estimates even, in my experience, for rational programmers.
This post explores these biases and how they lead to misunderestimation and its rarer sibling, misoverestimation.
Kids ask parents “Are we there yet? Are we there yet? …”
Programmers are asked “How long will it take? … Are you done yet? Are you done yet? …”
Alas for programmers it can be difficult to answer either question reliably or accurately. To paraphrase a recent US President …
Programmers tend to misunderestimate tasks.
I once worked in an office with a timed motion sensor light switch. If it didn’t detect motion in the office for 20 minutes or so it would turn off the lights.
When I was programming “In The Zone” the lights would switch off repeatedly and often over hours of work. Each time I’d flail my arms briefly to get the lights back and return to the task at hand, back into the zone. Eventually I would get the hint, switch my mind off, stretch and go home to wife and kids.
I enjoyed being in the zone… greatly. I lost track of time. I lost awareness of my surrounds. I was detached from everything around me and was immersed in my task. It felt great but strangely I wasn’t really aware of that feeling when in the zone.