The Cost of Waiting for Feedback in Software Development


Let’s imagine you are paid to write emails.


It works like this:



Now, imagine a different way of working




Well, unfortunately, this is the way most developers are working




But wait, the client has the exact same frustration!



Surely, there are better ways to waste my time!

What is the engineer’s solution?



“That’s how it’s done!”

There are indeed situations that demand this way of working.



So, what’s the alternative?





Often advocated. Seldom practiced.


Do we really waste that much time waiting for feedback?


Now, how much longer do you think it takes?




It’s also:

  • The delay between analysis and development
  • Waiting for approval or a sign-off on something

Now, how do we fix this?

Well, it’s not that hard… to write about! 🙂



And, if your role allows:











Those are not 10x engineers you’re talking about

There’s been a lot of discussion on Twitter recently about so-called 10X engineers. Here’s the tweet that started it all:  

Just to make sure you’re on the same page: a 10x engineer supposedly provides extraordinary value to their team and organization.

Now, this has resulted in dozens of jokes, memes, people wondering if these engineers also incur 10x technical debt and so on.

The general idea is, you don’t want to work with someone like that. 

But these are not 10x engineers.

These are exactly as described: toxic jerks. And there’s a huge difference between the two of them.

Sure, toxic jerks might self-promote their way to being perceived as a 10x engineer, but I doubt they will ever provide 10x value to their team or organization.

In what kind of organization would that behavior ever provide a 10x value? What kind of organization even enables such people to thrive? (Politics, maybe? ;-))

I do understand that if you’ve never worked with a 10x engineer, or if you believe they don’t exist, you may mistake this person as one.

And yes, I’ve worked with these toxic jerks and of course, I agree that you want to avoid them. They can provide value in some edge cases, but I’d rather not have them around.

Fortunately, I’ve also worked with what I regard as true 10x engineers.

And I’m not the only one.

(show full thread)

Whether they provide “10x” value is another discussion. Let’s assume for now that they are very valuable to their team and organization.

And how do they do that? Well, these engineers have a combination of the following traits:

  • Better-than-average tech skills and knowledge in a wide area. (OK, this one was obvious.)
  • Eager to improve how they work and how the team works.
  • Assisting other people, taking new people under their wings.
  • Giving credit where credit is due. 
  • Good communicators, good listeners.
  • Not too cocky to change their mind or admit they were wrong.
  • Eager to learn, on a wide area of topics.
  • Accumulating domain knowledge, if active in a specific field.
  • Dedicated to their job and everything related.
  • Emphatic; trying to understand the customer, colleagues, their manager, …
  • Last but not least: ideas of 10X value (or way more), because of a combination of the above!

This is by no means a complete list; it only contains what I remember from the “10x” people I’ve worked with. Just to be honest, none of them possess all those traits and some can be a bit of a jerk from time to time but never in a major toxic way. Like most of us, right?

Note: there are a lot of soft skills in this list, but they are still engineers, and their excellent tech skills remain their biggest asset. 

The 10x value isn’t all originating from the engineer, though.

The culture of the organization and the environment they’re working in play a major role too.

Can they work uninterrupted if necessary?
Do you promote a culture of helping and sharing? 
Do you facilitate good documentation, provide the necessary tools and training?
Do you often reflect on your way of working (a so-called retrospective)?
Is there a constructive, no-blame culture?

Going from a noisy open-plan office to having a couple of distraction-free hours a day might already “2x” your entire team. Unfortunately, I’ve seldom met a non-tech manager who believes strongly enough to actually take action.

You know, those engineers you see with their headphones on? It’s not because they like music so much; it’s because the music is less distracting than the office noise.

Bossy guy complaining to someone else: "They can't be that busy, they're all listening to music". There is also an "engineer" working concentrated in front of his 3 monitors, wearing headphones.

Now, how do you recognize these 10x engineers?

Well, in my experience, the direct colleagues and managers know, but the rest of the organization usually doesn’t.

It has taken me weeks or even months to realize a person I’ve been working with belongs in this category. It’s not that they fly under the radar or keep a low profile, but self-promotion isn’t on top of their list. It’s also possible I’m a bit slow at recognizing such things.

Sometimes, I have suspected people to be 10x much sooner… in a matter of days or even hours. But these have almost always turned out to be self-promoters of the toxic jerk variety.

