Working as a programmer - is it what you thought it would be?
12 comments
Since my best and most enjoyable programming happens at home during off hours, I wonder about how good the job is. If you happen to work at a company that 'gets it' (let this mean whatever YOU want it to mean, different for everyone), it's probably the best job around for a tech oriented person. However, LOTS of companies don't 'get it', and they make longstanding infrastructure decisions that make our job less fun and productive.
It continues to amaze me that so many companies, my present one included, recruit people with a lot of talent and experience, pay them a lot of money, and assign them exactly the same work as the interns.
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.
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.
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.
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.
Good point.
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.
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.
How do you do italics on Hacker News?
Working as a programmer.. I love the creative aspect where you build up something from scratch (translate photoshop/powerpoint mockups into code). I like fixing bugs because it appeals to my perfectionist nature - bringing up overall quality - I don't know why some other coders are loathe to fix bugs. It's easier to quantify what you have done, as opposed to my marketing/business friends who have to make a case for what they've accomplished. And you make enough money usually to support a lifestyle outside of coding (travelling, hobbies limited only by your current limitations).
In the past couple of weeks, I've been spending some time with a friend building a small Rails app in our spare time (which I don't have much of, since I have to work full time for my paycheck), and realized that I'd forgotten how pleasant it is to be DEVELOPING software, even simple software.
I don't know why some other coders are loathe to fix bugs.
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.
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.
It's not a bug if you need a requirement to fix it.
That's my personal rule. Yes, you still need to change the code but it's not a bug.
That's my personal rule. Yes, you still need to change the code but it's not a bug.
It is so much better than I ever could have imagined that it would be. It is a daily game of show and tell where we get to show off the cool things we got working. If you had told me 20 years ago how much fun it would have been I simply would not have believed you.
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.
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.
I have a 15 year-old brother who shows some knack for programming. I've been thinking about what kind of career advice I would give him related to programming. I might say something like, "Being a software developer is awesome, but being a corporate software developer is awful."
Sometimes I wonder if I should just tell him to keep it as a skill but eschew it as a career.
Sometimes I wonder if I should just tell him to keep it as a skill but eschew it as a career.
I think (and I discovered this far too late :-( ) that the most interesting programming is done by people who aren't really programmers. People who apply software to knowledge domains. A biochemist can learn Python a hell of a lot more quickly than a programmer can learn about protein folding, for example. A friend of mine is an astrophysicist and writes programs to model stellar events (then goes and checks his results with uber-telescopes). Me, I can connect interfaces to apps to data, I do a pretty good job of it (tho' I say so myself!) but what am I really adding to the sum of human understanding? Hmmm.
Well, I would argue that much of what has emerged on the Internet in the last 15 years has been novel.
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 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.
Except that a biochemist learning Python to solve problems he/she has in protein folding research (or whatever) is a useful skill to get things done in his/her field. A programmer learning about basic lab equipment probably isn't going to help too much in developing software (although it might help him/her get more attractive dates).
And protein folding is much more useful to humanity than compiler optimization. Does anyone even work on compiler optimization anymore?
And protein folding is much more useful to humanity than compiler optimization. Does anyone even work on compiler optimization anymore?
If it wasn't for the programmer creating languages that make massive, fast computation accessible to the biochemist, there would be no Python for the biochemist to use to do their research. The programmer is just once removed from the "important to humanity" aspects.
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.
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.
As someone who has published research on protein folding, trust me: compiler optimization is about a thousand times more useful.
Protein folding is the biochemical equivalent of string theory. It's fun to talk about, but the practical applications are perpetually 20 years away.
Protein folding is the biochemical equivalent of string theory. It's fun to talk about, but the practical applications are perpetually 20 years away.
Then we are in the same club. I've published research on global optimization algorithms for protein folding. I'm not a biochemist, but I understood that protein folding actually has immediate application in understanding disease and drug design.
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?
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?
"I'm not a biochemist, but I understood that protein folding actually has immediate application in understanding disease and drug design....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!)
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!)
Thanks for the very detailed answer. Amazingly, I can follow the gist of it after over 10 years.
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?
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?
I did answer your question, but now you're asking a different one. I have no idea how "important" protein structure prediction will ultimately become; I just know that it's currently pretty useless, and getting worse.
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.
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.
I'm asking the same question, and you're not close to answering it. My question was "what problems in compiler optimization make it a thousand times more useful than protein folding and associated medical problems?" because you authoritatively stated that protein folding work (implicitly computational protein folding work) was much less important/useful (pick one) than compiler optimization work. You keep talking about protein folding research, but you don't say anything about compiler optimization. Was that comparison just an off-hand or self-deprecating remark about protein folding work? I'm not asking which area is more important. And, I know enough about both fields to not get lost in the technical details of your answers. So, I'll ask it again: what problems in compiler optimization make it a thousand times more useful than protein folding and associated medical problems?
If you want to know the most important/useful areas in compiler research, go ask a compiler researcher. I'm not a compiler researcher.
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.
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.
[deleted]
I didn't mean for people to focus on "protein folding", that was just an example of something that scientists do that's computationally intensive.
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 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.
Wow. This is really enlightening; I thought that the computational method was going to open a new phase in disease treatment, but you seem to say here that the empirical method is on its way to making it useless. So the Pande group at Stanford is wasting their time. Interesting.
"So the Pande group at Stanford is wasting their time."
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.
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.
Is it the weakness of the modeling or the lack of computational horsepower that limits the research in this area? And would you mind linking to your papers?
That's a matter of debate. Some people think that the problem is search limited, others think that the current models are bad. In my opinion, the bulk of the evidence supports the latter conclusion.
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.
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.
Will do. And thanks for the info, you may have spared me a decade or so of wasted effort.
Oops...that third paragraph should read:
"the vast majority of proteins are much larger than 150 residues."
"the vast majority of proteins are much larger than 150 residues."
Can you show me how I can learn biochemistry in two days? I would be really interested!
No.
But if you haven't learned anything new about programming since two days after you started, you're doing it wrong.
But if you haven't learned anything new about programming since two days after you started, you're doing it wrong.
Well I remember learning Python in one day. If I could do the same for biochemistry, it would be fantastic.
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.
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.
You learned the rules of chess in one day, but how many chess games will you win with only one day of experience?
[deleted]
Coming from someone who has been involved in Biochemistry research and software development - I prefer software development. Here's why: in both fields, you get to explore and break new grounds, but you move much faster in software development.
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?
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?
Friends of mine in neuroscience, who do electrophysiology, love the instantaneous gratification of it: patch onto a cell. Watch/listen to it fire. Treat it with chemicals. Treat the cells innervating it with chemicals. Make them fire with external electrodes. Etc. Do this multiple times, over a period of months/years, until you have dissected some local circuitry properties. Pretty cool, if you get off on listening to neurons fire, day in and day out.
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. 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.
Upmodded for
"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.
"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.
My take on this situation:
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. :)
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. :)
My perspective: I've wanted to be a developer since I was like 11, and first started using HyperCard on the Mac. I liked being able to create stuff and share it with people (via AOL shareware libraries, back then :P).
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.
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.
That would be good advice to your brother. Programming as a career seems like a dead end going forward, for whatever reasons. However, if he is in some other seemingly unrelated occupation (law, medicine, education, etc.), then programming skill could be a competitive advantage.
Tell him to keep programming as a hobby. If he truly enjoys programming, he'll keep on doing it and getting better and better at it no matter what else he does. Above all, I'd suggest avoiding a CS degree, since most of the stuff he'll learn there will be stuff that he would learn on his own time anyway. If you're going to go through the effort of going through university, might as well learn something that you wouldn't have otherwise (I did Physics).
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.
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.
To answer the original question: I have been a programmer for 11 years and love it. There are ups and downs, but mostly ups.
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.
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.
Yup, corporate work is not necessarily as evil as it sounds.
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.
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.
It is everything I thought it would be, in both the good ways and the bad.
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.
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.
One of the best decisions I ever made.
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.
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.
Just out of curiosity - do you live near a major metro area or get your gigs virtually? I am just about 4 years into an enterprise job and I look around and see the dead eyes of many 18 year on the job coworkers and I shudder - so I'm thinking about taking a job elsewhere just to keep fresh - but the money is so good and the work is so damn easy I worry that I am going to be shooting myself in the foot. The reason I ask the geography question is that there aren't that many companies in the area I live so I am more inclined to keep what I have rather than roll the dice. But the few times I have consulted I've noticed how much sharper I got - because I had to be.
Yes. I have always lived in a major metro area. 6 of them.
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.)
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.)
I can't imagine of doing anything else. It is basically like fooling/playing around. At work, sometimes it gets repetitive and boring -- so what I do, I conjure up a small project at home or do some freelance or in some cases dabble with a programming language that I know nothing about. Then when it gets busy at work or when something comes up interesting, I take it slow on the sidejobs/sideprojects.
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.
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.
I enjoy the constant learning required to solve new problems.
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.
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.
It's been even better than I thought it'd be. I almost switched out of Computer Science in college because I was fed up with the boring classes, but I'm glad I didn't. Getting paid to program rocks!
Programming has its ups and downs, but on the whole it's what I love to do. It's like each program is a little baby; making it is lots of fun (;))and seeing it grow up, even better.
Working for someone else has its problems. Working on my own projects, I feel heroic. Like Prometheus.
Never before have I had so much power to do so much good.
Never before have I had so much power to do so much good.