sitting

[caption id="attachment_827" align="alignright" width="300" caption="In case you didn\'t read it: None of Us is as dumb as All of Us."][/caption]

<rant>

There is a lie we like to tell ourselves that goes something like this, "I am in control of my life." You are not, it's a cultural lie though, one of those things that we've all agreed makes us feel better so we politely nod our heads and lie to each other and all get through the day a little easier. It's similar to that radical 90's style lie I grew up with during school that went something along the lines of, "Everyone is special and magical and made out of ponies." Everyone gets a trophy, even if you didn't win, because you are special just for trying. It's a lie that everyone knows is a lie, but it makes people feel better, so what's the harm.

Well over the last few months it's become apparent to me that these things are lies, that I'm no more in control of what goes on in my life then my dog is of his own. At any moment someone could walk through the door and kill us all just for laughs, or someone could hand me a million dollars. The uncertainty of it all is unsettling and exciting. The one thing that has slowly crept into my life recently is the subject of my post, and that is the hallowed institute of meetings. Somehow I went from a code ninja hacking down mountains of whatever was thrown in front of me to a table jockey. I am now scheduled to attend no fewer than 8 meetings per work week.

That works out to 1.6 meetings/day, and rest assured there is at least 1 meeting everyday. I know people that do nothing all day but meetings, it boggles the mind. I would say that I "hate" meetings, but that really doesn't convey the depth of my loathing for them. Meetings are the bane of my existence, I could stomach maybe 1 a week, a short sweet status meeting, but what I can't handle is the bread and butter corporate meeting, and I'm going to detail why.

1. Marketspeak: I don't know what the fuck happens to people when they get in meetings but everything, everything gets some fancy new moniker. Sure I could say that I'm working on some stuff, but wouldn't it be better to say that goal-forwarding has been achieved on several Tier-1 action items. There are no people anymore, just assets and resources, dehumanized by the cruel tongue of Marketspeak. Every concept, no matter how simple, is wrapped in shiny new clothes, as though you might confuse the dog turd covered in whipped cream as a delicious fudge sundae.


2. Teleconferencing: There is always some person (sorry, meant to say "stakeholder touchpoint") who thinks its appropriate to call into the meeting on a 1992 Nokia Celfone while in the middle of a monsoon while driving through a tunnel. Bonus points if this person has a thick accent that makes even high-fidelity communication less than understandable. The other issue is having 10 people on one side of the conference line and 10 on the other, and the fun of each side trying to figure out who is talking.


3. Pointless Status: Managing people is difficult, so management is obsessed with the idea of status. The problem is that status is normally not quantitative but qualitative, too bad that doesn't fit into the Holy Spreadsheet. People are forced to turn things into percentages, I'm 80% done reflanging the spline, even if that doesn't make any sense. Status reports are a proxy for involvement, they are a way to feel connected to a process you don't have any part in.


4. Workturbation: Meetings are insidious, if you have 8 hours of meetings you will go home mentally exhausted, more than likely frustrated, and with a feeling that you've really put in a hard day's work. The problem is that when you try to figure out what you've actually accomplished the list is either non-existent or incredibly paltry. Meetings feel like work but rarely accomplish anything of actual significance. Meetings also have the incredible ability of spawning meta-work just for the sake of the meeting itself. Before the meeting you have to prepare whatever pointless agenda you have for your meeting, secure a place to have the meeting, work around everyone's schedules. Afterward someone prepares the minutes and it gets emailed to the companyname-all mailing list where inevitably the tiny list of things that were actually decided are rehashed again and again. Personal bikesheds are floated around, and more than likely all the chatter on the email list will require ANOTHER FUCKING MEETING to sort out.


5. Punting: Punting is the amazing technique where something interferes with the meeting so it is moved down the road to another meeting. Punting is sometimes necessary when someone wants to discuss in detail some trivial point, but the best and most frequent kind of punting is the following. Design meeting is convened, difficult non-trivial thing is brought up that requires actual thinking and problem solving, meeting participants get frightened by the idea of actually having to dust off the critical thinking part of their brain instead of blithely parroting made up statuses of underlings, issue is tabled to be dealt with in the future, a piece of me dies inside. Keeping the meeting moving becomes MORE important than getting anything decided or accomplished.

The list is in no way exhaustive or universal. At the end of the day though, a meeting is taking up time you could be doing something, they should be looked at that way. All that time you are sitting in meetings talking about all the stuff that could be getting done if everyone wasn't stuck in meetings all the time... my head hurts. What we need are people with their hands on the problem empowered to make decisions and move things forward. Then we can meet once a week to talk about how things are going, instead of sitting around all week wondering why nothing is getting done.

</rant>

micro-optimization

[caption id="attachment_818" align="alignright" width="277" caption="Yea, I know it\'s on fire, but check it, I almost got Freebird down pat."][/caption]

As all good developers should know, one of the cardinal sins of software development is premature optimization. Premature optimization is bad for a whole host of reasons. But there is another set of optimizations that are in the same realm of bad, micro-optimizations.

I recall learning at some point that in C and C++ it is more efficient to use the pre-increment operator rather than the post-increment operator. Why is this the case, well it's because of the minor difference in behavior between the following two snippets.

[cpp]
int source = 10;
int destination = 0;

destination = ++source;

printf("Destination: %d", destination); //Prints "Destination: 11"
[/cpp]

Compare with this snippet

[cpp]
int source = 10;
int destination = 0;

destination = source++;

printf("Destination: %d", destination); //Prints "Destination: 10"
[/cpp]

WHA!? This is actually exactly what we would expect, pre-increment increments the value BEFORE assignment while post-increment increments the value AFTER assignment. What does this all mean, well basically that if you use post-increment you are executing more instructions, because the compiler has to keep the old value around to return to the assignment. That means that unless you are assigning the value and require the particular behavior that post-increment gives you, you can generate faster code by using the pre-increment operator (this may be handled by compiler optimizations these days).

All of the for-loops that you've written for(int i = 0; i < something; i++) are identical to and SLOWER than for(int i = 0; i < something; ++i). NOOOOO!!!!! Don't worry though, because this is a micro-optimization, its something to not care about, because in reality that one or two extra machine instructions isn't your bottleneck. Micro-optimizations are all those tricks that make code faster that in the vast majority of cases (although not all cases) don't really amount to any actual noticeable performance gain. A new processor can do something in the magnitude of 100,000 MIPS (Millions of Instructions Per Second). Every second it does 100,000,000,000 Instructions, that is 100 billion instructions. every. single. second. Changing from post- to pre- increment saves 1 or 2 instructions, so for every time that gets executed you have saved a 100th of a nanosecond.

