examining an existing problem, devising an elegant software solution, building that solution, and enjoying the results.
helping a customer define a process and improving that process with technology 100X.
building something over and over again but knowing it's not quite right until we've sifted through the output enough to figure it out and then build it perfectly.
always working on puzzles but never knowing when the lightbulb will go off. When it does, dropping everything to build the solution that popped into our head.
taking existing software that was built with good intentions but didn't quite do the job and getting it to do the job right.
changing the way a data base is structured in order to eliminate 90% of the existing code.
teaching proper technique to someone who only knows how to hack together kludges and watching them blossom.
experiencing the tension between getting really good at what you know and always yearning to learn something new.
something we never could have done if we were born 100 years earlier and may not be able to do if we were born 100 years later.
building something that never existed anywhere before except in your own mind and bringing it to reality.
doing a happy dance when something works for the first time.
This, this right here. One of the things that I discovered over the course of my 20s is that this one particular thing gives me vastly more satisfaction than solving any of the "big problems" I thought I cared about when I was 23.
In my day job as a TechnicalLead/PM/sysadmin/perfOptimizer, I do all of the 'non-coding' tasks daily.
I guess I shouldn't feel so bad that I do all the non-coding grunt work for my team. They prefer to just write code.
Still. I should create something of my own just to fill in the last 10%.
This is #1 reason i've always felt imposter syndrome hanging around real hackers in HN who write code regularly.
Anyone else like me who doesn't quite perfectly fit into the 'hacker in a startup' role?
One day a student came to Moon and said,
"I understand how to make a better garbage collector.
We must keep a reference count of the pointers to each cons."
Moon patiently told the student the following story --
"One day a student came to Moon and said,
"I understand how to make a better garbage collector..."
A lot of the things listed are things that infrastructure guys, not programmers, should be doing...
Then I took a long lunch and wrote a specification for something elegant that can be done in two days, instead of the presently planned weeks... And then I got cursed out by the boss for taking a long lunch.
(I am quite happy here, but today I feel like trawling jobs sites for telecommute Perl jobs where it is ok to be very rusty on web development.)
Programming is... the craft of doing what you've been doing since you were eight years old, with increasing efficiency and foresight, while using complex names for things in order to sound like you're not simply doing what you've been doing since you were eight. :-)