He [Scott Davis] told a story (I believe to be from the book) that succinctly showed what happens when consumers are presented with too many choices: Given 3-5 options for tasting Jellies/Jams, customers ended up buying more of it. However, increasing that to two-dozen left sales at levels lower than having no sampling at all.

We simply become overwhelmed by the number of options available, turn off, and refuse to make a choice at all. That leads us to the Maximizer/Satisficer concept, where the Maximizers are especially prone to analysis because they try to be more prepared when making decisions and never stop analyzing, even after making the choice. On the other hand, satisficers try to narrow their decision-making points down to a reasonable few.

More powerful programming languages make programs shorter. And programmers seem to think of programs at least partially in the language they're using to write them. The more succinct the language, the shorter the program, and the easier it is to load and keep in your head.

We want to use R-mode more than we have because the R-mode provides intuition, and that's something we desperately need in order to become experts. We cannot be expert without it. The Dreyfus model emphasizes the expert's reliance on tacit knowledge; that's over here in the R-mode as well. Experts rely on seeing and discriminating patterns; pattern matching is here too.

But now, "We're settling into a pattern where a relatively small percentage of IT workers will need a certification to work in the area that they're in."

One of those areas is high-end IT architecture, and there are several certs that are profitable, in his view. They include the architecture-related certs offered by Cisco, Oracle, Microsoft, IBM, and EMC.

A certification like one of these can make or break a job interview.

Any hint that companies are de-emphasizing the technical certification process is troubling, because it could so easily have a negative effect on professional standards. I'm as big a believer as anyone in the importance of on-the-job training and real-world experience, but that doesn't begin to obviate the need for a formal certification program.

In a world where risk management and business continuity planning are essential pursuits for any healthy IT organization, every asset needs to be defined and monitored, and that includes technical skills. There's no better way to accomplish that than through a consistent, well-conceived means of documenting who has what skills. And that means certification.

Do you remember a pop star named Tiffany (no last name) from the 1980s? She was in the top of the top forty, and a constant sound on the radio back then. She enjoyed immense success, becoming for a short time a household name.
...
Apparently, if she tried, she didn't move fast enough to hold the affection -- or even the attention -- of her fans. When the tastes of the nation turned from bubble gum to grunge, Tiffany suddenly became obsolete.

Looking ahead and being explicit about your skill development can mean the difference between being blind or being visionary.

Java is mainly used in Web applications that are mostly fairly trivial. If all we do is train students to be able to do simple Web programming in Java, they won't get jobs, since those are the jobs that can be easily outsourced. What we need are software engineers who understand how to build complex systems.

Every programmer should also read Chad Fowler's "My Job Went To India" book, where he explains that as larger and larger numbers of programmers adopt a particular skill, that skill becomes more and more a commodity. Rails development becoming a commodity is really not in the economic interest of any Rails developer. This is especially the case because programming skill is very difficult to measure, which - according to the same economics which govern lemons and used-car markets - means that the average price of programmers in any given market is more a reflection of the worst programmers in that market than the best. An influx of programmers drives your rates down, and an influx of incompetent programmers drives your rates way the fuck down. (Bold emphasis mine)

The be-all end-all self building framework/generator has been the holy grail of software development since its inception, and it isn't really much closer to achieving that now than it was 20 years ago.

Anybody remember CASE (Computer Aided Software Engineering)? It was sold as the end of software development. To build an application, a layperson would just drag and drop computer generated components onto a "whiteboard" and connect them up by drawing lines. CASE was THE buzzword in the late eighties. 20 years later, it's nowhere to be found.

Software development will become a complete commodity the moment business decides to stop using their systems as a way to gain a competitive advantage.

As for the skills required, I'd actually argue that the workplace is demanding people with MORE skills than ever before. There is a lot of crap work for sure, and that market is dying out. For companies that want to be serious players, though, the demands are higher than they've ever been.

Your personal product road map is what you use to tell whether you've moved. When you're going to the same office day in and day out, working on a lot of the same things, the scenery around you doesn't change. You need to throw out some markers that you can see in the distance, so you'll know that you've actually moved when you get to them. Your product "features" are these markers.

Unless you really lay it out and make a plan, you won't be able to see beyond the next blip on the horizon. In Chapters 2 and 3, you discovered how to be intentional about your choice of career path and how to invest in our professional selves. Though I focused on what seemed like a onetime choice of what to invest in, each choice should be part of a greater whole. Thinking of each new set of knowledge or capability as equivalent to a single feature in an application puts it in context really well. An application with one feature isn't much of an application.

What's more, an application with a bunch of features that aren't cohesive is going to confuse its users... A personal product road map can not only help you stay on track, constantly evolving, but it can also show you the bigger picture of what you have to offer...

While it's definitely OK to learn diverse skills -- it expands your thinking -- it's also a good idea to think about the story your skill set tells. (Bold emphasis applied by me.)

Let's start with the impolite question: Should one really care about multilanguage support? When this feature was announced at .NET's July 2000 debut, Microsoft's competitors sneered that it wasn't anything anyone needed. I've heard multilanguage development dismissed, or at least questioned, on the argument that most projects simply choose one language and stay with it. But that argument doesn't really address the issue. For one thing, it sounds too much like asserting, from personal observation, that people in Singapore don't like skiing. Lack of opportunity doesn't imply lack of desire or need. Before .NET, the effort required to interface modules from multiple languages was enough to make many people stick to just one; but, with an easy way to combine languages seamlessly and effortlessly, they may -- as early experience with .NET suggests -- start to appreciate their newfound freedom to mix and match languages.

Applications of the future will take advantage of the polyglot nature of the language world. We have 2 primary platforms for "enterprise" development: .NET and Java. There are now lots of languages that target those platforms. We should embrace this idea. While it will make some chores more difficult (like debugging), it makes others trivially easy (or at least easier). It's all about choosing the right tool for the job and leveraging it correctly. Pervasive testing helps the debugging problem (adamant test-driven development folks spend much less time in the debugger). SQL, Ajax, and XML are just the beginning. Increasingly, as I've written before, we're going to start adding domain specific languages. The times of writing an application in a single general purpose language is over. Polyglot programming is a subject I'm going to speak about a lot next year.

The first layer is what I called the stable layer. It's not a very large part of the application in terms of functionality. But it's the part that everything else builds on top off, and is as such a very important part of it. This layer is the layer where static type safety will really help. ...

