Friday, April 17, 2009
Monday, April 13, 2009
Knowledge Work
Thinking about the similarities in what every knowledge worker does, it seems that we all do the same things, just in different realms. We all think, create, examine, refine, over and over. How does one, then, break into a different application area? How is managing the state of world politics any different than writing good software? Good software is robust in a changing environment, considers a functional set of requirements, delivers demonstrable value to the stake-holders. Are these not all qualities of a foreign affairs official, a sociologist modeling the world, a medical researcher, etc?
Wednesday, March 25, 2009
Tell me anything and I'll believe it
Perhaps the "tell me anything and I'll believe it" facial expression of Barbi was a means to break down the "barrier to entry" between men and women. That is, if the woman is brainless, then there is no competition between male and female: the male is obviously the dominant one.
Male dominance has been perpetuated in our society, certainly, by many things. Perhaps the doll contributed to it in this and other subtle ways.
Male dominance has been perpetuated in our society, certainly, by many things. Perhaps the doll contributed to it in this and other subtle ways.
Tuesday, March 24, 2009
When to rewrite
Analyze complexity of working with existing code. If you can write a simpler solution in less time than you can debug the problem, do so.
Sunday, December 28, 2008
Code: under, over, seasoned developer
So, I was recently told by a friend that someone has developed three phases of growth for a software developer: under-developer, over-developer, seasoned developer. The first goes for the most obvious solution without regard for tomorrow, the over-developer has learned this to be bad and is now creating hugely too complex solutions to compensate for every possible scenario, the seasoned developer knows exactly how much complexity to introduce at exactly the right moment.
I have decided that I don't like these descriptions, mainly because I don't know how to evaluate myself with respect to them. So I've come up with a different scale: implement solutions which account for the farthest you can see into the definite future, and no further. If you have a nail in your tire and are loosing air at a rate such that it will be flat this time tomorrow if you fill it up now, and you have nothing else which you are required to do today, don't just put air in it and wait until tomorrow. Take it to the shop. Now, if you do have things which demand your time today, then put air in it, and make a note somewhere reminding yourself and anyone else who may drive the car that the tire's going flat.
I have decided that I don't like these descriptions, mainly because I don't know how to evaluate myself with respect to them. So I've come up with a different scale: implement solutions which account for the farthest you can see into the definite future, and no further. If you have a nail in your tire and are loosing air at a rate such that it will be flat this time tomorrow if you fill it up now, and you have nothing else which you are required to do today, don't just put air in it and wait until tomorrow. Take it to the shop. Now, if you do have things which demand your time today, then put air in it, and make a note somewhere reminding yourself and anyone else who may drive the car that the tire's going flat.
Labeling code portions
Every portion of an object should be notated with how good the creator believes the implementation to be. This allows the most minimalistic implementation possible to be used on the first cycle, while leaving a notice about how good of an idea it is for another developer (or the same developer) to use it as a basis for other features.
Thursday, December 25, 2008
functionalism in programming
The problem with most imperative programming languages is that there is no formal definition for the relationship between methods. Within one method, another is called, but the calling of the second method occurs in a way such that the formal definition of the calling method does not include the second method call.
Subscribe to:
Posts (Atom)