So no, there are no rules or tricks. It’s the same as finding out if you like working or living with someone. Maybe you’ve got a gut-feeling, but it will take some time and going through tough and stressful situations together before you know for sure.

Would it be possible to nurture engineers to 10x level?

Well, I’m sure you can, up to a certain level and with proper coaching.

What I’d do is provide a “10x nest” with an optimal culture and environment to attract, nurture and retain 10x engineers. 

Yes, I know that sounds mushy, but there’s a shortage of good engineers. Instead of hiring additional ones, what if you tried to optimize for the ones you’ve got?

Providing a good environment and culture might attract more talent if needed, as 10x engineers often have other 10x engineers among their friends. Birds of a feather flock together, so why not let them flock to your 10x nest?

But be careful that you don’t end up with a toxic clique!

Have you worked with 10x engineers?
Or do you only know toxic jerks impersonating as such?
Don’t hesitate to reach out on Twitter or by email!

Recognising a Bad User Interface at First Glance

And translated to Japanese (with my approval).





Here are my findings…

Too generic or inconsistent use of terms/labels






An Excel/development IDE – like user interface







undefined icons UI

Unclear/confusing error messages

(written by the programmer).

Pointless error dialog




Too much text/instructions





Message Implementation Guide

Excerpt from an EDI Message Implementation Guide



Weird, irrelevant and complex date/time formatting




Being too Mouse-dependent


This has been annoying users since the invention of the mouse.

Too many pointless message boxes

‘Are you sure you want to print the document?’



Inconsistent warning dialogs

A while ago I saw a CRM-ish application.

When exiting an unsaved contact’s form, it said
‘Are you sure you wish to exit without saving?’

When exiting an unsaved company’s form, it said
‘Save changes before exiting?’

Clicking ‘yes’ obviously gives two different results here.

The user interface is totally empty when starting out


You should guide your users towards taking their first steps here.


You get the picture.

Visual clutter


Tell us in the comments!

Being User Friendly Beyond the Software






Tell us in the comments!


Header photo by rdolishny, used under CC BY-NC 2.0

Enterprise Software Acquisition: What’s Missing and How to Fix It







Hallway testing to the rescue!


Joel Spolsky, The Joel Test – 12 Steps to Better Code






Isn’t Hallway Testing only for occasional processes?






Some example Hallway Testing tasks


  • add a contact
  • search for this contact
  • change the contact

And when evaluating a bookkeeping/invoicing system:

  • add a client
  • make an invoice for this new client
  • send the invoice through email


Other things to keep in mind

Modern software should be able to talk to other software


This is often overlooked.


And this in 2015.


Responsiveness is a requirement



What about including these requirements:





Did you hunt on google for alternatives?









But I don’t want the data to leave the company!





Reconsider having it custom developed




Don’t blindly believe references

“XXX and YYY are using it too”







Remember: Always take references with a grain of salt!

Look online for actual user’s reactions

salesforce sucks - Google Search


salesforce sucks - Twitter Search






Everyone uses Java/C# and Oracle, why choose something else?

If the tech guy (or girl) advises going for a less common technology, and something goes wrong, he’ll get blamed. “Why didn’t you use Java/Oracle/IBM like everyone else does?

And you can be sure that something WILL go wrong sooner or later… and this guy knows it.

He knows he has a mortgage, kids that have to go through college, a wife with a spending habit… why take any chances? What’s in it for him if it works out? And what if it doesn’t?

People avoid taking risks. Especially people who work a ‘safe’ job as an employee.

Is this the lizard brain at work?

For the record: There’s nothing wrong with Java/C# (or any other language for that matter). They all have their (dis)advantages on speed, memory usage, developer-friendliness, license/price…

Yet NONE of them fit all tasks and situations you can throw at them, while yes: you can use most of them to implement most tasks.

Do you have any idea how many programming languages exist?

Just look at this list. These languages weren’t developed because there’s hardly any difference between them, or because a ‘one size fits all’ language exists.

Now, if you are a developer/sysadmin, I probably needn’t explain. But as I’m hoping to enlighten the non-tech manager here, I think an analogy is in order.

Let’s say you’re building a house. Would you use nails or screws for all attaching situations?

No. Depending on the kind of materials you need to bond, the needed strength, the climate it’s in, the budget, how long it should last… you either use nails, screws, glue, cement, or god knows what else.

You use the right tool for the job. It’s the same with programming languages.


Philip Greenspun, Java is the SUV of programming tools

