I like to dabble in the "user experience" a lot, but when I say "dabble," I mean "No one in the world would EVER let me influence user experience so I pretty to do it on my own projects in order to feel like I'm contributing something. I have Smashing Magazine in my feed reader, among others. I just don't have the eye for the "design" part of the whole equation. I'm not a command line zealot either, but I don't know how to recreate the "feel" of an app that I really like. So I continue to dabble.

This morning, I was reading through the feed reader, and just went on a link stroll through the internet after clicking through links to other articles. I stumbled on a blog that I wish were still around, called Creating Passionate Users. I found it because Jeff of Coding Horror was blogging about why Passionate Users is no longer around. While I didn't much care for the Jeff's recent post (not that it isn't important, just that it's not something that is directly on my mind), it led me to a few links that I found were directly inspiring to not only user experience, but to general life: Jeff's Who Needs Talent When You Have Intensity and Kathy's How To Be An Expert

I've posted what I think it takes to be a good developer before. I've worked with some good developers, and I've worked with some bad developers, and I've worked with developers in between. The colleagues that I really have to dig to remember are mostly the ones that write code as a 9-5 job. This isn't necessarily a bad thing, but I can tell you that you don't do a job that you LOVE the same way you do a job that you start at 9am and end a 5pm. I've worked with people who claim coding is their passion, but don't seem to take pride in their work (and in all but one case, I have to clean up that work, the one case being I was laid off in time to miss that maintenance...) But after all is said and done, just like Tenacious D is musically horrible yet entertaining, the good developers are those with passion.

How do I have passion? On my bedside table, there currently sits a copy of "Buffy the Vampire Slayer Omnibus Vol 2" along with "JSP, JSF, and Tomcat", "Pro Javascript Techniques", and "Java Generics." Buffy usually gets read once a week or so. I write code at work at all, and then I come home and write more code. I usually like to take on a new language or a new framework every three months or so. I find niches that need to be filled. And what makes an expert, as Kathy points out in her post, is someone who is always looking for ways to improve. I recently endeavored on the quest to re-engineer the backend of Entertainer, because it had some valid issues, and because I knew I could make it better.

The moral of the story is that I need to stop "dabbling" in understand user experiences, and make it my passion, so that it will start showing through in the products I create or help to create. You should do the same for the things you want to do.

Today, I went into the office for a team review of our first stab at the agile development methodology Scrum. We didn't get nearly as much as we planned completed, for multiple reasons. However, during this whole development cycle, I've learned a few things about general development and developed my own practices based on what I've learned, so I thought I'd share with you some of the things I've learned. Many of these ideas are not new, nor are they even new to me, but I mention them mostly because they were reinforced into my mind, which means that it only has to happen a few more times before it clicks, ent?

It's a Buffet, You Can Come Back

One of the biggest problems is that we're undergoing some major changes to our codebase (read: complete re-write of most of the codebase). So when we started, we laid out all of our tasks on the board. It was quite a daunting task. We had a new database model, a new web framework, and the implementation of all existing functionality to port. This was quite the task. However, in our excitement, we did what I end up doing at a buffet on a normal basis: I forget you can come back for more, so I get more than I can eat in the first place. So my task list was humongous, and large task lists are bad for productivity.

The whole point of Scrum is to take small steps to accomplish a larger goal. Understand that you can come back. The stuff you couldn't squeeze into this cycle into another later on. Prioritize. Take the stuff from the buffet that you'd like to warm up with (like a salad, or modifying your framework for your specific needs). Build out from there. Pretty soon, you'll have built something that allows you to add new features in only a few weeks.

Boil the Ocean One Kettle at a Time . . . And Ship The Kettles!

My biggest problem was getting started. Rewriting code is difficult (at least, re-writing this code). Working with a new framework comes with a learning curve. Creating all the base libraries is time consuming and requires a lot research, research that only comes from actually developing the platform. All three of these problems, along with the unfortunate motorcycle accident of another developer, led to a slow start.