Micro-optimizations are rarely worth the hassle, and, as with premature optimization, the solution is to benchmark and trace where your actual bottlenecks are and go about solving those. It doesn't matter if you're screaming through your increments saving a whole nanosecond if your crappy no index having table is taking a whole minute to read because you are doing a table-scan.

But wait, there's more. Micro-optimization, like everything in programming, can be directly applied to life in general. I work with a person who will spend 5 minutes discussing how to save 30 seconds, this is another incarnation of the micro-optimization. It's that shortcut you take home that actually takes longer, or some everyday voodoo that is draining your time without paying you back, or that client that provides you with 2% of your income but eats up 40% of your effort. Micro-optimizations abound all around us, in the little picture they seem ok, but in the big picture they are nonsense. Take a fresh look at the things and obligations around you and examine them for micro-optimizations, see if the things you do make sense in the big picture.

let me google that for you

[caption id="attachment_805" align="alignleft" width="300" caption="I wonder what Google\'s legal team thinks of this website"][/caption]

I was recently given the task of writing a Windows Service in Managed C++ (or C++/CLI I can't quite figure out what it's actually called). Having had 3.5 years of C++ experience from college and basic literacy I started clicking around in Visual Studio like a blind man searching for a nickle. Everything was going great until I got to the code it generated... there were ^'s and gcnew's and all kinds of craziness. It looked like the Standard Template Library and C# had gotten together with a bottle of tequila, the next day C++ was knocked up and throwing up carets all over the place. This was not the C++ I had learned back in college on our quaint little Unix box editing code in pico, this was some new monster that vaguely resembled an old friend. Undaunted I clicked this link and began the journey on the road of enlightenment. Right now I have a Windows Service that builds and hopefully over the next few days I can confirm that it actually works.

This got me to thinking about the vast wealth of information sitting literally at our fingertips. I recalled the phone call I had with my mom over the weekend that went something like this.

Mom: They asked me at work to archive some files by burning them to a CD.
Me: Oh, how'd that go?
Mom: Well I had to use a Mac, and I don't know those so I asked for help.
Me: Makes sense.
Mom: The only person who knew how to do it said to use Toast, but that wasn't installed. :(
Me: What did you do?
Mom: Well I thought, how hard can this be, googled it, and followed the tutorial, it was really simple.
Me: You've just taken your first step on the road to geekdom, congratulations.

The dirty little secret is that for anyone that's good with computers, unless you ask them a question directly in their area of expertise, they might have some vague notion but will more than likely just end up Googling it. "My computer crashed and the BSOD said STOP CODE 0xA70000084, what does that mean?" What you will hear on the other end of the phone is me biding my time while I type "STOP CODE 0xA70000084" into Google and look for the answer. Because, and this may surprise everyone who is not a computer person, having a CS or MSI degree does not mean that you programmed Windows. There is a world of stuff for us programmers to try to hold in our brains, and every error code shooting out of Redmond is low on the totem poll.

If all us nerds are just Googling things, then why don't normal people do it. We know that everyone Googles stuff: "Naked ladies", "Hot naked ladies", "Other naked ladies I haven't already seen", "How to erase your browsing history", etc. Why don't non-technical people think about typing that perfectly searchable error code into that happy little textbox? There are a litany of reasons from laziness to sloth, but I think the one that most people fall into is intimidation.

Google is power!!! You ask it a question and you get a list of a gajillion results. Don't believe me, I'm going to search for blue screen of death and it returns 9,710,000 results in less than half a second. If you are a non-technical person that is a sea of information, its even worse for technical problems, as the most relevant links are normally some discussion board with a thread 900 replies deep, the solution normally some incantation you chant over the motherboard while spraying the monitor with goat's blood. For the technical doing things like digging around in the System32 directory and clicking around is everyday no big deal stuff. For the non-technical, who normally have the "I hid this for your protection, don't touch these files or your computer will explode" screens still on, it can be a terrifying leap of faith.

[caption id="attachment_806" align="alignleft" width="300" caption="for a normal user this is like a grizzly bear with chainsaw arms"][/caption]

The thing that we can do to encourage our non-technical friends and families is to teach them to fish. Normally we just want to give them a fish and get on with our lives. When you take the time to explain how resilient a computer is and how easy it is to find the information, after a while they will come around to solving their own problems. And it's like sweet sexy meth when they do. Try to remember what it was like to have that thrill for the first time of being able to command the computer to do your bidding, once they get a taste they will want more, which may actually end up being more work for you, but it's the good kind of work that furthers another's understanding of the world.

Drop some lmgtfy love on your loved ones, help them help themselves, introduce them to the intoxication of solving their own technical problems. Once people realize that computers do what we tell them and not the other way around, the world will be a much better place.

ideas

[caption id="attachment_800" align="alignright" width="234" caption="In the future, we will rule this world!"][/caption]

Ideas are interesting things, we have them all the time, we dismiss them frequently, and we value them heartily. Some people don't like to talk about their ideas, don't want people to steal their million dollar brain baby, and I can respect that, but a million dollar idea with zero execution is worth nothing.

Ideas, like misery, love company, if I tell you an idea your brain will immediately start thinking about it, having its own ideas and interpretations. Then you tell me your ideas that my ideas caused and I get more ideas and so on and so forth, this is the basis of a conversation. That our ideas can grow and change organically, that we can piggy back off of each other, this is the basis of our society. But let's get out of the woods of the abstract and into the city of concrete.

What I want to talk about today are those entrepreneurial ideas that we all have from time to time. Those things that you are certain will make you rich and famous, or the ideas that leap back into our minds when we see some new thing, a worldwide pornography distribution network, Tim Berners-Lee stole my idea! What should you do with these ideas, how should you handle them, and why and what and huh.

Every person will have their own way of handling the little lightning bolts that leap into their head but I want to take you through the path that I've found helpful for me.

1. Write it down - I write down almost every business thought I have, no matter how far fetched, and no matter how overloaded with tasks I am. This seems a little silly, if you are actively working at one thing it can even feel disloyal to start thinking about something else, what am I a squirrel easily distracted by a shiny piece of tinfoil? No, in my opinion you can never have enough ideas in reserve. It doesn't take too much time to jot down enough information to be able to recall it later, and it doesn't mean you aren't serious about your current set of priorities. We would all like to think that everything we are working on will always work out, but you will never be sad that you have more ideas to fall back on.


