Caffeinated Coder

Back from another fun weekend that consisted of a couple of 6 hour car trips with a bored 7 year old and a screaming 6 month old with a bad case of explosive diarrhea. All this just to visit in-laws in a nursing home located in the booming metropolis that is West Plains, MO. What could be better?

1. More thinking about “Agile” vs “Waterfall” – Fresh insight by Jason Yip into the strengths and weaknesses of the Agile and Waterfall methodologies, including some challenges to conventional wisdom about when a waterfall approach is most appropriate. I especially liked his refinement of the Agile principles and values.
2. The Problem with Every Implementation of a “Forgot Your Password?” Feature I’ve Seen Online – Dare Obasanjo reflects on the recent Sarah Palin email hack and draws what should have been a really obvious conclusion that the standard ‘forgot password’ functionality which relies on answering a personal questions in lieu of the password is fundamentally unsafe in the age of google, wikipedia, and social networking sites like facebook and myspace.
3. Simple Trouble Shooting Application Now Fixes Everything – The Secret Geek provides a humorous list of common debugging techniques. I enjoyed the silly, creative ones on the list, but it also got me thinking about how many times developers rely on catch-all ‘reset’ techniques to resolve problems without really figuring out or understanding the underlying causes.

Popularity: 7% [?]

This is part two of my quest to convince Jurgen and his fellow judges that I should be the one who gets to blow the $100 dollar Amazon gift certificate on cool Software Development books.

In part one, I approached the question backwards by describing seven motivational anti-patterns.

Now I’ll focus on the positive and list some of the things that I find most motivating as a developer.

In no particular order…

1. Time in the Zone – This is like crack cocaine for me and I don’t get to experience it nearly enough. It is when I am so absorbed in my work that time flies by and I suddenly realize that 4 hours have gone by when it only felt like 10 minutes. It usually occurs when I feel totally engaged in a problem with highly challenging tasks that require skills that I feel very competent in.
2. Solving the Mystery – Debugging is one of my favorite activities. When I get a really tricky problem to sink my teeth into, I tend to anthropomorphize it into a living foe and then start taunting and swearing at it under my breath. I’ve even been known to do a little touch down dance after emerging victorious from particularly long debugging session.
3. Finding Creative Alternatives – I love being confronted with ‘impossible’ technical or logistical problems because they are almost always surmountable by taking several steps back and brainstorming completely different approaches to the problem. There have been a few times where I’ve felt like a zen master for having side stepped a massively difficult technical problem by simply rearranging the workflow on the screen or by eliminating the need for the feature altogether and satisfying the underlying requirements in other ways instead.
4. Eliminating Tediousness - I have no patience for tedious manual processes myself, so I find it very rewarding whenever I have been able to eliminate tedium from other people’s work days through the software I help create. 
5. Simplifying the Complex – For some reason I find it really satisfying to reduce the number of lines of code in a project by rigorously applying the DRY principle and then making it infinitely more readable through refactoring and using thoughtful naming conventions. I also love reducing the number of clicks that a user is required to make in the user interface. 
6. Uniting in Purpose – It is way too common in the industry to either work in virtual isolation (even when on a team) or actually work against each other. Nothing kills productivity faster than wasting time playing the blame game or falling into the ‘its not my problem’ trap. There have been a few times (usually spurred by crazy deadlines) when I’ve felt like I bonded with a group because we all truly shared a common goal and we all felt collective ownership of the end product. It’s difficult to reproduce all the ingredients that led to this group dynamic, but I can tell you that it was a true pleasure to experience and very highly motivating.
7. Receiving the Occasional Spousal Peace-Making Gift – I’ll throw in at least one superficial motivator to round off the list. Sometimes the spousal unit gets really pissed off when I have to work late or when work commitments override personal commitments. Those are the times when a simple gift certificate from the boss for a fancy dinner and night out on the town really come in handy. It’s flat out bribery, but highly effective. Afterall, when the wife is happy, then everyone is happy.

Oh…and I also find it very motivating whenever I get a $100 worth of free programming books (hint…hint).