(I just used this quote to show that there can be some bias and strong opinions concerning certain languages. I also don’t like Java, but that’s beside the point.)

Yes, you can hammer a screw into wood (I tried this as a kid), but it will take a lot of effort and will provide less bonding than a nail. And you might hit your fingers in the process (I also did this as a kid).

Still not convinced? Do you know that some programming languages can be 100 times faster than others? And there are also other differences just as relevant as execution speed.

And though execution speed can be important, it shouldn’t be your guiding factor.

Often people, especially computer engineers, focus on the machines. They think, “By doing this, the machine will run fast. By doing this, the machine will run more effectively. By doing this, the machine will something something something.” They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines. We are the masters. They are the slaves.

Yukihiro Matsumoto, Ruby programming language on Wikipedia

People sometimes dismiss Ruby because Ruby is slow. Well it is, and I don’t care. The biggest performance bottlenecks that I have day to day is the database, the file system, the internet and bugs. These are not problems with Ruby, so speeding it up will have a negligible effect.

Additionally, hardware is cheap and developers are not. If you can use a programming language like Ruby to make your programmers more productive, then you can increase the performance of your code with better hardware. You can buy the better hardware with the money you saved by making your developers more productive.

Graham Jenson, What is Ruby? It is fun and makes you happy!

I once was part of a team that had to make an internal web application. We didn’t have any Java experience, but the company already had some customer-facing Java web apps developed by the ‘webdev’ team. So we agreed to use Java.

After evaluating several Java frameworks, one of us bumped into this new thing called ‘Ruby on Rails’ (V0.11 at that time iirc). ‘Rails’, as it’s often called, was like a breath of fresh air after being bombarded with Java that seemed more like configuration than programming at that time.

There was only 1 problem: Rails uses Ruby instead of Java as its programming language.

Even so, we decided to go for it. We finished the project in considerably less time than the original estimate. This also helped management accept that we had neglected to use Java.

Was this all because Rails somehow made us work faster?

Not really, but it was very suited for this job, it was a really fun language (it still is), it was new and exciting, and because we were supposed to use Java, our asses were on the line in a major way.

It was the right tool for the job AND the right tool for us. By the way, last time I heard, this application was still running (I no longer work there).

And when we showed the hardcore Java aficionados, one comment really struck: “it’s easy that way.” And this wasn’t the last time I heard this (often concerning Ruby). And shouldn’t that exactly be the whole point? Making things easier?

Unfortunately, when technology is concerned, the decisions aren’t always that clear and we rely a lot on other (less?) relevant factors to guide us.

Why your devs might not like a language that makes their lives easier

When I started out as a pro programmer, the company I worked for made client software in a not-so-easy language/framework. Why? Primary reason: they wanted the software to be as fast as possible, which is very valid.

Unfortunately, the database technology we were using was so damn slow that any advantage the faster language offered was totally obliterated. This was a huge bottleneck. The language was like a Ferrari, but it was waiting 98% of the time for the database’s traffic light. And that light won’t switch to green faster just because there’s a Ferrari waiting.

(For the tech guys: we were using C++/MFC and an Access database through ODBC… ok, stop laughing, we eventually switched to faster database tech.)

It also took several minutes to compile the project, meaning that we couldn’t just make changes and test them right away. No, we had to wait several minutes to test things, or get an error (and in the old days, that could have been several hours, but only graybeards remember this).

When I suggested that another language/technology (Delphi) was really more suited for the job, colleagues argued: “there’s no demand for Delphi programmers, this isn’t good for us.

They were right. For me, this was my first job and I wanted to make a good impression. However, they had already proven themselves, knew this wasn’t going to be their last job and didn’t want to lock themselves into a framework/language that wasn’t in demand.

And I have no idea if they would have been able to find Delphi programmers.

Besides that, we could be pretty sure that Microsoft (the manufacturer of the tool we used) would still be around in a couple of years… while Borland (the original developer of Delphi) always seemed to be hovering on the edge of bankruptcy.

Would we have been more productive using Delphi? I’m pretty sure we would have. It was just much more suited for what we were doing and more forgiving for the rather average developers we were.

Would it have been good for the company? Not if the devs ran away and couldn’t be replaced by others.

Would it have been good for me? In hindsight, no. Now I can put 8 years of ‘pro’ C++ development on my CV, which is a lot more impressive compared to Delphi/Pascal. A lot of people used Pascal in high school, so it’s often not taken seriously.