2. Percolate - Go do something else, even if you aren't actively thinking about something, after writing it down it will be floating around in your brain someplace. Great ideas refuse to fall to the wayside, if you find yourself coming back to something in your head more than a few times, move onto step 3.


3. Talk it out - Share your idea with other people, sanity check it, see if they laugh at you. Don't get discouraged too easily though, great ideas can sound crazy and still be great ideas. After discussing it with a few people you can get a handle on how realistic it is and how excited you should be about your new idea.


4. Prototype or Shelf - If you've made it to step 4 you have to look around and prioritize, it's easy to be swept up in the novelty of a new idea, but strive to objectively adjudicate whether or not you have the free time to move forward. If you do, grab some technology you are comfortable with and make a prototype, don't invest too much time or money. If not shelf the idea, keep a short list of things ready made to work on and add this idea to it.


5. Focus Group Lite - If you made a prototype put it in front of some people, or float a pilot program. See how people react, sometimes an idea can sound great until you see it, then you realize some fundamental flaw. If this stage is good then move onto step 6.


6. Jump in with both feet - Get cracking. If you have the time, passion, and indication that people could use your idea, go for it. It will be difficult and you will probably fail, but you will be better for it.

Ideas are nothing without execution, but they are still valuable. Make sure you save your ideas, bounce them off of other people, and if your gut and other people tell you to go for it, take the chance. You may not always succeed, but you will rarely be disappointed that you tried.

macgyver

[caption id="attachment_781" align="alignright" width="216" caption="All I need are these everyday objects — a toothpick, some liquor, a gun with no bullets, bullets, and three of my MacGyver writers. "][/caption]

So it's come to this, a blog meme post. Every so often in the hallowed world of writing content for free to be distributed to people that you don't know for no particular reason other than hearing your fingers clickity-clack, you meet someone else doing the same thing and they challenge you. Considering that this is a hobby built upon the sturdy foundation of honor, glory, and red bull, you must rise to meet this challenge, and write a themed blog post. David Stein started this and it continued to Brent Ozar who has called out my name in the darkness, to answer the call to write about: My MacGyver Moment.

Now I've written about my favorite MacGyver Moment before in a previous post toolmaker, the time that I wrote an automated PL/SQL to T-SQL translation program. In that post though the MacGyver moment played a small roll and didn't get the attention it deserved, so I will go into its history and explain it in greater detail.

The seed is planted

[caption id="attachment_782" align="alignleft" width="300" caption="This is how MacGyver would solve most of his problems in the future."][/caption]

It was my last semester in college, I had finished up all the required course work and just needed to take some 400-level electives to finish off my degree. I looked through the catalog and found a course that looked interesting, "Language Design and Implementation." The course seemed exciting for a few reasons, the professor had worked as a professional compiler writer for years and was a decided brilliant and fun teacher, the course work included building a compiler, and compiling source code was a part of the development chain that I had a theoretical understanding of but was still somewhat of a blackbox. I signed up for the course, it was fun, it was hard, I built a compiler (for a made up language called LITTLE targeting the JVM), and I learned a lot. I learned about parsers, tokenizers, compiler optimizations, bootstrapping, and a hundred other interesting concepts. The value that I took away from the course was a litany of problem solving techniques and an appreciation for what runs under the gcc hood.

The problem

My company sold some software. Doesn't seem like a problem at first, in fact, it's how the company does all those little things like pay my salary, so it's actually a good thing. The problem was that the software was written to run on an Oracle backend and we sold it to an organization that only had a SQL Server backend. There we sit looking at a mountain of PL/SQL code that does everything from execute a simple search to closing out and actualizing a fiscal year. 60,000 LoC representing tens of man-years of effort. Take this and put it in an extremely aggressive timeframe for porting and limited resources... suddenly the problem is easy to understand.

Bubblegum, paperclips, and string functions

60,000 lines of PL/SQL needed to become T-SQL, looks like compiling code to me. I knew my source language and my target language, time to write up a parser, tokenizer, emitter, etc. Then I noticed something while scanning through the PL/SQL, the problem domain was constrained, although PL/SQL can be constructed in a number of permutations all syntactically different, this was not the case. This PL/SQL was very uniform in construction, I didn't need all the pieces parts of an actual compiler. I didn't need to tokenizer and parse into abstract syntax trees for emission into the target language, I could just cheat, there were only 3-4 syntactic structures present in the source file.

I began writing the translator, after quieting that part of my brain that was telling me I was wasting time, just trying to avoid the unpleasant task of translating this by hand. Hackity hack hack, code is complete, hack up some nifty progress bars, run run run... translation complete! I looked at it, not quite perfect but I would estimate that the success rate on translation was around 99%.

The lesson

Sometimes hacking up a kludge to transmogrify data is the best course of action. Shutting up the part of your brain that doubts your ability, or the part telling you to do something the "right way" is the best way forward. Learning something for no other reason than that it seems interesting can provide you with the tools necessary to solve thorny problems down the road. Sometimes you really can defuse the bomb with a rubber band, #2 pencil, and thumbtack.

blackbox revisited

[caption id="attachment_767" align="alignright" width="275" caption="Oh shit they\'ve miniaturized HAL "][/caption]

The other day I wrote about the concept of the blackbox. I focused specifically on the idea of a blackbox as us programmers think about it. I've been thinking about it more and more though and realized that there are blackboxes all around us. There are processes that our often complicated, confusing, manual messes that our non-programming friends and family have to suffer through. If they knew a little bit of ruby or maybe some batch programming they would be able to save mountains of time and effort, but they don't, so that's where programmers can shine. The problem is that to help our friends and family we have to shine some light into their blackbox tasks and figure out what they do, that's not the easiest task for a programmer to take on.

Recently at work they announced a change to the timecard system that we use, all timecards MUST be submitted by 10:00am Monday morning. The old system was, they should be in sometime on Monday and if not then our very nice receptionist will send out a sternly worded email shaming you into submitting you timecard. Being curious (and being that the explanation was just a few more lines down in the email) I wondered what change had occurred to the system to require this 10:00am deadline. Ends up that our receptionist used to enter this data by hand from the system we enter it in into the accounting software. This was a tedious and error-prone task, once someone bothered to look at it they realized that with a little bit of code they could automate this all and get these programs chatting back and forth like old bridge partners. A couple hours of programmer effort later and now our receptionist is able to answer calls and do all the other receptionisty things that she is great at instead of spending time copying numbers from one program to another.

