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.
was a book that had a great impact on my view of programming. I read it after having programmed for 6 years, and the book just put names on so many things I had felt and done during this time. It was like the time when I was studying my B.Sc, I had a good friend who was really interested in the same topics as me and we would discuss theoretical computer science on my terrace all night. I read this book and understood that I was not special, (some would say this is bad, but I think it is actually good not being special) there are many programmers out there that feel that things are not right and we should start changing how we work (a favorite from the book is “
. I have to say that although the book is really good, I was a bit disappointed. This book is less about technology and more about a state of mind. More philosophical than concrete. More about business and less about the art of programming. I don’t mean to say that the book is bad, but it is not a book about passionate programmers. It is a book about programmers that want to grow, love what they do, earn money doing it and be happy. Many of the themes proposed in the book are relevant for all fields of work, from music (the author is a saxophone player) to many kinds of entrepreneurship, to being a good engineer in many fields, and even outside engineering most of the book is relevant if you want to be better than the rest. I would rename it to “the passionate career person” or something like that. There are people out there that are passionate about programming regardless of pay. Think 
. But seriously, the book has many good tips for any person who is passionate about what he does, and for programmers there are even more guidelines on how to improve your career, get the job you want and earn better.
the following quote (attributed to