Here’s an idea: get a job. After a year, you’ll have plenty of ideas, maybe even one of your own.
I hate to rain on anyone’s parade, but the thought of begging for ideas is just so alien to me. The best predictor of your success in any endeavor is your own determination. With someone else’s idea, you’re much more likely to bail at the first sign of difficulty. Once you get a little real world experience under your belt, you’ll find plenty of opportunities to encounter something for which you’ll have real passion.
Your chances of success increase astronomically when you’re working on something you “have to do”. The only way to know if you “have to do it” is to have a little background and experience with it. Trading ideas like commodities seems like the least likely way to find something you’ll be passionate about.
OTOH, a “boring job” can be an incredibly fertile environment for start-up ideas. You’ll learn what people want, see what works and what doesn’t, and be much more adept at identifying opportunities. Oh, and get a chance to bank some money so that when you do start working on your passion, you can concentrate on that instead of begging for funding.
Sometimes the easy way out is just that: the easy way “out”. Get a job and pay your dues. You’ll probably be glad that you did.
The advice from this post is exactly what you’d expect in theory and exactly “what not to do” in practice. For one simple reason: the source code is (hopefully) the only thing pretty much guaranteed to survive.
I have seen countless shops where valuable history was lost because it was stored on someone’s c: drive, a network drive, or some repository that failed to survive some kind of migration. And even if these other files (digital or paper) did survive, chances are that the programmer that needed to see them never did anyway.
Good shops practice keeping audit trails “in the source code”. This means good commenting. Which means good code review and quality control.
I recently came across a single piece of code that had been changed back and forth 6 times in the previous 2 years. The comments looked something like:
* jeo 02/11/09 Use Ship Date, not Book Date per Sarah in Sales
* jrm 04/15/09 Use Book Date to make military contracts balance
* msl 08/24/09 Use Ship Date per Joe in Ops (military no longer active)
* jrm 12/13/09 Use Book Date per Rick Smith to prepare for new contracts
* jrm 02/14/10 Use Ship Date per Rick Smith after Ops meeting
* jrm 05/25/10 Use Book Date per Rick Smith until Q3 migration
I know that this is an extreme example, but this stuff happens all the time in commercial environments. How easy do you think it would be for the programmer/analyst to provide background if these comments were not in the source code, but somewhere else?
Sure it’s a pain it the ass to maintain this, but it immediately provides the needed background to the person who needs it, when he needs, where he’s already working. For critical projects with confused users (what isn’t), the alternative is usually much more work.
Very fast. Let me explain.
I work in 2 modes: (A) At the computer and (B) Away from the computer.
When I’m in Mode A at the computer, I’m cranking out lines of code, testing, revising, testing, revising, etc. This process must be very fast. Several hundred lines of code (or whatever) in less than an hour. A complete cycle in less than a couple of hours. My guideline is that if I’m not working that fast, then I must not be prepared to work that fast, so I don’t deserve to be at the computer. I should be in mode (B).
Mode B is generally much slower. Reviewing code, specs, or notes. Refactoring code. Laying things out with pen and paper. When I have enough work clearly laid out, I know it’s time to get back to the computer and return to Mode A.
The most important thing for me in Mode A is to see results, any results, quickly and often. It doesn’t matter how correct anything is, just as long as it’s progress (or sometimes, reverse progress). I like to think of programming as making incremental progress in micro jumps, evaluate where I’m at, and go for the next micro jump.
Some of the best advice I ever got was from a prolific artist friend of mine who claimed, “I paint every day.” So I started coding every day. But that wasn’t enough. Now I make progress every day.
There are many definitions of progress. Sometimes I copy a few hundred lines of code, make a few changes, spit out a new app, and then start applying micro changes. Other times I decide that I need to see today and find a way to get there. Things don’t always work out as planned, but that’s OK. As long as tomorrow’s starting point is beyond today’s, I’m satisfied.
That’s my definition of fast. Not sure that was what you were asking, but I hope that paints you an accurate picture.
“I’ve never seen anyone able to design something away from keyboard that doesn’t change significantly once it’s written”
It “does” change once it’s written.
The idea is to get a clear work plan on a “close enough” design. I estimate that my first cut of anything is maybe 50% or so.
The idea is also to avoid sitting at the computer all day and then being disappointed with how little I accomplished. Activity != accomplishment.
A little more background…
First term freshman year, 90% of science students took Chemistry I. On Mondays and Wednesdays, only 50% of the seats in the dining room were taken for dinner. Chem Lab started at 1:00 p.m. and dinner was at 6:00 p.m. So, most freshman chemistry students took more than 5 hours to complete their lab work.
This never made sense to me. I took Chemistry I second term freshman year. My lab partner and I made a pact to “never” miss dinner. We did everything we possibility could to expedite lab time. We did all the reading, planning, and reviewing other people’s results “before” we entered the lab. We even wrote our reports in advance, filling in the results as we went. Our longest lab took 2 1/2 hours. Our shortest took 1 1/4 hour. (We also both got A+.)
I still practice that methodology today. My computer is my lab and my bed or sofa is my lab prep. Preparation takes as long as it needs. Labs go fast. If they don’t it’s because I wasn’t prepared enough when I started.
“So why is it that as we grow up we lose all the passion, the energy, the will and the strength to keep our dreams alive.”
Because we lose so much energy in general.
Because we don’t take care of ourselves.
Anyone who has ever been to any Tony Robbins event knows that he always starts with health (eating right, exercising, and mental attitude) before addressing anything else. Because he already knows what many don’t: if you’re not feeling right, nothing else matters.
Almost all of us have ample energy in our teens and twenties. But as we get older, we have to make a conscious effort to maintain energy and vitality. Most people I know in their 30s, 40s, and 50s don’t do nearly enough. We slow down, put on weight, and lose energy. It happens so gradually that we barely notice. And we blame everything else: family, finances, lifestyle, etc. And we avoid acknowledging the elephant in the room: it’s awfully hard to get passionate about anything when we only have enough energy to plop down in front of
the TV with a bag of chips.
Most people I know with the energy to accomplish a lot, regardless of age, take care of themselves, especially those working 2 jobs or running a side business.
All of the other reasons (fear of failure, responsibilities, etc.) make sense, but I wonder how many people don’t follow their dreams simply because they’ve run out of energy by not taking good enough care of themselves.
I’ve always thought there were 2 types of things that could be optimized:
1. Things that need to be “cleaned up”.
2. Things that never should have been written in the first place.
Simple example of Type 1: You rush to get something up and running, and in your first code review, you find the exact same code multiple times. So you write a function, parameterize a few variables, tighten it up, and reference it all over the place. Cool.
Simple example of Type 2: You have an SQL SELECT inside an iteration. At 500 iterations it runs smoothly. At 50,000 iterations, it becomes non-functional. Your only hope to scale this thing is to rethink the whole process to run with one SQL SELECT (and maybe a database redesign) outside the iteration. You basically have to start over. What were you thinking?
You need to trust your “process” that Type 1 things will rise to the surface in due time, thus avoiding premature optimization.
For Type 2 things, there is no such thing as “premature optimization”. They need to be designed and written properly in the first place.
Bad design is “everywhere”…
My old microwave oven had one control, a dial. Just put the food in and turn it. The whole dial represented 12 minutes, so just estimate how far to turn it. My new microwave has 22 buttons. I forget which is which. I have to turn on the lights and get my glasses.
The previous owner installed vertical blinds on the double hung windows. Think about that. Impossible to have open windows without endless noise and movement.
An office where I work is near an airport. They have a key card system that beeps with a successful swipe. So you can’t hear the beep when an airplane is passing overhead (every 5 minutes) and have to wait until it’s gone to get into the building.
Another office has “gone green” and installed motion sensors everywhere to turn off lights not being used. Good luck finishing up in the restroom if you’ve been sitting too long.
Some of my software asks “Save before exit?” whether I’ve changed anything or not. I got so tired of trying to remember if I had updated or only viewed, I just click “Yes” every time. Pointless.
Every time the garbage truck drops the dumpster back down next door, 3 car alarms go off. No one ever responds, because they assume that it’s a false alarm. Not that big a deal until the garbage truck shows up at 4:00 a.m. on Saturday.
My TV remote has 33 buttons. So they’re so small, you have to stop and look at it to hit “Mute” or “Last Channel”, the only 2 buttons I ever use. Who designed this thing, a munchkin?
The airports in Orlando, Philadelphia, San Jose, and Miami put the restaurants (not counting junk food) “outside” of security. So you have to wonder, “Do I have enough time to eat and then get through the line?” (Pittsburgh, Tampa, and Chicago Midway did it right.)
The trunk release and gas cap release levers in my car are next to each other but not visible. It’s hard to pull one without the other. Seems like my gas cap door is always open.
A theater we went to the other night only had aisles on the sides with 50 seats in between. Do your really want that great seat in the center knowing you may have to climb over 25 people if you need the restroom before the movie is over?
Intersections that gridlock because of traffic from the next light. Too many to mention.
Microsoft Windows.
There’s an elephant in the room: your best people leave because you’re not paying them enough.
And you’re not paying them enough because you’ve chosen to adopt a pay structure that, by definition, cannot handle outliers (which are exactly what your best people are).
An excellent programmer can routinely do the work of ten mediocre programmers. Have you ever heard of a pay scale that pays Programmer III ten times as much as Programmer I?
An excellent programmer can save you millions of dollars by increasing revenues, reducing costs, changing the way you do business, or any combination of these. How much of those millions does the programmer get?
An excellent programmer can provide a company significantly more value than his boss and his boss’s boss.
How much more does he get paid?
An excellent programmer can earn real equity and merit bonuses in enlightened firms. How many companies don’t even have this on their HR radar?
An excellent programmer can go out and pound the pavement or join a start-up and earn what he/she is really worth. And until most companies provide that same opportunities, they probably will.
How do I find customers? I just talk to people. All the time. I allow my inquisitive nature to take over. But most importantly, I really care. A mentor of mine once told me that lots of people need what we provide, so it’s our responsibility to find them and see what we can do to help.
If I’m in someone’s business (even as a retail customer), I often ask to watch as they enter data into their customer facing system. This invariably leads to some discussion and who knows what else. I attend events and network regularly, even if it’s just staying in touch with acquaintances and asking what others are up to. Email works really well for this.
I don’t have a solution in mind because I want to listen to the other’s problems first. If something I have written (generally small business or e-commerce) sounds close to what can help them, I may go down that path. Anything else, I pass, but gladly provide a referral to someone who “can” help, if I know of any.
I don’t cold call in the pure sense. That’s just not my nature. If I ever got good at that, then I wouldn’t need to be a programmer, I’d just sell someone else’s product.
I think that your first step in becoming “addicted to programming” is understanding what building stuff really is: intense sprints of orgasmic discovery separated by long periods of building the prerequisites. Once you understand which phase you’re in, you can better understand why you feel the way you do.
A perfect example was my project last week. I had to make 14 changes (including 3 major structural reworks) to an existing application to produce one additional output. This output was key for a fundamental shift in thinking about the use of the app.
My week was actually fairly predictable:
Monday was fun for a while, thinking about how it would work, what needed to be different, how the data has to be restructured, and how cool the new results would be. But things became drudgery when I had to lay everything out build my work plan.
Tuesday sucked, tearing apart code while trying to maintain an audit trail and balancing the new functionality with keep everything old still working.
By Wednesday, I didn’t even want to work on it and spent a lot on time on-line, playing games, and surfing the internet. I struggled getting the final pieces in place.
On Thursday, my interest piqued when regression testing went almost flawlessly. But no matter, even if it didn’t, being in “getting it to work now” mode always captures my attention.
Friday was bliss. I was cranking code, unit testing, regression testing, reworking, getting the results I foresaw on Monday, and doing a happy dance every 20 minutes or so. Time flew as I worked into the night getting all this cool stuff working. I wish every day could be like Friday, but I needed to pay my dues earlier in the week just to get to that point.
I wish I had an easy answer for collapsing the long hours of building the prerequisites and expanding the time spent “in the zone”. The only suggestion I can make is get to the point of having “something” for output as early as possible. That’s when the fun usually begins. Until you reach that point, just understand you’re in “courting” mode. Just keep on working and the digital orgasms will arrive. Once they do, it’ll be worth it. Don’t worry, you’ll be “addicted”.