The blackbox, timecards turning into accounting information, was illuminated and the process was horrible, a little bit of code applied and BAM new productivity abounds. It gets me to wondering, how many other blackboxes are all around me, waiting for someone to shine some light in, see the inefficiencies, and offer up some soothing code. I've given myself a new little game to play when talking to my friends and loved ones, when they start complaining about something that they have to do in their day to day, instead of just offering a sympathetic, "Sucks to be you loser" I start digging deeper. "These reticulated splines are giving you a lot of trouble, how exactly do you make them?" Normally they will reply with a bit of hesitation, maybe even a polite, "Oh, its boring, you don't need to know about that." But if you keep on gently nudging, you can find out enough of the process to help.

It doesn't always have to be by providing code, sometimes just the general nerdy computer knowledge that we have can be incredibly beneficial. It's easy to forget that not everyone knows the little tricks to make the computer easier and more fun to use. I was able to save my mother hours a day by explaining to her that despite what her boss told her, she does not have to shut down Photoshop between opening every file. Until then she had been instructed and believed that she had to wait a good minute for Photoshop to boot up in between every file, opening hundreds of files a day, you do the math. By asking my girlfriend some questions about something she does at work I was able to throw together an Excel spreadsheet to save her a ton of time. The magic of VLOOKUP and some well placed formulas was all that was needed to take a boring repetitive task and make it much simpler and less error-prone.

For those in the computer-know it's easy to look at the computer as a simple tool, something to be mastered and leveraged to make our lives easier. For many people though, computers are blackboxes, confusing little machines that spit out weird error messages and are constantly fighting them to get things done. And there is the other edge of this sword, by shining light into a process blackbox and making life easier you do the double duty of helping illuminate the blackbox for a computer novice. You help show by example that the computer is not mean or frustrating (well sometimes they are frustrating) but just a tool that with careful skill, some essential knowledge, and most importantly a lack of fear, you can make bend to your will.

Go find the blackboxes around you, help someone save 15-20 minutes a day, show someone that computers are not just useful in general but can be made personally useful. You will be a technology hero to them, you will find an interesting puzzle to play with for yourself, and at the end of the day everyone will be better off. Find the blackboxes and start pouring in light, you will be pleasantly surprised at what you find.

blackbox

[caption id="attachment_751" align="alignright" width="241" caption="Something happens in there... with gnomes I think."][/caption]

The Blackbox, cornerstone of computer science, thing of mystery and beauty. It is the fundamental concept that allows us to build bigger and better abstractions, making life easier for everyone. A blackbox is something that has well defined inputs and outputs but the manner in which it functions in unknown. The classic example of this is a library function, sqrt(9) takes the number 9 and returns the square root 3. There is a well defined input (in this case 9) and a well defined output (the square root, 3). How does the function produce this result, who cares?

As programmers we can focus on what we are good at, if someone loves programming math algorithms they can make a kickass math library, if they love web programming, here comes Rails. Then when I'm interested in writing a web app that needs to do some math, I don't have to worry about how to find the square root of some number, there is a handy blackbox all ready to go. This is a huge boon to productivity, I'm happy, math programmer man is happy, and the user is happy because they don't have to use my buggy homegrown math libs that say they owe a $47 tip on a $9 check. (And my math degree weeps at me)

This is all well and good, the problem comes when you need to know what's going on in a blackbox. There are any number of scenarios in which you may need to shine light into the depths of a blackbox. You have some strict performance or memory requirements, the blackbox's "well-defined" outputs are failing (what do you do when you call out to sqrt(9) and get 7.2 back) or the use of a blackbox is having some negative side-effect. In these situations the whole damn thing comes crumbling back down to earth, you now need to roll up your sleeves and get it done. Here is how you should approach the problem.

• RTFM (Read the Fucking Manual) - This is the first step, if a blackbox is eating up too much memory see if there is a way to force a limit, if it is throwing an exception, check why that could be the case. Basically before you do anything else you should try to make sure that the blackbox is actually broken, because chances are that any sufficiently popular blackbox is going to have much more real-world use and rigorous testing than your new client code. This boils down to, don't blame the compiler for your shitty code.


• Ask someone familiar with the blackbox - After you've actually RTFM you can move on to this stage, seek help from someone more familiar. If there are colleagues that have used this particular blackbox ask them first, they may have already gone through this entire list and can shortcut you to the answer. If you have no colleagues to turn to, try turning to the community or the creator, if that fails try throwing it up on a more generic community like, stack overflow.


• Go to the source - If you are working with an open source blackbox then it isn't really a blackbox, just go read the code and see what it's doing. This is much easier said than done, so make sure you have exhausted the first two steps before diving into this one. If you are using a closed source blackbox you can either attempt to get the source through some sort of development channel (although this is unlikely) or you can decompile and look at that. Tools like RedGate's Reflector or the Java Decompiler Project can help to get at that closed source.


• Workaround - Sometimes no matter how dogged your determination, you can't seem to figure out why the blackbox isn't working right, at this point you have exhausted the detective route, time to pull a MacGyver. If you can figure out someway to use the blackbox and workaround the deficiency then go ahead and do that. The important thing is to take this workaround and record it properly. Create an adapter, thin wrapper, or function. Make your own lightweight blackbox that is 1 part the old blackbox and 1 part workaround aggregated together.


• Roll your own - Sometimes you get seriously desperate, you have researched your fingers to the bone and tried to work around the problem. You are at the end of your rope, the deadline is looming and the only thing standing between you and your project compiling is some pos third party closed source blackbox. Sure it would be nice to have a sqrt function nicely wrapped up for you, but hell you can dust off that part of your brain that remembers what a square root is and write your own function to find it. The important thing is that this should be the very last thing you do, after all other options are exhausted. Many a programmer will do this first or second, and that is Seriously Fucking Wrong©.

The power of a working blackbox is only matched by the frustration of a wonky blackbox. The good news is that a lot of blackboxes work really well sitting there quietly trimming our strings and rooting our squares. There is that every once and a while though when despite our best efforts we have to dive headlong into a blackbox and shine some light around.

telecommuting

[caption id="attachment_739" align="alignright" width="300" caption="Just let it warm up for a minute, you will be fine."][/caption]

I am not in Indiana today, the trip has been postponed until the Snowpocolypse is over. I awoke this morning to find another 6-9 inches of snow had fallen on top of the unmelted foot and a half of snow already on the ground. I groggily turned on the TV, Columbus is under a Level 2 Snow Emergency and just about everything is closed. I check with the Franklin County Sheriff Office and see that for a Level 2 Snow Emergency the situation is as follows: "Roadways are hazardous with blowing and drifting snow. Only those who feel it is necessary to drive should be out on the roadways. Contact your employer to see if you should report to work."

