Lazy Evaluation

I love to read everything: fiction and non-fiction, software books and eighteenth-century romantic classics.  But I'm not going to talk about the entertainment value or aesthetics of fiction, cause that's a matter of taste.  Here's why I think that reading good literature is actually essential to your career as a software developer:

1. Reading fiction will make you a better speaker and writer.  You become a better communicator and influencer if you learn how to tell stories.  And the best way to learn what makes a good story is to read lots of them.  Also, surrounding yourself with masterful uses of the English language (i.e., the kind you don't usually hear on TV) will make you a better writer.  Yes, you write code, not prose; I know. But you also write documentation, emails to clients and coworkers, and documents persuading management and coworkers of your point of view. 

2. Reading fiction will help you understand your users, clients, and coworkers.  To write good user interfaces or give your clients what they really want, it helps be able to put yourself in their shoes.   I'm not implying that we developers don't get people, just that all of us humans live in a world limited by our own narrow experiences and understanding.  Fiction gives you a window into the lives of all sorts of people who are different from you, and helps you empathize with them at work.   You can learn about other people's culture, values, and frustrations without traveling halfway across the world.

3.  Reading fiction will give you an appreciation for everything that the software industry's taken from literature: the Literate Programming paradigm, or the humor in the fact that this Win32 website is called Catch-22.  Think of these allusions that you hear all the time: big-endian and little-endian,  that the Answer to the Ultimate Question of Life, the Universe, and Everything is 42, and what it means to grok something.  Do you know what books those are from?*

For anyone who's not convinced, I point you to What Has Literature to Offer Computer Science?, by Mark Dougherty

*Gulliver's Travels by Jonathan Swift, The Hitchhiker's Guide to the Galaxy by Douglas Adams, and Stranger in a Strange Land by Robert Heinlein

The Software Development Study Group has been meeting in the SRT office (206 S. Fifth, Suite 200) on Tuesdays at 5:30pm for several weeks now.  We've picked a jam session format, meaning that each week a different person leads a one-hour jam any coding topic.  Getting to actually write some code instead of just hearing someone talk has been awesome! And everyone knows that sometimes the hardest part about getting started with a new technology is just figuring out what to install, and how to say "Hello, World!"   So far we've had:

October 6- Bill Heitzeg: Problem Solving

October 20 - Ben Barefield : Ruby

And the next one is yours truly, using the ruby base we got last time to give everyone an intro to rails.  Here are the pre-reqs to this week's jam:

1)  Make sure you have ruby installed somewhere, and a command-line available (either windows, cygwin, whatever).  If you don't have a preferred IDE or editor, windows ruby comes with scite, which is pretty cool.

2)  We will need to install some gems (ruby plugin libraries), so if your RubyGems system is old, update it by running
gem update —system 

3) We will be using SQLite instead of mySQL to minimize pain.   Download the pre-compiled version of SQLite3 3.5.4 from the SQLite web site (http://www.sqlite.org/sqlitedll-3_6_19.zip ) , unzip it and copy sqlite3.dll and sqlite3.def to your ruby/bin directory.

4) Now that SQLite3 is installed, just install the gem:
    gem install sqlite3-ruby

5) Install the rails gem:
gem install rails

6) Read the first 2 sections of this tutorial, which we will be using: http://guides.rubyonrails.org/getting_started.html

Hope to see you there!

A while ago I wrote about interview questions for software developers.  Jeff Atwood suggests another one:

I hate software -- most of all and especially my own -- because I know how hard it is to get it right. It may sound strange, but it's a natural and healthy attitude for a software developer. It's a bond, a rite of passage that you'll find all competent programmers share.

In fact, I think you can tell a competent software developer from an incompetent one with a single interview question:

     What's the worst code you've seen recently?

If their answer isn't immediately and without any hesitation these two words:

     My own.

Then you should end the interview immediately. Sorry, pal. You don't hate software enough yet. Maybe in a few more years. If you keep at it.

