There Are No Absolutes in ProgrammingDecember 04, 2011
Lots of people have strong opinions about programming. Some people even have research to back up their opinions. Even more people know someone whose opinions about programming they believe. The internet is full of articles by people with opinions about programming.
In the end however I don't think there are many absolutes in programming, if any. Absolutely your opinion may be different.
Program long enough, and you will hear lots of people, even really smart people with more letters around their names than you can count, tell everyone how something will improve their programming ability or results if they just do whatever they tell you to do. Then, after a few months or years, you will hear lots of people, etc. Often the same people have a new opinion.
Of course in the arena of programming, evolution of ideas is a constant (yes that is a pun of sorts). With so many people writing so much code, figuring out how to do new things in a an ever changing world, and in the relatively open universe of the internet, new ideas come rapidly and are often disseminated widely.
Every day I read a number of websites to see what's new and what people are talking about. When I started programming professionally in 1981 I read magazines and whatever journals I could find. Learning new things was pretty laborious but with enough effort you could see what was new. Then you could experiment a little and maybe see what might work. At my first job we constantly got "training" which was usually some vendor selling a "better way to program" which inevitably failed to be anything but snake oil. People promised revolutions but generally all that changed was a few hours away from work.
Today the problem is more filtering out the massive amounts of new ideas and evaluating them somehow in almost no time. I can read 50 articles a day and somehow be able to decide what works and what doesn't? Not possible. How can I really be sure that doing X will actually improve my programming quality or results or productivity? Or how about Y? Maybe if I do the whole alphabet all my code will write itself?
The issue with so many ideas is that they come from other people whose situations may not even vaguely resemble mine. Their experiences in writing code were probably very different than mine. The type of applications they have written with X may bear no relation to what I have worked on. The work environment could be totally different. The difficulty is trying to take ideas from a specific "universe" and making them be universal. Unlike say digging ditches with a shovel, programming is not and likely will never be a universal activity. It is so hard to define what programming is when you try to compare people maintaining 40 year old Cobol programs, writing first person shooter MMOs, building websites or coding device drivers.
For every good idea that someone believes is the key to better programming you can always find a different opinion. Waterfall or Agile or Lean or Scrum or Kanban or Scrum-ban or something came up yourself that works for you? Do you Test First, Unit Test, Assert or test some other way? Language? Frameworks? Argue about brace styles? Everything valid and useful and productive in how you go about producing results may suck horribly for someone else. I may write high quality code in a way that you might produce crap with and your way may cause me to leap off the nearest bridge.
That's the problem with arguments about programming: it might be useful to understand how other people do things but you still have to evaluate their approach in your situation. In the end being able to evaluate what you do and how a different approach might help/hurt is probably more important than anything you read by itself. That assumes you are willing to check out something new or at least consider it: being set in stone usually gets you run over by the technology steamroller. The opposite can be true as well: jumping on every new idea may make you unable to do anything right.
The one thing you can't be is be intimidated by other people's opinions that somehow each one is truly the answer. Even when reading a journal article by someone with enormous experience and high education backed by scads of research you have to be both intrigued and skeptical. Remember that programming is not gravity where the science might be pretty well understood (and even there scientists argue a lot).
I've always written good code, shipped high quality products to customers and tried to ensure that anything new I did did not lower the level of quality I expect. Some principles have remained fairly constant over my career and others have changed dramatically over time and I incorporated new ideas.
For example I read about object orientated programming (in Byte, the famous Smalltalk issue) and then wrote some object extensions to C when I started Deltagraph. This was before there was a C++. Sure, I got some of the ideas wrong, but I saw immediately that it solved a problem I had, how to build multiple output formats from a single graphic engine (namely internal format to Quickdraw, Postscript and Illustrator format). Primitive though it was, it made it easy to write and became the most important feature of Deltagraph (being able to generate charts in editable print quality). Of course I eventually got to use real C++ (but not on Deltagraph sadly) and then Objective-C and Java, etc. For most of the applications I have written since then OO programming has been a good tool.
I would never say that OO is the only way to write code. I see Haskell and Erlang and Scala and others and clearly they have a lot of supporters and I think that is a good thing; but one person can only manage so many tools in one brain. You have to pick and often it will be vastly different than someone else: we all live in the same gravity well here on earth, but each of use programs in our own space.
Arguing about how to program by itself is a good thing, because new ideas always come from a free interchange of other ideas. Today with the general openness ideas come faster and faster, unlike my magazine days, you rarely have enough time to think before being hit with yet another idea.
The key remains being smart enough to know how to apply to your situation and when to say no. After all there are no absolutes that apply to everyone but absolutely many people will tell you they absolutely know it all.
So stay thirsty for ideas my friend; just don't drink the kool-aid.