Anyone can program, but, only some people will learn to program well. Some people learn to program well very quickly. These fast learners find ways to work with the concepts that build the systems of thought that software is. What causes one person to "get it" and another to "miss it" entirely?
There is an art to programming. You've got to keep it DRY, you've got to be terse but not too terse, you've got to be lazy in the right way. Some people get it in a short time while others never seem to understand programming. What magic formula of personality, intelligence, and determination makes the difference between those who learn to program and those who learn to program well?
What makes good software? What makes a good programmer?
I contend that Software is the encoding of thought and if I stick to my resolution then I must also contend with the implication that good software constitutes thought that is also "good" in some way. The idea of a "good" programmer therefore is anchored in the idea of "good" thought and that means that a "good" programmer must also be a "good" thinker and a "good" communicator.
Whatever "good" in this context means. Albeit the idea of "good" thought is a little subjective. The idea of a "good" communicator is also subjective. Some people would find Jeff Foxworthy a "good" communicator others no so much. Some would prefer me to use Lou Dobbs as an example of a communicator. Others would prefer Jesse Jackson. All three of these people I've deliberately chosen because they communicate well to each of their respective audiences.
The definition of the "good communicator" is dependent on the audience that the communicator is communicating with. Each of the three examples I've picked communicate with a group that each has their own definition of "good" thought.
The definition of a "good" programmer is probably just as changing depending on the three audiences that a programmer communicates with: the computer, other programmers, and the end-user. These three groups are radically different for different kinds of programming projects. Know your audience.
Just as Jesse Jackson's jokes won't play well on Lou Dobb's audience... and Jeff Foxworthy would not play well to an audience gathered for Jesse Jackson. However I am confident that all three of these men could prepare and change up audiences if they wanted to. They could each entertain the other's audience in a way that avoided real catastrophe... because all three of them are good communicators and know how to pick a message to suit an audience. It would be harrowing but I think any one of those men could pull it off.
With programming your device driver, database developer, and web designer don't play well against each other's audiences. A good programmer can learn the audience and play to it well. Because the good programmer is a good communicator.
2006-07-18
2006-07-06
Terseness is good
Your head can only hold so much. Even very simple problems can flood your mind and escape your ability to follow them if they carry on long enough. For example addition is quite simple but if you are asked to keep a running sum for hours upon hours you are likely to begin making mistakes at some point.
Programmers face similar problems with software. Many seemingly simple things can be made unnecessarily complex by allowing a block to run-on without bound. The non-technical analogy might run something like this:
Which response to a query is preferable?
It is most assuredly true.
Yes.
Programmers face similar problems with software. Many seemingly simple things can be made unnecessarily complex by allowing a block to run-on without bound. The non-technical analogy might run something like this:
Which response to a query is preferable?
It is most assuredly true.
Yes.
2006-06-29
Lingua XML
How do you represent data? How do you exchange data on heterogeneous networks? How do you share representations of data between systems?
Since the dawn of modern computing (somewhere back around timestamp 0000000001 at the dawn of the epoch) we've had different methods for representing essentially the same data. Whether it was little-endian versus big-endian or variations on floating point numbers we haven't had a single common way to represent data.
This was a problem that has been attacked from several different angles. One was standards such as the IEEE floating point standard. CORBA was developed to create Interface Definitions that were mapped to platform specific implementations across machines and networks. Another approach was to declare plain old text as a standard and process it.
The plain old text approach had problems, one of which was not endian issues. The plain old text approach lacked structure. Without structure interpreting the text between programs became a chore. The parsers were brittle breaking each time a slight change occurred in one program's output. So structured text was introduced... And after a few iterations of this we get XML. The real power of XML is its ubiquity.
Obviously, ubiquity isn't something a computing standard gets automatically. People have to agree to use it. For example in the world of international languages French was once "lingua Franca" an expression meaning universal language but literally meaning language of the Francs. There was an attempt to create a new universal language but Esperanto is little more than a curiosity in practice. It isn't universal if people don't use it universally.
Just because a project uses XML doesn't make it better. You can do terrible things with an elegant tool. XML just gives us a universal tool to work with. It may not even be optimal for some tasks. Things such as JSON work better than XML for the specific task of asynchronous server to browser communication. XML, however, will probably win in this arena just because its power is its universality.
Since the dawn of modern computing (somewhere back around timestamp 0000000001 at the dawn of the epoch) we've had different methods for representing essentially the same data. Whether it was little-endian versus big-endian or variations on floating point numbers we haven't had a single common way to represent data.
This was a problem that has been attacked from several different angles. One was standards such as the IEEE floating point standard. CORBA was developed to create Interface Definitions that were mapped to platform specific implementations across machines and networks. Another approach was to declare plain old text as a standard and process it.
The plain old text approach had problems, one of which was not endian issues. The plain old text approach lacked structure. Without structure interpreting the text between programs became a chore. The parsers were brittle breaking each time a slight change occurred in one program's output. So structured text was introduced... And after a few iterations of this we get XML. The real power of XML is its ubiquity.
Obviously, ubiquity isn't something a computing standard gets automatically. People have to agree to use it. For example in the world of international languages French was once "lingua Franca" an expression meaning universal language but literally meaning language of the Francs. There was an attempt to create a new universal language but Esperanto is little more than a curiosity in practice. It isn't universal if people don't use it universally.
Just because a project uses XML doesn't make it better. You can do terrible things with an elegant tool. XML just gives us a universal tool to work with. It may not even be optimal for some tasks. Things such as JSON work better than XML for the specific task of asynchronous server to browser communication. XML, however, will probably win in this arena just because its power is its universality.
2006-06-27
Competing Mental Models: Object-Relational
In order to deal with complex issues, humans create models. The models we make deliberately ignore certain aspects of a real-world "thing" we deem as irrelevant. In this way we simplify a more complex problem enough to deal with it.
For example, when you try and solve the classic "If train A leaves city 1 at 8 am traveling 60 mph and train B leaves city 2 traveling at 40 mph at 8:30 am and the cities are 100 miles apart, when will the trains pass each other?" You ignore many facts about the trains, the cities, and train travel. How big are the trains? Was it raining? Did the passengers enjoy the ride?
In mathematics we have various models of the universe (sometimes called maths). Each new type of math has its own symbols and rules. Different kinds of math we find our selves using in computer science include graph theory and set theory. These different views of the world have generated different paradigms of computing that can compete with each other in the mind of the programmer.
In particular, I deal with (on nearly a daily basis) the competition between the non-complimentary techniques used in modeling data for Relational Databases and Object Oriented Programming languages. The term for this mental conflict is called the Object-Relational impedance mismatch.
I've observed this mismatch to yield some pretty strange ideas in the heads of my peers. I've seen designs that match one table per object with inheritance declared illegal because you can't model it "properly" in a database. I've seen developers completely ditch the concept of a database in favor of "pure" object designs that persist data in either serialized files or XML. And, I've even heard of doing away with Objects entirely in favor of "Data Oriented" designs.
If the model makes for more complexity than it solves... isn't it a bad model? At the end of a long day, it appears to me that the problem isn't in our heads it's in our languages. What our languages can communicate molds in part what our minds can model.
For example, when you try and solve the classic "If train A leaves city 1 at 8 am traveling 60 mph and train B leaves city 2 traveling at 40 mph at 8:30 am and the cities are 100 miles apart, when will the trains pass each other?" You ignore many facts about the trains, the cities, and train travel. How big are the trains? Was it raining? Did the passengers enjoy the ride?
In mathematics we have various models of the universe (sometimes called maths). Each new type of math has its own symbols and rules. Different kinds of math we find our selves using in computer science include graph theory and set theory. These different views of the world have generated different paradigms of computing that can compete with each other in the mind of the programmer.
In particular, I deal with (on nearly a daily basis) the competition between the non-complimentary techniques used in modeling data for Relational Databases and Object Oriented Programming languages. The term for this mental conflict is called the Object-Relational impedance mismatch.
I've observed this mismatch to yield some pretty strange ideas in the heads of my peers. I've seen designs that match one table per object with inheritance declared illegal because you can't model it "properly" in a database. I've seen developers completely ditch the concept of a database in favor of "pure" object designs that persist data in either serialized files or XML. And, I've even heard of doing away with Objects entirely in favor of "Data Oriented" designs.
If the model makes for more complexity than it solves... isn't it a bad model? At the end of a long day, it appears to me that the problem isn't in our heads it's in our languages. What our languages can communicate molds in part what our minds can model.
2006-06-23
Programmer = Communicator
I think it was Mitch Roth whom I first heard say,
The programmer communicates their thoughts and ideas to both the machine and the other programmers who read their code. If your comments and notes don't leave a clear picture of what your code does and what it was intended to do, then you have failed as a communicator. If you are clear about your intentions and vision then you are more likely to have success.
"A good programmer is a good communicator."I took MIPS assembly from Dr. Roth and he would grade our assembly not only on coding content but also on the grammar and spelling in our comments. Whenever students would complain about how this wasn't an English class but an assembly language class he would repeat the above quote. "A good programmer is a good communicator" was a common mantra at my university.
The programmer communicates their thoughts and ideas to both the machine and the other programmers who read their code. If your comments and notes don't leave a clear picture of what your code does and what it was intended to do, then you have failed as a communicator. If you are clear about your intentions and vision then you are more likely to have success.
2006-06-22
Lingua
If the language you speak in part constrains your thoughts, then isn't the same true for languages you code? If the language you speak can facilitate certain modes of thought, then isn't the same true for programming languages? Are there thoughts impossible to think in English that you can think in a programming language?
The computer is the first technology to act upon thought outside of a human mind. These thoughts are not the same as what the "analog" thinker thinks. The act of learning to program is transformational and forever alters the way that the student thinks about things. The thinker becomes a digital thinker.
The computer is the first technology to act upon thought outside of a human mind. These thoughts are not the same as what the "analog" thinker thinks. The act of learning to program is transformational and forever alters the way that the student thinks about things. The thinker becomes a digital thinker.
2006-06-21
Software Engineer
Somewhere along the line we created the position of "Software Engineer" and distinguished it from other software roles such as Programmer, Developer, and Architect. Somewhere along the line we got the idea that software should be engineered.
This seems to me that the Software Engineer is an engineer unlike any other. Instead of having a physical world which will respond as expected or clearly not the Software Engineer must shape thought itself into a disciplined structure. The material that is to be formed, welded, shaped, beaten on, or engineered is the minds of all the people interacting with the software.
What is a Website? A Torrent? A Blog? Or an Instant Messege? How are they different? Why do we care? These ideas are the stuff of the Software Engineer, the raw materials of the builder of castles in the air made of air.
The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.-- Frederick P. Brooks Jr.
This seems to me that the Software Engineer is an engineer unlike any other. Instead of having a physical world which will respond as expected or clearly not the Software Engineer must shape thought itself into a disciplined structure. The material that is to be formed, welded, shaped, beaten on, or engineered is the minds of all the people interacting with the software.
What is a Website? A Torrent? A Blog? Or an Instant Messege? How are they different? Why do we care? These ideas are the stuff of the Software Engineer, the raw materials of the builder of castles in the air made of air.
Subscribe to:
Posts (Atom)