I’ve worked now on both sides of the programming fence, and thought I would share my thoughts on the differences, as I see them, between focusing all of one’s energy on a single application (application centric development) and focusing all of one’s attention on a diversity of application development. I will tend to focus more on the course of application centric development as that is what I’m becoming accustomed to, as well as favoring as my personal style of work. First, let me explain what the landscape is like on each side of that fence.

Without pretending that I have a huge knowledge base behind this claim, I feel that programmers who focus daily on a very wide array of applications, that may or may not be similar to one another in any way, tend to freelance. This is an admirable place to be in my book, but comes standard with a set of disadvantages to all but those who were born to live the wild free life of a freelancer. As such, my own experience has shown me that a freelancer must, for the love of all that is holy and billed on a monthly basis, interact with and pretend that they love nothing more than making every money consuming change humanly possible for their client.

On the other end of the working spectrum, where I now thankfully find myself (although I certainly owe much to my freelancing roots, as discussed below) are those dedicated to the perfection of a single application, or depending upon your definition of application, a set of very tightly integrated applications. This person may, more likely, find themselves frustrated with the restrictions of what they do. The inability to find the coolest plugin you’ve ever seen on the web and immediately run and plug it into every outlet that can be found because you know, with no need for justification by anyone else, that that plugin can be integrated so quickly that the only thing any one will notice is how awesome you are. However, the real thing to remember is that this person, restricted by the boundaries of the application upon which he or she works, is only really restricted to their ability to convince the elders of the impending awesomeness, of which he or she possess’.

Of all the things that I have come to love most concerning the application centric development work environment is the obvious layer of restriction mentioned above. In this situation, expanding the boundaries of what one does is by no means impossible, but merely more challenging to obtain. The healthy implication of having to overcome the restrictions imposed on programming technologies/techniques is that once overcome, the application will never be blindly bombarded with the coolest, though quickly over the top, code ever written by man. Nope, by this point it has been thought out enough that you may even no longer want to use it, and if you do, it will certainly be used responsibly.

By our very nature, we desire to, or at a minimum, subconsciously get all loco with our code. Any responsible programmer would agree that there is a clear mathematical ratio between any given piece of software’s code loco-ness and that same piece of software’s level of stability. Unfortunately (for us), technology moves at a pace much faster than our ability to stay organized. Responsibility comes into play when we find ourselves justifying why it is that we want what we want, as opposed to just trying it out and hoping for the best. The tempting chaos with which technology presents us has the potential of complicating our code base to the quite literal point of application collapse. This is why, in my opinion, a single set of mediocre code is far better than a melting pot of the five greatest code bases ever. One’s code should reflect simplicity at its best.

I haven’t stated it explicitly, but the chaos within that often finds its way into our text editor most often occurs in the context of managing/developing a diverse set of applications. Of those who are in this position, only the absolute best and worst of them are capable of maintaining the goal of stable simplicity in this very chaotic environment. The best are responsible, the worst are just oblivious to the chaos that surrounds them. The application centric environment, however, provides the programmer the ability to delight in the slightly boring task of perfecting their encapsulated idea that is their application. There is little to distract the programmer from perfecting the thing in their hands. Only when it is understood that adopting code from the dark side will further push that application to its inevitable point of perfection does the application centric programmer flex the boundaries to utilize the unknown.

In the end, my days working on a wide expanse of applications at any given moment can be represented (metaphorically and quite literally) as having been written on a tabula rasa.  My current work within the confines of a single application with a single (albeit complex) driven goal is being written within the rules and restrictions of a framework.  The framework forces me to be conservative, and underneath it all I feel that 90% of the time that is right were I want and need to be.  On the other hand though, I recognize just how important expanding upon conservative technologies is, and how the freelancer is really the one who pushes the boundaries of programming.  As well, as in life, pushing the limits of what is appropriate are always the most exciting and ground-breaking moments.

I now better understand the seemingly great divide between these two.  I miss coding like a freelancer, but in absolutely no way miss being a freelancer.  Finding a healthy balance between the two has been key for me.  I miss pushing the boundaries, but am also passionate about perfecting the program.  And while I sometimes fondly look back on what it was like to make a split-second decision, I love understanding what I do.  While now I seem only capable of doing one or the other, perhaps at some point I will be able to push the boundaries of perfection.

While I’m no expert in marketing or advertisement I have spent the last year of my life developing applications directly applicable to the marketing and advertising world.  My job has certainly not been on the creative end of things, but I have been exposed to that area in having to work with those whose job it is to sell.  I’ll admit that I’ve kind of liked it.  It’s an area where a focus on user experience is as important as the raw functionality of the application itself.

It’s been interesting participating in and viewing the client-audience relationship and having to be the mediator between the two.  While clients fully understand their audience’s buying patterns they often have no idea what their behavioral patterns are.  The best clients in the business are those who understand that they have hired us to do more than just put together a technical application, but to research a market, understand that market, and build an application that is focused on and in tune with that market.  It’s here that I think things get most interesting.

Narrowing the audience allows me to be more creative with my applications because I get to build something that is much more detailed.  While this may seem to contradict the developer’s code of reusability, it also opens a new door for learning, expanding, and impressing.  I don’t feel forced into building an application that is broad enough to apply to anyone.  This I feel leads to applications that are boring, often cluttered, and just usable at best.  Many of the client’s that I have had to deal with have been willing to invest more money to get an application that fits their business model, as opposed adapting their business model to fit an existing application.

Beyond everything, it’s very important to remember, me especially, that the development is only a small part of the whole.  There’s selling the application, researching the client, understanding what the client is selling, understanding what’s most maintainable for the client, and of course meeting all of the client’s deadlines.  Then their is the consumer.  Who is the consumer, what will the consumer be trying to accomplish, and how can the application do 90% of that work for the consumer, and make the remaining 10% super fun?  Focusing first, not on which language and classes will be used, but on layout and the logical progression and flow of the application according to user expectations.  Understanding the designer, and how the application will run underneath a layer of HTML and CSS.  These are all new questions for me, and one’s I’m only learning to answer.  Beyond all the frustrations inherent in programming, and the constant suppression of telling the client that if they’re so confident that they can build it they’re more than welcome to, I’ve really enjoyed being forced to take an audience into consideration.  The web moves at a quick pace, hopefully I can keep up over the course of this year.

I thought I’d write a post about this topic since Adri and I have had a number of conversations concerning it the past week or so.  Templates, as I’m using it here is a reference to what is known as “cookie-cutter” websites, or those websites that you seem to see everywhere on the web with different colors and logos. I certainly have no intentions of dismissing templates, and as a developer I’m probably more ambivalent towards them than Adri who is viewing them through a designer’s eye.  Instead my thoughts are to be focused specifically on how the two types of websites compare and the uses of both.

(more…)