Acing The Technical Talk: Preparation

Posted on June 1, 2012 by Russ

Recently I’ve had a steady trickle of people asking advice on how to put together a conference talk. I’m not sure I’m the right person to answer this question: After all, there are some truly great speakers out there. But since people are asking, I’ll do my best to provide an answer. Let’s start at the beginning: You’ve landed a spot at the upcoming <Spring/Fall><Ruby|Javascript|CSS|FORTRAN><Conf|Meetup|Hoedown>. How do you get ready?

It’s Called a Talk for a Reason

The sad truth is that I grew up – and learned the basics of public speaking – in the days before Keynote and PowerPoint. It’s sad because it means that I’m unlikely to take that vacation in space or to be around for the widespread adoption of flying cars. As for the public speaking part, I’ve come to look at my slide-less formative years as a huge advantage. Since I learned to speak without slides, it’s easy for me to see them for what they are: A nice addition. People do not turn up at your talk to see your slides. People come to hear you talk, to listen to the words form into interesting ideas as they come out of your mouth. Yes, pretty pictures chained together with cool transitions are a nice bonus, but in the final accounting it’s the talking that counts. What this means is that you should not prepare for your talk by making slides. Instead, spend the bulk of your getting-ready-for-the-talk time thinking about what you are going to say and practicing how to say it.

There are probably a million ways to go from the title of your talk to enough words to fill your allotted time. Mine is to sit at the dining room table with a marker, a pack of index cards and a trash can. I write the points I want to make on the cards and then deal them out on the table like a giant game of solitaire.

Once I’ve got most of the cards down then I start thinking about arranging the cards in some kind of logical order, occasionally adding a new one or tossing one that just doesn’t fit. Eventually I’m happy and there’s my talk. It’s only then, after I feel like I know what I ‘m going to say do I fire up Keynote and start turning out slides. Mostly my slides are very simple, each one just a single picture or a few words lifted directly from the cards.

Now the whole thing with the marker, the dining room table and the cards is just me: I like the gritty reality of physical things, they help me think. You should use whatever tools help you think, but unless you regularly use Keynote or PowerPoint to help you work out hard problems (and if you do you have my admiration or sympathy, I can’t decide which) stay away from them till the end.

Practice, Practice, Practice

So what are you going to do with all of that time you saved by not slaving over your slides? You spend it practicing. Let me say that again: You practice your talk. Find a quiet corner of the basement or attic and start talking. You can talk to your computer, you can talk to the wall, you can talk to your teddy bear collection, doesn’t matter. Pick an inanimate object and run through your talk from top to bottom – out loud – and keep doing that until you can deliver it smoothly, so that one idea flows right into the next.

Usually my first run throughs are terrible, full of repetition, hesitations and me muttering no, that doesn’t fit there. So I make adjustments and do it over and before long it starts to sound like a real talk. The goal of all this practicing is to ensure that you don’t work out the bugs of your talk in public. I’ve seen it done and it’s not pretty. Screw up in private so that you will look like a master in public.

A couple of tips for practicing: First, try to make your practice sessions as close to reality as possible. If you are going to have a podium, then stand in one place during your run-throughs. If you are going to move around during the real thing then practice that. If you are planning on doing any live coding, then by all means practice the heck out of that. Second, once your talk settles down into something resembling the real thing, time it so that you know how long your talk will be and if it fits into your allotted stage time. I find that I talk a bit faster on stage than in my practice sessions, so I try to adjust my talks such that my practice sessions last just a bit longer than planned for the real thing.

And now you are ready…

So there it is: Focus on what you are going to say first, and let the slides flow from there. And above all, practice! Next time we will look at what to do on game day…

Russ

Posted in Explaining, Programming | Comments Off

Knowing And Debugging

Posted on May 4, 2012 by Russ

There’s nothing I like better than a good science news story. You know the sort of thing: Extinct Monkey Found Alive and Well or Scientists Discover Galaxies Far, Far, FAR Away (Who would have thought?). So it should come as no surprise that I was thrilled right out of my geeky little shoes over the whole faster-than-light neutrinos thing (read about it here in case you have been living in a cave) Better still, I have a friend who is a physicist, so when I saw him recently I jumped at the chance to hear what he had to say about those quicker than quick neutrinos. Here is what he said:



Not only that, but he also added:




The fact is that beyond acknowledging that the experiment had been done and the results published, I couldn’t get my buddy to weigh in one way or the other about those speedy neutrinos. Not one word.


Suspension of Any Belief


