This is a very simple example, but i use it to highlight something else.
When we encounter a problem in programming, what is our first response? What is our first gut reaction versus what are the first steps we take to resolve the issue?
Our reaction is heavily dependant on our own conditioning and experience both with development in general but also with the technology in particular.
This topic has been in my mind for quite a while for several reasons. The most prominent is this:
Who do you blame when something isn't working?
Essentially there are 3 main sources of potential "bugs" when trying to debug one's code:
1 - Your code
2 - The other person's code
3 - The technology
Unless you are dealign with beta, CTP or RC software, you should look in the order above when trying to fix a bug. This is especially true in my position where most of our code is at a high level where syntax is more likely a problem than stumbling upon some obscure bug for some corner case.
Being a small shop that develops internal busniess applications we are relatively free to use newer technologies in order to brighten an otherwise dark and mundane day. Not all developers are on board with such an approach. Feeling relatively safe in their position doing things they have always done, they are reluctant to move to newer technologies and platforms. For them something new is more work not less. For them typing out 1000 lines of code is not an issue since there is no ultimate goal.
Me, I have youtue to check, people and articles to write, code to explore. I embrace technologies that allow me more free time with a better guarentee of performance. for me, the learning curve is built into project development timelines.
These other corporate coders can't see the ultimate payoff since for them, as each day passes, any learning curve becomes too steep to climb. Learning new technologies is not much different than running. If you run a mile everyday, that mile becomes easier and easier. If you never run, a quarter mile is daunting and the end might as well be 1000 miles away.
Learning new technologies not only helps you learn the technology, but gives insight on how to approach other newer technologies. You apply lessons learned form the learning itself.
The "meta" learning is what is at stake. The corporate coder who rarely ventures beyond his drag and drop world is quick to blame new technologies when they do not behave exactly as expected. They are quick to yell out "Well it doesn't work and there are alot of bugs." These developers know their little world so well, they project that level of knowledge to absolutely everything outside that world. If they can't figure something out, that thing must be broken or too complicated. It is important to prevent that stagnation.
What is the outcome of such a developer on a given project?
I recently had to work with such a developer and here were some of the outcomes:
The project used .Net table adapters for the data access layer. Without going into the pros and cons of the technology 3 of the 4 developers agreed to use this technology. The fourth developer eventually signed on (in words) to use table adpaters to access the data in the logic layer.
First Sign
The very first issue came when in a meeting he said what we were trying to accomplish was impossible, he had never seen it doone and doubt we could do it. What was the task? Create an XML files from the table adapter, read the XML in to a table adapter, insert into the database from the table adapter. This is far from even a difficult task nevermind an impossible one. Within 30 minutes I had a working prototye for him using our project. I had actually created prodeuciton level code in a matter of minues. I am not a genius, that is what table adpaters are used for. Serialized data can be easily transformed into strongly typed datatables, generic datatables or XML.
Second Sign
Everything was going fine. For most people, this is not a sign, but I knew if I wasn't hearing anything, aomething was going wrong. The developer then tells me there is no way to set the connection string at runtime. He had not done any research, he had simply not been able to find a first glance ay of doing it. He had always set the connection string in the same way. Since it apparently couldnot be done in the same manner it was impossible. Without even looking at the code I offered several possible ways to set the connection string. I was able to do this, NOT because I had mastered the technology, but because I had taken time to learn how Microsoft does things. There were just some basic technieus which were probably in use in the table adapters.
Third Sign
One of the strength of the strongly typed datatables is that hey allow direct access to the data columns as row properties. This increased performance by elminating looking up columns by string values. However, when I looked into this developers code he was still using row.item("columnName") as opposed to row.ColumnName. By refactoring out the old way and using the new notation, I increased performance 400%. He just didn't understand how there could be a difference between an in memory object and a lookup. Since he never had to learn, he just didn't bother to learn.
The final sign
This developer had one section of code where he had to do his own data manipulation. And guess what, he reverted to what he knew. I didn't bother refactoring this code because i didn't have time, I just added an abnstracted layer to make it work within the general framework. Sometimes you just don't have enough time.
To Be Continued....(this was getting too long)
No comments:
Post a Comment