So how do you pick a suitable language/framework?

You should use what startups use!

That’s what I used to tell the CxO’s. And I was wrong, as most of them didn’t work for startups.

Tech startups are the hotbed of technology. They use cutting-edge tools and make amazing software that scales to millions of users. And you will have to look hard to find startups using Java/C#.


Technology is at the core of their business, and their goal is to grow fast or fail fast – which probably isn’t yours. You are probably looking for stability, and aren’t interested in failing, no matter how slow or fast it goes.

You’re part of a startup? You should have brighter guys on board than me who will tell you what language/framework to use. And pssst: don’t waste your time reading this, you’ve got a startup to grow!

So, should you just stick with classic, proven tech then?

Hell no!

The language and framework you use can make a real difference. I think that except for certain edge cases, the human impact far outweighs the technological impact.

Have your programmers experiment with alternatives. Even if they don’t get all excited and suggest ditching your current tools, they might just find them useful somewhere. Also, it will help to fight boreout and keep things interesting.

Depending on the kind of software you make, it might be worth investigating domain specific languages (DSL).

This is something that could motivate the seniors and benefit everyone.

I have worked in EDI in the past, and DSL’s would be perfect there. Of course, I’d do it in Ruby, but I’m biased.

But isn’t it hard to learn a new language?

The basic logical building blocks of all languages are more or less the same. To compare programmers to writers again: a good programmer can tell a solid, logical story, no matter what language or framework (s)he uses.

Regular learning will also make it easier to learn new things in the future. I like to think of this as keeping your ‘learning muscle’ in shape.

And it will certainly not hinder career opportunities to experiment with other tools.
Au contraire mon frère.

Finally, it will also help you attract new talent. A business that uses Java, but with some Ruby, PHP and Node.js where it makes sense, sounds a lot sexier to the kind of people you want (well, it does to me).

Some have even suggested using technology as a hiring filter.

“The programmers you’ll be able to hire to work on a Java project won’t be as smart as the ones you could get to work on a project written in Python. And the quality of your hackers probably matters more than the language you choose. Though, frankly, the fact that good hackers prefer Python to Java should tell you something about the relative merits of those languages.”

Paul Graham, Great Hackers

But don’t take my word (or Paul’s) for all this. Your mileage will vary. There are too many different situations to provide a ready-made answer. I hope I still gave you some food for thought and provided some insights though.

If there’s any meager advice I could give it would be this:

  • Talk to your developers
  • Are they using the right tools for the job?
  • Encourage experimentation. Without experimentation we’d still be using assembler (or gasp: Cobol!).
  • Have them investigate DSL’s.
  • Remember that this isn’t purely a tech/HR matter.

And know that something will always go wrong, and it often isn’t the technologies’ fault.

Had a good read? Sign up at here to get notified of future (dis)informative articles by email.

Agree? disagree? Let me know your thoughts in the comments.

Header image by Duncan Hull, used under CC BY 2.0.

Your Developers Aren’t Bricklayers, They’re Writers








Robert Glass, Facts and Fallacies of Software Engineering




Fred Brooks, The Mythical Man-Month

Let me give you an actual (yes, IRL) example

(Names have been changed to protect the innocent.)

This test/fix cycle is repeated two or three times.







Congrats! Rejoice! Champagne again!




Phil Haack, 10 Developers For The Price Of One

Now, what is the worst that could happen here?




So, why does this go unnoticed so often?





Related articles:
10 Developers For The Price Of One
What Makes Bad Programmers Different?
What Makes Great Programmers Different?

Who am I and why am I telling you this









Generating a twitter OAuth access key – the semi-manual way








Other Solutions



Authenticating with the Twitter API: old vs new

Acessing The Twitter API the old way:

require 'twitter'
httpauth ='my_account','my_secret_password')
client =

The OAuth way:

require 'twitter'
oauth ='ve4whatafuzzksaMQKjoI', 'KliketyklikspQ6qYALcuNandsomemored8pQ6qYALIG7mbEQY')
oauth.authorize_from_access('123-owhfmeyAgfozdyt5hDeprSevsWmPo5rVeroGfsthis', 'fGiinCdqtehMeehiddenymDeAsasaawgGeryye8amh')
client =

In the above case,

123-owhfmeyAgfozdyt5hDeprSevsWmPo5rVeroGfsthis is the ‘access token’ and


How to get these keys