With the threat of hazardous roadways and the fact that my job in no way, shape, or form requires my physical presence at any location, I shoot off an email, following the sheriff's advice to "Contact your employer to see if you should report to work." The sad news, of course, is to put on your business casual, bundle up, clear off the car, fight throw the blowing snow, and carry your laptop with you so you can plug in and get to work. The alternative of course would be to stay nice and warm, not endanger my life and property, and plug in my laptop at my desk at home. This alternative is clearly unacceptable, against the advice of the Sheriff's office and against all common sense I physical transported myself and my laptop several miles down the snow covered roads to plug in here at work today.

Here I am doing the same work I could be doing from home, as far as I know, the SOA book that I'm studying and the Message Broker Toolkit examples I'm working through are unaware of my physical location. I can easily access my corporate email, sametime account, and all relevant files from home, I can even participate in the conference call meeting that we have scheduled for 1 o'clock. The question is why, in spite of the rest of the city shutting down, was I required to come into work today? The rest of this post will present the Case For Telecommuting, the Case Against Telecommuting, and an Analysis. All of these sections are written with programming or some other suitable telecommuting profession in mind.

The Case For Telecommuting

Technology has long been on the march for decentralized development. Being able to reach resources from any location is more and more possible with web based solutions and DVCS. In addition to having resources available from any physical location our ability to communicate and collaborate despite physical distance has been steadily improving. Tools like Google Wave, Instant Messaging, and Collaborative editing have matured and become rich and expressive mediums. Phone conferences are now common place when working with outsourced resources and with physically distant resources.

For the particular case when travel is dangerous telecommuting has a distinct advantage over commuting. Commuting is another part of life that is ever growing.

In fact, so many people now commute more than an hour-and-a-half to work, the Census Bureau has given them a new name: Extreme commuters. ... It's growing five times as fast as the general growth in commuting — about three million, 3½ million [commute] more than 90 minutes a day, about ten million more than 60 minutes.

Commuting also has a negative effect on your physical, mental, and emotional health. The impact of Voluntary Solitary Confinement (VSC) are not pretty.

Long hours of commuting, especially if you’re driving, is associated with high blood pressure, musculoskeletal disorders, increased anger and resentment at work... Long commutes can also increase the risk of heart attacks, flu, depression etc.

- Effects of Long Commutes to Work

The Washington Post has an article from 2007 discussing the problems with long commutes.

As a consequence, more drivers will probably suffer the health effects of a commuter lifestyle, researchers and doctors said. "You tell someone they need to exercise or go to physical therapy, but how can they? They leave at 5 a.m. and get home at 7 or 8 p.m. at night," said Robert G. Squillante, an orthopedic surgeon in Fredericksburg who has treated patients for back pain and other commuting-related issues.
...
"It's just tiring," Hutson said of her daily drill. Someone who was never much for caffeine, she now bolsters herself with coffee in the morning and soda for the evening rush. But by midweek, "I'm running on fumes. That's the biggest toll. It's not enough sleep."

No one pays for the commute except the worker, and as we saw during the gas price spike up to $4/gal (even now its not much better, only because we have that high water mark to compare against does ~$2.50/gal seem reasonable) the cost of commuting can become a rather high "work tax." The Washington Post article hits on it briefly, but if you have to get up early to commute and get home late because of a commute you are also paying the price in terms of your time. You may only be getting paid from 9 to 5 but you are effectively giving your job all the time from the moment your commute begins in the morning to the moment it ends and you are home. If you have to adjust your sleep schedule to support this then any time you could be awake, doing something you enjoy, actually living your life, is forfeit to the needs of your employer and not you.

The Case Against Telecommuting

If telecommuting gives the working man more free time, more money in his pocket, and better health, why not let everyone telecommute? The arguments against telecommuting are many and we will examine a few that I have encountered.

The problem of split attention. When you are face to face with someone you know that they are giving you their full attention. With an IM or phone call the employee could easily be working on something else at the same time. They could be doing something work related, reading documentation, writing some code, discussing a problem with another colleague, but whatever it is they are splitting their attention and multi-tasking, and sometimes that is unacceptable.

The problem of accountability. This is a corollary to the problem of split attention. Split attention isn't so bad when the attention is split between listening to a meeting and writing code, it is pretty awful though if the attention is split between listening to a meeting and playing World of Warcraft. Keeping people accountable for the time they claim to be working is more difficult if they are unsupervised and physically distant.

The need for humanity. Often times phone conferences and IMs are more than enough to meet our communication needs, but this is not always the case. Sometimes there is no substitute for "pressing the flesh." Important meetings demand a level of attention that necessitates being physically present.

The problem of ineffective communication. As good as the tools have become there is still a gap between talking with someone, being able to read their facial expressions and body language, to fully understand what they are communicating. Telepresence and other techniques are getting us closer, but a face-to-face conversation conveys a wealth of unspoken communication.

The problem of bureaucracy. I am no fan of bureaucracy and there is a certain liberating power to having a team physically assembled. Difficult technical problems can be jotted out, ideas bounced around more easily. Communication tools are great, but still don't beat a whiteboard that everyone can see or sitting down with another programmer and sketching something out on a piece of paper. These impromptu mini-meetings are often incredibly productive, and they can be difficult to have when physically separated.

The problem of facility. Some of us have great work space set up for working from home. Fast internet connections, powerful machines, quiet space. But this isn't universal, some people can't work from home for one reason or another. A lack of connectivity or acceptable development machines, an environment that is not conducive to productivity, or some other issue. Some people require a more structured working environment in which to be productive. The lure of facebook and Judge Judy prove too much and workers that could be productive in an office environment fail when working from home.

Analysis

Telecommuting is increasing and is getting better. For now it is an option but societal and economic pressures and an increasingly agile work environment will make it more and more necessary to effectively optimize one's workforce. Many of the concerns and arguments against telecommuting boil down to a deficit in trust. The alternative though, longer and longer commutes coupled with increasing transportation costs is untenable.

As with an paradigm shift, new etiquette will have to be formed, the way we think about work and home will have to change, and tools will have to be built and improved to rise to the challenge. Although we shifted to the information age and a knowledge based economy in many ways, we continued to hold over traditions from a bygone era.

Telecommuting will take some time to get right, for anyone interested in adopting it I think a blended approach is the way to go. Start off small by offering anyone who would like to try it to telecommute one day a week or month. The important part will be follow up, getting feedback on what worked and what didn't. You can use this feedback to fine tune the experience and come up with a manageable system. Physical presence will always have a place in the workplace but as we move into a future with increasingly global concerns and clientele, increasing transportation costs, and a better understanding of the physical and emotional ramifications of chronic voluntary solitary confinement, telecommuting will become less science fiction and more day to day fact.