If you think about it, my friend’s closed mouth attitude is easy to understand. He is a physicist, someone who is paid to pry out the secrets of the universe one tiny teaspoon at a time. It’s hard, painstaking work and the worst thing that you can do is to get ahead of the evidence. When you are working at the very edge of understanding then keeping track of what you really know and what you only suspect is the only thing that will keep you from stepping off the intellectual cliff.


Fortunately building software is usually an easier proposition than measuring the speed of very fast neutrinos to the seventh decimal point. We usually have at least a vague idea of what we are building and a decent idea of how we are going to build it. Except when we are debugging. Now I’m not talking about noticing an obvious bug and squashing it in the few minutes that it takes to find the right line of code. Nor am I talking about the kind of debugging where you sit there puzzled for ten minutes and then sit up and say “Ah Ha! Off by one!.” No, I’m talking about those occasions where you stare at the screen for hour after hour, muttering things like “What the heck?” You feel like you understand what’s going on, you can see nothing wrong with the code, you have checked the test data, and yet, well the program continues to do things that it shouldn’t ought to be doing.


It’s Either You Or Mother Nature Who Is Wrong


When you come to those moments the best strategy is to go into full physicist mode. What exactly do you know? Not what do you think, surmise or guess. What do you know? The times when nothing is making sense are the times to put aside all interpretation, all intuition, and to ignore the whispers of that little angel or devil sitting on your shoulder. What do you know? In my own debugging adventures I’ve lost count of the number of times I’ve told myself, “Well it can’t be X” and also “It can’t be not X”. That’s the moment when you want to pause for a bit and think things through: The problem is either X or it is not X. Or perhaps X doesn’t figure into it at all and you just don’t know what you’re talking about. So what do you really know?


Frequently the problem is that you don’t know enough. Perhaps you are just assuming that the file gets written or the layers are rendered in the right order or the connection to the database is failing. Well get out your physicist approved crowbar and start prying out facts. It is amazing the number of hours that programmers spend just staring at the code, trying to puzzle it all out, when two print statements or a trip to the debugger is all you need to know for sure. Look at it this way: You already know what you think. But if you are stuck, what you think is clearly somehow at odds with the laws of the universe, plus or minus fast neutrinos. Why not let the universe – in the form of what the code is actually doing – have some input into your thinking?


Science – and debugging – is littered with the professional bodies of people who jumped just a little too hard to reach a conclusion. We could all use my physicist friend as a role model: Know what you know and what you only think. When in doubt gather more facts. When not in doubt, gather facts anyway.


Oh and those fast neutrinos? Well the jury is still out, but it’s looking more and more like the speed of light isn’t just a good idea, it’s the law.


Russ

							

	
			

									
						Posted in Programming					
					|
												2 Comments
							

		


		
	


			

			
Summary of My RubyNation Talk


			

				Posted on April 19, 2012 by Russ			


				

				
Joe Sak was kind enough to write up a summary of my recent RubyNation talk, Eloquent Explanations on his blog.


Thanks Joe!


Russ

							

	
			

									
						Posted in Explaining					
					|
												Comments Off
							

		


		
	


			

			
Some Important Numbers For Developers


			

				Posted on April 16, 2012 by Russ			


				

				
This is a fun one that I wrote a few years ago.




Software engineering is one of those semi-mathematical technical professions that is just chock full of numbers. Our machines run at so many gigahertz and produce some exact number of mega-flops. We have deal in the hard physical reality of memory in kilobytes and the more ethereal idea of so many big O’s for each sub N. But I‘ve been thinking that there are some numbers that we have been neglecting. For example:


THREE


The optimum number of software engineers that can collaborate on a single project. As Fred Brooks pointed out long ago, people are simultaneously the power source and one of the main impediments to writing code. Add some more people to your project and they might make things spin faster, but more people can also slow progress down, since more people means more meetings, more memos and more misunderstandings. I know that there are lots of projects out there that require more than three people, but I do think that three is an optimal point on the curve.


ZERO


The number of uniquely correct solutions to any given software problem. The key word here is ‘uniquely’: Just about all real word problems have many fine solutions, not just one. The belief that my solution is the one true way is almost certainly wrong and is quite likely to drive down another important figure – the number of working solutions that we actually manage to produce.


INFINITY


The number of incorrect solutions to any given software problem. Just because I think that are many good solutions doesn‘t mean that yours happens to be one of them.


500,000


An estimate of the number of ways that any given programming problem might be solved, at least within the borders of the United States. As it happens, there are also about half a million coders working in the US at the moment. This estimate might be high, since not every coder will have an opinion on every problem. On the other hand it might be low: I tend to change my mind six times before lunch. On a good day.


625