My biggest problem is that I wanted to get the libraries and models written right the first time. I think the biggest contributor to that was the plethora of books I've been reading, trying to improve my development methodology. It worked, but I also had to stop reading about it and do it. I think after I realized once again that the library would grow based on its needs. Instead of writing it one way, realizing it was wrong, and writing it another way, lathering, rinsing, and repeating, I just started with what I had, used it in some implementations, and found the problems there. This led me to change the libraries, fix the implementation, and then rinse, lather and repeat. The library code grew at an alarming rate, I found limitations in the framework that I was able to improve (hooray for open source), and created an implementation. It's definitely not the final product, but I know everything I need to know to fine tune it completely.

Keep Your Cycles Like Your Meetings : Short and Sweet

Our development cycle was a month long. That was too long. I spent a lot of time spinning my wheels, getting discouraged because I wasn't getting anywhere, watching the workload not shrink, but feeling like I had all the time in the world. After two weeks of that, I re-evaluated my process, and realized that I was literally trying to boil the ocean. I then sat down and shrunk my workload (see above), and made out a plan to finish only one set of functionality by the end of the cycle. Low and behold, two weeks of time was just enough for me to do what I needed to get done. There were snags, but it also meant that I worked more focused, set smaller goals to accomplish a the end goal, and took each set of goals day by day.

Along with that, we had daily status meetings in the morning. Almost all of our team telecommutes three days out of the week (including myself). The basic idea was that each member of the team accounted for what they did the day before, what they had planned for the day, and whether or not anything was blocking them from continuing (and what the blocker was). These meetings allowed visibility for eachother, and allowed us to coordinate our efforts. Seems that another developer had the same epiphany I had about the same time, and "with [our] powers combined" we provided a pretty decent deliverable (sorry, it wasn't Captain Planet).

Jeff Atwood @ Coding Horror posted a few days ago (but only came into my RSS reader today...) about getting his start in programming through writing games on his TI-99. He cites a few other developers who also got their start in games. Jeff continues with a brief history of a possible genealogy for the game Minesweeper, which I'm sure EVERY person who's ever worked at a call center or at a front desk is quite familiar with.

I've been playing video games since my dad brought home an NES when I was five. However, while I attribute the logic and troubleshooting to playing video games (and hooking up the NES when my dad unhooked it so I wouldn't play it), I seem to be among a small minority of developers who didn't get into programming through playing games. I got into writing code through my use of AOL when is was 12.

While I was still too young to apparently conduct myself properly on the internet, I found myself in the AOL internet portal world. While AOL's service is now only relevant to an older generation, I still found many of their services to be of use when I was younger (before there was a Google). I authored my first web page with AOLPress, on AOL's servers, as a tribute to Warcraft II, my favorite game at the time. AOLPress's ability to hop between WYSIWYG and raw HTML allowed me to make a change in the WYSIWYG and view the source, which taught me HTML. While my grandfather might have thought I was 1337, I still had no visitors to my "web site," and I was still really only writing markup, which really isn't programming.