baby steps

[caption id="attachment_714" align="alignright" width="200" caption="Today I conquer steps, tomorrow France!"][/caption]

Last night I had the unadulterated fun of updating a client's blog. After handing off the reigns everything was going smoothly until some unknown combination of plug-ins was causing the mobile version of the site to be served to actual browsers. I was called in to triage the situation, nothing too dire, just two plug-ins with some configuration problems, once I told them to play nice, all was fine. It was then that I noticed there were 15 plug-in updates waiting and the whole WordPress install needed to be updated. So I took the time to take a backup and update everything, nothing too serious (for anyone that doesn't use WordPress, updating is a one-click affair now) just the day to day stuff that needs to be done to keep the lights on.

This got me thinking about upgrading and Google's decision to discontinue support for IE6. Some people are crying foul, saying that IE6 should still be supported, I'm decidedly of the I-hope-IE6-dies-in-a-fire camp. Lest this become a let's bash on IE6 rant, which it so easily could, fucking broken box-model CSS1 piece of shit, let's get back on track. The people that are upset about this are not technical luddites clinging to the familiar. Digg performed a user survey to figure out what they should do about IE6 and part of that was asking why people used IE6. Of IE6 users 70% responded that they either lacked administrative rights needed to upgrade IE6 or were told by someone at work that they could not upgrade. For anyone that has ever worked in Corporate America this should be no surprise to you. The nagging question though is why?

Why would the IT department, home of nerds always hell bent on trying out the latest and greatest, demand that you use a 9 year old piece of software? There are a number of reasons people point to.

1. Mission Critical application is only compatible with IE6


2. IE6 comes installed on all the machines


3. IE6 is maintained by Microsoft, less of a headache for us


4. Licensing / Partnership / Legal-mumbo-jumbo

If you fall into #4, I pity you. #3 is laughable because although the updates might be bundled with Windows Updates you aren't saving yourself any administrative costs by putting the most targeted web browser for malware on all your machines. #2 is true, but if you are big enough for an IT department you probably have some way to push software to machines (or you could, and this is a shocking idea, trust your employees to choose a browser that fits their needs). I really, really, really want to talk about #1 though, because that is the point of this whole post.

I've worked at a number of places that used some sort of Web Application that was deemed critical that only worked right in IE6. This was then used as a justification for never moving past IE6, the timecard application won't work or the spline flanger won't have those cool IE6 exclusive filters. I understand that no one wants to expend resources on a "working" application pulling it into the future. But what is the longterm idea here, are you just going to use IE6 forever? This prevailing consensus seems to be ultimately self-defeating. Google recognizes this and as they try to push what can be done with the web they find themselves expending far too much time and energy on a nearly decade old piece of technology.

The nice part about fixing an application on IE6 is that you avoid some cost in updating it to make it work with other browsers like IE7. You could have spent a week or two adding in some CSS fixes and some markup changes and bingo bango IE7 now works like a charm. Instead you decide to use Corporate Fiat to force the continued use of IE6. Well now IE9 is looming around the corner and instead of paying a week here or a week there you now have a mountain of technical debt to pay down to get it to work.

Although IE6 is a convenient example, we can see this happen in all parts of the software development world. This program compiles when linked to an older version of the library but not this new one, I don't have the time to figure it out, well just link in the old one. This is all well and fine to meet the deadline but you have just accrued some technical debt. Later when that library gets some great new speed-up or killer new feature, there you will be plodding along with version 0.91 because you can't get it to work with the new hawtness. The problem is that these debts are not additive, they compound on one another and make what would be a simple conversion to 0.92 a nearly impossible conversion to 3.76.

Keep your tools up to date, keep an eye on what's up and coming, you don't have to be the first to jump on the latest and greatest but when a new version has proven itself and become the new standard move to it. Technology doesn't stand still, if you don't keep up with the latest stable releases you will find yourself in a tight spot trying to do an overnight re-engineer of your product. Take the easy baby steps from version to version so you don't find yourself having to take a technological leap down the road.

experience as a force multiplier

[caption id="attachment_701" align="alignleft" width="300" caption="Oh DS cat you lovable scamp, don\'t use up all my healing potions"][/caption]

Over the weekend I experienced two things, one rather normal for a "computer guy" the other less in my wheelhouse. The first thing was that my girlfriend wanted me to help her register a web domain for her dad for his birthday. I have done this twice before, once for the website you are currently viewing and one other time for http://prosper-lib.com (which just redirects back here for the time being). I remember the first time I registered a domain and carefully read all the forms, making measured decisions, and hesitantly moved from step to step unsure of myself. It took an hour or two and then a few more to set up the hosting and get ftp access, set up wordpress and get everything up and running. In total it took a few hours. I didn't have such a luxury of time, she needed me to get the site up and running, preferably with a custom "Coming Soon" page before lunch, it was 11:00 so I only had around an hour. I clicked over to the site, click click click type type type, and it was up and running. I looked over at the clock to see how badly I had overshot the envelope, 11:15... wait what?

The second experience I had this weekend was tearing up some carpet at my new place. I have undertaken tearing up 850 sq ft of carpet to install new wood flooring in my house. The first night I was able to remove carpet from two rooms in just under 4 hours. It was my first time, and I went slowly following the instructions and making sure that I did everything just right. The second night I worked with an experienced floor guy, we finished taking out the mats, staples, tack strips and carpets from 5 rooms. Over the weekend there was one room left to do, I was able to knock it out, carpet, mats, tack strips, the whole nine yards in about an hour.

After these two events it solidified a point in my head, experience is the best force multiplier. In the first case it was my own hard won experience (not that there is really anything that difficult about registering a website). After performing the task a few times I gained an experience that multiplied my force by an order of magnitude, what once took a few hours now only took a few minutes. In the second case I was able to leverage someone else's experience to augment my own. I learned countless tricks to getting the job done quickly and efficiently, but more importantly I gained a huge amount of confidence. Having someone that already had mastered the task work with me and confirm that I knew what I was doing gave me all the confidence in the world to go in on Saturday and tear up the last room lickety split.

There were two take away points from these experiences. When doing something new seek out someone more experienced than you to pair with, even if its just temporary. Fully participate with them, ask questions, and do not let them do everything for you. This is the best time to fail, you will get immediate feedback from the more experienced party about how you are failing, why you are failing, and how to avoid failure next time. This will give you a foothold to quickly learn by doing. The second point to take away is to experience lots of things, even if you suspect you will fail. Life is full of failures, but those failures impart experience which is the best force multiplier to get to success.

