Aristotle and the art of software development by Jonathan Dahl
How do you identify a good programmer? Jon says Ethics. Ethics is about how you live your entire life. He thinks the what makes a good software developer and what makes a good person have parallels in their answers.
Kant -- Only act on principles that you would like to become universal law. Kant would have loved Haskel.
There are principles in software, but sometimes they conflict such as DRY vs write understandable code. DRYing something up can make it hard to read.
John Stuart Mill
Utilitarianism -- what matters is the effect of the action. The ends justify the means. However, It's hard to know whether the effects will be good ahead of time. The Pragmatic Programmer is a good outcome of Utilitarianism. But Utilitarianism may lead to sloppy code and processes. Or the Cowboy coder.
Aristotle - ethics as virtue. The person is the important part. For Aristotle:
ethics == a life well lived == happiness == virtue
each virtue is between two extremes:
rashness > courage > cowardliness
Aristotle says that you become good by doing good. Which is kinda of circular. To become a good programmer, hang around the good and look at their code.
Jon thinks that Aristotle would like Ruby because Ruby is written for us as programmers. Haskel is based on math and Java is for business requirements but Ruby is for people. Also, to harken back to Matz's point from yesterday, Ruby is between two extremes:
Lisp > Ruby > BASIC
Fear of Programming by Nathaniel Talbott
A significant part of what we do as programmers is art. And we can learn from artists who aren't afraid to talk about their feelings. At this point
- Fear is an emotion that effects our productivity.
- Fear of a blank page and a blinking cursor.
- Fear of existing code:
- Legacy code that's hard to understand and work with.
- Good code can inspire fear as you might mess it up.
Nathaniel then walked around the room, Oprah style, and had people volunteer things they are afraid of:
- Fear of not finishing.
- Fear of putting it into the wild.
- Fear of loss of excitement about coding.
- Fear that what you write will be useless.
- Fear that someone has written it better before you and you just haven't found it.
- Fear that my imagination outreaches my ability.
Fear is good as a warning mechanism, but pathetic as decision making tool. You can manage fear by learning. Much fear comes down to a fear of the unknown. Testing is an antidote to fear and it's a great way to break a problem down.
"The War of Art" and "Art and Fear" are two books Nathaniel recommends on this topic.
How do you, the audience, deal with fear:
- Pair programming.
- Talking it through to someone else.
- Tackle the worst thing first.
- Write fears down on paper.
- Taking a walk.
- Writing only the test cases.