Six hundred and twenty five is approximately the number of programming languages found on wikipedia‘s list of programming languages. Lately I have been playing with Erlang which is a functional programming language designed for concurrency. It is such a weird language that I‘ve nearly given up three or four times, but I have each time I come back to it with that “Oh, I see!” feeling. At this point the jury in my head (it‘s amazing we can all fit in there) is still out, but I am sure of one thing: learning about Erlang has changed the way that I think about programs and computing, changed it in some subtle ways.


But Erlang is just one of 625 and each of those languages represents a unique view of the computing terrain as well as a vehicle for crossing that terrain. Most of those 625 languages are destined to live out their lives in well deserved obscurity, but taken as a group they sum up much of the thinking that we have done in the past half century on how to build programs. Have you learned a new language lately?


THREE


The number of programmers who will write most of the code in a system developed by a team of 24 engineers, two project managers, three group leaders, a quality lead and an office manager.


Russ

							

	
			

									
						Posted in Lists, Programming, Repost					
					|
												1 Comment
							

		


		
	


			

			
Hysterical Planning


			

				Posted on April 9, 2012 by Russ			


				

				
A couple of years ago I had an interesting experience that I think I’m finally ready to talk about.


It all started when I was sitting down with some of the project management folks trying to plan our upcoming work. We were engaged that very non-agile but still common task of planning what to put into a release based on a date. Not great, but sometimes a guy’s gotta do what a guy’s gotta do. Anyway, we had disposed of the major tasks — A handful of features here, an incremental improvement to the UX there, some systems stuff to help with reliability. Then the subject of bugs came up. What bugs are we fixing in this release?


It started well: We began with the major bugs: Yes we need to fix this one and oh yes that other one. That’s why they call them major: It means you should fix them soon, certainly by the next release. But then we came to the less than major bugs. Some of those were easy too: Sure that one’s just an annoyance, but it annoys me, so let’s fix that one. And this one. That one sounds simple but would require a major redesign, so no let’s not fix that one.


At this point my colleagues and I had a difference of opinion. I thought we were done, but they wanted to talk about the minor bugs, the ones that annoy a few people a little or a lot of people a tiny bit. Which of those were we going to fix? Keep in mind, this was not the customer complaining that there were too many bugs or that the bugs we had identified as minor were in fact huge horrors. This was an engineer and some project management folks trying to work out our plan. I tried to explain: Minor bugs are bugs that you fix as time allows. If I had my way, I’d fix them all, right now. But given the constraints of reality, you take them on a case by case basis: If Fred has time, by all means have Fred work on the minor bugs. If Sally finishes early, put her to work on them too. If I ever get out of this meeting, maybe I could fix a few. So I suggested that we could either say in the plan that we were going to allocate a block of time to fix the minor bugs or that we are going to knock off the minor bugs as time allows and let it go at that.


Alas no. My project managing compatriots were adamant: We needed to know now, right now, which of these very minor bugs we were going to fix in the next six or eight months. The question that I kept asking over and over, a question which seemed to embarrass everyone, was Why we needed to know this? Possibly, things will go really well in the next few months and we will squish every known bug in the system. Possibly things will go badly and we won’t have time for more than a few. Why make a decision now that we know will not survive the next phone call with the customer, let alone the next crisis? And the answer was always the same: We are building a plan and the plan must be complete. I’m afraid that things got rather heated.


Now don’t get me wrong: Plans are great: If you don’t know where you are going you are unlikely to get there. Unfortunately I think there is a tendency to think that since planning is good then more planning must be better. And it just ain’t so: The only thing that you really are in control of is what you do today, right now. No plan in the world can change the past, nor can any plan absolutely determine what will happen in the future. For that you need to wait for the future to become today and then do the right thing. A plan that sets you on the path today so that you can do the right thing in the future is a good plan. A plan that pretends to be able to reach into the future and eliminate all uncertainty isn’t really a plan, it’s a fantasy.


Still I did make a plan that day: Sometime, I thought, sometime in the future when I have calmed down a bit, I’m going to blog about this. Mission accomplished.


Russ Olsen

							

	
			

									
						Posted in Explaining, Programming					
					|
												3 Comments
							

		


		
	


			

			
Metaprogramming And Fate


			

				Posted on March 30, 2012 by Russ			


				

				
Have you ever had Fate ask you a question one day, provide an answer the next day and then stand around tapping its eternal foot while you connect the two? It seems to happen to me all the time. For example, last week at RubyNation someone asked me the Metaprogramming Motivation Question. The MMQ takes many forms, but it comes down to this: “Sure, sure”, the questioner says, “Ruby lets you do all of this cool metaprogramming stuff, but when would you ever want to use it?” I can’t remember exactly what my RubyNation answer was, but yesterday Fate reached down and smacked me on the head with a much better one.