Popularity: 9% [?]

I’ve decided to take a 2 part stab at answering Jurgen’s question about what motivates me in the work place.

To start with, I decided to meditate on a few things that tend to grab my motivation by the metaphorical gonads and squeeze.

In no particular order…

1. Sunshine-Up-the-Arse Speeches – Luckily these are most decidedly not part of the culture where I currently work, but I received enough of them at my prior job to hold me over for the rest of my career. I find impromptu homilies by CIO’s that are ripe with football analogies and dramatic pauses to be particularly loathsome. There are only so many happy mental places a developer can go to during these trying times before nervous ticks start developing and homicidal tendencies start to go unchecked.
2. Paper Certificates – At the successful conclusion of a 3 year project, I actually received a paper certificate of appreciation that my manager downloaded from the internet. Despite being laminated with great care by the secretary, these certificates were not received with quite the enthusiasm hoped for my management. I think I did actually hang mine on the wall for a little bit, but only because it made me giggle every time I looked at it.
3. Inappropriate Praise – I would rather have a boss that gives out too little praise than one that doles out too much. With the emotionally stingy boss, at least you know that the praise is honest on the rare occasions that it does come. With an overly effusive boss, however, even the truly genuine compliments will get lost in all the sickeningly positive noise.
4. Random Public Recognition\Rewards – Publicly praising a person in front of their peers during a meeting and then handing them a $50 gift certificate for some random bit of overtime or good work they recently did is one of those ideas that sounds good in theory but only leads to trouble. The chances are that one person left that meeting feeling awkward, while the rest left feeling bitter. 
5. High Friction Environments – I can’t remember how many times I wasted the day in an inane HR, audit, or department meeting and thought to myself…’I just want to do my job…if only they would let me do my job I would be so happy’. I had similar experiences of feeling that my company was one of the major roadblocks to getting work done while chasing down forms and signatures for piles of paperwork that were required to do the simplest of tasks. It’s amazing how much of an affect that just canceling unnecessary meetings and streamlining inefficient processes can have on morale.
6. Cancerous Team Members – Nothing saps motivation faster than a team-member who is allowed by management to consistently be abusive, arrogant, lazy, or incompetent without any repercussions. If you are a boss and want to motivate workers, then get a back-bone and deal decisively with the department’s resident problem child. Remember, we just want to be allowed to work in peace and sometimes people are the biggest roadblock of all.
7. Habitual Forced Overtime – As I argued here, I think overtime is rarely a good idea and is almost always preventable. However, if you are backed into a corner but still don’t want to incur the motivational penalty that inevitably goes along with overtime, then make sure it is infrequent, as flexible as possible, and compensated in some way (preferably with extra time off after the goal is met).

Feel free to chime in if I left any major gonad-squeezing anti-patterns out…

Popularity: 27% [?]

Question: What’s worse than the stomach flu?

Answer: Having your wife and 6 month old get sick at the same time and having it all happen on the same weekend as your parents visit from out of town.

Despite these horrors, I’m back and ready for business with my second Triple Shot installment.

1. Win $100 Worth of Software Development Books! – Jurgen is going to hook the person with the best ‘What motivates me’ answer with $100 of free software books from his chums at Amazon. I made an initial list, but so far everything on it will either get me arrested or kicked in the junk by my wife. I’m going to keep thinking though because I’m pretty sure that if I get rid of one of my cats I might be able to fit a couple of more computer books in the house.
2. SOA & DDD For Everyone – I was trying to blackmail my boss into sending me to this course last month when it was first advertised, but the original price tag simply broke our training budget. Now at $2000 for a week of premium training with Udi, it is a steal. Unfortunately, now personal commitments are standing in my way. Oh the miserable irony of it all…
3. Jeremy’s Penultimate Law of Continuous Integration – I’ve been bitten by this one several times in the last few months. It’s such a nice feeling to have everything checked in before you go home, but waiting to do it until right before you leave to do it automatically conjures up some really bad build-breaking ju-ju. Better to just let your code languish in check-in purgatory over-night than to chance angering the build gods with such a brazen act of coding hubris.