Jokes aside, he's got a good point.  Software's hard, and a little humility goes a long way.

As part of Jon Udell's Interviews with Innovators series, he talks to Joan Peckham about Computational Thinking for Everyone. She is a involved in an NSF project that's evaluating computational thinking in the context of K-12 education.  I love thinking about computer science education, and this adds a new twist: in the modern world, should we be focusing on educating kids about computing concepts way before college? If so, how?  A few interesting points from the interview:

• With the growing importance of technology in every aspect of life these days, should computational thinking be one of the "three R"s -- taught at every level in school, and considered crucial to being an educated citizen? 
• If so, how should kids be taught these concepts?  When they say computational thinking, the NSF project has way more than just using computers in mind: from the ability to organize one's thoughts in a systematic manner, to applying "debugging" skills to non-software problems, to approaching complicated systems by breaking them down into components with interfaces.  Curricula will need to be developed for different classroom levels, and teachers and parents need to understand this new subject.
• A topic of much debate in the computer science education world is whether a college-level computer science program must start with an in-depth programming class.  On one hand, there's a lot more to computer science than just writing code, and you don't want to immediately bore and discourage new students with dry coding exercises.  Instead, they should get a foundation in the important mathematical and social concepts of computing first.  But wait! On the other hand, you don't want these students to get any farther into their major without truly understanding what they're getting into: writing and understanding software will likely be a key aspect of the rest of their education, and of course of any job a computer science graduate later takes.  The idea of teaching computational thinking way before college helps clear up this debate: teach all kids what computers can be good for and how to think about them way before college, and then computer science freshmen will be ready for nitty-gritty programming details right away.
• Right now, while most kids and young adults say that they use technology every day and enjoy it, most think that majoring in computer science is something that only boring nerds do; they're not considering it. Perhaps by teaching computing in holistic way and relating it to other fields, we could engage many different types of students.  If kids with diverse interests understand the potential of software to create beautiful things and solve the world's social problems, they will hopefully go on to contribute to and truly enrich the software world.  And that's a worthy goal if I've ever heard one.

Next up for the NSF project: coming up with a PR-worthy name for the concepts they're discussing.  "Computational thinking" seems to have the connotation of teaching kids to think mechanically instead of creatively, and other alternatives have so far been too long or complex.

Check out the full interview here, and also interesting are Jon Udell's notes.

At CodeMash 2009 in January, I was lucky enough to end up in Jim Weirich and Joe O'Brien's Ruby 101 session.  These guys are smart and creative, so instead of just talking a lot, they came up with a set of Ruby Koans for the participants to work on during the session.  Koans were short ruby tests that we had to make pass,  each test actively teaching us a new ruby feature or concept.

For me, this is a great way to start learning a programming language. There's the competitive "game" aspect, but also the "hmm, I should look into this!" insights that, if one's paying attention, inevitably come from some of the tasks. So I've started looking for more of them:  small puzzles that are fun and challenging to solve, that can get my feet wet with a new programming language.  Here's a list I've compiled of highly-recommended quizzes, games, koans or kata.  Let me know if your favorite is missing, and I'll add it!

Ruby Koans - test-driven learning

Code Kata -  coding exercises, of Pragmatic Programmers fame

Ruby Quiz - weekly programming challenge for rubyists.  No longer updated, but lots of great ones in the archive

Perl Quiz of the Week - same idea, but for perl.  Check the archive.

Haskell Quiz - for those of us that long to write functional code in our free time

Robocode - Open-source java coding game: test your robot against the competition!

Python Challenge - It's a challenge, and it uses python.  Need I say more?

And of course, our SRT favorite, Project Euler.  Interesting and challenging math and computer science puzzles that can be solved using code.