The second layer is the dynamic layer. This is where maybe half the application code resides. The language types here are predominantly dynamic, strongly typed languages running on the JVM, like JRuby, Rhino and Jython. ...

The third layer is the domain layer. It should be implemented in DSL's, one or many depending on the needs of the system. In most cases it's probably enough to implement it as an internal DSL within the dynamic layer, and in those cases the second and third layer are not as easily distinguishable. But in some cases it's warranted to have an external DSL that can be interacted with. A typical example might be something like a rules engine (like Drools).

An easy way to measure your progress is to use a trusted third party. A mentor or a close colleague doesn't live in your head with you and can help give you a more objective look at where you stand. You might discuss your abilities as a software developer, project leader, communicator, team member, or any other facet of the total package that makes you who you are. (Chad Fowler, pgs. 155-156 of My Job Went to India)

If your company has such processes in place already, don't write them off as HR nonsense. Take them seriously and make good come out of them.

Many of us in the mid-1990s swore by Novell's NetWare platform when it came to providing ?le and print services in the enterprise. Novell was way ahead of its time with its directory services product, and those of us "in the know" were almost cocky in our criticism of competing technologies. Novell's product was enjoying a healthy majority in market share, and it was hard to imagine the tide turning.

No single event made it obvious that Novell was losing to Microsoft. Microsoft never made that magic Active Directory release that made us all say, "Wow! Drop NetWare!" But, Netware has slowly gone from bleeding- edge innovator to legacy technology. For many NetWare administrators, the water was boiling before they ever even realized the pot was warm.

• Communication bandwidth is lower when it's not face to face. Most will be done through email, so most of it will suck comparatively.
  
  
• Being in (often widely) different time zones means synchronous communication is limited to few overlapping hours of work. If you get stuck and need an answer, you stay stuck until you're in one of those overlaps. That sucks.
  
  
• Language and cultural barriers contribute to dysfunctional communication. You might need an accent to accent translator to desuckify things.
  
  
• Because of poor communication, we could find ourselves in situations where we don't know what each other is doing. That leads to duplicative work in some cases, and undone work in others. Which leads to more sucking for your team.
  
  

1. In the Draggable#updateDrag function (~ line 356), on the first line, I changed the value of the pointer argument to take into account how much the container had scrolled:
   
   pointer = new Array(pointer[0] + this.options.scroll.scrollLeft, pointer[1] + this.options.scroll.scrollTop);
   
   At least one of the solutions I recall seeing mentioned this.
   
   
2. In the same function, I changed the first two elements in the p array before the last two elements get pushed onto it:
   
   p = new Array(p[0] + this.options.scroll.scrollLeft, p[1] + this.options.scroll.scrollTop);
   
   This also just takes into account how far the container has been scrolled.
   
   
3. To ensure my droppables were able to receive the draggables given the adjusted coordinates, we need to adjust the scroll position just as we did above. First, I adjusted the code in my webpage that produces the droppables and added a scroll parameter that should be the name of the element that scrolls (the same parameter the draggable accepts):
   
   Droppables.add('slot_1_7_2', { scroll: 'weeklycalendar' });
   
   Since Droppable elements don't generally take a scroll option, we'll need to modify that code in Scriptaculous's dragdrop.js file as well. In the Droppable#fire function (~ line 109) add the folling lines under Position.prepare();:
   
   var point = [Event.pointerX(event), Event.pointerY(event)];
if(this.last_active.scroll){
  point[0] += $(this.last_active.scroll).scrollLeft;
  point[1] += $(this.last_active.scroll).scrollTop;
}

   Finally, just underneath that where it calls this.isAffected, change the first parameter from [Event.pointerX(event), Event.pointerY(event)] to use the variable we created above, pointer.

1. After listening to the problem description, the first thing to do is recognize whether or not you can solve the problem while the customer is on the phone, or if anyone can. If you can, then do it. If you think only someone else can do it, and work for an organization that has multiple levels of live-support, then escalate it.
   
   If you don't think solving the problem is possible without escalating it to a level of support that won't get to it immediately, thank the customer for reporting the issue, let them know the problem is being worked on, and boogie on to step 2.
   
   
2. As support, the first thing you need to do before escalating the issue is confirm there is an issue, and do it with a test account, not the user's.
   
   It's ridiculous to ask for the user's credentials. Don't do it. If someone were to ask you, "What is your username and password?" what would you think? The average user isn't going to know your query is tantamount stupidity, but if you get someone who is slightly security-conscious, you're going to lose a customer. Hopefully, he's not a representative of your whale.
   
   If anyone found out that you're in the habit of asking users for their passwords, they can easily call anyone who uses your software and get in by just asking. Further, since many people use the same password for everything or many things, that person would also have access to your customers' other sensitive information, wherever it resides.
   
   You can point the blame at your stupid customer for using the same password everywhere they go all you want. You're being just as stupid by opening the door for that type of attack. Further, you should always try to recreate and fix the problem with as little inconvenience to the user as possible. That means doing it with test accounts as opposed to asking the user for theirs, or changing their information.
   
   Keep things simple for the user. Don't jump immediately to using their time to make things easier on the support team. Doing that is lazy at best, sloppy most of the time, and could result in disaster at worst.
   
   
