When I wrote Can I Do Without This, it struck me how hard it can be to describe software. In the draft I described a real-world case, detailing how I took the principle I espoused in the essay and applied it to the software I am currently working on. I had to delete those paragraphs. The details distracted from the flow of the writing. I could not make them comprehensible to the reader without going off on a tangent to explain all of the made-up terminology that describes my classes and methods. Software is difficult to describe. I want to speak in specifics, but writing in plain English constrains me to generalities.
Source code exists for the specific purpose of describing programs. Algol (one of the earliest high level languages) was originally invented for the purpose of making it easier for computer scientists to communicate with each other in publications.
However, source code is not English, no matter how many pains you take to make it appear so. Source code is a form of notation, like mathematical notation or musical notes. Good advice for research students is to try to avoid putting math on their slides when they make presentations, lest they lose their audience's attention span. I think the issue is not just math, but that any form of notation is a denser form of communication than what humans are comfortable reading - too dense to put into an essay.
There are other reasons not to mix code with ordinary writing. The formatting that is applied to prose will severely damage the careful indentation structure of a source code example. Conversely, when the source code gets its own formatting, the breaks introduced by switching back and forth rapidly are jarring.
Code and prose don't mix well. This is a real problem if code itself is the subject of your writing. Ultimately, though, we are deluding ourselves if we think that someone is actually reading all the code examples, if we include them. Source code is to be read in the context of pursuing a bug fix or feature change in real source code files. I don't read other people's code examples in literature - why should I be inclined to think that other people will really read mine? When I started this blog, I knew that this issue would surface. I made a decision that I would focus on the articles more than the code examples. It's more readable.
Friday, April 6, 2007
Thursday, April 5, 2007
Good Stuff
Just wanted to share some Good Stuff I've run across in the past day.
Jason pointed me to this video of Steve Jobs addressing Stanford graduates. Frankly I'm surprised they were brave enough to let Steve Jobs talk to students - he speaks his mind, and he's rich enough to tell the truth and not give a damn. This is actually the first time I ever saw him speak. Having seen the video, I think, ah, now I understand why people get so fanatical about him.
You can find a lot of good stories about the early Steve Jobs, and the rest of the original Mac crew on folklore.org. There are over a hundred stories on the site, all very good, detailing the trials and tribulations surrounding the release of the first Macintosh computer. From the site's own description of itself:
"Folklore.org is a web site devoted to collective historical storytelling. It captures and presents sets of related stories that describe interesting events from multiple perspectives, allowing groups of people to recount their shared history in the form of interlinked anecdotes."
Also in the good stuff category, I just popped open a can of Guinness draught. It's delicious! Had quite a head on it too. I'm a big fan of their Extra Stout, but I hadn't tried their draught yet. Draught is similar to Extra Stout, but a lot smoother and maybe more "user friendly".
(For the unenlightened, Guinness is a beer from Ireland that's so strong it has the black color and approximate viscosity of used motor oil. This isn't your wimpy light beer.)
I'm a glass-bottle beer drinker. Not sure how I feel about Guinness in a can, but poured into a drinking glass it tastes good. I like how the side of the can boldly says "beer", you know, just in case you forgot after you got home from the store. There's also a mysterious plastic ball floating in the can, which is, according to the label, the "Guinness Floating Widget". WTF?
I spent part of the day browsing Why's blog about Ruby. Why is the author of Why's Poignant Guide to Ruby, which, along with an interactive online Ruby tutorial, is the reason I became interested in Ruby. Thanks to Why, Ruby must be the first programming language to have a significant book about it written in the style of badly translated Asia instruction manuals. Why is so random, you almost can't judge whether his writing is good or bad; he just kicks things up (or sideways) to a new level (of insanity). But I enjoy it just for the originality. His habit of posting code examples drawn with colored pencils cracks me up every time.
Jason pointed me to this video of Steve Jobs addressing Stanford graduates. Frankly I'm surprised they were brave enough to let Steve Jobs talk to students - he speaks his mind, and he's rich enough to tell the truth and not give a damn. This is actually the first time I ever saw him speak. Having seen the video, I think, ah, now I understand why people get so fanatical about him.
You can find a lot of good stories about the early Steve Jobs, and the rest of the original Mac crew on folklore.org. There are over a hundred stories on the site, all very good, detailing the trials and tribulations surrounding the release of the first Macintosh computer. From the site's own description of itself:
"Folklore.org is a web site devoted to collective historical storytelling. It captures and presents sets of related stories that describe interesting events from multiple perspectives, allowing groups of people to recount their shared history in the form of interlinked anecdotes."
Also in the good stuff category, I just popped open a can of Guinness draught. It's delicious! Had quite a head on it too. I'm a big fan of their Extra Stout, but I hadn't tried their draught yet. Draught is similar to Extra Stout, but a lot smoother and maybe more "user friendly".
(For the unenlightened, Guinness is a beer from Ireland that's so strong it has the black color and approximate viscosity of used motor oil. This isn't your wimpy light beer.)
I'm a glass-bottle beer drinker. Not sure how I feel about Guinness in a can, but poured into a drinking glass it tastes good. I like how the side of the can boldly says "beer", you know, just in case you forgot after you got home from the store. There's also a mysterious plastic ball floating in the can, which is, according to the label, the "Guinness Floating Widget". WTF?
I spent part of the day browsing Why's blog about Ruby. Why is the author of Why's Poignant Guide to Ruby, which, along with an interactive online Ruby tutorial, is the reason I became interested in Ruby. Thanks to Why, Ruby must be the first programming language to have a significant book about it written in the style of badly translated Asia instruction manuals. Why is so random, you almost can't judge whether his writing is good or bad; he just kicks things up (or sideways) to a new level (of insanity). But I enjoy it just for the originality. His habit of posting code examples drawn with colored pencils cracks me up every time.
Can I Do Without This?
I have to give credit to Jason Doucette, of xona.com, for reminding me of the topic I wanted to blog today. He said, "To be productive, you truly have to choose what not to do, and avoid it, even though you'll want to do it. Otherwise, it never gets done."
The difference between a good software project and a bad one is that the bad one is in a free-fall of runaway complexity, while a good one merely teeters continuously on the edge of it. There doesn't seem to be a way to build software that doesn't run the continual risk of running amok in it's own sprawling subroutines. It is not the software that has a problem - it's perfectly happy growing wild and wooly. But people can only take so much complexity before their heads explode.
If you just don't care about quality, if you don't have any passion for your work, the statement I quoted about being productive probably doesn't apply to you. You're not going around writing extra code as it is, and that's ok - there's not much I can say that will affect you.
The people I'm trying to reach are those who want to be great programmers, but who perhaps haven't yet found the path. Because you can be very smart and work very hard, only to find that the amount of work required to introduce each change to your beautiful software architecture grows faster than you can keep up with. What happens is that each feature suggests a symmetrical feature as well. If you have a list and a function to add to the list, don't you also need a delete? Not necessarily - if your application doesn't ever delete items from the list, don't write that code. You can write it when and if you do use it - who knows; in ten days you may change your architecture, and not even use that list at all!
You have to be something of a perfectionist to write solid code - you also have to be willing to put up with incompleteness if you want to finish software projects, and that can be a bitter pill to swallow.
I think the reason I had so much trouble with this, is that I learned to program by reading libraries. In the many years I spent learning to program before I had internet in my home, the finest code examples I had were contained in the standard language libraries and headers which came with my compilers. The quality of the code that goes into compiler libraries and language frameworks is usually exceptionally good. What I'm worried about is that smart programmers will fail to grasp the fact that code in a library is targetted for a completely different use-case than code in an application is.
When you look at only libraries and frameworks, you get a skewed idea of which things need to be done and which do not. You risk developing a lop-sided aesthetic sense that values the completeness of a class's API over completeness of the project. When I look at some of my older programs, I realize that what I had were layers upon layers of homemade libraries, building up like a pyramid until at the pinnacle you have one library call which sums up the whole program.
So what's wrong with that? Isn't that the holy grail of software design - to be able to issue one simple command and know that everything else is going to be taken care of?
It's wrong because it took me - f o r e v e r - to finish programs that way. When I look through the code I see dozens of functions which are never called anywhere in the entire program. I put them in, not because I needed them, but just to make the class API complete. Ridiculous!
I'm not alone. I once heard a computer science professor give a group of freshmen the bad advice that, "when you make a class, you should give it as many overloaded constructors as you can, as many as you can think of, in case you need them." Remember, kids, to stock up on constructors; that way you'll be prepared when the global function shortage hits...
The path I alluded to earlier is the way out of the quagmire of slow software development. Imagine the space of all programs as a huge, dark forest. Walking the path means not straying from what you need to write to accomplish your goals. You can write code, even good code, while meandering all over the place, but you will spend much time lost in the forest and may never reach the end. Every time you leave the path to go explore something interesting, you are covering a greater area in the space of all possible programs, making it ever harder to come back from your excursion.
So much for not writing what you do not have to. Yet I am advocating something beyond even that. You must continually re-examine everything you have already written, and eliminate dead code. Do not be wedded to code you have written just because you spent time on it. Instead, value the code only on how much it contributes to the final product.
When I work on software I run variations of the same question through my mind continuously: Can I do without this? Is this a necessary function? If I delete this piece of code, will the rest of the system continue to work?
You can't have bugs in code that is not there.
Sunday, April 1, 2007
I Like that Old Time Rock and Roll
If you want to really understand something, you must go straight to the source. Led Zepplin. The Beatles. Ernest Hemmingway. Shakespeare. The original works in any area may not be the most polished - but they are the ones you will learn the most from. Good ideas have a way of gathering extraneous junk over time - it's as if every original concept is a potential katarami damacy ball, absorbing more cruft with each reincarnation. Eventually it reaches a point that the quality without a name that made the idea good in the first place is completely obscured.
It's easy to see why this happens. Original ideas are rare, and original people are scary. Sometimes they smell bad, too. It's much easier find a person who'll take an original idea and adapt it. There are three ways to adapt an old idea - you can remove part of it, or you can substitute part of it with something else, or you can tack on unnecessary crap. Of these ways, the first two require some understanding of what you are doing. I don't look down on them. Everything is created in the larger context of the culture and technology that spawned it, and I suspect what we call original ideas, are mostly made of other original ideas by simplifying them or substituting parts of another idea.
The third way of co-opting an idea, however, is a form of pollution. It's easy to take a good idea and add something that doesn't change it, because it doesn't break what was already there. Anyone can do it. That's the problem. Look, it's not just a dog, it's a dog with a flower on it's head! It's original! Dog 2.0. The noosphere is littered with junk like this.
The best way to avoid exposure to junk is to go back in time far enough to reach a point before the cruft took over. So when I wanted to understand computer architecture better, I set out to build a homemade system based around one of the oldest 8-bit classics: the 6502 microprocessor. To those of you who may ask why I would want to design my own computer, I refer you to my previous blog entry.
There are all manner of shortcuts that could be taken in such a project. For instance, I could have just used a 6502 emulator on a PC - but I don't want to pretend I have a 6502 computer, I want to have a real 6502 that I can hold in my hands. One shortcut I do think is reasonable is that I am using a powerful modern microcontroller, the Propeller from Parallax, to manage all the I/O and control logic for the circuit. It will allow me to use software to replace a whole handful of support chips. The Propeller is over a hundred times more powerful than the 6502 CPU it will be supporting, but the point is not to make a powerful computer, but to gain a better insight into computer architecture. The Von Neumann architecture, which most computers today are based on, remains remarkably unchanged whether you're looking at a 6502 or a modern Pentium.
(Incidently, the Propeller chip itself is also an example of an original work, the first of its own class.)
My 6502-computer remains a work in progress. I've run NOPs and simple loops on it using its single-cycle facility, but it's temporarily offline while I make some changes. I figured out a way to eliminate even more chips from the circuit, using software on the Propeller to do their jobs, but the computer will not be operational again until I finish writing that firmware.
Even so, I've already uncovered a wealth of fascinating things, which I would never have suspected. Building actual projects provides you with these wonderful Zen moments where your whole plan of action is suddenly brought up short by something unexpected. You find there's a gap in your reasoning and there's nothing in your plans for connecting it. Getting stuck is a wonderful thing because it means you're about to learn something that will change your perspective.
Some of the interesting problems I've overcome so far:
Problem: The hardest part of the whole project is... wiring. If you've never tried to build a microprocessor circuit, you might think that the chips and the signals are what's important. For the most part, those will sort themselves out as you improve your design. But your schematic doesn't give you any hint how to keep hundreds of wires from turning into a horrible rats nest. Bad wiring is the perpetrator of electrical gremlins, and wiring is by far the most time consuming aspect of building a homebrew computer.
Solution: Ribbon cables to keep the mess manageable, and patience.
Problem: The 6502 doesn't always behave the same way every time you reset it. Sometimes it produces junk for six machine cycles before jumping to its reset vector, and sometimes it is seven or eight. This is a problem because my theoretical design depended upon carefully counting the number of machine cycles so that I would know when the 6502 is looking for its reset vector, so that I can substitute another number.
Solution: In my original design, I didn't give the Propeller any connections to the 6502's address lines. I was relying on counting machine cycles to predict what the address should be. I had to change my design, because I needed it to measure actual addresses instead. Plus, you really do need to know the machine addresses for debugging. Guessing doesn't cut the mustard.
Problem: The 6502 I'm using is rated for a 2 MHz clock. I would like to run the 6502 at a slower-than-normal clock speed while I'm debugging it, because certain electrical problems are mitigated by running the circuit more slowly. However, the 6502 uses dynamic RAM for its registers, which have to be refreshed. There is a minimum safe clock speed that will still keep the registers refreshed on time - but what is it?
Solution: It seems no one knows what the real minimum clock speed is. However, everyone agrees that 500 KHz is fast enough. In my own experiments, I found that some operations (like resets and interrupts) would still work at speeds as slow as 10 KHz, but others did not. I've taken to running the processor at 500 KHz normally, and 50 KHz for specific tests.
Problem: The 6502 lacks many "essential" bus control signals. When I first evaluated the chip, I thought, wow, this is really simple. It doesn't have all the confusing extra pin functions that other microprocessors have. Then I went to actually implement the thing and realized there were signals I needed which the 6502 doesn't provide.
Solution: The 6502 has a clock input, as you would expect, but it also has two clock outputs, for no obvious reason. When I first looked at the datasheets, I ignored these because I didn't understand what they did. You can't ignore them. The reason the 6502 appears to be simpler in its bus control pins is that other microprocessors include bus-decoding logic on the chip, but the 6502 makes you use the two clock-phase outputs to synthesize your own bus logic. I first used NAND gates to combine the signals in the way I needed, but my new design will use firmware on the Propeller to decode it on the fly.
Problem: The 6502 single-step feature is very poorly documented, and poses a complex logic design problem. It is also very easy to lock up the 6502 if the single-step pin is asserted at an inconvenient time. (I think they tried to gloss over that in the official docs.)
Solution: I found a schematic of the 6502 single-step circuit that the man himself, Steve Wozniak, used on the Apple II. It was a brilliantly designed state machine using a pair of D-flipflops in a 7474 chip. I'm proud to report that I independently came up with the same idea of using a 7474, and had something already that looked remarkably like Woz's circuit - except for the small detail that mine locked up the 6502, but Woz's actually worked. I analyzed his circuit and realized that the clock-phase outputs (mentioned above) were the piece of the puzzle that I had been missing. Using a flipflop configuration inspired by Woz's, I at last got single-stepping to work, but no sooner had I gotten it working than I realized I could do it in software on the Propeller, without any additional chips.
It's easy to see why this happens. Original ideas are rare, and original people are scary. Sometimes they smell bad, too. It's much easier find a person who'll take an original idea and adapt it. There are three ways to adapt an old idea - you can remove part of it, or you can substitute part of it with something else, or you can tack on unnecessary crap. Of these ways, the first two require some understanding of what you are doing. I don't look down on them. Everything is created in the larger context of the culture and technology that spawned it, and I suspect what we call original ideas, are mostly made of other original ideas by simplifying them or substituting parts of another idea.
The third way of co-opting an idea, however, is a form of pollution. It's easy to take a good idea and add something that doesn't change it, because it doesn't break what was already there. Anyone can do it. That's the problem. Look, it's not just a dog, it's a dog with a flower on it's head! It's original! Dog 2.0. The noosphere is littered with junk like this.
The best way to avoid exposure to junk is to go back in time far enough to reach a point before the cruft took over. So when I wanted to understand computer architecture better, I set out to build a homemade system based around one of the oldest 8-bit classics: the 6502 microprocessor. To those of you who may ask why I would want to design my own computer, I refer you to my previous blog entry.
There are all manner of shortcuts that could be taken in such a project. For instance, I could have just used a 6502 emulator on a PC - but I don't want to pretend I have a 6502 computer, I want to have a real 6502 that I can hold in my hands. One shortcut I do think is reasonable is that I am using a powerful modern microcontroller, the Propeller from Parallax, to manage all the I/O and control logic for the circuit. It will allow me to use software to replace a whole handful of support chips. The Propeller is over a hundred times more powerful than the 6502 CPU it will be supporting, but the point is not to make a powerful computer, but to gain a better insight into computer architecture. The Von Neumann architecture, which most computers today are based on, remains remarkably unchanged whether you're looking at a 6502 or a modern Pentium.
(Incidently, the Propeller chip itself is also an example of an original work, the first of its own class.)
My 6502-computer remains a work in progress. I've run NOPs and simple loops on it using its single-cycle facility, but it's temporarily offline while I make some changes. I figured out a way to eliminate even more chips from the circuit, using software on the Propeller to do their jobs, but the computer will not be operational again until I finish writing that firmware.
Even so, I've already uncovered a wealth of fascinating things, which I would never have suspected. Building actual projects provides you with these wonderful Zen moments where your whole plan of action is suddenly brought up short by something unexpected. You find there's a gap in your reasoning and there's nothing in your plans for connecting it. Getting stuck is a wonderful thing because it means you're about to learn something that will change your perspective.
Some of the interesting problems I've overcome so far:
Problem: The hardest part of the whole project is... wiring. If you've never tried to build a microprocessor circuit, you might think that the chips and the signals are what's important. For the most part, those will sort themselves out as you improve your design. But your schematic doesn't give you any hint how to keep hundreds of wires from turning into a horrible rats nest. Bad wiring is the perpetrator of electrical gremlins, and wiring is by far the most time consuming aspect of building a homebrew computer.
Solution: Ribbon cables to keep the mess manageable, and patience.
Problem: The 6502 doesn't always behave the same way every time you reset it. Sometimes it produces junk for six machine cycles before jumping to its reset vector, and sometimes it is seven or eight. This is a problem because my theoretical design depended upon carefully counting the number of machine cycles so that I would know when the 6502 is looking for its reset vector, so that I can substitute another number.
Solution: In my original design, I didn't give the Propeller any connections to the 6502's address lines. I was relying on counting machine cycles to predict what the address should be. I had to change my design, because I needed it to measure actual addresses instead. Plus, you really do need to know the machine addresses for debugging. Guessing doesn't cut the mustard.
Problem: The 6502 I'm using is rated for a 2 MHz clock. I would like to run the 6502 at a slower-than-normal clock speed while I'm debugging it, because certain electrical problems are mitigated by running the circuit more slowly. However, the 6502 uses dynamic RAM for its registers, which have to be refreshed. There is a minimum safe clock speed that will still keep the registers refreshed on time - but what is it?
Solution: It seems no one knows what the real minimum clock speed is. However, everyone agrees that 500 KHz is fast enough. In my own experiments, I found that some operations (like resets and interrupts) would still work at speeds as slow as 10 KHz, but others did not. I've taken to running the processor at 500 KHz normally, and 50 KHz for specific tests.
Problem: The 6502 lacks many "essential" bus control signals. When I first evaluated the chip, I thought, wow, this is really simple. It doesn't have all the confusing extra pin functions that other microprocessors have. Then I went to actually implement the thing and realized there were signals I needed which the 6502 doesn't provide.
Solution: The 6502 has a clock input, as you would expect, but it also has two clock outputs, for no obvious reason. When I first looked at the datasheets, I ignored these because I didn't understand what they did. You can't ignore them. The reason the 6502 appears to be simpler in its bus control pins is that other microprocessors include bus-decoding logic on the chip, but the 6502 makes you use the two clock-phase outputs to synthesize your own bus logic. I first used NAND gates to combine the signals in the way I needed, but my new design will use firmware on the Propeller to decode it on the fly.
Problem: The 6502 single-step feature is very poorly documented, and poses a complex logic design problem. It is also very easy to lock up the 6502 if the single-step pin is asserted at an inconvenient time. (I think they tried to gloss over that in the official docs.)
Solution: I found a schematic of the 6502 single-step circuit that the man himself, Steve Wozniak, used on the Apple II. It was a brilliantly designed state machine using a pair of D-flipflops in a 7474 chip. I'm proud to report that I independently came up with the same idea of using a 7474, and had something already that looked remarkably like Woz's circuit - except for the small detail that mine locked up the 6502, but Woz's actually worked. I analyzed his circuit and realized that the clock-phase outputs (mentioned above) were the piece of the puzzle that I had been missing. Using a flipflop configuration inspired by Woz's, I at last got single-stepping to work, but no sooner had I gotten it working than I realized I could do it in software on the Propeller, without any additional chips.
Saturday, March 31, 2007
In Which I Do Not Fly a Kite on the Beach
Ah, I should be ashamed of myself. What kind of person pays a $65 buy-in for the craziest beach party of the year, and after one night says, "You know what? I'm tired of partying. Let's go home, read a book, and maybe write a blog entry."
I'll never be able to pass myself off as a normal person now.
It's not that I have no life, it's just that I can only do the social thing so long before I want to quit wasting time, and go do something geeky and constructive with my time. Alcohol doesn't really do it for me. I like the people at the beach party. I had the time of my life. But this morning I realized I'm just not interested in getting intoxicated enough to enjoy another night with 75 loud, intoxicated college students.
Ok, maybe it is that I have no social life.
I don't worry about it. I may be crazy but it's a happy kind of crazy. I enjoy my geeky life. I just wish my fiancee could have been here with me this weekend.
My original plans for the beach party were to get an awesome parafoil kite, and spend the weekend flying the kite on the beach. Then all the girls would say, "Wow, that's a cool kite, can I fly it?" And I'd have to say, "Piss off. Get your own kite."
(Just a joke - I'm really not that mean.)
So I bought the kite. Unfortunately some bad thunderstorms are keeping everyone inside this weekend - no kite flying, or beachly activities of any kind. I can't remember whether the Mythbusters episode confirmed or busted the myth that you can get killed by lightning striking a kite, but I'd hate to find out the hard way.
(Some people have this strange idea that you should go into the water, or something, when you go to the beach. I hear it's called "swimming". I've never tried it myself - it sounds terribly unpleasant.)
The book I'm curling up with on this rainy day is titled Born on a Blue Day. It is the autobiography of Daniel Tammet, who is a famous memory savant who has Asperger's syndrome. The book makes an outstanding contribution to the body of works that includes Temple Grandin's autobiography, Thinking in Pictures, and the novel by Mark Haddon, The Curious Incident of the Dog in the Night-time. I'll post a review of Born on a Blue Day sometime this week.
I'll never be able to pass myself off as a normal person now.
It's not that I have no life, it's just that I can only do the social thing so long before I want to quit wasting time, and go do something geeky and constructive with my time. Alcohol doesn't really do it for me. I like the people at the beach party. I had the time of my life. But this morning I realized I'm just not interested in getting intoxicated enough to enjoy another night with 75 loud, intoxicated college students.
Ok, maybe it is that I have no social life.
I don't worry about it. I may be crazy but it's a happy kind of crazy. I enjoy my geeky life. I just wish my fiancee could have been here with me this weekend.
My original plans for the beach party were to get an awesome parafoil kite, and spend the weekend flying the kite on the beach. Then all the girls would say, "Wow, that's a cool kite, can I fly it?" And I'd have to say, "Piss off. Get your own kite."
(Just a joke - I'm really not that mean.)
So I bought the kite. Unfortunately some bad thunderstorms are keeping everyone inside this weekend - no kite flying, or beachly activities of any kind. I can't remember whether the Mythbusters episode confirmed or busted the myth that you can get killed by lightning striking a kite, but I'd hate to find out the hard way.
(Some people have this strange idea that you should go into the water, or something, when you go to the beach. I hear it's called "swimming". I've never tried it myself - it sounds terribly unpleasant.)
The book I'm curling up with on this rainy day is titled Born on a Blue Day. It is the autobiography of Daniel Tammet, who is a famous memory savant who has Asperger's syndrome. The book makes an outstanding contribution to the body of works that includes Temple Grandin's autobiography, Thinking in Pictures, and the novel by Mark Haddon, The Curious Incident of the Dog in the Night-time. I'll post a review of Born on a Blue Day sometime this week.
Tuesday, March 27, 2007
Why Do Anything?
Personal hack projects, like the kind they write about on hackaday, are indispensable to the aspiring technology wizard's development. These are small feats of engineering done for no other purpose than for the joy of making things, or to prove that something considered impossible can actually be done. Other computer science students often ask me how I acquired the skills I have, and want to know how they might improve their own skills. "Projects!" I tell them. I advise them to choose something that interests them but lies just outside their current skillset. In doing the project they will acquire the skills the project requires and polish the ones they already have. It's also great fun!
I, of all people, should not have any difficulty justifying to myself why I do projects - right? Well let me tell you...
I have a favorite uncle who is a computer consultant. I am greatly indebted to him - my first experiences with computers were playing games at his house when I was very young, and it was also he who gave me my first "real" computer.
We definitely have some common interests, but whenever I would tell him my latest idea for some fun but purposeless project, he would reply: "That sounds interesting... but why would you want to?"
As an adult and now a computer professional myself, I've come to understand his viewpoint. Our field is simply too full of possibilities to go tilting at every windmill. You have to pick and choose your battles. A simple but mundane solution to an interesting problem is not a waste of a good problem - it is a job well done, or at least done with minimal risk.
Yet there has always been something that bothered me about the way my uncle posed that question. "But why would you want to?" The answer to it is meaningless. I don't know why I want to. I just get ideas for projects and I do them.
It is not the answer but the question itself that troubles my thoughts. No, not even the question. It runs deeper than that. It is the act of asking the question that raises the hairs on my neck.
Because you see if you start asking this question when you have an idea for project to do for fun, it only leads to self-doubt. You will never reach your full potential if you question your own motivation. I've met many geeks who regularly do astonishing things with technology. I've met many more, just as smart, who talk about great things but do not do them. What stops them?
There are many cases where self-doubt is a good thing. It is a survival trait. One day my best friend needed to fix something on the roof of his house. I held a ladder while he climbed to the roof. It was very windy. Suddenly he hesitated and climbed back down. "What's wrong?" I asked. He said, "I don't know whether I suddenly became smarter or am just chickenshit, but I just got the feeling I shouldn't be up on that roof." As he said that, another violent gust of wind shook the ladder in my hands. I think he made the right choice.
Most electronics and software projects are not nearly as dangerous as climbing a ladder on a windy day. Provided you practice good lab safety habits, the real danger is to your own ego. The fear you deal with is just fear of the unknown - "What if I can't get this to work?" "I don't know where to begin." When it comes to doing a project, self-doubt is not a survival trait - it's a stumbling block.
It's appropriate to apply the "but why would you want to?" question when evaluating solutions to a major engineering project at your day job. You'd be irresponsible if you created unnecessary work by not differentiating between things that are fun to do and things you need to do. But if you ask "why would you want to?" about personal projects that are just for fun in the first place, you will invariably find a reason not to do it. An old 'geezer' I know recently lamented to me that the downside of today's advanced technology is that no one is impressed anymore when you show them what you've been working on, because they can buy a piece of consumer electronics from Walmart that does the same thing. When anything that has a real purpose is already available, and anything you may build that is one of a kind probably also doesn't have any practical value, it begs the question, "Why do anything?"
I, of all people, should not have any difficulty justifying to myself why I do projects - right? Well let me tell you...
I have a favorite uncle who is a computer consultant. I am greatly indebted to him - my first experiences with computers were playing games at his house when I was very young, and it was also he who gave me my first "real" computer.
We definitely have some common interests, but whenever I would tell him my latest idea for some fun but purposeless project, he would reply: "That sounds interesting... but why would you want to?"
As an adult and now a computer professional myself, I've come to understand his viewpoint. Our field is simply too full of possibilities to go tilting at every windmill. You have to pick and choose your battles. A simple but mundane solution to an interesting problem is not a waste of a good problem - it is a job well done, or at least done with minimal risk.
Yet there has always been something that bothered me about the way my uncle posed that question. "But why would you want to?" The answer to it is meaningless. I don't know why I want to. I just get ideas for projects and I do them.
It is not the answer but the question itself that troubles my thoughts. No, not even the question. It runs deeper than that. It is the act of asking the question that raises the hairs on my neck.
Because you see if you start asking this question when you have an idea for project to do for fun, it only leads to self-doubt. You will never reach your full potential if you question your own motivation. I've met many geeks who regularly do astonishing things with technology. I've met many more, just as smart, who talk about great things but do not do them. What stops them?
There are many cases where self-doubt is a good thing. It is a survival trait. One day my best friend needed to fix something on the roof of his house. I held a ladder while he climbed to the roof. It was very windy. Suddenly he hesitated and climbed back down. "What's wrong?" I asked. He said, "I don't know whether I suddenly became smarter or am just chickenshit, but I just got the feeling I shouldn't be up on that roof." As he said that, another violent gust of wind shook the ladder in my hands. I think he made the right choice.
Most electronics and software projects are not nearly as dangerous as climbing a ladder on a windy day. Provided you practice good lab safety habits, the real danger is to your own ego. The fear you deal with is just fear of the unknown - "What if I can't get this to work?" "I don't know where to begin." When it comes to doing a project, self-doubt is not a survival trait - it's a stumbling block.
It's appropriate to apply the "but why would you want to?" question when evaluating solutions to a major engineering project at your day job. You'd be irresponsible if you created unnecessary work by not differentiating between things that are fun to do and things you need to do. But if you ask "why would you want to?" about personal projects that are just for fun in the first place, you will invariably find a reason not to do it. An old 'geezer' I know recently lamented to me that the downside of today's advanced technology is that no one is impressed anymore when you show them what you've been working on, because they can buy a piece of consumer electronics from Walmart that does the same thing. When anything that has a real purpose is already available, and anything you may build that is one of a kind probably also doesn't have any practical value, it begs the question, "Why do anything?"
Subscribe to:
Posts (Atom)