I've been reading an interesting book called Good Business by Mihaly Csikzentmihalyi.  The author is a psychology professor who is known for his work in the study of happiness and creativity, and in particular, a state of concentration he calls flow.  Most software developers have felt this from time to time, perhaps when working on a particularly challenging and consuming piece of code.  We might call this being in the zone.  In this book he applies his research to business, claiming that today's workplace, instead of contributing to human happiness, has often become a source of drudgery and dissatisfaction to the employee.  Though we spend much of our lives at work, for various reasons, the typical job today is unlikely to cause the employee to experience flow in his work.  This, Csikzentmihalyi claims, is a true disappointment, because a business that contributes to the happiness and well-being of its employees by maximizing the flow they experience is not only benefiting society, but also likely being successful in the marketplace.

Keep in mind that flow is not necessarily connected to work, but can occur in anything humans do: playing music or sports, reading, conversation, religion, etc.  Csikzentmihalyi's research has gathered examples from rock climbers, surgeons, dancers, housewives and any number of other people who report similar experiences while engaged in very different activities.  However, since we do spend a good chunk of our lives at work, it's worthwhile to think about how we can experience flow in our jobs, not just in our favorite hobbies, where it's typically felt by most people.  Based on his research, these are the components of flow, although not all are necessary to experience it:

1. The goals are clear: precise tasks to accomplish are clear in any moment, but one savors each step along the way instead of focusing only on the end goal

2.  Feedback is immediate: others involved, or usually the activity itself provides feedback about progress

3.  There's a balance between opportunity and capacity:  the task is neither too challenging, causing anxiety, nor too easy, causing boredom.  Skills are matched.

4. Concentration deepens: an almost meditation-like concentration, undistracted by the outside world

5. The present is what matters: everyday worries or problems don't register in the mind; attention is fully focused on the present task

6.  Control is no problem: unlike everyday life, whose events are often beyond our control, the situation seems fully within one's power to control

7.  The sense of time is altered: time seems to fly, or stands nearly still.  The speed at which time passes depends on mental "absorption"

8. The loss of ego: one tends to forget not only one's problems, but one's very self, getting lost in the action

The author concludes that to be effective in leading a "Good Business" (by creating an atmosphere and culture conducive to flow), the essential components are:

1 - Clear Goals (for the company, from executives and management, and individually)
2 - Good & Immediate Feedback (from one's superiors, but also one's colleagues)
3 - Incremental Challenges (both from management to employees, and individually -- employees find ways to challenge themselves at work)

So what does this have to do with software development?  We can all agree that our most productive and most interesting times as a developer are when we manage to reach this elusive state.   By adjusting our environment and work culture to encourage flow experiences, we can both be more successful and find more enjoyment at work.  While the the author's research and interviews for Good Business focused on what a company's leadership could do to run a business with flow in mind, I've used them as a base to come up with ideas for us software developers to implement in our jobs ourselves.  Most of us lucky to have jobs that allow us plenty of freedom, so we should take advantage of this.  Here are my ideas:

• Don't allow yourself to be a cog in the wheel: find ways to use your unique skills at work.  If you're a developer but have a talent for writing, volunteer to help with client proposals or documentation; if you have a good eye for UI and design, help out on that component of projects.
• Know your company's goals, and work for one whose goals you agree with.  Is the goal to expand the company, or to work on as much cool technology as possible, or to create and sell something new? It's hard to be focused at work if you aren't on board with the goals.
• Speaking of goals: if your manager doesn't set them for you, set your own.  If your workplace doesn't do agile, you can still set up your own iteration plan and measure whether you've accomplished it at the end.   Or track your own bugs, if there's no system in place.  You may not be rewarded or recognized, but you'll have the satisfaction of reaching your goals.
• Challenge:  Same thing.  While it'd be nice if our bosses knew the progression of all of our skills and exactly when we're ready to move on to more challenging projects, that's not realistic.  Find ways to challenge yourself, perhaps by learning a new technique or technology and applying it to your current project.
• Environment matters: if your office isn't comfortable, clean, and relatively calming, think about what you can do to change this. 
• Communication:  ask your colleagues and your manager for feedback.  Not just twice a year at your review, but talk all the time.  Ask for help and ideas.
• Finally, and perhaps most importantly, attitude: nothing external can guarantee that a developer finds intrinsic satisfaction in writing code.  Look beyond just technical skills for the right attitude when hiring.