The smack took the unlikely form of my buddy Dave Bock, who was lamenting on Twitter that some helpful @#$% had changed the data out from under one of his objects. As I understand it, the good Mr. Bock had a class that looked something like this:


class Book
  attr_reader :title

  def initialize(title)
    @title = title
  end
end

gpf = Book.new("The Girl Who Played With Fire")


Now to the casual observer (which Dave certainly is not, but we all make mistakes) the Book class appears to be about as immutable as anything in Ruby ever is — after all, there is that attr_reader big as life right up there at the top of the class.


What bit the good Dr. Bock was that when you say gpf.title you are getting back a reference to the original string, the one that the gpf object is hanging on to. Now here’s the punch line: Ruby strings are mutable. So all you have to do is something like this:


gpf.title << 'flies'


And now you have a girl who plays with fireflies, which is not the same thing at all. So are we Ruby programmers simply out of luck, doomed to forever be on our guard for those who might take the edge off of our trendy book titles?


No! We can just metaprogram our way out of this bind. To see how metaprogramming can help us, consider what that original attr_reader :title actually does: It creates a new method on the Book class, a method called title, a method which returns the value of the  @title instance variable. The cool thing is that there is no special magic in attr_reader — we can write one of our own:


class Class
  def my_attr_reader(name)
    define_method(name) do
      instance_variable_name = "@#{name}".to_sym
      instance_variable_get(instance_variable_name)
    end
  end
end


Now it looks like there is a lot going on in the code above, but most of it is really just some unfamiliar syntax: We are simply adding a new method to an existing class. One of the confusing bits is that the existing class is the Class class, the base class of all Ruby classes (say that three times fast). The method we are adding is called my_attr_reader and it does something interesting: It defines a new instance method on the class that calls it. You pass in the name of the new method to my_attr_reader, perhaps :title and it will conjure that method up. And just what does that new title method do? Why it returns the value of the instance variable with the same name, in this case  @title.


If you substitute my_attr_reader for the regular attr_reader method, like this:


class Book
  my_attr_reader :title

  def initialize(title)
    @title = title
  end
end


You will still end up with a class with a title method that does the right thing.


Which brings us back to the good Messrs Bock and Fate. Dave’s troubles all stem from the fact that when someone asks for title his objects are returning the one and only title string, leaving open the possibility of accidental modification. Now Dave’s woes would be over if only we had a variant of attr_reader, one which would return a copy or a clone of the original value. Hmmmmm:


class Class
  def safe_attr_reader(name)
    define_method(name) do
      instance_variable_name = "@#{name}".to_sym
      instance_variable_get(instance_variable_name).clone
    end
  end
end


Notice the call to clone right there at the end of the instance_variable_get method? If we switch the Book class over to using safe_attr_reader, like this:


class Book
  safe_attr_reader :title

  def initialize(title)
    @title = title
  end
end


Then we can do things like this all day long:


gpf.title << 'flies'
gpf.title.gsub!(/Girl/, 'Boy')
gpf.title.upcase!


Without making any changes to  @title inside of gpf because the title method will always return a copy of the string. How’s that for some Metaprogramming motivation?


And so Fate, shaking his cowled head at the slowness of mere mortal thinking (and at the difficulties of getting a good hoagie in Northern Virginia) recedes into the darkness.


Russ

							

	
			

									
						Posted in Programming, Ruby					
					|
													
						Tagged , , , 					
					|
								3 Comments
							

		


		
	


			

			
The Best New Thing: Datomic


			

				Posted on March 28, 2012 by Russ			


				

				
In the last few days I've bumped into a couple of people who asked me what all of the fuss about Datomic is about. For me, it just comes down to a few questions:


    

  • How would your life change if your database kept track of everything that happened, the complete history of the world, at least as far as that database was concerned? If you could just conjure up the state of your data as it was last week, or last month or last April 15th? All without lifting a finger?
    • 

  • How does your life change if you can start with last April's data and say "What if I did this, not that?", all without affecting the original?
    • 

  • How would your life change if you could do real-time analysis on your data without gumming up the production system?
    • 



If this all sounds a bit like Git for your database, well yes. Exactly. Check it out over at Datomic. I guess I should also mention that I biased since I a) Work for Relevance and b) Really like the people behind Datomic.


Russ


PS Did I mention that you can get rid of a lot of that nasty ORM layer in the process?

							

	
			

									
						Posted in Programming					
					|
												Comments Off
							

		


		
	


			

			