1. Surf to the twitter apps registration page


2. Register your application





3. Get your consumer key and consumer secret


oauth =[consumer key], [consumer secret])
4. Obtain your request token

run the following in IRB to obtain your ‘request token’

{:site => ''})
irb(main):004:0> request_token.token
=> "UrperqaukeWsWt3IAlfbxzyBUFpwWIcWkHP94QH2C1"


5. Authorize your application

surf to[the above token], for example:


6. Get your oauth_verifier from the redirected url


In my case the browser redirected to:


7. Request an access token


=> "123-owhfmeyAgfozdyt5hDeprSevsWmPo5rVeroGfsthis"
=> "fGiinCdqtehMeehiddenymDeAsasaawgGeryye8amh"

We’re there!

123-owhfmeyAgfozdyt5hDeprSevsWmPo5rVeroGfsthis is the access token.
fGiinCdqtehMeehiddenymDeAsasaawgGeryye8amh is the access secret.

Try it!

Try the following to post an update:

require 'twitter'
oauth ='ve4whatafuzzksaMQKjoI', 'KliketyklikspQ6qYALcuNandsomemored8pQ6qYALIG7mbEQY')
oauth.authorize_from_access('123-owhfmeyAgfozdyt5hDeprSevsWmPo5rVeroGfsthis', 'fGiinCdqtehMeehiddenymDeAsasaawgGeryye8amh')
client =


MODx character encoding

Ahhh character encodings. Don’t you just love them?

Having character issues in MODx? Then probably the MODx manager character encoding, the character encoding of the site itself, your database’s character encoding, or the encoding MODx/php uses to talk to MySQL isn’t correct.

The Website Encoding

Your MODx site’s character encoding can be configured in the manager under Tools/Configuration/Site/Character encoding. This is the encoding your website’s visitors will get.

The Manager’s Encoding

The manager’s encoding can be changed by setting $modx_manager_charset at manager/includes/lang/<language>.inc.php like this (for example):

$modx_manager_charset = 'iso-8859-1';

To find out what language you’re using (and thus was file you need to change), check Tools/Configuration/Site/Language (1 line above the character encoding setting).

This needs to be the same encoding as your site. You can’t have your manager in utf8 and your site in iso-8859-1.

Your Database’s Encoding

The charset MODx/php uses to talk to your database can be set by changing $database_connection_charset in manager/includes/ This needs to be the same as your database’s charset. Make sure you use the correct corresponding charset, for iso-8859-1 you need to use ‘latin1’. Utf8 is just utf8.


$database_connection_charset = 'latin1';

Now, if you check Reports/System info, the ‘Database Charset’ might say something else. This is because the mysql variable ‘character_set_database’ is displayed here, which contains the character set used by the default database and not the one for the current database/connection.

However, if you’d change this to display ‘character_set_connection’, it could still say something else because the ‘set character set’ statement used by MODx doesn’t change this value either. The ‘set names’ statement does, but since it turns out my MODx install works now as expected I’ll just leave it at this before I get a headache.

If I saved you a potential headache or you think I’m totally wrong or overlooked something, let me know in the comments.

btw: I want to be able to use a real editor with MODx. Somehow.

The hidden cost of interrupting knowledge workers

The November issue of pragpub has an interesting article on interruptions. The article is written by Brian Tarbox, who also mentions the article on his blog. I like the subtitle: ‘Simple Strategies for Avoiding Dumping Your Mental Stack’.

Brian talks about the effective cost of interrupting a ‘knowledge worker’, often with trivial questions or distractions. In the eyes of the interruptor, the interruption only costs the time the interrupted had to listen to the question and give an answer. However, depending on what the interrupted was doing at the time, getting fully immersed in their task again might take up to 15-20 minutes. Enough interruptions might even cause a knowledge worker to mentally call it a day.

According to this article interruptions can consume about 28% of a knowledge worker’s time, translating in a $588 billion loss for US companies each year.

interruptions can consume about 28% of a knowledge worker's time, translating in a $588 billion loss for US companies each year Click To Tweet

Looking for a new developer to join your team? Ever thought about optimizing your team’s environment and the way they work instead?

Making non knowledge workers aware

You can’t. Well, I haven’t succeeded yet. And believe me: I’ve tried. When you’ve got a simple way to really increase your productivity (‘give me 2 hours of uninterrupted time a day’) it wouldn’t be right not to tell your boss or team-leader about it.

