Reading through tech blogs and articles around the net I see various topics from TDD.NET to structuremaps to specialized frameworks to augment other frameworks that were suppose to make things easier to begin with. Taking a minute with a few of these blogs I understand the logic, but unless you deal with that proprietary and often cryptic super specialized system, is it even worth reading let alone the blogger posting? Lets talk about it here in this entry of the Programming Underground!
I have always been a firm believer in the idea that through coding practices and standardization we would ultimately achieve that one unifying language or technology out there that would unite all devices from handhelds to laptops to the conventional desktop. Your ipod would notify you when in proximity to a music store’s wifi advertisements of their latest free music. That the hearing implants for the deaf would tune itself to not only hear but actually digitally correct the sound to dolby surround sound 14.2.165 and maybe pickup wireless RSS news feeds.
But have you ever surfed around a few blogs and seen what is being talked about and “put out there” for public consumption? I think many techies have strayed away from the idea that blogs are not only suppose to be informational, they are suppose to be written to be consumable by the average programmer at the minimum, and the average person at its best!
I am beginning to believe that programmers are actually moving further away from one another by becoming too specialized. They then make no effort to share with everyone how they got to point B from point A. This leads to blogs which make several assumptions…
1) The reader followed my conclusions, my discoveries, and my development from the beginning when in fact this is the first time they stumbled across my blog.
2) If the reader wants to learn about it, they can go look it up on the Internet. Problem with this is that sometimes these developers are working for a company who is pioneering a new area of computer science and that is not widely known outside the company the blogger/developer works for.
3) As pioneers they often jump forward in their code, make assumptions about their next step and when they reach the end result believe that the only way to get to that end point was through the path they blazed. Then then proceed to make up their own lingo for the steps they took, draw conclusions based on what worked for them not necessarily why it worked that way, and that since their stuff does work it is their right to set the standard of how things will be done. There is more than one way to climb the mountain.
Instead of doing the work needed to document as they go, analyze the steps they took, figure out why things work the way they do, they just layout their projects on their blog and say “this is how it is done”.
So here comes the average programmer, talented, knows a bit about programming and the principles behind the language and lands on a specialized blog. “What is this? Let me take a look. I understand a bit of the code, but unfortunately I have no clue what this name represents. I can’t relate, I am outta here.”
Out of 100 programmers who may land on a blog, how many of them are going to have the faintest idea, or even care, that you were able to get your proprietary specialized framework to iterate through IIspect interfaced objects twice as fast as before?” Unless you worked for the company itself, how are they even suppose to know what you are talking about?
As a rule of my blogs I try the best I can to do five things…
1) I try to explain what it is I am doing and I am trying to accomplish.
2) I try to classify the post according to a theme that can relate to the user. Like putting the more simple topics in a “basics” category or put a more theoretical piece in “programming theory” so that the user can dig as deep as they can go and relate what they know to what is being discussed based on their own skill levels.
3) I try to go through the examples with a fine toothed comb to explain what is what and why it is there.
4) How might my examples improve on solving the problem? How it is not the only solution? How might it be customized to meet a variety of similar problems? By relating it to others we draw the two of our ideas closer to achieving something that works.
5) Assume the user is brand new every time.
Number 3, 4 and 5 are the key to solving this tech blog problem I believe. If you explain yourself, relate it to what else is being done, and assume the user is new and needs to be brought up to speed we strengthen tech blogs. We do not simply throw them out there, we also teach.
If all these tech blogs did that perhaps it would be easier for the techie doing the ipod blog to teach the techie doing the music store wifi developer how the ipod standard for a wifi signal would work so that they can eventually be merged together into a solution. But until that day comes, the music store developer will see the ipod standardization development, not understand it, get lost and eventually create a blog about his music store development standard that the ipod developer won’t understand. He might even go as far as recreating some of the same functionality!
I guess that is where people like me fit in. Half the time developers like myself are hired to bridge the gaps between the developers who don’t talk to one another and develop separately. Don’t we do that on the DIC boards? Bridge new programmers projects to the development technology already out there in development to come up with a new solution? It is a lonely life in that I have to learn the ipod developers logic, the music store developers logic and THEN find a way to get them to work together.
I shouldn’t have to do that.
Thanks for reading. 🙂