RubyNation 2012 Slides


			

				Posted on March 27, 2012 by Russ			


				

				
I’ve posted the slides for my RubyNation 2011 talk Eloquent Explanations over at SpeakerDeck.

							

	
			

									
						Posted in Programming					
					|
												Comments Off
							

		


		
	


			

			
Ruby Nation 2012 Is A Wrap!


			

				Posted on March 27, 2012 by Russ			


				

				
It’s hard to believe, but Ruby Nation is over for another year. For me the high points of the conference were:


    

  1. Having a chance to chat with the other Ruby Nation organizers. We tend to be all business in the run up to the conference and it’s nice to be able to just shoot the breeze.
    2. 

  2. Talking space elevators with Dave Keener.
    3. 

  3. Pretending that Pete Campbell (@sumirolabs) wrote his own very flattering intro. Except that Pete did write his own intro. And it was pretty flattering…
    4. 

  4. Having Sandi Metz punch me in the shoulder 6,183 times. Over all, 5,792 of those hits where in exactly the same spot which is, I think, a new personal best.
    5. 

  5. Introducing Justin Gehtland by saying “This is Stu Halloway…” a couple of times.
    6. 

  6. Realizing we no longer do the “Who gets paid for writing Ruby?” poll at the end of the conference. If you know Ruby, you can get paid to write it.
    7. 

  7. Having people laugh at the “Numerical Techniques that Usually Work” joke.
    8. 

  8. Signing a copy of Eloquent Ruby for this guy who seemed equal parts embarrassed to be asking and pleased that I would do it. (My policy is that if you buy a copy of one of my books, I’ll sign any name you like in it.)
    9. 

  9. Overhearing people talking about Datomic. Finally.
    10. 

  10. Having someone tell me that Ruby Nation 2008 changed his life.
    11. 



See you all next year!


Russ

							

	
			

									
						Posted in Lists, Programming					
					|
													
						Tagged , 					
					|
								1 Comment
							

		


		
	


			

			
Olsen’s Law of Continuing Education


			

				Posted on March 27, 2012 by Russ			


				

				
This one is from 2009 and had always been one of my favorites.




Let‘s face it: Agile programming is full of some pretty far fetched ideas. Pair programming is the concept that two people devoted to a one person job can be more efficient. Unit testing is the idea that writing approximately twice as much code will make your project finish earlier. Refactoring is the concept that you can stabilize your system most effectively by rewriting the working parts. Constantly.


Of course those of us who have turned to agile techniques have done so because we know that these seemingly crazy ideas simply work. Two sets of eyes can produce better code faster. Automated tests not only speed development, but also fire a warning flare if something gets broken. Refactoring keeps your system coherent. The trouble is, all of this wisdom is hard to explain. It‘s hard to see the benefits of pair programming until you have witnessed the damage that one misguided engineer can do in a single day. You need to have an install fail because of a unnoticed bug that was introduced six months ago to really appreciate unit testing. And you need to shed actual tears over the pulsing mutant glob that your system has become because no one had the guts to rewrite the GUI code. Since most nontechnical people lack these important life experiences, trying to get the agile ideas across to them can be tedious.


There is one part of agile programming that I have had some success selling to the non technical folks: avoiding a complete up front design. Over the past few years I have used the same single sentence to explain why it is a bad idea to make all of your design decisions up front. So much success, in fact, that people have occasionally referred to that one sentence as Olsen‘s Law of Continuing Education, or simply Olsen‘s Law. So without further ado I give you the magic sentence:


Olsen is as stupid today as he ever will be.


It has a certain musical charm, don‘t you think? The point is, of course, that if you force Olsen to make all possible decisions at the earliest possible minute, some of those decisions are guaranteed to be worse than the decisions that Olsen will make tomorrow. This is because Olsen is getting smarter with each passing day. Smarter in general: I like to think I am getting better as an engineer. But also smarter in tightly focused ways: tomorrow I will understand your requirements, configuration, users, and font preferences better than I do right now. So let’s agree to put off whatever decisions can be put off and let that smarter guy handle them.


Of course Olsen‘s law is not terribly original. It is simply a restatement of the agile principle that making all your design decisions up front is a bad idea. What Olsen‘s law has going for it is a brutal bluntness. None of this pie in the sky stuff about software teams flocking like migrating birds or finding the design like a sculpture hidden in a block of marble. No, just a naked admission of stupidity. It‘s hard to argue with.


Still, I‘m not really sure why those ten words work so well. But check back with me tomorrow. I may have figured it out.

							

	
			

									
						Posted in Programming, Repost					
					|
												Comments Off