3. After confirming the existence of the problem, provide the steps of how to reproduce it. Give some screen shots. If it's a web app, provide links. Don't constantly send and email and ask the higher levels about it. Doing so once or twice is one thing, but doing it for every request is a time-waster. Just send the email and the next level will get to it when they can. If they don't get to it within the acceptable time-frame for your organization, send a reminder. Include the boss if you need to. But don't do that prematurely (and that's another subject altogether).
   
   
4. Don't jump to conclusions about the source of the problem. Although Abby Fichtner wasn't speaking directly to support ...
   
   
   
   ... This is the opposite of my general approach. The parallel here is code : customer :: you : dumb². I've learned (even if through a bit of self-torture) that I should always look at the code first, if for no other reason than I don't want to be foolishly blaming others when I'm to blame. In the case of support, I've always hated the term "User Error," and that's what the tweet reminds me of.
   
   By framing it as an external problem, we miss an opportunity to teach the user how to use the product, or a chance to improve the product to make sure they can't use it "incorrectly."

• Keyboard Shortcuts: Shoes leaves it to the programmer to implement keyboard shortcuts, so while familiar actions like Copy (ctrl-C) and Paste (ctrl-V) are available via the mouse, I have yet to implement them on the keyboard.
  
  
• Error Handling: It's minimal. If you enter a non-existent file, or non-Rails-production file, who knows what will happen?
  
  
• Crazy web-of-a-graph: My intent is to build the data model such that you can search most items in approximately O(1) time. Right now, you drill down to the day in constantish time, and after that it becomes linear search.
  
  
• Testing on all platforms and Rails versions: I proudly certify this version (0.1) WOMM.
  
  
  Source
  
  That means I've only tested it on Mac OS 10.5.8 (Leopard), using straight log files from Rails 2.2 on Ruby 1.8.6 and 1.8.7.
  
  That being said, Shoes is supposed to work on Windows and Linux as well, and I've not noticed any major differences in the log files between Rails versions, so you might find it works great for you too. If not, I encourage you to let me know and I'll fix it up quick for you. (Please have a sample log file available if possible.)

1. Setup, in which we use globally shared memory
2. Negate the number if it is negative, for no reason I can think of, and set a reminder flag.
3. Set buffer to point to the final spot. Move it back one, dereference it, and insert the null string terminator there.
4. Move the buffer backwards. Dereference the pointer and set the value there to the character '0'. Add the remainder of the number divided by ten to that, since '1' is 1 away from '0', and so forth.
5. Divide the number by 10 so we can get to the next digit.
6. If we've done the loop 3 times, move the buffer pointer back one location and insert a comma.
7. Repeat starting at step 4 until the number is 0.
8. Cleanup - if the front character is a comma, remove it by moving the buffer pointer forward.
9. Cleanup - Move the buffer pointer backwards and insert our '-' if the negative flag has been set.

1. Copy the number to a string.
2. Starting at the end, copy each character to another string, inserting a comma every 3rd time.

1. You have the source code. Look through it. You have no other choice when no one has had your problem, and you might benefit by doing so even if someone already has.
   
   
2. Even when you think you're focused working late, and resolve to leave when you lose the focus, you're still going to make stupid decisions that you won't notice until the morning. I turned a 5 hour journey into a 12 hour marathon. Sleep, FTW.

Requirements

1. Can you name a number of non-functional (or quality) requirements?
   I'd first mention performance and security, from the user's perspective. I'd then mention meeting minimum requirements for metrics like code coverage in testing and dependencies in our design. I don't consider code quality out-of-order when it comes to requirements.
   
   The non-functional requirements page at Wikipedia lists several examples. Notable exceptions from my quickie-response: accessibility, documentation, portability. There are several that are listed that I consider covered by what I've listed, but I missed some that caused me to say
   
   
   
   
2. What is your advice when a customer wants high performance, high usability and high security?
   My "advice" starts with the questions: "What do you consider X to be?" where X belongs to the set {"high performance", "high usability", "high security"}. I might offer that I consider "high performance" to be a misnomer, as it's either acceptable or not, and that unless the customer defines it, I don't know how we'd even attempt to measure something as vague as "usability."
   
   I'm not sure where I'd prepare for this question. Any suggestions are appreciated.
   
   
3. Can you name a number of different techniques for specifying requirements? What works best in which case?
   I can name several: tell me in person, tell me over email, tell me over IM or over the phone. I know that's not what you're looking for. You're looking for answers like "use cases." It all boils down to the same. I might even mention "unit tests" here. That's part of the spec, as far as I'm concerned, and for almost any software I write for myself, it's the only way I specify requirements (except for maybe a very informal to-do list).
   
   Face-to-face works best in most cases, I'd gather.
   
   The answer after doing some research: ¡Ay, ay, ay, no me gusta! I didn't see this coming. There are a number of things that could qualify as answers (Prototyping, Storyboards, Modeling, ..., State transitions) that I knew about beforehand. I thought to include none of them.
   
   
   
   
4. What is requirements tracing? What is backward tracing vs. forward tracing?
   My response? "I don't know anything about requirements tracing. I'm willing to learn."
   
   Once again, Wikipedia tells us about requirements traceability, illuminating the issue for us.
   
   
5. Which tools do you like to use for keeping track of requirements?
   I generally use a combination of a text file and emails, as far as the client is concerned. If it's a larger system, I'll use something like Sharepoint, Basecamp, or another system that performs a similar function. I have no preferences, because nothing I've ever used compares to a simple list. If it does, it's equally useful.
   
   I don't know that I'd say I like any of them. In reality I prefer a simple to-do list that I encode in tests (insofar as I'm capable of writing the tests) and knock them out one-by-one.
   
   
6. How do you treat changing requirements? Are they good or bad? Why?
   I don't give a value judgement on changing requirements: they are inevitable. They can be good or bad depending on how the client handles them.
   
   I always try to let the client know: I can do X amount in Y timeframe. You asked for Z total. Here's an estimate for each item in Z, pick X from it for our current Y timeframe. I'll get back to you every Y timeframe to show a demo, and you can choose X from the remaining Z again (with changes based on circumstances if required). Feel free to fire me when you have enough out of Z that's functional. (Ok, I probably wouldn't say the last sentence in those terms, but I'd find a way to say it, if for no other reason than to sell them the rest of the process.)
   
   As far as looking it up before the interview: I've review Agile literature. Searching any of the agile yahoo groups for the question at hand ought to be good enough.
   
   
7. How do you search and find requirements? What are possible sources?
   "What do you mean?" would be my response. I really don't know. What does searching and finding requirements mean? Does it mean figuring out how to do requirements that I don't know how to accomplish?
   
   If so, the first step is Google. In the rare event no one that I can find has had my problem, I'll go traipsing through the source code if it's available.
   
   Clearly, I don't know where to start here.
   
   
8. How do you prioritize requirements? Do you know different techniques?
   I rarely prioritize requirements. I let the customer decide. I give them a relative cost of implementing X requirement vs. implementing Y requirement, and let them decide. If Y requires X, then I tell them so.
   
   I know of different techniques - take "random" for example. I don't know what they might be called. But I cannot think of anything better, even if it were decreed as a Top 10 Commandment for Prioritizing Requirements.
   
   No web search for this comes to mind. I'd review a couple of process management books if I had no clue. This seems to be a decent discussion, if you must have one from me from a cursory browse.
   
   
9. Can you name the responsibilities of the user, the customer and the developer in the requirements process?
   The user will be the person using the software, versus the customer being the one who pays for its development. I hate that distinction. The developer programs it. Responsibilities? In my ideal organization, I'd have:
   • Developers working with the Customer to manage requirements.
   • Developers working with the User to make the application work for them regardless of the Customer (I've seen too many projects where the User had to use whatever the Customer purchased, even if the purchase was ... little yellow bus-ish.)
   • Customer/User having daily meetings with the developer
   • Developer making the best software he/she can given the constraints.
   Again, I don't know where I'd look this up before being asked. Suggestions (again, as always) are most welcome.
   
   
10. What do you do with requirements that are incomplete or incomprehensible?
    I send an email saying "I don't understand what you mean. Please read the very small attached book and get back to me."
    
    
    
    Just kidding, of course (at least in most cases. I've been recently tempted to send that exact email, as it happens.)
    
    I just ask them to clarify. If I don't have contact with the customer, I ask the intermediary to clarify or get clarification.
    
    Outside reading: Agile, and hopefully other processes for some compare and contrast.
    
    

1. What are metaphors used for in functional design? Can you name some successful examples?
   I hate to start the first one off with an IDK, but what else can you do? I feel like I can talk intelligently about some of the issues involved in functional design, but until now, I never realized it was a process unto itself, nor did I know what all it entailed until after I browsed the remaining questions.
   
   Reading: The Wikipedia page on functional design is delightfully lacking any useful information about the topic. However, these functional design guidelines on Smashing Magazine seem to be a reasonable starting point.
   
   
2. How can you reduce the user's perception of waiting when some functions take a lot of time?
   Show a progress bar. Distract them with something they need to read or stage data-collection/interaction with the user. Of course, the obvious yet overlooked answer here would be to make the offending functions faster. At worst, if the function doesn't require user interaction at all, you could spawn a new thread to do the work in the background and let the user continue working. Then they'd notice no waiting at all.
   
   Reading: I picked this up from observation and deduction. I don't know where I'd go to read such information.
   
   
   
   
3. Which controls would you use when a user must select multiple items from a big list, in a minimal amount of space?
   What controls do I have to pick from? Can the list be grouped by some recurring values? For instance, consider how the iPod uses the scroll wheel to let you navigate a long list of music. Now apply finding one song to finding several, and you have an idea of what I'm talking about.
   
   Another option might be to have auto-complete, with a special key for "add to list" when you're satisfied, which puts you back at the beginning of the text box. Another key would end the sequence.
   
   Can you visualize the list in some way? The user could then click pictures to drill down and roll up on items in the list, viewing it from different levels. For example, if the list was of colors, you could take the typical color-picker from every image program out there, and use it to choose your list.
   
   Reading: I came up with these on the spot, and can't say I've seen them completely implemented yet, so again, when it comes time for advice on where to read up on this topic, I've got nothing.
   
   
4. Can you name different measures to guarantee correctness of data entry?
   Aside from the pains of torture? You'll definitely want a fast-acting validation to let the user know as soon as possible that you think their input is incorrect. When talking about the web, you'll want to validate it server side as well. You'll want to show some examples if you need a certain format of input (or just if the customer expects to be forced into a format, you'll want to relieve their anxiety by providing an example). Finally, make the user type as little as possible, except if you're doing a progressive lookup / autocomplete on their typing.
   
   Reading list is vacant. Please advise.
   
   
   
   
5. Can you name different techniques for prototyping an application?
   At first, I didn't realize there were different techniques. Unless we were talking about storyboards vs. mark-up-only or a shell of an application. I don't imagine that was the point.
   
   I did find something that I think was the point: for reading, Scott Ambler has a take from a different point of view: tips and techniques in user interface prototyping that includes another list of resources. A treasure trove!
   
   Now that I know what we're talking about, I'd have given similar answers. I feel I could have been effective in a conversation about this, but the other party would have had to lead me that direction. I couldn't get there from the question alone.
   
   
6. Can you name examples of how an application can anticipate user behavior?
   Analyze it and look for patterns. Use a Markov Model to predict next action based on previous N actions.
   
   That's the only way (well, there are variation on the same theme) I can think of that an application would do it. We could of course observe the users and make changes ourselves. I don't think that would be a bad idea.
   
   Reading is nonexistent. Those ideas came from elsewhere, but never as part of functional design.
   
   
7. Can you name different ways of designing access to a large and complex list of features?
   There's the outmoded File/Edit/View tree menu controls (find link to discussion), ribbon interfaces, and progressive search, or autocomplete.
   
   I'd also consider re-purposing my answers to #3.
   
   
8. How would you design editing twenty fields for a list of 10 items? And editing 3 fields for a list of 1000 items?
   For the latter, I'd almost certainly put them all in one page. Or 100+ at a time. The fewer clicks the better. It's worth importing from a spreadsheet every time, if that's an option.
   
   For the former- Can the 20 fields be broken down into more cohesive units? Twenty fields in one form is often too many. 10 forms is not absurd, on the other hand.
   
   
9. What is the problem of using different colors when highlighting pieces of a text?
   The highlight color can make the text hard(er) or downright impossible to read. Anything else?
   
   I don't see room for discussion, unless you're flashing the colors -- then you might get into causing epileptic seizures in those susceptible to them.
   
   
10. Can you name some limitations of a web environment vs. a Windows environment?
    Access to the file system. Lag mainly - less responsive experience for most of web than on Windows.
    
    

• Do you know what a regression test is? How do you verify that new changes have not broken existing features?
  You answered the second part of the question with the first: you run regression tests to ensure that new changes have not broken existing features. For me, regression tests come in the form of already written tests, especially unit tests that I've let turn into integration tests. However, you could write a regression test before making a new change, and it would work as well.
  
  The point is that you want to have some tests in place so that when you inevitably make changes, you can ensure they didn't cascade throughout the system introducing bugs.
  
  
• How can you implement unit testing when there are dependencies between a business layer and a data layer?
  Generally I'd let that unit test become an integration test. But if the time to run the tests was becoming too long, I'd build a mock object that represented the data layer without hitting the database or file system, and that would be expected to decrease the running time significantly.
  
  
• Which tools are essential to you for testing the quality of your code?
  I don't know if anything is essential. If you've got asserts or throws, you can always implement testing yourself, and a good eye for bad code helps as well. That said, to reduce psychological barriers to testing, it would be nice to have tools already made for this purpose.
  
  Luckily, we have such tool available: unit testing frameworks and static code analysis tools in your language of choice.
  
  
• What types of problems have you encountered most often in your products after deployment?
  Most recently I've encountered very specific integration errors, and written about some ideas on fixing the polysystemic testing nightmare.
  
  
• Do you know what code coverage is? What types of code coverage are there?
  Generally I'd thought it refers to the percentage of code covered by tests. I don't know what the second question here refers to, as I thought it referred exclusively to testing.
  
  
• Do you know the difference between functional testing and exploratory testing? How would you test a web site?
  I have to admit that before being asked this question, I wouldn't have thought about it. My guess is that functional testing refers to testing the expected functionality of an application, whereas exploratory testing involves testing without knowing any specific expectations.
  
  As far as testing a web site, I'll have plenty of unit tests, some acceptance tests, perhaps some in Selenium or a similar offering, as well as load testing. These aren't specific to web apps, however, except for load testing in most cases.
  
  I'm very interested in feedback here, given my misunderstanding of the question. If you can offer it, let me thank you in advance.
  
  
• What is the difference between a test suite, a test case and a test plan? How would you organize testing?
  A test suite is made up of test cases. I'm not sure what a test plan is, aside from the obvious which the name would suggest. As far as organizing testing: I tend to organize my unit tests by class, with the method they test in the same order they exist within that class.
  
  
• What kind of tests would you include for a smoke test of an ecommerce web site?
  Again, here's another where I didn't know the terminology, so having to ask would result in demerits, but knowing the answer of "what is a smoke test?" allows us to properly answer the question:

  In software testing, a smoke test is a collection of written tests that are performed on a system prior to being accepted for further testing.

  
  
  In that case, I'd click around (or more likely, write an application that could be run many times that does the same thing, or use that application to write Selenium tests) looking for problems. I'd fill out some forms, and leave others blank. Ideally, it would all be random, so as to find problems with the specs as often as possible without actually testing all the specs, since the point seems to be to give us a quick way to reject the release without doing full testing.
  
  
• What can you do reduce the chance that a customer finds things that he doesn't like during acceptance testing?
  The best thing to do is to use incremental and iterative development that keeps the customer in the loop providing feedback before you get down to acceptance testing. Have effective tests in place that cover his requirements and ensure you hit those tests. When you come across something you know won't pass muster, address it even though it might not be a formal requirement.
  
  There are undoubtedly underhanded ways to achieve that goal as well, but I'm not in the habit of going that direction, so I won't address them here.
  
  
• Can you tell me something that you have learned about testing and quality assurance in the last year?
  Again I'm going to reference my polysystemic testing nightmare, because it taught me that testing is extremely hard when you don't have the right tools at your disposal, and that sometimes, you've got to create them on your own.
  
  

The metric I, and others I know, have used to judge unit testing is: does it find bugs? The answer has been no. For the majority of the code I write, it certainly doesn't find enough bugs to make it worth the investment of time.

1. If changing your code means broken tests cascading through the system to the tune of 10%, you haven't written unit tests, have you?
   
   (Further, the sorts of changes that would needlessly break so many unit-cum-integration tests would be rare, unless you've somehow happened or tried very hard to design a tightly coupled spaghetti monster while writing unit tests too.)
   
   
2. I've not yet met a project where the unit tests are the maintenance nightmare. More often, it's the project itself, and it probably doesn't have unit tests to maintain. The larger the code base, with large numbers of dependencies and high coupling, the more resistant it is to change - with or without unit tests. The unit tests are there in part to give you confidence that your changes haven't broken the system when you do make a change.
   
   If you're making changes where you expect the interface and/or behavior to change, I just don't see where the maintenance nightmare comes from regarding tests. In fact, you can run them and find out what else in your code base needs to change as a result of your modifications.
   
   In short, these scenarios don't happen enough such that they would make testing worthless.
   
   
3. You may indeed write a bunch of tests that don't do anything to test your code, but why would you? You'd have to try pretty hard to get 100% code coverage with your tests while succesfully testing nothing.
   
   Perhaps some percentage of your tests under normal development will provide a false sense of security. But without any tests whatsoever, what sense of security will you have?
   
   
4. If you measure the value of unit testing by the number of bugs it finds (with more being better), you're looking at it completely wrong. That's like measuring the value of a prophylactic by the number of diseases you get after using it. The value is in the number of bugs that never made it into production. As a 2008 study from Microsoft finds [PDF], at least with TDD, that number can be astonishingly high.
   
   
5. As for user reports, automated monitoring systems, and logging doing a better job at finding bugs than unit testing: I agree. It's just that I'd prefer my shipped software to have fewer bugs for them to find, and I certainly don't look at my users as tests for my software quality once it's in production.

• How do you make sure that your code can handle different kinds of error situations?
  I write tests that describe the expected error situations and check to see that they are handled appropriately. If the software is legacy and prone to generating exceptions, I'll wrap it up to report the exceptions to get an idea of what needs attention first, and start attacking it there. Of course where required, we'll use try/catch.
  
  Mostly I try to follow the rigorous WOMM development process.
  
  
  
  
• Can you explain what Test-Driven Development is? Can you name some principles of Extreme Programming?
  TDD: Red, Green, Refactor. You write a test that specifies some behavior the code should produce. Run the test to make sure it fails. Write code to make the test pass, then run it to make sure it passes. Change the code as needed to improve its design.
  
  XP: Aside from testing, we want to continuously review code through pair programming, maintain sustainable work conditions with sane work-weeks, and continually integrate our code to reduce the time we have to spend working out kinks in that process. There's more, but those are a few.
  
  Reading: Xprogramming.com is a good starting point. The associated lists (TDD and XP) on Yahoo Groups are great for discussion. It's probably worth reading a book or two on the subjects. I'd recommend Kent Beck or Ron Jeffries.
  
  
• What do you care about most when reviewing somebody else's code?
  Does it say what it's doing, and do it correctly? Is it readable?
  
  Reading: As with most of these questions, Steve McConnell's Code Complete 2 is an outstanding resource on the subject. If you don't read anything else, read that.
  
  
• When do you use an abstract class and when do you use an interface?
  I'd use an abstract class when I want to provide some implementation for reuse, but where some also remains to be specified by the inheriting class. An interface is useful for multiple inheritance in languages that don't allow it, as well as a decoupling device - allowing you to depend on interfaces that don't change as often as implementations might.
  
  Reading: Books on OO design are useful, especially those targeting static languages like Java.
  
  
• Apart from the IDE, which other favorite tools do you use that you think are essential to you?
  Continuous integration tools, testing frameworks, (some people might include dependency injection frameworks), scripting languages, the command line, source control, ... What else would you include?
  
  Reading: McConnell's aforementioned book, The Pragmatic Programmer, Practices of an Agile Developer, tons of blogs that talk about the tools they use to make themselves more productive, and (although I've only seen the presentation and not read the book), Neal Ford's The Productive Programmer probably contains some useful items.
  
  
• How do you make sure that your code is both safe and fast?
  The question seems to imply these goals are normally at odds. I haven't felt that way. I'd program for security first, and then if it's slow, I'd try to identify the bottleneck and then find a way to improve its time complexity. If the algorithm is already at its lower bound for time complexity, I'd move on to micro improvements, like moving variable creation and function calls outside of loops.
  
  
• When do you use polymorphism and when do you use delegates?
  I don't have any hard and fast rules. I rarely need to use polymorphism since I primarily program in dynamic languages that make it unnecessary. (I guess it's still polymorphism, but you're not doing anything special to achieve it.) When I have been in static languages, I'll implement the methods that accept different types as needed to make client code more friendly to work in. If we're actually building an API for public consumption, then obviously we have to move from "as needed" to a more aggressive schedule.
  
  I'm at a loss for a better answer to this question, because (surprisingly to me) I've not thought about it before now.
  
  
• When would you use a class with static members and when would you use a Singleton class?
  I don't know how to answer this except for "when the situation calls for it." I'd normally opt for the class with static members when it makes sense to do it. As far as a proper Singleton, I don't know that I've ever written one that enforces that property. More often, if I need just one, I only create one.
  
• Can you name examples of anticipating changing requirements in your code?
  I write unit tests, so that helps with changing requirements. How? It helps keep the design very modular to allow for extension and easy changes, and the tests themselves provide assurance I haven't broken anything when I do need to make a change.
  
  I don't generally go leaving hooks and pre-implementing code that I think will be needed. YAGNI helps guide me in that regard.
  
  
• Can you describe the process you use for writing a piece of code, from requirements to delivery?
  Requirement -> unit test -> code -> run tests -> commit -> run tests -> deploy.
  
  I think that explains it all, and explaining each step could be a blog post or more of its own.

• How do you find out if a number is a power of 2? And how do you know if it is an odd number?
  To find out if a number is a power of two, you can divide by two until the number is 1 or odd. If the number is odd at any point before you reach one, the number is not a power of two. To find out if a number is odd, I'd normally take number mod 2 and see if the result is 1 or not (1 would mean the number is odd). If performance is a concern and the compiler or runtime doesn't optimize for mod 2, you could use a bit mask that checks if the smallest bit is set or not. If so, the number is odd. If not, the number is even.
  
  
  
  Here's an example with the bit mask:
  
  

  def even? n
    n == n & 0b11111111_11111111_11111111_11111110
  
  end
  
  n = 512
  while even?(n) && n > 1 do
  
    n = n >> 1  
  end
  
  puts n==1
  
  

  
  Note you'll need a large enough bit mask to cover the size of the number in bits.
  
  
• How do you find the middle item in a linked list?
  If it's important to be able to find the middle element, I'd keep a pointer to it. If it's implemented using an array and it's important, we can store the array length and divide by two. If it's implemented using pointers to elements, we can iterate over the list while counting its length, then iterate from the beginning until we get halfway there. We could also take the size of the structure in memory and divide by two, going straight to that element by adding 1/2 the size to the pointer, but that'd be a mighty WTF to most programmers when trying to understand it.
  
  
• How would you change the format of all the phone numbers in 10,000 static html web pages?
  Not by hand if I could avoid it. I'd write a regex that matches any of the known formats in the set of pages and use a language with a function that replaces based on a regular expression find.
  
  
• Can you name an example of a recursive solution that you created?
  I was creating a pattern enumeration algorithm in an effort to statistically identify potentially important subsequences in a given genome. The more immediate goal was to identify Rho sites in a set of bacterial genomes. Since we wanted to identify any potential pattern, the form needed to be general, so a variable depth was required and we used recursion to achieve this. (This is a job interview, so I tried to think of the most impressive sounding example from the last year I could think of.)
  
  
  
  
• Which is faster: finding an item in a hashtable or in a sorted list?
  Item retrieval is basically O(1) in a hash table, while O(log n) in a sorted list, so the hash table is faster on average.
  
  
• What is the last thing you learned about algorithms from a book, magazine or web site?
  I guess it depends on what you'd consider learning. For instance, I recently looked up merge sort to use as reference in writing a sorting algorithm for a custom data structure, but I wouldn't say I "learned" it there. If you take "learning" as being introduced to, it was in a course at school or via a book.
  
  
• How would you write a function to reverse a string? And can you do that without a temporary string?
  In most instances I'd be working with a language that already implements a reverse method for strings. If not working in such a language, and I'm using a temporary string, the problem boils down to iterating backwards over the given string, and assigning tempstring[realstring_length - i] = realstring[i]. If we restrict the usage of a temporary string, then we can just use a variable to store the current character for swapping:
  
  for(i=0; i<len; i++) {
  lowerchar = realstring[i];
  realstring[i] = realstring[len-i-1]; // -1 for 0 based arrays
  realstring[len-1] = lowerchar;
}
  
  
• What type of language do you prefer for writing complex algorithms?
  I prefer very super extremely high level languages (to distinguish from VHLL) that tend to be dynamic. The reason is that, in using them, I don't have to worry about low level details that might otherwise get in the way of understanding the algorithm. After that, I'll normally have to implement the same algorithm in a lower level language and take care of the details I could otherwise ignore, because normally performance is going to matter when developing that complex algorithm.
  
  
• In an array with integers between 1 and 1,000,000 one value is in the array twice. How do you determine which one?
  I'd insert each value as a key in a hash and when the key already exists, I know we've hit the duplicate. This gives us O(n) time complexity, which I'm sure could be proven to be the lower bound.
  
  
• Do you know about the Traveling Salesman Problem?
  Yes, it's famous. The problem asks us to find the shortest path that visits every node in a graph.
  
  

1. The Art of Computer Programming series by Donald Knuth
2. Wikipedia's list of algorithms is another good place to start.

def monkeypatch_httpclient_sslsocketwrap(ssl_verify_mode)
    return unless ssl_verify_mode 
    @sslsocket_monkeypatched = true

    require 'soap/nethttpclient'
    block = <<END 
      alias :original_initialize :initialize
      def initialize(socket, context, debug_dev = nil)

        unless SOAP::NetHttpClient::SSLEnabled
          raise ConfigurationError.new('Ruby/OpenSSL module is required')
        end

        @context = context
        @context.verify_mode = #{ssl_verify_mode}
        @socket = socket
        @ssl_socket = create_openssl_socket(@socket)

        @debug_dev = debug_dev
      end
END
      HTTPClient::SSLSocketWrap.class_eval block
end

def monkeypatch_authentication(username, password)
    return unless username && password
    @auth_monkeypatched = true

    require 'wsdl/xmlSchema/importer'
    block = <<END
      alias :original_fetch :fetch
      def fetch(location)

        warn("importing: " + location) if $DEBUG
        content = nil

        normalizedlocation = location
        if location.scheme == 'file' or

          (location.relative? and FileTest.exist?(location.path))

        content = File.open(location.path).read
          normalizedlocation = URI.parse('file://' + File.expand_path(location.path))

        elsif location.scheme and location.scheme.size == 1 and

          FileTest.exist?(location.to_s)
          content = File.open(location.to_s).read
        else

          client = web_client.new(nil, "WSDL4R")
          client.proxy = ::SOAP::Env::HTTP_PROXY
          client.no_proxy = ::SOAP::Env::NO_PROXY
          client.set_auth(location, "#{username}", "#{password}") #added for auth

          if opt = ::SOAP::Property.loadproperty(::SOAP::PropertyName)
            http_opt = opt["client.protocol.http"]

            ::SOAP::HTTPConfigLoader.set_options(client, http_opt) if http_opt
          end
          content = client.get_content(location)

        end
        return content, normalizedlocation
      end
END
      WSDL::XMLSchema::Importer.class_eval block
end

class SendBasicAuthFilter < SOAP::Filter::StreamHandler
  def initialize(loginname, password)

    @authorization = 'Basic ' + [ loginname + ':' + password ].pack('m').delete("\r\n")

  end

  def on_http_outbound(req)
    req.header.delete('Authorization')

    req.header['Authorization'] = @authorization
  end

  def on_http_inbound(req, res)

  end
end

list_service_url = 'https://somesite/path/?WSDL'
list_service_driver = SOAP::WSDLDriverFactory.new(list_service_url).create_rpc_driver

user = 'username'

pass = 'password'
list_service_driver.streamhandler.filterchain << SendBasicAuthFilter.new(user,pass)

• How would you implement the structure of the London underground in a computer's memory?
  Without having travelled to London or on its subway system, I'd guess a graph would be the right data structure. The set of vertices would represent the stations, and the edges connecting them would be the tracks.
  
  Not safe for work (language):
  
  
  I don't know the proper in-memory representation of tramps.
  
  
• How would you store the value of a color in a database, as efficiently as possible?
  Efficiently for retrieval speed, storage speed, size? I'm guessing size. After asking why such efficiency is needed, and assuming we're talking about a range of up to 16⁶ colors (FFFFFF), I'd just store it as the smallest integer type where it would fit.
  
  
• What is the difference between a queue and a stack?
  A queue is typically FIFO (priority queues don't quite follow that) while a stack is LIFO. Elements get inserted at one end of a queue and retrieved from the other, while the insertion and removal operations for a stack are done at the same end.
  
  
• What is the difference between storing data on the heap vs. on the stack?
  The stack is smaller, but quicker for creating variables, while the heap is limited in size only by how much memory can be allocated. Stack would include most compile time variables, while heap would include anything created with malloc or new. (This is for C/C++, and not strictly the case.)
  
  
• How would you store a vector in N dimensions in a datatable?
  I need a little direction for this question, as I know not what it means. I encourage my readers, who have on most occasions proven themselves more adept than me, to come through again.
  
  
• What type of language do you prefer for writing complex data structures?
  I can't imagine using anything higher level than C or C++. Anything more advanced has most anything already built and not very easily molded. Or perhaps I just wouldn't think of it as complex.
  
  
• What is the number 21 in binary format? And in hex?
  10101 in binary and 15 in hex, and no I didn't cheat and use a calculator. It works just like decimal. Take the following digits of an arbitrary number in base B:
  
  UVWXYZ
  
  The number in decimal is U*B5 + V*B4 + W*B3 + X*B2 + Y*B1 + Z*B0
  
  As more digits are added, you just increase the power by which it is raised. Also note that any number raised to the zeroth power is 1, so the Z element is just itself, and the ones digit.
  
  
• What is the last thing you learned about data structures from a book, magazine or web site?
  As with my answer to this question with regard to algorithms, I'm certain I've used to web for reference here, but I'd guess my introduction and original knowledge acquisition came from a book.
  
  However, I would add journal article to the list of answers, because in both cases that would have been my answer, even though I read them via the web.
  
  
• How would you store the results of a soccer/football competition (with teams and scores) in an XML document?
  
  

  <fixtures>
  
    <fixture>
      <team name="Chelsea FC">
  	<score>0</score>
      </team>
  
      <team name="Fulham FC">
  	<score>1</score>
  	<!-- any other stats? -->
      </team>
  
    </fixture>
  </fixtures>
  

  
  That might be reasonable.
  
  
• Can you name some different text file formats for storing unicode characters?
  I have to be honest here and say I don't know what you're talking about. I can't think of a file format that wouldn't take it.
  
  

1. The Art of Computer Programming series by Donald Knuth
2. Wikipedia's list of data structures is another good place to start.
3. Perhaps a book or resource on data modeling, since there were XML and DB questions.

I get emails like this all the time:

"Hey Ramit, what do you think of that article I sent last week? Any suggested changes?"

My reaction? "Ugh, what is he talking about? Oh yeah, that article on savings accounts ... I have to dig that up and reply to him. Where is that? I'll search for it later. Marks email as unread"

Note: You can yell at me for not just taking the 30 seconds to find his email right then, but that's exactly the point: By not including the article in this followup email, he triggered a passive barrier of me needing to think about what he was talking about, search for it, and then decide what to reply to. The lack of the attached article is the passive barrier, and our most common response to barriers is to do nothing.

• Minimizing or closing the browser. When a compilation is expected to take up to a minute, or a test suite will run for too long, or a query takes forever, there's not much work that can be done, so I might fire up the feed reader, email, or twitter to pass the time away. The problem here is that you'll often spend far longer on your excursion than it takes for your process to complete. If you waste just 5 minutes each time, you've accomplished nothing - you're just skimming and certainly not getting anything out of it, and you could have been back working on what you were trying to accomplish. In these situations, I have my email, feed reader, and twitter minimized, and that significantly reduces the urge to open them up and start a side quest.
  
  If you wanted to get more to the active side of barriers, you might just add the line

  127.0.0.1	reddit.com

  to your hosts file. That turns a passive barrier to time waste into a downright pain.
  
  
• Having a test suite with continuous integration and code analysis tools running. At various points in a day you might be tempted to check in code that breaks the build or introduces a bug. This is especially true at the end of the day. However, if you have a test suite that runs on every commit, you're much more likely to run it to avoid the embarrassment of checking in bad code. If you've got static analysis tools that also report on potentially poor code, you're less likely to write it.
  
  
• Annoyance Driven Development. This isn't one that I know how to turn on or off, but I think it would be a great feature to have in IDEs or text editors: it gets slow when your methods or classes or files get too big. This would be a great preventative tool, if it exists. I guess it falls back to using test suites and code analysis to provide instant feedback that annoys you into doing the right thing.
  
  
• Working with others, or having others review your code. Most of us pay more attention to quality when we know others will be looking at the code we write. Imagine how much more of your code you'd be proud to show off if you just knew that someone would be looking at it later.
  
  

• Interruptions. This one is obvious, but so pervasive it should be mentioned. IM, telephone calls, email, coworkers stopping by to chat or ask questions - they all prevent us from working from time to time. The easy answer is to close these things, and that's what I do. They all represent passive barriers to getting work done, and you can easily turn that around to be a passive barrier against wasting time (see above). Pair programming is an effective technique that erects its own barrier to these time wasters.
  
  If you're really looking for something to help you focus, I'd have a look at The Pomodoro Technique, which divides your work into tomato time units of 25 minutes each, which really helps you focus on work. It's agile for time management. (The Pomodoro Technique PDF book is available for free.)
  
  
• Rotting Design: Rigidity, Fragility, Immobility, and Viscosity. Bob Martin discusses these in his (PDF) article on Design Principles and Design Patterns. Quoting him for the descriptions, I'll leave it to you to read for the full story:

  Rigidity is the tendency for software to be difficult to change, even in simple ways. Every change causes a cascade of subsequent changes in dependent modules. What begins as a simple two day change to one module grows into a multi- week marathon of change in module after module as the engineers chase the thread of the change through the application.
  ...
  Closely related to rigidity is fragility. Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way.
  ...
  Immobility is the inability to reuse software from other projects or from parts of the same project. It often happens that one engineer will discover that he needs a module that is similar to one that another engineer wrote. However, it also often happens that the module in question has too much baggage that it depends upon. After much work, the engineers discover that the work and risk required to separate the desirable parts of the software from the undesirable parts are too great to tolerate. And so the software is simply rewritten instead of reused.
  ...
  Viscosity comes in two forms: viscosity of the design, and viscosity of the environment. When faced with a change, engineers usually find more than one way to make the change. Some of the ways preserve the design, others do not (i.e. they are hacks.) When the design preserving methods are harder to employ than the hacks, then the viscosity of the design is high. It is easy to do the wrong thing, but hard to do the right thing.

  The point is that poor software design makes an effective barrier to progress. There are only two ways I know to tear down this wall: avoid the rot, and make a conscious decision to fix it when you know there's a problem. There are plenty of ways to avoid the rot, but books are devoted to them, so I'll leave it alone except to say a lot of the agile literature will point you in the right direction.
  
  
  
  
• Unit Tests. I struggled with the idea of putting this on here or not. If you're an expert, you already know this. If you're a novice or lazy, you'll use it as an excuse to avoid unit testing. The point remains: unit testing can be a barrier to producing software, if you are exploring new spaces and having trouble determining test cases for it. I'll let the Godfather of TDD, Kent Beck, explain:

  ... I still didn't have any software. As with any speculative idea, the chances that this one will actually work out are slim, but without having anything running, the chances are zero. In six or eight hours of solid programming time, I can still make significant progress. If I'd just written some stuff and verified it by hand, I would probably have the final answer to whether my idea is actually worth money by now. Instead, all I have is a complicated test that doesn't work, a pile of frustration, eight fewer hours in my life, and the motivation to write another essay.

1. Does she concentrate on a single item well enough to finish it? In this case, they are asking the opposite of what they want to find out. The trick relies on the reviewer to give an honest opinion, whereas most people would assume they should answer each question in the affirmative. Because the rest of the questions seem straightforward, I'd give this potential "real question" a low probability of being what they really want to know.
   
   
2. Is the candidate able to juggle multiple different projects and work effectively? I give this one the higher probability of being the question the employer really wants the answer to. But it's a ridiculous question. On the one hand, you already know the job candidate has successfully completed two levels of college, so it should be clear that they can handle multiple different projects given the appropriate resources. On the other hand, I don't think they care about the "appropriate resources" part. I think they're setting their employees up to fail because they don't understand that

   Multitasking can result in time wasted due to human context switching and apparently causing more errors due to insufficient attention.

This is my Quality is Dead hypothesis: a pleasing level of quality for end users has become too hard to achieve while demand for it has simultaneously evaporated and penalties for not achieving it are weak. The entropy caused by mindboggling change and innovation in computing has reached a point where it is extremely expensive to use traditional development and testing methods to create reasonably good products and get a reasonable return on investment. Meanwhile, user expectations of quality have been beaten out of them. When I say quality is dead, I don't mean that it's dying, or that it's under threat. What I mean is that we have collectively- and rationally- ceased to expect that software normally works well, even under normal conditions. Furthermore, there is very little any one user can do about it.

I haven't figured out yet exactly how I'm going to use this, but it'll probably look like this: one new beat per day, one new track per weekend. One new app per month, one milestone on the app per week. The goal is not to establish a far-off goal and find a way to hit it, but to establish a series of tiny, immediate goals that keep you forever moving forward. Aristotle argued that virtue was mostly a matter of having good habits; Lao-Tzu tells us that the voyage of a million miles starts with a single step. So the key is to get moving and keep moving.

But in computer games, it's impossible to have an equal match. It's humans versus machines. One side has an advantage of being able to perform a billion calculations per second, and the other has the massively parallel human brain.

Any parity here is an illusion, and it's that illusion that we seek to improve and maintain via the introduction of intelligent mistakes and artificial stupidity.

The computer has to throw the game in order to make it fun. When you beat the computer, it's an illusion. The computer let you win. We just want it to let you win in a way that feels good.