The problem is: only productive knowledge workers seem to understand this. People who don’t fall into this category just seem to think you’re joking, being arrogant or anti-social when you tell them the interruptions can really have an impact on your productivity.

Also, knowledge workers often work in a very concentrated mental state which is described here as:

It is the same mindfulness as ecstatic lovemaking, the merging of two into a fluidly harmonious one. The hallmark of flow is a feeling of spontaneous joy, even rapture, while performing a task.

Yes, coding can be addictive and if you’re interrupting a programmer at the wrong moment, you’re effectively bringing down a junkie from his high in just a few seconds. This can result in seemingly arrogant, almost aggressive reactions.

How to make people aware of the production-cost they’re inflicting: I’ve been often pondering that question myself. The article suggests that solutions based on that question never seem to work. To be honest: I’ve never even been able to find a half decent solution for this question. People who are not in this situations just don’t understand the issue, no matter how you try to explain it.

Fun (?) thing I’ve noticed: Programmers or IT people in general who don’t get this are often the kind of people who just don’t get anything done.

Interrupt handling (interruption management?) IRL

Have non-urgent questions handled in a non-interruptive way

It helps a bit to educate people into using non-interruptive ways to ask questions: “duh, I have no idea, but I’m a bit busy here now could you put it in an email so I don’t forget?”. Eventually, a considerable amount of people will skip interrupting you and just send an email right away. Some stubborn-headed people however will continue to just interrupt you, saying “you’re 10 meters from my desk, why can’t we just talk?”.

Just remember to disable your email notifications, it can be hard to resist opening your email client when you know a new email just arrived.

Use Do Not Disturb signals

When working in a group of programmers, often the unofficial sign you can only be interrupted for something important is to put on headphones. And when the environment is quiet enough, often people aren’t even listening to music. Otherwise music can help to block the indirect distractions (someone else talking on the phone or tapping their feet). You might get a “they’re all just surfing and listening to music”-reaction from outsiders though.

Peopleware talks about a team where the no-interruption sign was placing a shawl on the desk. If I remember correctly, I am unable to locate my copy of this really excellent must-read book.
If you have all standardized on the same IM tool, maybe that tool has a ‘do not disturb’ setting. Also some phone-systems have a ‘DND’ (do not disturb) setting.


Brian offers a number of good suggestions, some obvious like: hide away somewhere they can’t find you. Not sure how long it’ll be till someone thinks you’re just taking a nap somewhere though. Also, this often isn’t possible or your boss might not understand this. And if you really get caught taking a nap, make sure to explain that your were powernapping.

Counter-act interruptions

Another suggestion he offers is when you’re being interrupted to just hold up your hand, blocking the interruption, and at least giving you time to finish your sentence or your block/line of code. The last suggestion works more as a way to make it obvious to the interruptor that they really are interrupting your work and to offload some of the cost on the interruptor. In practice, this can also helps you cool down a bit so you don’t start saying nasty things to the interruptor.

Unfortunately I’ve sometimes been confronted with people who just ignore this signal and keep talking, as if they’re sure that whatever they’ve got to say is really worth listening to and without a doubt more important than anything you might be doing.
This behaviour usually leaves me speechless (not good when someone just asked a question). I’ve noticed that these people are usually also the first to complain when being interrupted themselves. They’re generally not very liked as colleagues, so try not to imitate their behaviour.

TDD as a way to minimize recovery time

I don’t like Test Driven Development. Mainly for only one reason: It interrupts flow. At least, that’s what it does for me, but maybe I’m just not grown used to TDD yet.

BUT a positive effect TDD has on me when I have to work in an interruptive environment and can’t really get into the ‘flow’ (also supposedly called ‘the zone’ by software developers, although I’ve never heard it 1st hand), TDD helps me to concentrate on the tasks at hand and helps me to get back at work after an interruption. I feel when using TDD, I can get by without the need for being totally ‘in’ the project and I can be reasonably productive without obtaining ‘flow’.

Do you have a suggestion on how to make people aware of the concept of ‘flow’ and the cost of interruptions? (without looking like an arrogant ass or a weirdo)

Twitter gem – undefined method `stringify_keys’


from test.rb:26



module Twitter
  class Search
    def fetch(force=false)

      if @fetch.nil? || force
        query = @query.dup


        return nil if response.class != Hash

        @fetch =



(adapted from

If you have a better solution: speak up!