I have found that even in writing code that never sees the light of day, there is something positive that can gleaned from the experience.
How else do you learn what not to do? Which is just as important as learning what to do.
also, I’ve had the experience of coding features that the user didn’t know the needed until they started using them. Then you get e-mails like “you have cut my administration time by 20 hours”. When I wrote the feature, I “Assumed” that the user would use it. but we do that for all features.
My question is what is the best way of identifying which features have the highest probability of being useful?
My directly-written software gets used every day by hundreds of thousands of people. You can kick that up into the millions if you count code based on mine or derived from mine over the course of the last decade. Prior to this particular job my code was in limited venues, and now it’s literally world-wide.
Fun stuff, but a big responsibility, too. The next release must live up to the quality of the prior releases, and now needs to incorporate ideas about software design we didn’t have 10 years ago. I don’t just write new code for new releases, I have to revise existing code to match the new code (and keep an eye out for future maintenance coders).
The good news is, it never gets dull. I’m starting a major new release today, and I’ve got about three weeks to finish it. Hey! What the heck am I wasting time here for?
Jeff, you make an excellent point but sometimes it’s completely out of a programmer’s control to ship a usable product. What do you say to programmers who have to deal with unrealistic deadlines, ridiculous requirements and a producer that thinks having the site done in all Adobe Flash is the way to go?
I can write code. No I can write good code…but without everybody on the same page it’s hard to make something that really gets used by the end user. The fact is Chuck Jazdzewski’s quote is still dead accurate: If a measure of success is if I ship a product I believe as a programmer I have succeeded. But on that same token shipping software doesn’t necessarily mean you shipped usable software and you can’t expect the failure of people not using the program is the software developers fault.
I don’t think number of users matters. I would rather write something that the top 10 brain surgeons in the world rely on to do their jobs than write several lines of trivial code in Microsoft’s TCP/IP implementation that get used by 100,000,000 people a day.
I agree with him more than Our Host. Here’s why. There are two broad classes of coders; coders for hire and developers. I’ve worked for both kinds of organizations and been the customer of both kinds. The latter is preferred over the former. Being a coder for hire is awful, as the article demonstrates; not much different from bricklaying. Being a developer working for (or being The Smart Guy) is better by any measure. The Vision Thing does matter. It is the reason that software development really exists: to implement a Better Way to do something. A Better Way To Do Something almost always comes from a subject expert who: does know a Better Way, knows this strongly enough to tell the client to Stuff It when called for, and does want to get the code right (it expresses His Vision).
Oddly enough (superficially, odd) the client gets a better system through the application of Tough Love: “you’re a freaking fool, just shut up and do what you’re told”. Clients who think they’re in control because they’ve got some coders on billable almost always end up with drek. They get what they deserve. If you’ve spent any time in the financial industry you’ve seen lots of 1960s software running around in Pixel Dust. Amen.
I’ll be honest, the little bit of code I’ve released outside of my own computer (most of my code was for myself) received a small amount of use. But 450 people using my program as opposed to just me is still a heady thing. I once uploaded an app to AOL in the mid 90’s. In the early 00’s I went back in and checked on it, and it had gotten over 10,000 downloads. There’s still one of my apps floating around out there that some use, even though I haven’t supported it in years and years. That’s an interesting experience.
What was sad, though, was that I had a computer that had three full-fledged applications ready to ship when my company folded and took the software. I wasn’t even writing the software for them, it was my own private effort on the company computer. I learned, then, to never put anything on my work computer. A simple lesson, now, but one hard learned when I was a teenager. I’ll never rewrite those apps again.
Anyhow, writing code SHOULD be fun… but most often, it simply isn’t.
The greatest thing about being a professional programmer is getting a paycheck.
Yes, it is truly great if hundreds/thousands/millions of users use/love your app. But, to be quite honest, I don’t really care from a standpoint of personal satisfaction. I want the users to use and or love my app but that’s only because I want to stay employed. Do I take pride in my code, my UI design? Of course I do. But I won’t lose too much sleep if my boss says the powers that be have killed the project I’ve been working on for months.
As long as I’m treated with respect, given a proper working environment and collect a decent check on Friday then all is golden.
If you want to feel true personal acheivement from coding then code something you want to code in your spare time. Make certain it is something you can put your heart into and nurture and develop using your standards and your guidelines. Then when it’s ready toss it out there into the big wide open and see if people like it (and more importantly will pay to use it).
I’m young and not yet at the employable stage. It scares me that I might end up having to write pointless code until I think that’s what I’m doing at the moment.
And Mike, Google Code Search can be used something to that effect, I’ve pouched and adapted a lot of code I’ve found there. It’s also very useful as extra documentation if you don’t know how to use a library.
Thank you! This is inspiration. I write lots of fun throwaway scripts for the purpose of learning this-or-that esoteric language. I have lots of ideas, but nothing ever gets done. I have now cleaned out my “~/Dev/Projects” folder and permanently trashed most of the half-finished messes that did nothing in order to focus on only two real usable projects.
I think you are all missing the fact that you don’t know beforehand what will be successfull and not, that’s the reason why large companies have hords of people that seem to do nothing or working on projects that may seem useless. Who knows ?
Also, as long as you are coding you are learning, it’s careless to say the only thing that matters is to ship, Rich Skrenta seem to go as far as to say that work on standards is useless, thats pretty important work in a long perspective.
sometimes it’s completely out of a programmer’s control to ship a usable product
Is it truly out of a programmer’s control to ship a usable product? If so, then that’s a type of programming I would choose not to participate in. You can change your organization, or you can change your organization.
“Some people want to write the best software in terms of size, speed, elegance, etc.”
Sorry, elegance counts for squat. An elegant solution may satisfy intellectually, and just as several have mentioned, there is value in this. However, relative to success in software development (the main point of the post), it matters not.
I just finished a (beta) sub-system that I’m convinced would greatly simplify our process and increase productivity. As I was working on it, I tried to imagine the reasons (perhaps good reasons) that it would not be adopted at this change resistant organization.
In the end, nobody even looked at the camtasia demo I recorded. Worst outcome ever - I picture myself explaining this in some future interview, “it really was a good idea and would’ve been useful.” Yeah, right - prove it. Worse than failure.
that’s a type of programming I would choose not to participate in
Good point but if I changed my job everytime I was unhappy with the direction of the application I’d probably have a resume 20 pages long. I think it’s a fine line just like anything else in life.
But I agree with you…everytime I find someone complaining I just tell them…DO SOMETHING THEN!
How many users actually use your application? Now that’s the ultimate metric of success.
I would rather my programs be very useful to a few dozen people than to be only slightly useful to thousands. Mind you, all my applications apply to a very narrow field of users so this might not apply to all types of programs.
In the long run I would like to lead the function of a large organization.
In the short term I would like to build up myself as an efficient employee through knowledge, skill, responsibility and honesty.
For a few years I had the distinct impression that nothing I wrote would ever see the light of day. I went from project to project working on code that eventually got scrapped because of a change in corporate direction or because the client changed their mind about something. In once case I was hired into a large computer company that rhymes with Hell where on my first day I was informed that the large project I was hired to work on had been canceled, so find something to do while we figure out what we’re going to do next. After bouncing around for awhile I took a job with a smaller company but within two weeks of being there I started producing applications that were used on a daily basis by about fifty people in the company and got continual feedback. It was one of the best feelings in the world, having people come by and say “This is great! Now if only it would also do this…”
Two or so years ago, while discussing a late-‘90s start-up I used to code for, a new co-worker asked me if my application was still in use. It was food for thought then…and now a defining metric along this thread for me includes “How long is my application in use?” I am very please that two of the applications I devoted years of my working life to are still in production. (Eight years and four years, respectively.) Sure, some (much?) of the code has been refactored out of existance, but data structures and business object taxonomy has most definitely endured.
This “how long in production” metric is personally rewarding, I recognize this and the viability of my new employer’s application played a significant role in my decision to join the team last summer.
