RuGUI Framework Blog

In the past days I’ve been thinking about those two words: Developer and Programmer. Wikipedia says that a Programmer is someone who writes computer software, while a Developer is someone concerned with the developement process, somenone who architects the software, on a higher level.

Well, for me, the difference is more simple. What is a program anyway? It is a sequence of steps that should be followed to achieve a pre-defined goal, or to solve a specific problem. When you run a program it will always have the same behavior, in other words, it will do the same thing again and again and again. And what about Development? Development is the process of getting an initial idea and elaborate it, evolve it, so that it reaches its goal, in other words, solve the problem.

A programmer is someone who writes programs. A developer is someone who develops an idea, or a solution. This is an iterative process. First there is the idea (or solution), then you improve it, and you ask: “Is it good?”. The answer: “No”. So you improve it again, and repeat the question on and on until you are satisfied.

“When You’re A Hammer Everything Looks Like A Nail”. A very famous saying. But what does it has to do with Developers VS Programmers thing? Well, when all you see are problems, you tend to look (and fix) problems. Likewise, when all you see are solutions, you tend to look (and think) about solutions.

A developer should always think about the solution. The problem is there, he realizes it, he knows that. There is nothing he can do to change the problem. But he can, and will, find a solution for that problem. Focusing on finding the solution, he will often ask himself: “Is it a good solution? Can I improve it? Should I spend more time on it?”. Programmers, on the other hand, are easy to please. If they can solve a problem with 10 lines of bad code, why should they care if there is a solution that solves it using 5 lines of good, clear and simpler code? If they can write a single and huge method, why should they split it? Just because someone may want to use some of that functionality later? Bah…

Does it look good? Definitly NO!

Is not that every code you write is bad, but if you, the one person that has written it, do not have the nerve to judge it, who will? Maybe you could refator some method, or change the order in which you check for conditions in an if. Maybe you will just end up liking your code the way it is, and won’t change it at all. Nevertheless, you need to judge your code. If it is not good for you, then it ain’t good at all.

One of the greatest things about Ruby is its philosofy. Unlike other languages Ruby doesn’t oblige you to solve a problem with a single solution. For example, how can you get the size of an array? [].size. But you could also get its length [].length, or count how many items with [].count (for Ruby>1.8.7). For each context there is a solution that may be better than another. There is no single way to do it. There is the way that it is best for you. The one you like the most. And this could be applied to any language, not only Ruby. Ruby only makes this easier by given these options in its core.

The most important thing to learn here is that code is less written than it is read. You will write your code once, but it will be read many times, by many people. Thus when you write some code you should always put yourself in the place of those who will read it later. If the code is not clear, than you should make it clear. Don’t just go adding some crazy documentation trying to explain the mess you’ve just made. Try to improve the code, refactor it, split it into multiple smaller methods, give a better name for the method or variable. You will get a good, clean, easy to read, running code, and, who knows, you may even reuse some of those smaller methods later.

Just think about it, you want to be a programmer, somenone who just repeats tasks, creating code that no one understands, solving bugs that were already solved, copying and pasting code everywhere trying to make it work? Or do you want to make code that will last, not because it is mythical, but because it’s good? Do you want to take a list of tasks you should do, and just do them, like a machine? Shouldn’t you discuss it, share your ideas, improve the solution?

Be a developer, not a programmer!