I would be unable to count the number of times I've ruled out some great idea because it took me down some unknown avenue, and I was afraid of failing. I have no experience charging people money, I don't know how to start up a business, I don't know how to make a website. These are all things I've said to myself at one point or another, the thing I realize now is that no one is born knowing how to do these things, there is only one way to get experience, try new things. Don't be afraid to fail, work hard to succeed, and know that no matter what happens the experience is valuable and worth it.

persist

[caption id="attachment_696" align="alignright" width="300" caption="measure twice, turn once"][/caption]

I just witnessed an interesting even unfold in front of my current client's building. Today in beautiful Columbus, Ohio we are experiencing one hell of a winter storm, lots of fun. A semi truck decided that our parking lot was a great place to turn around in, he just apparently forgot to measure. CRASH BOOM and the lamppost has changed from its normal 90° to a more precarious 78ish°. After striking the lamppost and ramming a concrete barrier the semi was fairly well wedged, but the driver continued revving and the engine struggled and moaned. This persistence paid off and after about 10 minutes of maneuvering he was free. Now to call the insurance companies.

This got me thinking about the nature of difficult situations (self-imposed or otherwise). I also had a breakthrough largely due to persistence today, so happy coincidence. After months of working on documentation, being told that I would never be allowed to program the sacred system, the tides have turned (thanks to an excessively high quote) and the coach has called me up, and I'm ready to play under the bright lights.

I've just completed printing out 400 pages of documentation (my weekend is going to be so much fun!) and I will prepare myself for the difficult task ahead. My persistence has paid off, but the bigger realization is that persistence in general pays off.

To borrow one of my favorite quotes from Scrubs, "People are bastard-coated bastards with bastard filling." People don't ever want to think that you can succeed, and they are going to tell you no over and over again. There are two reasons for people to shut down your dreams:

1. They have tried and failed, the task is impossible, your success would undermine them. If you succeed where they have failed then it isn't an impossible task, they just weren't good enough to do it.


2. The have achieved it, but only by their virtue of their amazing talents and pure force of will. You don't have what it takes!

This is why it's vitally important to ask people for advice, sage wisdom, realistic assessments, but always keep in mind that very few people actually want you to succeed, especially if its in something they can't or already have. Don't worry though, these aren't bad people, it's human nature, and when you succeed you will act the same way. Success through hardship and against the odds plays a fun trick on the human brain, it makes you believe you pulled off the impossible. This feels amazing and so you will do anything in to hold on to it, and you don't want some dirty unwashed masses pulling off the same feat and diminishing it.

The big lesson here though is persistence, the most successful people in the world are those that were willing to have the door slammed in their faces 1000 times before making that sale. This is what you need to do, steel yourself for the struggle, prepare to be emotionally drained, and realize that this is what living is. Life is a stream of people telling you no, with the occasional yes. What separates the successful from the mediocre is that the successful are willing to wade through all the noes to get to the sweet succulent yes.

I've been paying my dues on this project for 3 months, and finally I get to go back to what I love the most, coding. There are a hundred stories of people trying and failing and trying and failing and trying and failing to finally succeed. It is definitely the path less taken, but it will make all the difference.

stupid ideas

[caption id="attachment_671" align="alignleft" width="263" caption="No caption needed"][/caption]

I want to be honest with you for a minute, I have lots of stupid ideas. I have them all day, in the shower, while eating a sandwich, while writing my blog posts, stupid ideas come streaming into my head. I used to just ignore them, "No one needs a peanut powered lawnmower" I would tell myself. The interesting turn was when I started writing these stupid ideas down.

Some stupid ideas will always remain stupid ideas, some though will change over time. That dumb idea might actually just be so brilliant it looks stupid. It might be so big and scary that you've convinced yourself it's stupid. It might not be a bad idea at all, after some careful reflection. It might even be a wonderful idea.

Why do we throw away our stupid ideas? Is it because we don't have time for them, bah, that can't be it, you are currently wasting precious time reading the stupid things I have to say. Is it because we are so swamped with brilliant ideas that we have to prioritize, probably not, or else you'd be sipping margaritas next to your perpetual motion machine. No, the answer is much simpler, its because we are afraid or failing. Stupid ideas are failure babies, a dumb idea grows up to be a hairy ugly failure, and we have learned in the school of life that failures are bad, so we avoid them.

Have you ever talked to a 4 year old? I have on various occasions, interesting little buggers those 4 year olds. They will tell you every little thought that bounces into their overly energetic little brains, no matter how wrong or foolish. They don't mind failing over and over again, they will insist the moon is made of mashed potatoes and not feel bad at all when you tell them the truth. And most importantly they learn a ton of information.

Now don't take this the wrong way, I don't think you should just go around like some half-cocked lunatic spouting off every little thing that pops into your head. There was a time for that and if you go into the board room now insisting the moon is made of mashed potatoes you will be roundly mocked and rightfully so. What I am advocating is the preservation and analysis of your stupid ideas. Let's take a look at some stupid ideas quickly to see why this is useful.

• Idea #1: A blanket that has arm holes and you wear it backwards or something... yea like a backwards robe! Pretty fucking stupid, but better known as the Snuggie, which has become a huge success and sold tons.


• Idea #2: Instead of executing the code on this machine, let's build another machine that doesn't actually exist and have that fake machine live on the real machine and have code execute on the fake machine.... What? What are you rambling about Jenkins, get out of my office! Jenkins just invented the Virtual Machine architecture that power things like Java's JVM and .Net's CLR.


• Idea #3: Wouldn't it be awesome if you could tape together 4 iPhones and have like a really big iPhone. I'm sorry, did you just smoke a bunch of peyote?! That's dumb.... Or its the new iPad.

You get the picture I'm trying to paint here. A lot of the amazing things we take for granted and depend upon everyday, things that seem like great ideas now, all had a moment in time when they were some far-fetched pie-in-the-sky dream. Most ideas start off as stupid ideas. Stupid ideas are important and valuable, not all of them, but there will be some diamonds in those dirt clods. You just have to be smart enough to sift through them.

My advice to you is to jot down those stupid ideas you normally throw by the wayside. Revisit them every once and a while, re-evaluate their "stupidness." Sometimes you will find a diamond in the rough, sometimes a stupid idea can be the spark needed to have a brilliant idea, and sometimes you will just get a good laugh out of the stupid things you think up.

learn autoit

