Constantly learning is important. Lots of disciplines today change at an extremely fast pace. Software is definitely one of those fields. As we learn new things, we try to integrate them into our existing mental frameworks. We think of different areas where we can apply this new knowledge, or if it can be used to simplify any existing solutions. I for one am constantly trying out new frameworks or languages by thinking of apps I can write with them :)

There is a caveat here though, particularly with newer programmers. Right after learning a new pattern, we have the propensity to use it more than we should. We force it to fit our problems, usually by throwing more patterns in the mix. The code ends up being far too complex for what it's supposed to be doing, and it's much harder to follow what's actually going on. In short, we end up with more complexity and less flexibility. That sounds like what we were trying to avoid in the first place.

Programmers also tend to get emotional and invested in their solutions. Admitting that we took the wrong path is hard to do. Software is the kind of thing that doesn't really have just one answer; we can solve our problems with just about any language or technique. Some are obviously better for certain problems than others, but just about any of them can be *made* to work. This brings me to a quote:

xml is like violence. If a little doesn't work, just use more of it.

I've got more quotes about xml, but I'll save those for another day :)

We all have our own opinions on what kinds of software or tools are useful, and many of us have very strong opinions on these matters. My opinions here tend to change on a daily basis :) But even though we don't like to admit it to ourselves, virtually every approach has its own tradeoffs. In fact, I'd go so far as to say that most of programming is just a series of tradeoffs.

The important thing is to use the best tools for the job. Having lots of opinions is healthy, and it only really becomes dangerous when we fail to consider other options. Bad options are valuable to us too, because they help us focus on what really *is* important.

Perhaps what's most striking is the fact that our problem solving methods in the software world are sometimes backwards. We have a list of solutions in mind, and we try to see which one fits the problem. From one perspective, this is completely natural. How are we supposed to think of solutions that we don't know of yet? But on the other hand, none of our pre-canned solutions may be a good fit at all. In this case, some research into the problem space may help clear the muddy waters and reveal better alternatives. But how do we know if this is necessary, and we're just not wasting our time? Well, I like to follow the mantra that if it feels like there must be an easier way, then there probably is. In any case, taking a step back and looking around again can be a healthy thing. After all, times change, perhaps faster now than ever before. Yesterday's pitfalls can become today's best practices.

When all you have is a hammer, everything looks like a nail.

Programmers and learning

February 18, 2009
May you live in interesting times

Never before has access to information been so easy, and so readily available. And we're starting to accumulate more and more at an incredible rate. What's more is that we are are able to summon information virtually instantaneously. But ironically, too much information can also have the effect of preventing any useful information from getting out. In addition to having a wealth of information readily available, we're also forced to filter out the noise to find the gem in a haystack, if you will.

But if we find ourselves constantly filtering the same kind of information, computers can help us here. After all, they're good at repeating tasks over and over again. And here is where programmers have a significant advantage.

Programmers can improve their rate of learning.

In particular, programmers are able to improve their workflows. They're trained to recognize repetitive patterns, and can make tweaks here and there to help things along. But when you can take baby steps quickly, you start to move fast.

An example that comes to mind is the tool for os x: quicksilver. If you're using os x and you haven't checked it out, you really should. If you're running gnome, gnome do provides similar functionality. These tools let you express the action you're trying to perform more naturally, almost in the form of a sentence. But command line users have enjoyed this richness for a while now. This is an example where the programmers are ahead of the curve, but it's good to see that there are efforts to help out the "less fortunate" :P

Throughout your life advance daily, becoming more skillful than yesterday, more skillful than today. This is never-ending.

When faced with a new problem, we start thinking of the different approaches we can take to solve it. We look back on previous experiences, and see if we've solved anything similar in the past. If so, maybe that same type of solution can be applicable to the current problem. If not, maybe it can be adapted. Pattern recognition can be a powerful tool to help us solve problems.

But with our previous experiences come our own biases as well, directing our trains of thought. If my previous problems all had a large focus on security, chances are high that I'm going to be keeping security in the back of my mind. While this is beneficial for preventing security holes, it can also work against us if I try to inject sophisticated security mechanisms when they aren't needed, just in case.

It's important to remember exactly what we're supposed to be building. Who is it for? What are they going to be doing with it? Is this new feature going to help? Is it necessary? The more frills we add on, the greater the chances that the motivation for what we're doing will be lost. Programmers can have a tendency to make things more complicated than they have to be.

At the onset of a project, this is easier to keep in mind. But as time goes on, we keep our heads deeper and deeper in the details, and we can lose the forest for the trees. We add tweaks here and there, spend some time on peripheral tasks, and then get caught surprised wondering why it is we're so far off mark.