These small changes can help you experience flow at work, even in an ordinary and occasionally mundane job.   A related question on my mind is whether and how independent software projects (open source, or anything else we work on outside of our jobs for fun) differ in the flow we feel from software we write at work.  What do you think?  What am I missing that's been effective for you?

In ruby, when you call a method that doesn't actually exist on that object, the object always invokes the method_missing method instead.  This is one of ruby's cool metaprogramming features: it lets you decide yourself how to handle what would have otherwise been an error.  This feature is used in lots of interesting ways, such as dynamically finding and generating methods, dispatching method or system calls, and generating custom XML with method calls.  But let's start with something simple: using method_missing to implement basic tracing functionality.

That's my class.  It has some methods!

This is a wrapper class: it will be initialized with my class as a parameter.  Notice it has no methods defined except method_missing.  That means any method calls will just invoke method_missing.  method_missing outputs a trace message and then invokes the method (with the given parameters) on the wrapped object.

To use the Tracer, we create a new MyClass object and pass it to a new Tracer, and we're good to go!

Called do_something with args: blah, 5
Something happened!

Called foo with args: 89
17

To keep it simple, this example doesn't get the return value of the invoked method, or account for stacked method calls. 

Find the difference between the sum of the squares of the first one hundred natural numbers and the square of the sum.

----

We don't actually need a computer to solve this problem, but why not?

The formula for the sum of the squares of the first n natural numbers is:  n*(n+1)*(2n+1)/6 .

The formula for the sum of the first n natural numbers is:  n(n+1)/2 .

We can write this in ruby:

Note that you don't need an explicit return statement.  The last expression in any function will be returned by default.

Every interview is difficult, because on both sides, you know you're about to make an important decision based on very little information.  But it seems to me that interviewing a recent college grad can be especially difficult for an industry veteran.  There typically isn't much to say about the candidate's past software experience or framework knowledge, so the interviewer is left evaluating the candidate only on intelligence and personal qualities, rather than on real-world software development competence.  So what are the most useful questions to ask in this scenario? 

Here are some of the memorable questions I've been asked in interviews for an intern or junior software developer role: the good, the bad, and the ugly. 

Q: A Microsoft puzzle, such as: How many gas stations are there in the USA?, or How many golf balls fit into a school bus?

My verdict: Bad. If the candidate doesn't display her cluelessness by being flabbergasted, how exactly do you judge the creativity or accuracy of her reasoning?

Q: Write a function to reverse a string.

My verdict: Good.  Discussing solutions that optimize for space or speed can show a candidate's understanding of the basics (or lack thereof).

Q: There is a room with a door (closed) and three light bulbs. Outside the room there are three switches, connected to the bulbs. You may manipulate the switches as you wish, but once you open the door you can't change them. Identify each switch with its bulb.

My verdict: Bad.  Either the candidate has heard this question before, or he hasn't.  Even the unlikely case where he comes up with the solution on the spot doesn't tell you much about his prowess with a compiler or a customer.

Q: Does object-oriented Square extend Rectangle?

My verdict: Good.  What does resize(3,5) do to a Square : Rectangle?   If a brand-new developer can see this pitfall to the naive approach to object-oriented design from CS 101, that's pretty good.

Q: The typical HR-type questions: What is your weakness; Where do you want to be in five years?

My verdict: Ugly.  Unless the candidate, instead of reciting the typical canned answer, admits a fondness for underage girls, or his plan to take over your business and become your boss. 

Q: Design an elevator system for a 100-story office building.

My verdict: Good. Opens the discussion to technical and UI factors, and  lets you assess your candidate's creative and problem solving skills.  Can he see the big picture?

