In some cases, they end up having the interns build the new stuff and the seniors maintain the crap that the previous interns built... and they wonder why their systems are bug ridden, poorly thought out, and require gargantuan amounts of effort to fix.
I think the problem is that nobody wonders about this. They think it's normal for software to be broken and very expensive to maintain.
If you watch a novice user use software, you'll notice that they blame themselves when the software fucks up. If they're in a building that collapses, however, they blame the engineer. I'm not sure how we convinced users that bad software was their fault, but it's not something I'm proud about. "Civil Engineering" means something. "Software Engineering" is meaningless.
The other problem is that programmers don't know what users want, and users don't know what to ask for. So we guess, and they're unhappy, but they don't know why.
sigh.
One depressing thing that I've noticed is that most of the best people I know in the field are seeking to leave it. This community is for an exception, although it probably has a lot to do with the fact that I was in the DC area for most of my career, and most of the work there is government-related in some fashion, even in the startups.
Still, the fact remains that because people are willing to accept crappy software, the bar for entry is low, and the industry has a tendency to drive out the good people by treating them the same way that they treat the bad ones, which is to say, like peons.
It's because they think that somehow their first revision is going to be perfect, and they've failed if there's a bug in their code. Also, it's annoying when a "bug" is a change in the spec.
That's my personal rule. Yes, you still need to change the code but it's not a bug.
Programming opened the whole world to me and I've written code in Africa, Asia and Europe in addition to the small New England town where I live now. The money is respectable, the hours are flexible and I always have the opportunity to learn something new and try a different approach.
I simply cannot imagine a life where I do not get to run up the stairs to my office and bounce in anticipation as emacs fires up for another day of profound geek joy. I do not ever plan to retire, they are just going to have to pull me kicking and screaming away from the keyboard someday.
Sometimes I wonder if I should just tell him to keep it as a skill but eschew it as a career.
And a biochemist can learn the basics of Python about as easily as a programmer can learn how to operate basic lab equipment. A biochemist could no more easily add to human knowledge about compiler optimization than a programmer is likely add anything to protein folding. If anything, I would say the opposite of what you claim is true -- programmers are more likely to be interested in leading-edge science as a hobby than the other way around.
And protein folding is much more useful to humanity than compiler optimization. Does anyone even work on compiler optimization anymore?
And if it wasn't for the programmers who get excited about languages and pioneer different uses of them, the biochemist would most likely never even know there is this tool available for them to use.
Protein folding is the biochemical equivalent of string theory. It's fun to talk about, but the practical applications are perpetually 20 years away.
As a computer scientist, I also understood that compiler optimization is a mature field with most of the low-hanging fruit already picked. So, I guess I'm confused and will ask respectfully what problems in compiler optimization make it a thousand times more useful than protein folding and associated medical problems?
Short answer:
Compilers are used for real work, every day. Nobody is using protein structure prediction for anything practical, and they likely won't be for decades more. At this point, it's blue-sky research.
Long answer:
"Immediate application" is one of those bits of academic-speak that really means "is related to", but sounds better to grant review boards. While it's true that protein folding is important (after all, most biological processes are mediated by folded proteins), it's not true that protein structure prediction is important. It would be great if we could predict protein structures accurately, but we can't, and until we can, it's not a practically useful discipline.
Even the very best, crystallographically determined protein structures are barely sufficient to do rational drug design, and predicted structures don't come close to that level of quality. For example: we can sometimes (very rarely) predict very small (<150 residue) protein structures to within 1 angstrom RMSD of their experimentally determined shapes (i.e. >2 angstrom resolution, in the best case). However, the interactions important to drug binding, protein design, etc., don't start until a tenth of that (scales of ~0.1 angstrom).
Throw in the fact that the vast majority of proteins are much larger than 150 angstroms, and that we keep creating cheaper, faster, more automated ways of getting actual experimental information on structure, and the role of protein structure prediction looks increasingly marginalized. It's definitely a cool, fun problem -- just not a very practical one.
For whatever it's worth, my first papers were on applying the state-of-the-art method (you've heard of it...I think you're paraphrasing the lab's PR) for protein structure prediction to genome annotation. To call the approach useful was/is a stretch, and that's for a much easier application than drug design (in fact, we were trying to find a practical application for protein structure prediction, and it was the most likely thing we could think of!)
But, you still don't answer the question. What problems in compiler optimization are more important than problems in protein folding? You seems to indicate that protein folding is a basic science problem and not a "practically useful discipline". In fact, your statement "It would be great if we could predict protein structure accurately, but we can't, and until we can, it's not a practically useful discipline" says that the because the problem isn't solved, it's not important, but it will be important when it's solved. So, trying to solve the problem is important, no?
But, you don't say anything about compiler research, and specifically compiler optimization research and development, which you claimed is much more important. What specific areas in compiler optimization (or just in compiler design) are more important than protein structure prediction and modeling?
My first comment was that compiler optimization is about a thousand times more useful than protein folding. I stand by that remark. However, at the beginning of my long answer, I mistakenly wrote that protein structure prediction is not important, when I had meant to write that it is not useful: protein folding is an important biological process, but protein structure prediction is not particularly useful, for the reasons I've mentioned.
It's not my place to say which area of research is more important. That's a subjective question, and the answer depends on your value system, your outlook, and your willingness to wait. Obviously, I think that compiler optimization is more useful, because compilers are actually in use today. In 100 years...who knows?
That said, I think you're laboring under the assumption that compiler optimization is a "mature" field, and that it is "solved" (and therefore less important), whereas protein folding is not "solved" (and therefore more important). The thing is, people have been doing protein folding research for at least fifty years -- it is a very mature field, and the low-hanging fruit has been picked. I think that a new researcher is equally likely to make significant gains in either field, but that the potential for practical impact is still much greater in compiler design.
Compilers are used on a daily basis for real work; protein structure prediction is not. For this reason alone, research into compilers is more useful.
I find myself in my early 30s knowing an awful lot about database applications, but zero domain knowledge. I can go into any field and implement a spec, but I don't understand any of it. Someone wants a graph of this data in their application, I'll give them a great graph, but I look at it and it's just squiggly lines to me. I just feel like I'm missing something.
I wouldn't go quite that far. The research is definitely speculative, but lots of interesting things can come from speculative research. My point is that you don't do research into protein structure prediction with the intent of finding anything useful. It's basic science.
We can (and occasionally do) learn things from computer models of proteins. But the PR in this field has been seriously exaggerating the results of a few of the more prominent researchers. We're a long way from curing diseases or designing drugs with this stuff.
Backchannel me, and I'll be happy to provide you with references to the papers I wrote/helped write. Most of them aren't open access, unfortunately.
"the vast majority of proteins are much larger than 150 residues."
But if you haven't learned anything new about programming since two days after you started, you're doing it wrong.
Maybe it is only the lack of hands on tutorials that is the problem, though. There are tomes of biochemistry books, but I suspect after reading them you are still not sure what to do.
To do anything interesting self-directed work in the life-sciences, you have to get a PhD and by then, your hands are still tied down to the government because you have to write grants to NIH. Unlike programming, where you hatch a idea, Google sample code-sources, dive into a hackthon and build a prototype after one evening of intense programming. Biochemistry takes months of patience, where you micropipette and shake test-tubes, use the PCR machines. It is hard to deciper the details, you can't step-through the codes of DNA (at least yet) or trace the memory stacks of the cells that you are studying. Coming from a programming background, I was so frustrated in Biochemistry.
Also you should know that the life sciences is slowly being transformed into a information sciences (Bioinformatics). There's a movement in the field called System Biology, that treats the body/a cell/macromolecular as a finite automata, the DNA the source code, and the protein products it makes the output. Sounds familiar?
I think the key in science is to do something that is interesting and pleasurable in both the long and short term. My electrophysiologist friends like it day-to-day, and also like the long term agenda of it. Sounds like you liked the long-term agenda of biochemistry, but not the day-to-day.
Probably similar lessons apply to hacking. For me, I got out of it: I didn't like how I felt after looking at a glowing monitor for 12+ hours a day, week after week. I like programming this intensively when I feel like it, but not when I'm pressured to do so for some business goal.
"I think the key in science is to do something that is interesting and pleasurable in both the long and short term."
I discovered that this (the hard way, after a decade buildng enterprise software) is true for software dev too. Now I do algorithm intensive work and there's more to do than I have time in this lifetime to do.
At 15, I'd say he should try a few other things he finds interesting or thinks he might find interesting. Pursue them enough to actually get pretty good at them, it's hard to judge early on. When the time comes to choose a university subject/career, he should go wherever his heart lies.
Why?
At school I was (really) good at physics, (I got through to international level at the Physics Olympiad) but I never really fell in love with it, and actually didn't go to the international event a second time, as I hated the people there. (I made a couple of friends on the national level though)
Programming in my spare time was what I loved most. I ended up doing physics at university based on advice from the people around me. About 2-2½ years in, at the stage where I could no longer get away with minimal work and still get decent grades, I first consciously realised that my heart was just not in it. I finished my degree but haven't touched physics since.
Oddly enough, with all my focus being channeled on physics at school and by my parents, I kind of missed out on really getting to know maths beyond what everyone was taught at school. At university it turned out I most enjoyed the maths modules and consistently got the best grades in them, although I unfortunately wasn't permitted to choose many maths electives. Also, my university wouldn't let me switch subjects and carry over any credits, so I didn't.
My girlfriend studied maths so I managed to learn quite a bit from helping her out, although I can't help but think that doing a joint CompSci/Maths degree would have brought me more joy.
I've stopped taking advice from family now by the way, and I'm a lot happier. :)
I've been out of school and working for a big company in the InfoServices dept. for 2 years, and it sucks. Great pay, benefits, really boring support work with lots of vendor management and semi-incompetent peers. So tell him not to do that.
But if he likes development, I'd definitely encourage him to be a developer. I'd just strongly encourage him to start writing his own stuff now. Don't get bogged down with the coursework in college, but start a few personal projects and finish them. Sell them if you can, but don't focus on Big Money, just do fun stuff.
And when school's over, at least try doing your own thing before taking a job somewhere. I didn't try; never really thought it was an option, and now I have to do my project on the side. Definitely doable, but when you're young, it's a great chance to give it a try fulltime. I think PG's mentioned this kind of thing in his essays ;).
Uh, I'm rambling, but it boils down to: Encourage him, but let him know that the real fun of software development comes in an environment where you have some control/responsibility, and lets you use some creativity without going through the bureaucracy.
So get good early, do some fun stuff, get a job somewhere cool or start your own thing. Programming is fun, but I wouldn't recommend the big company path.
Please note that keeping programming as a hobby doesn't mean it won't turn in a job if he needs it to (as it has for me) - only that he will always be a well-rounded person rather than just a tech-only programmer.
Also being a corporate developer is not awful at all. It is great. It might depend on the environment and the corp that you are talking about.
The big factor that I have noticed in my enjoyment is working in an Extreme Programming environment, specifically pair-programming.
Take my situation for example. In theory, my company sells a library that is embedded into set top boxes. It's written in C, as that is the only language available for many platforms in the embedded space.
But in reality, I spend most of my time hacking in Ruby, doing tools. For example, a while back, to stuff up pirates, I transferred the lib to run inside of a virtual machine. I wrote a tool that took a relatively short description of an existing processor, parsed the file, and generated the C code to emulate the processor.
Then, in testing we found that asynchronous cryptography was just too slow in the VM, so we needed to move it back out to native. I then wrote a tool that could examine the two that were compiled (inside the VM, and native), identify the missing functions, and then parse the header files for each lib to automatically generate the code that serialised the parameters crossing the interface of the VM.
Right now I'm working on a tool that is very similar to distcc, to speed up our compile times - when we prepare a delivery of the software, we have to verify that everything compiles correctly without warning on about 30 different platforms, with about 6 different options being available. that makes nearly 200 builds, with each build taking about 10mins. You can get old checking for compile errors, and then correcting them. We're hoping, with the help of a server farm and my tool to get that time down to about 10 mins.
In fact, I can't remember the last time I actually worked on the actual problem domain at my company. I spend most of my life working with binary files, compilers, simple parsers and other pure computer sciencey stuff.
So much for corporate work being boring. That said, I'm working hard on an application for the Mac that I'm hoping to sell, as I'm over having to play politics to convince PHBs that there are improvements that can be made to the product.
In the big corporate world, there are places where bureaucracy replaces the beauty of the code. You sit in meetings discussing what the code should do, often for longer than it would take to actually write it. I was in a meeting to discuss a prototype once which degenerated into an hour long discussion on the label of the 3rd text field on the screen. The bottom line is that in some big companies, the goal is to work as little as possible. If you want to write code (or maintain sanity) , avoid these at all costs.
I'm now working at a NASA contractor, and the work is considerably more interesting. Still, we are plagued with drama but at least there's always something to do.
In short, just like any career there are the boring, stressful and tedious aspects. There is also the pleasure of imagining how code should function, then immediately seeing it come to place. I'd rather be in control of what I'm working on, but until that day comes I'm happy.
Is is "what I thought it would be"? I don't know. Because I had no idea what to expect. (I did my first programming on the job; I started before there was much opportunity to do it on your own.)
I have done projects at over 80 companies. I have gotten involved in almost every aspect of the business. I have travelled all over the country, met many interesting people (and friends for life), and have constantly been learning and doing. Oh, and I have earned far more than most of the people I have ever worked with. It wasn't unusual for me to be earning more than my supervisor and much, much more than my users.
I have done lots of work on my own and have taken lots of time off between gigs.
Sure, there have been lots of negatives. I've even thought of leaving IT and doing something else. I know many who have. But then I think about it and realize that this is what I still really want to do.
There have been horrible working conditions (cubicles), unreasonable people (let's just leave it at that), terrible projects, long commutes, and worst of all, boredom and disapproval on someone else's project. But instead of whining (present post excluded), I always did something about it. I either fixed what was broken for me or moved on.
Because of modern technology and lifestyle, I am more excited about being a programmer than ever before. I don't want to sound like an old timer (I know, too late), but I clearly remember how hard it used to be to get good. I had to go to expensive seminars or to one of the half dozen good technical bookstores in the U.S. My first computer cost $6000 (double that today). Now with cheap hardware, google, downloadable environments, boards like this, and Borders around the corner, everything is so easy! I just can't get enough.
For someone even mildly interested in programming, I would say, "Go for it!" Get a job and play around on your own. Learn as much as you can, technical and business, and if you don't like where it's heading, find a way to make it work for you. Give it a chance. I'm sure glad that I did.
dead eyes of many 18 year on the job coworkers
I can't imagine 18 years in the same job. Sounds like 1 years experience 18 times. No wonder they're eyes are dead.
the money is so good and the work is so damn easy
I know. I haved walked out on many a good gig because I knew it was time. It's never easy to do that.
inclined to keep what I have rather than roll the dice
Why not do both? Find something better, then quit. (You're right to be cautious: I wouldn't want to be out of work with less than 6 months expenses set aside. 2 years would be even better.)
Seriously, when I think of it, I can do this my entire life. The only thing that can probably stop me is having my own startup -- still, I will still be doing some programming. It's weird, I can't think of anything aside from it.
To echo some other sentiment in this thread, take the problem domain you are most passionate about and find a way to improve it through programming.
I once ended up in a rut where I was not learning and I had been on the project too long (I was still passionate about making things better, but I was swimming against a tide of corporate inertia). I went back to graduate school part time to address the boredom, and moved to a project that I liked and had enough unsolved problems to be interesting for a while.
Never before have I had so much power to do so much good.