[caption id="attachment_655" align="alignright" width="300" caption="Bezels and shadows and reflections, oh my"][/caption]

If you use windows at work or at play this post is for you, macheads and linux people I'm sorry, this post probably won't help you much. I have had the joy of doing documentation work for the last 2-3 months at work. Gnarly, ugly documentation that serves little purpose other than making someone feel happy that there are reams and reams of documentation. At some point, probably around the 5th document, I made the realization that out of 20 pages it was mostly boilerplate, with about 8 things peppered throughout that changed. I decided that it would be easiest to make a template document and then just do a find and replace on those eight symbols [[DOCNUM]] [[DOCNAME]] [[DOCTRANSACTION]] etc.

Productivity shot up, I could now stub out a document in a few minutes instead of the hour or so that it used to take to manually hunt through and change things. All was well and after a day or two of find / replacing I had stubbed out the 80 or so documents. Then came the meeting where it was decided that 2 new sections would be needed and that 8 sections could be removed as being redundant. This victory for common sense was also a giant headache, as I didn't really look forward to restubbing 80 documents. There had to be an easier way, a better way, I remembered a screen driver tool I had some exposure to at a past engagement, AutoIt.

After reading through the documentation and goofing around with it for a while yesterday I now have a fully functional script that will automatically stub out all of the documentation with the click of a button. A task that used to be an error-prone, manually intensive process now requires no intervention. We can restub on demand now, so changing the template is no problem.

The Good

• Saves a ton of time


• Removes the human aspect from an existing process


• Centralizes specific knowledge


• Easy to write and test

The new script saves a ton of time, I can regenerate all documentation in about 10 minutes, so I click a button and go walk around the office bugging people. AutoIt simply takes a known working process and steps in to be the person driving it, I didn't have to take time dreaming up a brand new workflow, I could focus on just getting it done. The script is now the system of record for the specific things that change from document to document, which is nice for trying to determine at a glance what makes an HCR1 different from a ARC6 command, without digging through 40 pages of documentation. AutoIt also utilizes a stripped down version of SciTE with auto-completion and built in support for compiling and running, which makes writing and testing the script a breeze.

The Bad

• Ugly syntax (like VBScript and PHP had a bastard child)


• Oddly organized documentation and variably helpful community


• Inherently brittle scripts


• Still slower than I'd like


• Foreground processing

AutoIt has an ugly syntax (think VBScript), but it has all the pieces parts to make a nice script, functions and variables. The documentation takes a little getting used to, there is plenty in there, but it could be organized better. AutoIt depends on things like the window title and absolute paths, so it is inherently brittle, I doubt this script would run unaltered on someone else's machine. This could just be me being a n00b at AutoIt but I followed the practices laid out in the tutorials and the documentation. The other bad part about AutoIt is that it drives your screen, it simulates you pressing buttons and mousing about, so the script is slow and you can't interact with the machine while its running or you will probably mess everything up.

Alternatives

After proclaiming my victory over the documentation monster, I got some replies from colleagues asking why I didn't just make a powershell or ruby program or java program or something. I could have cracked open OpenWriter or something and attempted to build some massive program that could create .docx files, but that would have taken a ton of time. The AutoIt solution was incredibly quick to produce, took about 2 hours of playing around with it. There were a bunch of side benefits that the alternatives wouldn't have had. The template file is just a plain ordinary .docx file with all kinds of crazy formatting and images, instead of trying to figure out how to reproduce this in code, I can use Word to do the heavy lifting for me. This allows business users to change the template and we can rapidly restub and get back up and running.

Conclusion

You should go and learn AutoIt or AppleScript or whatever GUI driver program is available for your platform. It is not the tool for every job, but it's perfect for some jobs. Being the person on your team that can take some boring, error-prone, laborious task and turn it into a turn-crank task is a great thing. You can save your team time, get back to doing actual work more quickly, and make a name for yourself as a problem solver.

who cares?

[caption id="attachment_573" align="alignright" width="300" caption="I shot who in the what now?"][/caption]

It's one of my favorite questions to ask during a technical discussion. Who cares? Some others I like to throw out our, why should I care? why does it matter? and I don't care! Am I some sort of raging lunatic completely out of my mind and trying to pick a fight with everyone I meet? Yes, but that's not why I ask these questions. I ask these questions because as great as the big picture is we sometimes have to drop complexities to get stuff done.

When you have a big flow diagram or giant UML Class Hierarchy it can be fun to think about the abstract way that things interact and how you can pass state around and whatnot. This definitely is useful for getting a feel for a new system, but then there comes the worst part of any software developer's job, actually getting things done. You see that's what we get paid for, actually putting our fingers on keys, typing stuff out, compiling it, and shipping a product. Part of this is doing the upfront design work and getting all of our t's crossed and i's dotted, but just as important is actually getting something working.

I talked about this before in my post about simplifying things. This simple question, "who cares?" (you can be more diplomatic about it if you like) is a great tool for getting to the heart of a problem. I like the simplicity and straight-forwardness of the question, it normally catches people off guard and challenges their assumptions.

Frank: So we need to pass this data into the layer
Bob: Who cares?
Frank (taken aback): I care, I care deeply about this data
Bob: But why do you care about it being in that layer, its just going to hand it off to this layer, and that layer doesn't care at all about it
Frank: I guess you are right, we don't need it there

BAM!!! Problem simplified! For anyone that's ever taken any education classes you may recognize this as a rather blunt application of Socratic Method. The point is confrontation, but not between the two people discussing something, between each person and their preconceived notions about a problem or situation.

In High School I took a chemistry class, it is one of the few classes that I really remember in any detail from so long ago, the teacher taught the entire semester in Socratic Method. He would question us, we would experiment, we would reason out why we observed what we observed, he prodded us, and we cherished our knowledge. Anyone can tell you water is composed of 2 hydrogen atoms and 1 oxygen atom, but when you had to work for it, when you had to defend your knowledge of it from scrutiny, it became concrete, it became your discovery.

Applying this to software development is useful, we can get locked into our preconceived notions, and direct, blunt, sometimes even rude questions can spur you to really consider what you are talking about. Software is incredibly fluid, sometimes an idea or concept can become out-dated in a matter of months or a matter of hours. The biggest ones are the most difficult to challenge, because they often have the most dependent code around them, but this makes them the most important to constantly consider.

Keeping your conceptual design, implementation, and solution in lock step with a problem domain often involves some amount of change, that change can be hard to come by though. By challenging our standing beliefs we can find new avenues for exploration or strengthen the existing techniques and gain a better understanding of them.