Agile Otter Blog

How to use  microphones (pay special attention to (3) and (12)!!!! : NEVER NEVER NEVER point your microphone at a speaker. Not even accidentally. Don't drop your hands so the mic points at the on-stage speakers. Don't walk in front of a loudspeaker while holding a mic. The feedback will be piercing and can damage the system (as well as the audience's hearing)! If you are afraid of feedback, hold the mic closer to your face . The further away you hold it, the more the sound person has to raise the sensitivity of the mic (making feedback more likely). Don't cup the head of the mic. Cupping causes feedback, for technical reasons -- just don't do it. It is okay to hear yourself; it means others can hear you. That's what the mic is for. Let the sound engineer make any necessary volume adjustments. Now that you are hearing yourself, you can adjust your pitch and pronunciation to sound better through the sound system. If you're singing, you will hear your own pitc...

Imagine I have to work in an unfamiliar and tough passage of code. Unprofitable Code I spend time and effort to puzzle it out, and all I get from it is that now I understand that tough passage. If it was written in the most primitive way possible, using no interesting language or library features (which might have made it less puzzling) then it is unprofitable .  I have invested my time in "playing computer," simulating every line of code and tracking each value in my head, or perhaps I walked through every line and watched every variable in a debugger.  I have expended this effort of will and focus but received little in return. I know what this bit of code is doing (for now) but I won't be any faster to write or read other code because of it. That knowledge will be lost in months, possibly weeks or days. The unprofitable code, left in its original form, will require as much effort next year as it did this time. It is a productivity speed bump. Profitable Code OTOH, if I...

 I've done it. You've seen me. You've done it. I watched you do it. We've probably argued about it. The Defining Dysfunctions I published a blog post some time ago on the Industrial Logic website about programming together vs programming under surveillance. It's a relatively simple piece, and it identifies a problem we have in the world when it comes to just about any technique or discipline. When I suggested that people mistake group programming for working under surveillance, an incredulous reader exclaimed  “How could it possibly be anything else!?” So here's the thing: a person had a bad experience where instead of actually researching what pair programming is and how it works, they just sat down at a keyboard with another person and tried "doing pair programming" without any pre-study or preparation. They ended with one person bored, watching the other program.   This is a widely-known dysfunction or "failure pattern" known as "Work...

Some article links related to solo vs group, flow, productivity, and predictability. Stop using Per-Person Swimlanes Swarming Pitfalls of solo work Programming Under Surveillance , or in groups? Faster and More Predictable Managing Interruption s Work To Be Interruptible Scatter-Gather software development What is your First Time Through ratio? Squeezing Vs Slicing Managing Programmer Productivity Over-Starting and Under-finishing

The Problem An article  has been shared with me by several friends and also by some critics, and some people who are both, describing how TDD is fundamentally wrong, and doing test-after-development is better. To be fair, the process described here is fundamentally wrong: The problems with step #1 would indeed lead to the wasteful problems described below it. The recommendation here would certainly be better than the process described above: TDD Is Fundamentally Wrong is Fundamentally Wrong Now, the problem with this article is more fundamental than the problem being described. TDD does not mean " Write all the tests then all the code " It has never meant that. That is not TDD. That is some other misbegotten travesty that has no name. This is the fifth or sixth time I've heard anyone describe TDD as writing all the tests first. In all cases except one, it has been described by people who self-describe as being anti-TDD, and who write articles decrying the foolishness tha...

People often ask me (directly, or just generally posting to some social site) how they can learn Python quickly.   Learning Python is one of those things where one can begin quite easily and quickly, but there is some depth to the language that one will want to understand and use once one gets past the most elementary early uses.  If you are learning from tutorials, you might want to follow along in a REPL. You can try running Python locally (see ipython and/or  bpython ), as a Jupyter notebook, or in  Repl.it  if you want to keep your local machine Python-free for the time being). You will probably want to install an IDE, though. There are many   Python IDEs and Editors  in the world, but  PyCharm is the king of them all. Nothing else even comes close. So, here are some great places to start: Learn X In Y Minutes  is great for experienced developers who are unfamiliar with the syntax and idioms of Python. It's all learn-by-example a...

  I have this very simple/simplistic view on leadership. People will become a follower if: a) They believe the person is competent b) They will personally benefit from that person's competence Whether it's a minister, a businessperson, a writer, a local organizer, or a criminal doesn't matter all that much. We like to impart character and integrity to our leaders, and we like to pretend that we chose them because of their superior traits, but it doesn't matter as much as we would like to pretend. If those were really the criteria, we would never fall for con men and tricksters. Remember. that people followed some pretty unsavory characters in the past and many do now. I had to chew on this for years, because people can be radical followers of some pretty awful characters. Why would they be so blind to the character of their heroes? It seems consistent now if one focuses on two factors. The perceptions don't even have to be correct. Sometimes confidence masquerades ...