When I started
coding in 1980, my constraints were different than they are now: a 5 MHz clock, 2Kx16 or RAM, and a monitor program that had a limited assembler built into it but no filesystem whatsoever for persistent storage. In addition, I was programming for my own education with another goal as my primary motivation.
The computers I use today have vastly different capability sets, and I have very different reasons for programming. Between then and now, I have been paid at various times to program single chip microcontrollers, code generators, programmable logic arrays, and data scrapers, and the machines I use have multiplied in CPU speed by almost 1000x, data bus width by 4, and memory cache is now 128x what my entire volatile memory was.
In addition, I've made transitions several times between coding for my own profit, hiring coders, and writing code for others. Some of my personal-profit projects are on the plus side, but I have also had to bury a few and take the loss. Painfully.
This twenty-five year perspective has given me one overriding mandate: find the biggest picture I can in which to view the work I do. In some cases, this leads me to stop coding and go home to spend time with my family. In others, it leads me to set myself up as one who is insulated from the urgency of a particular department's crises so that I can write applications that solve long term problems while leaving others to deal with the heartburn du jour.
Very few of us have the luxury of tweaking the politics of a major lab group for its own good, but this same principle can be applied to questions of how to optimize one's coding time and resources. We all have spent time barking up the speed-optimization tree, and sometimes it's warranted and others not. There are times when every cycle counts, and others where the hours you spend writing comments and docs and listening to user feedback are far more important than the nanoseconds you shave from execution of a process.
What is the ultimate goal of your coding? Are you learning to be a better coder? Are you satisfying yourself, or are you working for a bigger goal? Is your programming going to 'count'?
Some of us are good enough -- and dedicated enough -- to dig into the core of our tools to extend them or make them better. I've had several humbling opportunities to sit at the feet of some of these giants as they warped the fabric of my progamming environment right before my eyes. At other times, I've had the pleasure of seeing a fire kindled in a ten-year-old's eyes as he 'gets' how the shell tells the computer what he wants to do, and knowing that my choice to spend my time in his classroom made a measurable difference for him that day.
It's baseball playoff season now, and one of the choices I've made is to let them play away without my attention. The reason I bring up baseball, though, is to paint a few analogies. The ultimate goal of a baseball game is to win, and the way a team wins is to score more runs than the opponent does. There are many ways to do this, though. Some players do it by learning to hit home runs. Others do it by pitching so well that their pitches can't be hit. On other teams, the managers do a lot of work on getting their players to work together to advance around the bases a little bit at a time. All these different individual and team strategies have a lot of luck in them, compared to programming. In our field, with the exception of business aspects, we can focus more on project completion in a more straightforward sense, without as much of our path being affected by a belligerent clump of buffalo grass or a momentary change in the wind direction.
Another area where baseball has much to teach us is the area of personal motivation. The team's goal is winning games, but what are the motivations that drive the individual players? Baseball has had both great players and terrible egotists, and often their stories are paraded through the media as they lead their team to success or destroy its chances with a careless word. In life, we have many opportunities to excel, and, in my life, I've had occasions where I've been great and occasions where I've been gross. The hardest-learned lesson I hold in my heart is the lesson that we each do have tomorrow, and today's embarrassing gaffe may not be retractable, but tomorrow's good will stand on its own.
The big picture is that good is always good, no matter the cost of bad. There are some days when the only good I accomplish is to get myself to the gym to keep the bod healthy a little while longer. On others, I juggle mentorship and productive coding. Sometimes one wins out and other times the other does. Here at Perl Monks, I have the honor of associating with many kinds of Monks, and I have come to realize that in some ways I've got wisdom to share, and in others I'm a humble newbie and my best option is to shut up and listen. The best news of all is that that's okay, and today's a day I still have time in which to do some more good.
Thank you, Perl Monks! :D
Edited by planetscape - added readmore tags
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
| |
For: |
|
Use: |
| & | | & |
| < | | < |
| > | | > |
| [ | | [ |
| ] | | ] |
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.