I absolutely “love” what I do and can’t imagine doing anything else. “However”…I have had very few jobs where I was happy. I think there are 2 primary reasons.
1. I want to work on what I want to work on. When I work on anything else, all I can think about is what I really want to work on. In a job situation, I rarely work on what I want. (OTOH, a job that has me working on what I want is usually a great job.)
2. I want to work when I want to work. Sometimes, 8 to 5 works, often it doesn’t. We were simply not meant to sit in cubicles without windows all day long. Enough said.
There are lots of other things most of us don’t like (difficult people, crappy code to maintain, poor management, difficult deadlines, etc.), but those are all part of the territory. I could live with them if I could work on what I want when I want.
I have been programming continuously for 30 years and I’ve “never” been burnt out. In fact, I’m having more fun than ever. I can’t imagine doing anything else.
I have worked in 88 companies, either as a contractor or an employee. I have seen other scenarios play out many times. I have worked on the worst garbage code and dealt with incredibly nasty and incompetent people almost everywhere I’ve been. But I never let them beat me.
Only I get to decide how I feel about anything, especially work. When things have gone sour, which they almost always do, I have done everything I could to fix them, and when that wasn’t enough, I have moved on. I’ve always felt that one of my biggest strengths was the breadth of my experience. I use almost all of it every time I do something.
There’s now more hope and opportunity for true hackers than ever. It’s just a matter of continually finding your best place. Maybe a small service business. Maybe that perfect job. Maybe a startup. If all else fails, keep the lousy day job and hack away at something cool at night.
If you’re really burnt out, take a break. But make it your decision - don’t let the bastards take your inner hacker away. Ever.
There’s a chasm you have to cross to become “senior”, whatever that means. One of the biggest skills you need to learn is not technical. That skill is understanding exactly how to apply our limited resources.
Should we worry about how well a certain module was written? Maybe, maybe not. Sometimes the answer really is, “It runs well and isn’t hurting anything, so let’s leave it alone. Opening up that can of worms dumps 47 new issues into our queue and now is not a good time to do that.” Or the answer may be, “This has to be
made right before we can add these 27 other things to the system or we’ll all be in deep sh*t.” How do you know which? Experience. Understanding the big picture. Understanding your customers and users. Understanding your dev team. You get the idea.
Taking on a lead role is not selling out if it’s used to expand your horizons and make you an all-around better dev person. When you return to full time development, you’ll be light years ahead of those who never had to manage the whole project. A little perspective goes a long way.
Kinda reminds me of the time Robert Frost was a technical writer for a day :-)
The Thread Not Traversed
TWO threads diverged in a yellow stack,
And sorry I could not traverse so
And be one parser, long I stood
And looped through one as long as I could
To where it spawned in the overflow;
Then invoked the other, as just as fair,
And having perhaps the faster stats,
Because it was hashed and wanted wear;
Though as for that the data there
Had run them into third normal form,
And both that session equally lay
In objects no instance had trodden class.
Oh, I kept the version for another day!
Yet knowing how code leads on to code,
I doubted if I should ever unit test.
I shall be documenting this with a sigh
Somewhere many transactions hence:
Two threads diverged in a stack, and I—
I took the one less traversed by,
And that has caused the site to fly.
As smart people who deal a lot with binaryness (there “is” a right answer), we place high regard for education, as we should. But please understand that business and academia are 2 different animals with only a little overlap. I have lots of education and lots of practical work experience, and I have to be careful “when” to apply my formal education, which isn’t often.
Classic example (I’m sure many of you have many more):
I graduated Allegheny College with the founders of ijet.com. At an alumni event, they presented their business case and web site. It was very interesting. At the end, a business professor summed things up. Not a single thing he said made any sense or had anything to do with the presentation. I wondered if he had even watched it. That’s when I decided to stop feeling bad about sleeping through all that Cost/Value Curve bullshit so many years ago.
Get your degree. Get your education. But please understand they aren’t necessarily the same thing.
I prefer to sit with my users. As you can imagine, this concept is met with a bit of resistance in corporate America.
I want to dwell with them and be a part of their lives. I want to hear them complain about their apps, their customers and vendors, their bosses, and each other. I want to know what they go through all day every day.
When I sit and suffer with them, the resulting software is “always” better. All the meetings, prototypes, demos, specs, etc., etc., etc. have never been able to deliver the same knowledge needed to develop their apps.
On the other hand, I “don’t” want to sit with other programmers, unless we’re working on the same thing at the same time. I don’t care about your problems, I have my own.
How I Write Code:
1. Copy the smallest piece of code I’ve already written and change it slightly to do something really small. Get it working perfectly.
2. Add a little bit. Get it working perfectly.
3. Add a little bit more. Get it working perfectly.
4. Repeat until it’s not so easy to add anything, even a little bit. Print a hard copy. Holy crap! Did I write all that?
5. Mark it up like crazy with a red pen. Combine similar code into common functions. Rename variables. Rename them again. Rename them again. Rename them to what they originally were, but without vowels. Restructure unwieldy functions. Rewrite the stuff I can’t believe I actually wrote myself.
6. Sit down at terminal and enter changes. Save every version (even though I never look at it again). Get it to work perfectly (again). Holy crap! What did I do? It’s totally broken! Debug, debug, debug. Good. Now it runs perfectly. Time to add more…go back to Step 1. (Except every 5th time through this loop: Scrap it all and rewrite it the way I should have in the first place.)
7. Repeat until dead.
“1955 was the best year for geek births”
For outliers, maybe, but for the rest of us, NO!
I was born in 1955, on the same day as James Gosling, inventor of Java.
But I was not an outlier. I was pretty much a regular person from a middle class family who went to public school and aspired to be the first in my family to graduate college. Here’s the problem with being born “too soon”:
I graduated high school, college, and graduate school “without ever having touched a computer”. Think about that. Neither of my colleges even had a Comp Sci department. I grew up in Western Pennsylvania, far from the leading edges of Boston and California. Nobodyknew anything about computers. They were giant machines that sent your electric bill. Period. Unless you were fortunate to be close to the geek counter culture of Northern California or had parents with millions of dollars, forget it.
I graduated with an MBA and got a job as a restaurant manager (1978 was a lot like 2009). Then I picked up a COBOL book and practically memorized it for a difficult to get programming interview. I got the job and the rest is history.
I often wonder what my life would have been like if I had been born 10 or 20 years later. But it’s a wasted thought. What if I had been born 10 or 20 years earlier. I’d probably be a retired car dealer now.
The great thing is that now it just doesn’t matter. I took a while to get here, but I can’t imagine doing anything else. Maybe that’s why I’m here so often: making up for lost time.
This question reminds me of the greatest cook ever, my grandmother. She used no technology whatsoever. All of her tools had been her mother’s which were probably manufactured in the 1800s. She chopped everything by hand in a wooden bowl. If anyone else helped her with the chopping, everyone at dinner could tell. She never used pencil or paper and measured nothing. She stood in line at the farmer’s market, the butcher, or the grocery store and inspected every item. And absolutely nothing I have ever eaten since, in any restaurant or home, has been remotely close to hers. It was magnificent! And I miss it so much.
I’d like to think I have almost as much passion about my work. I use the most primitive tools, 24 x 80 green screen editor, no framework, no IDE, no debugger, and mostly pencil and paper. I savor every byte just as I imagine my grandmother savored every little detail of her cooking. I’m not trying to save time or be fast, I just aspire to creating Grandma-quality software. I only hope my software brings someone the same joy her food
brought all of us.
I’ve used many different tools. And I rarely care how fancy they are. Ironically, the simpler, the more joy I have found along the way.
A salesman, a project manager, and a programmer are kidnapped by terrorists on the way to a customer demo. The company refuses to pay ransom so they are to be executed. The kidnappers grant each a last request. The salesman said, “I have been working very hard on a Power Point presentation of our new release and I haven’t had a chance to present it yet. It’s only 143 slides and 2 hours long, and I’d like to present it before I’m killed.”
The project manager said, “I have developed a new methodology for implementing our new release. I’d like to present 25 flip chart pages to describe it. I will only take one hour.” The programmer said, “Kill me first.”