About the same time, I discovered the "underground" AOL presence. I found chat rooms that ran bots to email you mp3s (before it was illegal), software (that I didn't know was illegal), and/or pornography (but I feared my dad more than the government). So while I upgraded myself from midi renditions of "Crocodile Rock" to an mp3 compressed version (that still took >30 min to download at 56k), I also stumbled across a copy of Microsoft Visual Basic 3. I thought it was awesome. I could make little programs that had a button that would pop up a message box that said hi, and it took me only a few minutes. This same underground also used Visual Basic to create helper apps for usage in AOL, like the bot that would email everyone in a chat room the various warez, programs that would scroll macros to the chat room, and even "punters", that would send massive amounts of instant messages to a user containing multiple <h1> </h1> causing (for a still unknown reason to me) the attacker to "punt" the victim from their connection to AOL, causing them to need dial-up again, and usually be confronted by the same offending user "punting" them again.

Now, my first official project in Visual Basic 3 was an antipunter, which introduced me to Win32 programming, and all the HWND sort of stuff (that I've since forgotten). The program was named before it was even developed, and I called it The North Pole Antipunter, cleverly implying that the antipunter gives punters the "cold shoulder." The basic idea was that the system would check for new IMs, and close the IM window immediately. As long as those <h1>'s didn't pile up in a window, you were okay to stay online. So the antipunter could go constantly without you being punted. The problem with the application was that if someone wanted to legitimately IM you, the antipunter would close that window. It didn't check the contents of the IM, only the presence of an IM window. At the point of this discovery, I had EOL'd the program for newer and cooler things.

The drive for me to continue with Visual Basic (and other languages later on) was pure mischief. I wanted to be able to put a program on a friend's computer that would do something funny every hour. I created a piece of software that would shut down my computer at 10 o'clock on weekdays so I wouldn't stay up too late (which became a problem). While I don't condone writing viruses as a way to get into computers, there's a lot to learn in that process that would be invaluable later on in life.

So I guess I did get my start in programming by writing games. The only difference is that my games involved playing with other people.

I spend 8+ hours a day writing PHP code, debugging PHP code, and refactoring PHP code (is that possible?) Needless to say, sometimes I feel the weight of PHP's utter lack of design bearing down on my like your mom when you don't eat your vegetables. I often feel helpless at the fact that PHP has a significant amount of cruft that sometimes you just can't do anything about. I've been reading as much as I can on the topic, hoping to maybe one day learn to write Beautiful Code but I don't feel that day will be anytime in the next few months.

Recently, a few coworkers and I sat around discussing the possibility of creating a Drupal plugin for Turnplay as a supplement to the Turnplay Facebook app. We all had something to say about Drupal and its benefits and detriments. However, all of us came to one conclusion: There is very little need to use a third party framework in PHP.

Let me take a step back and explain myself. I like to write C code. It's fun. However, there's a lot of menial stuff I don't want to do over and over again. So we introduce libraries, and someone else's code. With open source libraries, if the documentation sucks, who cares? You've got the source to peruse (and maybe fix a bug or two...). Using someone else's library speeds up your development time, because they've already debugged their library API. Other developers have learned everything they need to know to write a library for X-protocol, so you don't have to read the X-protocol docs and then write and debug your own X-protocol generator/parser. The time saved by using someone else's library is orders of magnitude better than building your own.

Now, I use a framework for this very site (Django) and I'm an advocate of making life easier. However, with PHP, the design of the language (or lack thereof) is to make everything easy without needing more tools. I can't think of a single time I've needed to go to a site like PHPClasses to grab a module I couldn't write in the same amount of time. Sometimes, the learning curve of someone else's class or framework can cost you a PS3.

With PHP, most things you could possibly need are built in. Want to write an RSS feedparser? Use simplexml_load_file(). Want to interface with a mysql database? Check out mysql_connect(). Granted, support for Oracle database connections and other enterprise software packages take a little more coercion, but I've honestly never needed to use an outside library. The closest I can claim to doing so is using the PHP-Pear libraries (only Mail and Mail_Mime). So, while some languages spend time pulling in external libraries, linking in .o files, etc. I can write code. And I like writing code.

You've heard of it. All the cool kids are doing it. If you're not doing it, you're living under a rock. C'mon, just try it. The girls will start noticing you if you do it. You'll start meeting all sorts of cool people, and get invited to all the 1337-est parties. No, I'm not talking about cigarettes. I'm talking about fuzzing.

Fuzzing is the process of providing random data (the "fuzz") to the input of a program. Anywhere that input is received into a program, a fuzzer would allow you to test the robustness of your platform. A network fuzzer would be able to construct a random packet of a given type and throw it to an open port. File fuzzers create random files to be opened in a given program. Hopefully, you get the idea. The concept here is not new, but it seems that there has been an increased buzz for fuzzing in the last few years.

This last weekend at Defcon 15, there was a presentation on a network fuzzer called Funk. Fuzzing for me has never been able to draw me to it the way others have clinged to it. Some of that probably has to do with my lack of interest in hardcore security. However, I was drawn to this fuzzer because it was written in Chicken Scheme. Scheme is a great little language from what I've experienced, but I was having a hard time seeing an actual use for the language. So as I sat in the talk, I checked out that code and took a gander. It was a cool idea, and I've already got a little bit of a contribution patch that I'm preparing to submit to the project.

At the BlackHat Briefings in Las Vegas last week, Mozilla released a Javascript fuzzer designed to help browser developers to "fuzz" their browsers to find security vulnerabilities before releasing their products. The media can spin it how they like, but I am glad to see them opening up their tools, and providing documentation on using them. I especially find it useful because Opera, a competing browser, has now used the tool to find at least four bugs in their browser and release a new build. Hooray for communities!

Let's face it, every piece of software has its bugs. However, in the use case that Mozilla is using their fuzzer (and many other companies use their fuzzers), the fuzzing is equal to some great tests. As a web developer by day, I quickly learned that input should ALWAYS be sterilized, no matter how much you "trust" the users of your platform. It's hard, however, for me to find attack vectors in my own software, mostly because I've designed it around one use case, i.e. the one given to me by the "higher-ups." In my mind, I would say "If only I had a tool that would give me some real world use cases," in hopes to cover both stupid users (creating good error reporting) and malicious users (sterilizing the data or failing silently). Creating a good fuzzing tool would fit this bill exactly.

I'm sold on fuzzing now

I've been intrigued with the concept of testing software for quite some time. Unfortunately, the team I work with at my employer is so small that we hardly have time to write tests for everything we've needed. This means that my experience with testing software has been solely on personal, non-critical projects. I've read books and blog posts and entire mailing list threads on the topic of application testing with fascination. The one thing I've seen lacking is information on testing web applications. It seems the mentality of web applications is that since web applications are all written in Java, we can just use any of the Java testing suites. I hope you see the problem....

Yesterday, I stumbled upon Grig Gheorghiu's blog post about his new O'Reilly e-book An Introduction to Testing Web Applications with twill and Selenium which I went out and purchased, mostly because the price was right. I figured if the book sucked, it was a $10 loss. I'd never purchased an e-book before, but it was a subject that appeared to be something I'd definitely be interested in.

I've played with Selenium before, but I didn't find it to be incredibly useful, and I could never get the Selenium Remote Control to work right. I'd heard about twill, but I had never actually experienced it. After having downloaded and written tests in twill, I can see it's exactly what I've been spending a lot of time writing : a DSL to wrap Python's mechanize module for web testing. The limitation I had with twill was with pages that were AJAX driven, because it couldn't interpret Javascript. That's why the combination of twill and Selenium is so great. Because Selenium runs in your browser (it's got a Firefox extension...), it allows the browser to execute the Javascript, thus giving Selenium access to dynamically created DOM elements.

While I haven't quite finished the whole "book" yet, I'd highly recommend it to anyone who's tired of writing new features for their web applications, and fearing that they may be breaking other functionality at the same time. After subscribing to the testing-in-python mailing list, I cannot stress enough the importance of testing, testing, and more testing.

In the morning, when I come in to work, I usually have a procedure for landing into the day's development. It consists of a variety of things, including reading email, reading the contents of my Google Reader, sometimes a stop at Programming @ Reddit and DZone. After that, I do my Getting Things Done planning for the day, and I attack the day. Depending on what my lunch is like, I may also revisit some of my reading, but sometimes I'm in a groove, and space lunch completely.

Today I found myself reflecting on the last few years, and how far I've come as a developer. A few years ago, I was still trying to grok the first few pages of "Instant Java Server Pages" thinking I needed to understand a web language to create something a bit more dynamic. Now, in less than three hours, I can create an entire CMS software (like the one powering this site) without much of a struggle. I work in a variety of languages, and pride myself on the ability to pick up and use a new language when I find the need to. I was also surprised at how little of these skills I learned in school, and how many of them I learned by actual experience. So I slowly analyzed what it was the brought me here, and began to set some more goals on where I'd like to be in the future. Below are some observations I've made.

Have Passion - I absolutely love writing code. I write code all day at work, and 6 out of 7 days, I come home and write at least a little bit of code. On Saturdays, when my wife is at work, and it's just the puppy and I, I'll spend four or five hours just writing code. When I can't code, I think of ways to improve my existing code, or ideas that would be cool to implement in the future. I can tell the difference between someone who codes because it's their job, and someone who just loves to code. Guess which one is the better developer.

Be A Sponge - I cannot stress this enough. For me, school was a waste of time. Maybe if I went back to get my Master's degree or something, I might find a little encouragement in the college education system. When I landed my first software engineering job, I immediately realized that the people around me could teach me more than any college professor could. I wanted to learn, and working closely with those who would teach me meant that I could soak in everything they said. I also quickly learned to differentiate between opinion and fact, but even the opinions of fellow developers allow me some insight into their coding styles, their development styles, and their work styles. Soak up everything, good or bad, and build yourself with it.

Tweak Your Surroundings - If you're not comfortable in your surroundings, you won't thrive as a developer. I would go as far as to say you won't thrive as anything. For instance, at work, we all use SuSE 10.0, or SuSE 10.2 for development. Now, I have no qualms against SuSE, but I didn't find that it was my kind of Linux distribution. I'm not a KDE user at all, and I found that when I customized my environment, it broke YaST, so I could no longer install packages through the SuSE environment. After having a pretty rough day struggling, I spent a weekend building a Ubuntu Feisty system on a USB hard drive, which I now boot from at work. Sure, I worked the weekend to make sure I wasn't spending my company's time being finicky, but I have seen my development abilities double since I did it. Things like dual monitors, a good window fan, and just the right amount of lighting also attribute to my development ability. Find what works and go with it.

Open Up - I have this theory that if everyone worked at a fast food restaurant at some point in their lives, we'd all be kinder to those who make their living asking about our preference of Super Sizing. I think this also applies to Open Source. I think every developer should at least have one open source project that they work on with regular intervals. Air out your dirty laundry so that everyone can see. Trust me, you're not the best C++ developer in the world (and neither am I), so you're bound to learn something (see above about being a sponge). Have the guts to open up a personal project of yours that may have value in the community. You'll grow from it, you'll become confident in the code you write, and you'll laugh at the code you aren't proud of, instead of fooling yourself into thinking it is the best way.

Share - The open source movement (as well as the Free Software movement) claim that human knowledge is to be shared. We have this powerful network of information called teh Internets, and boy do we use it! The first place I go when I'm trying to figure out a problem is Google. The solution is usually found in a blog post. This is the sole reason I have a blog in the first place. I feel that my knowledge is licensed under the GPL, and I need to contribute back to the community. Maybe as I squeeze out my mental sponge, there will be another sponge waiting to soak up the knowledge.

Read - When you can't code, read about coding. Read blogs. Read books. Read magazines. Read. My wife teases me because I have a stack of technical books at the side of the bed. I don't read them cover to cover usually. I think I've only done one technical book cover to cover, and I did that just to say I did. Rather, I read books until I know enough to do some coding on my own. Somehow the books never make it back to the bookshelf, but every fews nights, I'll pull another one off the bookshelf and bring it to bed. I read a few pages before I go to sleep. Read a book about Design Patterns, then read one that is Anti-Design Pattern. Read a Python book, then read a Ruby book. I've been swapping between Rootkits: Subverting the Windows Kernel and The Linux Kernel Primer: A Top Down Approach for x86 and PowerPC Architectures recently. This allows me to see how the Windows kernel contrasts with the Linux kernel. It has been eye opening to the different design philosophies for me. Read all you can, and then read some more.

Expand - Decide right now that by the end of the year, you'd like to know at least one new programming language. Stretch yourself here. Don't decide that you're gonna learn C++ if you're a C developer. Learn SmallTalk. Learn Java. Learn the Linden Scripting Language from Second Life. I find myself going to Google Video and typing in Tech Talk, browsing for an interesting video, and watching it, or loading it to my iPod to watch later. A coworker of mine, who is a very good developer, was asking about a approach methodology for a problem. At the time, I was the most inexperienced developer in the room, but I suggested something similar to what I had used while working with the Qt GUI framework, which he liked, and implemented. If I hadn't been working with Qt, or the open source software that I was working on, I wouldn't have been in the position to suggest the idea in the first place. If you find coding mundane, you'd better mix it up a bit.

There definitely are those people who have a knack for software development. Others don't. But good developers are indeed made, not born. There are "muscles" that you have to exercise, and stretches you need to do. With the right training though, anyone can become a good developer.