Software Development

For a long time, I thought I was different. And I am. I could not find other programmers like me. Before I get to that, I should mention another kind of programmer that I've yet to describe. I've only met one of them. I won't mention this person by name because it's unnecessary. But I found it fascinating that I've met many architects, but never this one specific kind of programmer again.

This person could think up ideas and concepts on how to build something or how to solve a problem. But not at the implementation level. It was always in terms of concepts and strategies. I really liked this because I'm particularly good at taking ideas and concepts and turning them into practical solutions. Given enough time, he could do it too. It just struck me as odd that his strengths were concepts and implementation, but the bridge in between was not as strong.

Now, I'm not talking about thinking up solutions to problems and then implementing them. That's a user programmer. This is about creating patterns and strategies. Concepts that can be applied to a wide variety of situations and more specifically to the one we're trying to implement. But converting a pattern into a usable programmable tool is not so easy. Just writing a library isn't easy. And this guy could think up patterns like no one else. Why aren't there more people like this? I've since met architects that can build extensible foundations. But I've yet to meet someone who can think at such a high level. I think I'm the better for it having seen this side of programming.

So as scarce as I believe architects are, the visionaries are even scarcer than this. The user programmers permeate the programming field. They see a problem. They want to solve it. But solving their own problems seems to be a no-no. Become an architect for once. Think of something that would help YOU as a programmer and then implement that. Oh crap! You're gonna have to learn real programming, eh? You're gonna have to build something and have to come up with your own requirements? This is what an architect does.

The next step up is seeing beyond the immediate needs. It's about seeing similarities in places that you wouldn't normally think there were any. It's about building concepts and strategies without being locked into any specific implementation. This opens up new doors that you can explore. You can't do that if you try and solve one particular problem using one particular implementation. If you try to go to India from North America in a car, well, without removing the car implementation, you're gonna have a tough time.

I used to think that visionaries (thinkers or dreamers) were a step up, but this isn't strictly true. They are actually in between architects and user programmers. They see patterns in design that should be used as a tool for user programmers. They may not know how to make the transition from a concept to an implementation, but properly explained these ideas can be implemented by an architect so that the user programmers can use them.

So I think programmers deserve different titles. Most programmers are users. It's like a game. Here's a problem and they'll fix it. I have to be honest. After a while, this is awfully boring. Not just boring. I want to bang my head against a wall because this feels so much better than fixing other people's problems.

If you've never written something to make yourself a better and faster programmer, then you're not a developer. Unless you've written your own parser (a real one like LL, LR or at least LALR), compiler, custom editor w/ tools (or plugins), IDE or anything else that makes your life easier as a programmer then you're not helping the field. You don't need to succeed either. You just have to try. Because you know what? When you go out there, you will understand these concepts. I honestly believe that if you understand how to manipulate data and the concepts behind code generation as well as making your life easier, the rest is chump change. You will understand how to create your own requirements. I am fascinated at how horrible programmers are at this. If you can't produce your own requirements, how can anyone expect you to solve anyone else's? You wouldn't understand where these requirements come from in the first place. And if you understand code generation, then you're ahead of the game because everything else is built on top of these concepts. Well, a good chunk of it anyways.

Just to brag, I've written LL, LR, LALR parsers (and generators). I've written a LR(1) parser generator. Just to be extra twisted, since the grammar itself needs to be parsed, I wrote a grammar for the grammar. I used this as input to my LR(1) parser generator and produced an executable that could read in a grammar. I then used this code inside my LR(1) parser replacing the old grammar parsing code. So now, you can replace the grammar syntax. This is the kind of thing user programmers really like. Down to the nitty gritty details. I find some satisfaction in stating that my LR(1) parser generator generated some of its own source code. I've written a non-recursive, backtracking regular expression parser with backreferences here. I've never seen one that wasn't recursive, so I wanted to learn about what would be involved. It's kinda messy in parts, and it has to be because you need to simulate the stack that is automatically handled for you when using recursion. I've written a conversion application from Intel obj format to my own custom one. I've also written a CodeView debug file creator for Borland C++ Builder's map files. Very useful when you want to use Windows debug libraries. I've also written my own 386 assembler. That's a compiler. It outputs my custom format I spoke about. Today, I'd use Intel, MS or COFF files since there are existing tools. I plan to keep this an option for Project V, my new development environment.

Then I think about an example I gave a while back about asking a friend to implement something that holds 2D walls and he couldn't do it. And in the articles from Reginald, he has the FizzBuzz problem. If you want to deal in concrete, I can deal in concrete. But how can you not know FizzBuzz? As others have mentioned, it's funny seeing wrong solutions. The difference between FizzBuzz and the examples given above is that the ones above require the programmer to think in higher terms. You have to produce tools for others to use. You have to give them data structures and other programming idioms in your programming language. You have to enable people to produce their own grammars and implementations for the action routines. In each of these cases, the user comes first (those darn user programmers I spoke of). The implementation doesn't get first billing as it does with problems such as FizzBuzz.

So if a 'programmer' cannot do FizzBuzz, then I agree that this is a no hire. There's nothing about FizzBuzz that you shouldn't know. As mentioned, the only problem easier than this is counting from 1 to 10. And still some people can't do this. Man, I'm in the wrong part of the world. Actually, I'm not sure I want to be in places where this is common.

I always thought that the most wanted programmers were the ones who could handle providing good user interfaces. I think programmers are really uncomfortable with this. If a programmer is able to handle FizzBuzz, I'd want to know that they can handle user interfaces. Not just visual ones, but at the code level. I want to know that they can write code that others can use. I truly believe that most programmers have a fear of biblical proportions when they have to tackle these kinds of problems.

The simplest example might be an expansion of the FizzBuzz example. Write me a function that does what the original FizzBuzz problem asks. But it returns the string and takes as input the range of numbers as well as a list of pairs specifying the multiple and the word to print. Here, they have to provide the simplest of interfaces called a function. I can already see people asking how the pairs should be stored and how to specify the range. You're the designer. You decide. User programmers aren't used to this, yet it's still in the user programmer realm.

I've mentioned examples of what I do to expand my knowledge. Ask yourself what you do. What's your way to improve? Do you do anything beyond learning new languages? Do you do that much? Solving problems is one thing. Advancing our industry is another. Just having better programmers will do untold benefit. We will get more respect and more credibility as a profession.