Popularity: 6% [?]

I decided that I liked the concept of sharing some of my favorite links each week along with my witty banter, but that I don’t particularly like the format offered by the Feedburner-Delicious integration service.

I especially don’t like how there is no way to leave comments and it is not available to people who stumble on the blog outside of an RSS channel.

So instead of doing the Delicious links, I’m just going to do publish the links as a traditional blog post with the heading “Triple Shot Links” (obviously I’ll continue with my established habit of providing three links at a time).

Here’s the first installment using the new format.

1. Best tools for creating website wireframes – Stack Overflow - This is the first referrer link to my blog from Stack Overflow. In honor of the occasion, I finally signed up for an account tonight and started trolling for questions. So far I only have 1 pity reputation point that I got for signing up…:-(
2. Animated Sorting Algorithms – Click on the green arrow to see a mesmerizing animation of how each sort method work. Warning: Do not watch while taking any narcotic substances! I found it through Hanselman’s latest Back-To-Basics inspired post. It’s great for anyone feeling nostalgic for their old college days or inferior for having mis sed out on a proper CS education.
3. Hiring Expert Web Developers at Hashrocket – Describes a tempting job offer from Obie Fernandez’s company. I especially like the part about “up to 8 hours paid time per week allotted to ‘other activities’ including open-source hacking, writing books and blogs, education and other internal initiatives”. I wonder if he is bitter about my little jest about his old blog photo…oh wait…Florida…nevermind. I guess I’ll have to stick with writing my blog posts during my lunch hour and at night after the wee ones go to bed. Sigh…

Popularity: 7% [?]

In the spirit of LEAN and attempting to trim waste from existing processes, I’ve been pondering the optimal amount of effort to spend doing mockups lately.

By mockups, I just mean a quick and dirty approximation of what the GUI will look like once development is complete. Mockups are usually considered disposable artifacts that are done to validate requirements and draw out those inevitable changes earlier rather than later in order to minimize the impact to the project timeline and budget.

The amount of time and effort developers devote to doing mockups can vary greatly.

Some developers prefer quick and dirty drawings that can be done on the spur of the moment using napkins and whiteboards. Others use expensive graphic design tools or even code with simple events that use hard coded data to simulate dynamic functionality.

The trick is to waste the least amount of time working on non-production code while still giving customers an inexpensive way to play around with design, usability, and workflow.

Sometimes that is not so easy to do.

Generally, I favor the more Agile approach to developer artifacts and opt for the more lighter weight approaches whenever possible. If you use short iteration cycles (2-3 weeks) that end in user acceptance testing, communicate frequently with user, and use Test Driven Development, then making rapid changes to code shouldn’t be nearly as expensive to do as it used to be in the old Waterfall days. Under these circumstances, it just doesn’t make as much sense to spend much time on mockups.

I only have 2 problems:

1. I’m no longer really working in an agile environment.
2. I really suck at drawing on napkins and whiteboards.

Fortunately, my team just started using Balsamiq, an amazing light-weight, yet still professional looking, mockup tool built on Adobe Air.

It’s has a slick, web 2.0 style interface and within minutes I was able to build mockups that looked like these without even having to sludge through a tutorial first.

Sample mockup of Desktop App.

Sample mockup of website taken

See more samples here.

I especially like how the mockups purposefully look like sketches, which helps avoid the old ‘this-looks-so-real-that-you-must-almost-be-done’ syndrome that sometimes bites developers in the butt when they do too good of job on mockups.

This tool works especially well if you have Confluence or JIRA because it integrates seemlessly via a plugin.

Unfortunately, this is not an open source tool, but in my opinion the cost was well worth it. It was under $500 for a site Confluence license for our whole team, but it looks like you can also get a stand-alone desktop version for $80 a piece.

I highly recommend taking a few minutes to play with the online demo here.

Popularity: 10% [?]

I recently read Jurgen Appelo’s post, Professionalism = Knowledge First, Experience Last, and then Ted Neward’s somewhat harsh response, From the “You Must Be Trolling for Hits” Department….

Although both posts rang true when highlighting the various problems that occur when developers are deficient in either knowledge or experience, I don’t think either post pursued a very fruitful path by trying to prioritize one over the other.

There are simply too many horror stories of technical sabotage perpetrated by both architecture astronauts, who inappropriately apply their knowledge, and developer monkeys, who viciously fighting to protect absurdly sub-optimal status quos for no other reason than it has always been that way.

If both paths can potentially lead to such undesirable results, then what is the point of choosing between the lesser of two evils?

To me a much more interesting question to ask and then try to answer is what makes some knowledge and experience more valuable than other knowledge and experience.

In other words, how is it that I can interview two candidates with the exact same number of years of experience and an almost identical list of buzzwords on their resumes, yet there is still an order of magnitude difference between them in terms of the overall value they bring to an organization?

I believe the gap exists because there are a number of knowledge and experience ‘multipliers’ that some people utilize and others don’t.

An example of an experience multiplier would be self-reflection. A person who is naturally self-aware and systematically reflects on both their successes and failures is going to gain a lot more value from their experiences than a person who always focuses on the ‘what’ but never the ‘why’.

An example of a knowledge multiplier would be a healthy respect for context. Every methodology, best practice, framework, and tool performs optimally under a certain set of circumstances while performing terribly under other sets of circumstances. A person who is conscientious enough the learn the full context of the environment they are in before making any recommendations will be far more effective in being able to use their knowledge than someone who impulsively pushes the latest and greatest solution regardless of the costs and consequences.

The more multipliers that people employ, the higher quality of experience and knowledge they will have.

So if you’re trying to resolve the Experience vs. Knowledge debate for yourself so that you know whether to focus more on the number of years of experience or the number of relevant buzzwords on the next batch of resumes that shows up on your desk, try this instead.

Come up with a list of what you consider to be knowledge and experience multipliers (stay tuned for my list coming soon) and use them to create list of interview questions. Based on the answers to these questions, award each candidate a score of 1 to 10 for the quality of their experience and another score of 1 to 10 for the quality of their knowledge. Then add both numbers together and choose the candidate with the highest overall score.

It may not be a perfect solution, but at least it seems better to me than focusing solely on experience or solely on knowledge because you happened to have been burned by an architectural astronaut or developer monkey recently.

Popularity: 8% [?]

Someone (Max) finally pegged me with this old tech meme that has been floating the blogosphere forever. I decided to be a good sport about it, so here’s the whole seedy story of how I got started in the industry.

How old were you when you started programming?

Although I do remember spending several hours as a pre-teen typing in BASIC programs on my Comodore 64, I never really became infatuated with computers and programming until I was in my mid twenties. Before that I was a History major in college and then spent my first few professional years teaching in an inner city Washington DC school through an alternative certification program called Teach For America.

How did you get started in programming?

After four very long years, I realized that I was definitely not cut out to be a teacher. My original plan had been to go back to grad school to get a PhD in history after a few years of teaching, but I decided I really didn’t want to do that after all so I was looking for new options. I thought about all the things I either really liked doing or was good at, such as studying foreign languages, playing chess, problem solving, and being hyper focused on single problems for hours on end, and somehow it occurred to me that I might like computer programming.

On a whim I picked up a couple of brick sized C++ books on the first day of a summer vacation one year and was immediately sucked in. I spent every waking moment for the rest of that summer obsessively trying out every code sample and demo exercise I could find using notepad and a basic command line compiler. By the end of the summer I knew I had finally found my professional calling.

After that I concocted an insanely ambitious 9 month plan of intensive self-study and actually managed to follow through with it despite being perpetually sleep deprived. By the end of the school year, I worked up enough nerve to quit my teaching job and somehow managed to find a real job before my paltry savings ran out.

What was your first language?

As I mentioned before, I really did things ass-backwards by starting out with C++ instead of some scripting language (I didn’t know any better at the time). However, in hindsight I think it was a blessing in disguise because it helped give me pick up some lower level foundational principals that I otherwise would have missed out on by not receiving a traditional Computer Science education. It also made everything afterwards look relatively easy by comparison.

What was the first real program you wrote?

I wrote a few classic ASP applications with Access back ends for the school I worked for in order to help automate a new paper intensive professional development process that they had just started. I’m not sure if my apps were used much after I left, but at least they allowed me to escape the world of contrived book examples and finally get some real experience with the software development process.

What languages have you used since you started programming?

After C++, I studied Java for a while because I had a friend who thought he could get me a job as a java programmer. As my impending job search approached and I was scrambling around for some opportunities to build real applications, I decided to switch to Cold Fusion and then ASP because those were the options available to me on the school district’s web servers. I went on to use ASP, Javascript, and VB6 (COM) in my first job and then .NET as soon at the beta was released. I’ve been a .NET developer every since then, but have experimented with Ruby, Python, and PHP over the last few years. I also had to fix a production bug in a really old version of PowerBuilder once, but I’d rather not talk about that…

What was your first professional programming gig?

I worked for a publishing company writing the front end for a classic ASP\COM internal web app that tracked trade magazine subscriptions which they gave to people in exchange for selling their souls to the advertising demons. I think that was the last time I did any significant web development other than routine maintenance.

If you knew then what you know now, would you have started programming?

Absofrikenlutely. My only regret is that I didn’t start earlier.

If there is one thing you learned along the way that you would tell new developers, what would it be?

If you don’t like being a continuous learner, then this isn’t the profession for you. The best way to maintain your motivation over time is to constantly cultivate your passion for software as well as your humility.

What’s the most fun you’ve ever had… programming?

I love writing code, but my most enjoyable experience on the job was actually doing some security penetration testing on all of our internally developed applications at my last job. My knowledge in this area is still pretty basic, but the analysis processes reminded me of a chess game where you had to fight for small strategic advantages that you could eventually string together to win your objective.

One particularly satisfying moment was when I finished my analysis and then let our IT Security Specialist know that I found some serious security holes. He didn’t believe me, so I decided to provide a demonstration. The next day I had the pleasure of watching the look of shock on his face as I asked him to disable the new domain admin account that I was able to create for myself and gave him the instructions for how to remove the vulnerability.

That was fun.

If I ever get bored with corporate development, then I’m guessing that I’ll migrate over to the security world. In other words, I want to be a hacker when I grow up.

Now with the tagging…

I’m tagging Justice Gray because I’ve been waiting for an excuse to exact karmic revenge on him for starting that insipid How I’m becoming a better developer meme last year.

I’m also tagging D’Arcy Lussier under the condition that he somehow work in a picture of Justice Gray wearing a Princess Lei bikini and looking longingly at Jabba the Hut into the post.

Popularity: 9% [?]

Everyone has memories of certain formative experiences that seemed to mark the end of naive adolescence and the beginning of cynical adulthood.

When I think back over my career as a software developer, I realize that I’ve had several experiences that taught me some hard and valuable lessons about the art and science of software development that seem like rites of passage in hindsight.

Here are some of my more memorable ones. Most are either bone headed mistakes or else situations that could have been avoided with more disciplined engineering practices and better methodologies in place. Nevertheless I look back on them with a slightly masochistic fondness. After all, what better way to truly understand the reasons behind best practice than to have experienced the pain that they are trying to remedy first hand.

Enjoy.

In no particular order…

1. Releasing software to production that took twice as long as the original, padded estimate with half the features and still having the users be happy about it.
2. Being on both the giving and the receiving end of a situation where consultants were given god-like powers by executive management.
3. Laughing out loud in a meeting with an auditor because I thought they were making a joke about some new software development mandate only to find out that they were serious.
4. Averaging more than 70 hours a week for 6 months straight and then getting yelled at for not making an arbitrary delivery date when the requirements were in a constant state of flux.
5. Feeling more like a lawyer than a developer while trying to explicitly capture requirements or determine whether an issue that surfaced during testing is really a new feature or a bug.
6. Realizing for the first time that office diplomacy often had a bigger influence on project success than how many software best practices were being followed.
7. Deciding to stop printing out a project’s object model and\or database because it would no longer fit on the walls of the largest conference room.
8. Being at least indirectly responsible for a bug that cost the company more money than I made in a year (I used to work in a banker’s bank that loaned billions).
9. Helping to write a 500 page requirements document that very few people read and that was hopelessly out of date before it was even finished printing.
10. Getting woken up on a Friday night in order to troubleshoot a production problem remotely in a code base that I’ve never seen before.
11. Accidentally trashing a half million records in a production database.
12. Having to fix a problem with a system that the company no longer had the source code to.
13. Realizing that I no longer remembered how to do a hello world app in a technology that I used to be viewed as an expert in.
14. Spending multiple days on a problem that took only one line of code to fix.
15. Spending over 6 months creating an application that worked flawlessly only to have it scrapped because of a merger and downsizing.
16. Being treated like a hero for out-of-the box functionality that took only minutes to implement.
17. Being treated like an idiot for taking too long to solve a nearly impossible problem that other developers weren’t even sure could be done.
18. Being solely responsible for the decision to fire another developer.
19. Having a sense of deja vu when reading about a latest and greatest technology and\or methodology.
20. Having to debug and then clean up the data carnage caused by a 1500 line stored procedure with no error handling or transaction management.
21. Realizing that I still love my job even after eight years of coping with extreme dysfunction in an industry that rarely learns from its mistakes.

Do any of these sound familiar? What are your most memorable rites of passage as a developer?

Popularity: 10% [?]

I was doing some spring cleaning on my blog this last weekend and decided to review and refactor my category list.

Categorization of posts is probably not something that most bloggers bother to spend much time thinking about. I’m sure there are a few anal retentive souls out there that do this on a regular basis, but attention to detail is not usually one of my strengths so I was surprised when I found myself so engrossed in this activity.

Mostly I think I liked doing this because it helped me reflect on on how my blogging style and interests have changed over time. I realized that I used to write quite a few posts that were imbued with a sense of fun and satire, but that over time my content became much more serious and research based.

I really enjoyed rereading those earlier posts and it made me nostalgic for that type of writing. Blogging was way more fun then.

I still definitely enjoy researching and writing about more serious, technically oriented posts and will continue to do so, but I think that focusing too much on serious content for too long definitely contributed to me becoming a little burned out on blogging and needing a hiatus.

In the future, I’m going to experiment with striking a better balance between these two sides of my personality.

In the meantime, I decided to create a new category for these earlier posts here as well as highlight a few of my favorites for those of you who subscribed to my blog more recently and may have missed out on the lighter side of Caffeinated Coder.

Enjoy.

1. ALT.NET Conference: The Geek Paparazzi Uncover Real Controversy – This one is easily my favorite. As a response to the claims that Alt.NET was too elitist, I decided to have some fun by making up a story to go with a handful of peculiar pictures that I found posted from the first Alt.NET conference in Austin.
2. Breaking Up Is Hard To Do… When I changed jobs about a year ago, I got really sick of having to repeat my nice, scripted answers to why I was leaving, so I came up with these alternative gems that I would have liked to have told people instead.
3. On Communal Douche Bags and My New Business Model Remember back when Fake Steve Jobs pretended that he was being strong armed by the real Steve Jobs into shutting up? Here’s some fun I had with the topic that even included juxtaposing a picture of Steve Jobs next to a picture of a real douche bag.
4. Scott Guthrie Gets an Image Makeover Have you ever imagined Scott Gu as an action hero kicking some major *ss? I had way too much fun with Jib-Jab in this post.
5. Mystery Solved – Here’s a little Paint.NET fun that I had at the expense of Scott Bellware back when his blog mysteriously disappeared from CodeBetter.
6. Conspiracy++ – Here’s my April Fool’s response to the Usual Canadian Suspect’s attempt to simultaneously claim credit for the anonymous Alt.NET pursefight blog.

Popularity: 7% [?]