This post was in my “drafts” for some time, and yesterday after the “final class” panel of the Reversim 2013 summit, I decided it was time to close it up.
It all started while trying to explain to my wife what I’m doing in my PhD research. Some background: my wife is a Chemical Engineer, works in quality and reliability of semiconductors, and is very, VERY smart and tough. She is the kind of person who always asks the difficult questions that make you think, and think, and think. So I sat there, trying to explain to her that I am creating a visual programming language based on the visual modeling methodology that my advisor created (the Object-Process Methodology, aka OPM).
“So why is this language better? Everyone programs in C/C++/Java, etc. Why a visual language?” she asked. And really, why do we need another programming language? what problems will this language solve? but before this, what problems do we have? I had to think this one out a bit. Why am I doing this (“Just for the fun” is not an acceptable answer, although it is one of the reasons)? This made me think… about what is a programmer.
So, what is a good programmer? A good programmer is someone who knows how to solve a problem. By problem I mean requirements/desires/expectations/bugs/needs/whatever. A programmer knows how to take a problem definition and analyze it. He divides it into small pieces and tries to find which of them are trivial and which are complex. He knows how to zoom into the parts of the system that need this zoom-in, but knows when to stay on the broad level when not needed (Thanks to Harel for this idea). And he knows his toolbox; He not only learns Scala/Python/List/Ruby “just for the fun”, but because this usually helps him find better solutions to the problems he has (or to future problems). He is not expected to carry all of his tools around (because it’s too much weight to carry), uses the common tools to solve the common problems, and searches, learns and uses special tools when the occasion arrives. He reads RSSs and listens to podcasts because they maintain him updated with new and developing technologies that may later help him solving problems faster/better. He does TDD not because it is the latest fad, but because he sees the value of TDD in his problem-solving process. And when he sees no value in TDD, he doesn’t do TDD. Same for pair programming, BDD, and other buzzwords. He knows enough about the business model of his company to prioritize between maintenance, new features, algorithm improvements, refactoring, and others (Thanks to Yaki for pointing this out). He uses continuous integration and deployment because he understands its value.
And he is pragmatic and passionate. Pragmatic because otherwise he would never stop researching new technologies and improving his solutions, because they can always be improved. And passionate because otherwise he wouldn’t invest his time in new technologies, new platforms, new paradigms, new tools.
This, IMHO, is not a good programmer. It is a GREAT programmer. It’s the kind of programmer I would love to work with and to become one day. And it is very hard to be one. It takes time, it takes patience, it takes energy. And that is why he needs passion.
So how it this connected tho why I’m developing a new programming language? Because I think in some cases (not all, but many of them) visual programming can help us create a better solution to our problems. This is what I think, and I don’t have any proof. But “just for the fun” is also part of the answer. But I can sleep with that.
And once again, thanks to Ran and all the people and companies who made the Reversim Summit 2013 possible.