It's important to note that what we're building can change over time. In fact, if it's a long project, it probably should change. If not, what we're building may no longer meet its demands.

So when we're lost, we should remember to take a step back, take in a deep breath, and ask ourselves what we're supposed to be building.

Ask a programmer to hang a picture frame, and you'll get a new wall instead.

Beauty vs Practicality

December 25, 2008

We can see software development as a duality with beauty on one side, and practicality on the other. Beauty is coming up with a masterpiece of a solution. Practicality is solving our problems with methods that are known to work. These don't have to be mutually exclusive, but they usually feel that way.

The advantage of the practical solution is that we know it will work. We've usually employed it in the past, and we're confident with it. Examples of brute force methods come to mind, although they don't necessarily have to be. The practical approach is particularly appealing to business, which almost without fail tries to avoid the worst possible scenario. Regardless though, we know we will end up with a working solution in a fixed amount of time, and not just with only scribbles on a whiteboard.

The problem with this is that things can get difficult to work with after a while. Like trying to find something on a messy desk, it's always easier to quickly go through the mess. But if we repeat this several times, then it's better to organize the desk appropriately first.

Finding an elegant solution can mean modeling our needs as a specific instance of a more general concept. We can also try to fit our needs into a pattern by thinking about them from a different perspective. Generally though, I think elegant solutions share the fact that they make our problems look simple.

Looking simple is key. When things are simple, we are able to have many more ideas freely dance about in our heads. Merely keeping complex ideas in our heads can be difficult, let alone finding ways to extend them. And at this rate, we can forget about debugging.

But beautiful solutions are more than just simple. They are a set of neat abstractions, naturally joined together. Each addition compounds on the previous, magnifying the strengths of the whole with a new dimension of power. This continues until the problem itself looks feeble in comparison, like it was created as a reaction to the solution.

Unfortunately, it's difficult to create these problem slayers. Our problems usually hide in dark corners, only revealing themselves at inopportune moments. It's only then that we realize that our methods are inadequate, and sometimes it can be hard to adapt them. It's at this point that we often see the obviousness of our shortcomings. But of course, it's always easier to predict the past than the future.

In the end then, we need a healthy mix of both beauty and practicality. We need to cultivate our magnificent visions, while listening to the sobering voice of reality. As Alan Kay said:

Just play it grand.

PHP - language of the web

November 26, 2008

Currently, php is the most popular language on the web, popular here meaning sheer numbers. There are number of reasons for this, some of them obvious in retrospect. But then again, a lot of things are obvious in retrospect.

Php is easy to get started with. I think this one most of all is the biggest reason for php's popularity. In its simplest form, php is just a powerful templating language. We can take some html, sprinkle in a couple of php tags here and there, and presto, we have ourselves a dynamic page.

Php is easy to deploy. This almost goes hand in hand with php being easy to get started with. Most web servers are already php enabled, so chances are good that things will "just work" for us out of the box. If they don't, php's popularity virtually guarantees that the solution will be easily found online.

Updates are easy to see. All we have to do is save a file, and reload our browser. As a programmer, I can really appreciate this one, since I'm used to having to restart a process and waiting for it to come back up before I get feedback.

It's easy to find somebody that understands php. I can say this for anything that's really popular currently, so it's not something that's specific to php. What php has going for it here is that there is a low barrier to entry, making it easier for a programmer to quickly learn php without having any previous experience.

If I were to sum up php's downside then, it would have to be its ability to scale in terms of complexity. Most changes are made in an ad-hoc manner, with little thought for the whole. With respect to systems, this is the wrong approach. We want the overall system to have a strong foundation, and have the individual pieces be the ones that take care of their own messes. Php emphasizes getting the individual pieces working, and they often have to know about each other's internals.

For simple systems though, this doesn't matter. If we're just building a doghouse, we don't need to spend the time thinking about having a strong core, because we won't need one. If we just slab things together, it'll hold. We only run into problems when we use this approach to build a skyscraper.

That being said, I think most sites on the web are simple. There's a way to put new data in, a way to control what gets displayed, which could be through a search or not, and maybe a custom workflow for interacting with the data. It's often the case that building up these small pieces from scratch is faster than trying to fit them into the context of a larger system.

Even for more complex systems, there is a benefit to prototyping a naive solution, and seeing where it breaks down. Sometimes it's not where we expect, and this information becomes tremendously valuable when trying to design a more robust solution.

There are attempts to overcome php's shortcomings too. There are many php based frameworks and content management systems out there. Each one of these makes certain separations for you, like MVC, to help ease the burden of maintenance.

There's no denying that php does some things well. After all, millions of web sites can't be wrong, right?