Next time: more ideas for effectively interviewing entry-level developers.

Last week, I went to Eric Ivancich's awesome AACS talk on Using Ruby to Create Domain-Specific Languages here at the SRT Solutions office.  I'd been lazy before, but that day I decided to finally pay my $20 AACS dues and become an official member.   As more validation for the fact that I'm the luckiest girl in the world*, I ended up more than recouping my loss when I won the Borders gift card in the members-only drawing at the end of the night!  Now I'm faced with a serious dilemma... what to spend it on, from my mile-long Books To Read list?  My educational options:

A new ruby book, maybe The Best of Ruby Quiz?  Inspiration after learning more about ruby's metaprogramming features

or:

The software engineering book everyone's been talking about: Beautiful Code

I'm earmarking this hard-earned money for tech, and making myself stay away from the fiction section (mmm, very tempting).  What does everyone think?  I love reading recommendations.

* Other evidence: I get to work with not just one, but three Microsoft MVPs!

 What is the smallest number that is evenly divisible by all of the numbers from 1 to 20?

----

To solve this problem easily, we need to remember that the smallest number that is evenly divisible by two numbers is their least common multiple.  Armed with this knowledge (and the fact that ruby already has a least common multiple function!), we can write:

So for those of you at SRT (or elsewhere) that still harbor any doubts about ruby, can you beat that?!  Fine, ok, so you might say that using a built-in lcm function is kind of lame.  So as a bonus, here's how I implemented lcm myself in a cute way using the greatest common divisor:

A while ago, we had a discussion here at the office about nerdy t-shirts.  We all know what I'm talking about: usually worn by a male geek/programmer with a neckbeard, a black shirt with a "witty" technical reference.  Opinions about these shirts vary among SRT employees: some of us find them funny and even wear them on dates [no report on the results, though], some are skeptical.  You might guess that I fall into the second camp.  Here are the worst offenders in my book:


 

The geek love poem... 

 It's so bad it's good.

The worst one of all.  Nearly ubiquitous in computer science buildings on campuses nationwide, but yet still considered brilliant and unique by the wearer.

And of course, I can't leave out geeky women's gear -- in some ways even more horrifying than the men's stuff.  Evidence presented:

HTML tags -- get it?!

I have no words.  Instead I'll leave you with ThinkGeek's description of these: "... we bring you HTTPanties for the discriminating woman who would prefer a web-savvy and somewhat-direct approach in the romance department.  Feeling frisky? Well then don the black "200 OK" panties and see where they take you. Alternatively, the white "403 Forbidden" style sends a very different and hopefully clear message. We think "411 Length Required" and "413 Requested Entity Too Large" are pretty self-explanatory."

 Find the largest palindrome made from the product of two 3-digit numbers.

----- 

 First, I defined a palindrome recursively: a number is one if its first and last digits are the same, and if the inside is also a palindrome.

Note that in Ruby, methods can end with a question mark, a convention that really helps readability.  Also note that the "else if" keyword is elsif, which is weird and unhelpful to me.  I want that 20 minutes of staring at my code like "wtf?!" (before figuring that out) back.

 Then we do a search of all the multiples of two three-digit numbers until we find the biggest palindrome:

There's probably a prettier way to do this. 

 What is the largest prime factor of the number 600851475143 ?

 -----

 I wrote this piece of disgusting, un-Rubylike Ruby to get the answer by creating a list of a number's prime factors:

And then I learned that ruby has a prime number generator.  All I need to do is:

 I am slightly ashamed.

The problem: 

Find the sum of all the even-valued terms in the [Fibonacci] sequence which do not exceed four million.

Here's my fibonacci function:

And here's how I use it to get the answer:

I learned about the awesomeness of 'yield' by doing this problem, so it was totally worth it.  yield let me calculate as many fibonacci terms as I needed, but not more, and without having to calculate any term more than once.