I'm not a Libertarian, and I've read a lot more Dickens than Darwin. But I'll answer this anyway.
You are absolutely correct that class structure is real in the US, and growing.
I also agree with you about the absolute uselessness of trust fund babies who grow up rich...like, for example, George W. Bush or the Kennedys. You're dead wrong about how they got rich in the first place, though. At least one of their ancestors worked really hard, provided something lots of people wanted, and made wise investments. And decided he'd rather his descendants be useless parasites than be forced to do it over again.
Fair enough. Whatever. That's one motivation for working hard, and it's not like they actually hurt me (well, except for the ones who get into Congress and spend their days schmoozing for campaign bucks or figuring out ways to control my life).
Then again, we also have a few self-made billionaire monsters like George Soros. No system's perfect (although he seems to have gotten where he is by exploiting the collectivism in the system).
The gap isn't there because the rich just magically get richer and the poor get poorer. And mugging the rich to feed the poor doesn't make the poor more wealthy. It just makes them dependent on the mugger.
Most of the problem is class envy, people's world view, and the government interfering in the free market.
You create your own reality. Sure, some people are born with advantages, and others seem to have insurmountable disadvantages. But, sooner or later, people have to grow up and accept responsibility for their own fate. See Shawn Stephenson.
How do you get that utopia where "workers self management that allowed everyone to receive the product of their own labor"?
IIRC, there have been at least a couple of countries that tried to make that happen. Seems like they generally wound up with genocide, a dictator, and a bunch of miserable people who did their lazy best to contribute as little as possible.
Capitalism stinks...but it's still the closest thing we've discovered to a "fair" system that has a prayer of working in the real world.
Well, it would be if we could just convince the government to give it a chance. Which may mean that it's just another utopian fantasy.
Sure, if you take a few steps back and look at everything from a different angle.
The "field" I'm talking about is the one that involves the Von Neumann implementation of the Turing machine we're using to have this discussion.
You are correct that "formulating algorithms" is at least as old as recorded history. But that's math. "Computer science" is a specialized branch of that field that has something to do with creating machines to implement those algorithms. I'd say that programming is the practical application of that "science" to the real world.
Maybe the communication problem here is that, in general, most people equate "computer science" with "anything dealing with computers." I have a friend with a master's degree in computer science who never got deeper into computers than Power Point.
It depends on the project and the programmers, obviously.
It'll be a lot faster and easier to tweak algorithms in Python than C.
Michael Abrash had a series of columns, ages ago, about code optimization. They started out in assembly language. Then he did a few exploring the differences between the 286, 386, and 486.
Not long after that, he switched to the model I've suggested: write the bulk of your program in a high level language (he used C++). Optimize the algorithms in the bottlenecks. Then, if it still makes sense, switch to something lower level (a lot of times, for his examples, it just wasn't worth it. Something along the lines of "If I take my bottleneck and cut it out completely, the program runs in 4.95 seconds instead of 5. So we're done for this month").
The articles are still interesting, fun, and worth reading. Also kind of mind-bending to consider how much computing's changed since then. And how much it's stayed the same.
I wouldn't generally start with Python on a project that I knew, from the beginning, would need to use lots of cores/threads [precisely because of this]. I'd probably start with something that's designed for that, and widely deployed in the real world, like Erlang.
Then again, that was the first language Google introduced for App Engine. I suppose that having Guido on staff might give you some extra flexibility.
I'd rather crank out a project quickly, get it in front of customers, have them love it, and realize that I need to rewrite one specific part in C than spend years writing it in C, hand-tuning it to handle millions of hits a second, and find out that absolutely everybody hates it after I finally get it released.
It's good to have twitter's problems.
And yet, OTOH...if you're writing something to track the trades in a stock exchange...well, you won't have any say in the matter.
I'm sorry about your dad, and I'm glad you're getting your zest for life back. And I totally agree that having interests away from computers is vital to living a happy, balanced life.
The "one new language a year" pretty much is just an arbitrary rule, but it's pretty common advice. It's turned up in _The Pragmatic Programmer_, Scott Hanselman practices it (http://www.hanselman.com/blog/ProgrammerIntentOrWhatYoureNotGettingAboutRubyAndWhyItsTheTits.aspx),
http://norvig.com/21-days.html recommends learning 6 different languages that support different paradigms in 10 years. Eric S. Raymond points to the Norvig essay in the "Learn how to program" section of http://www.catb.org/~esr/faqs/hacker-howto.html. He also mentions that, after you've learned a few, you should be able to learn a new one in just a few days.
It depends on the individual, the company, the quality of the code base, and the industry, of course. Off the top of my head, I'd guess that most places I've worked took an average developer about 2 years to really get to know the environment, the business domain, and the code base.
Sure, an experienced programmer can hit the ground running and start contributing immediately, but it'll take anyone a while to become an "expert." (Of course, getting someone who already has experience in the the field helps).
I totally agree with you about breadth and stagnating. That's one of the biggest reasons I prefer working at small companies. There seems to almost always be plenty of variety.
I wonder if the high turnover is one of the real reasons that most bigger companies prefer average drones they can mix and match? Rock star programmers are great for tiny startups, but a cubicle row of Wally's is a lot more stable and predictable than Wozniak.
It depends on what the company's doing, and the reason those programs are getting written.
If you're in some corporate IT position, on a staff with 300 different coders, and they're just there to keep track of whatever your actual business is, then, yeah, you want average, mindless drones.
If you're some hot-shot startup that produces software for its livelihood, with 2 programmers on staff, then you want the smartest people you can get. Then again, in this case, you probably shouldn't be using asp.net for much.
Nah, that's what interviews are for. Technical questions and coding exercises are much more fair in this respect.
Unless you're involved in a process that involves days (and how many companies can afford to devote that much time and effort, much less convince candidates to do so?), with several different people, these are only going to give you a drop-in-the-bucket sampling.
Sure, you'll usually be able to quickly tell the difference between someone who pulled his resume out of thin air and one who has a vague clue. But that's really just a finger-in-the-wind test.
Even if you do devote multiple days to the interview, these things will only give you an idea how well the candidate knows whichever technology you're checking. Your point about javascript is great. In the long run, how much effort will it take any given developer to switch from whatever you're using today to whatever the company happens to switch to in a couple of years?
I know several really good, experienced developers who refuse to sit through an interview where they got grilled like that. Well, one of them does so every few years when he re-applies to Microsoft, but only because he's a fanboi.
Anyway, it seems to me that you're the exception that proves the rule. The GP's mostly correct: kids fresh out of school are, for the most part, completely worthless.
(I know exactly one guy who successfully invented 2 years of experience to lie his way into a job after school. Everyone else gets caught in the interview or within a couple of weeks).
Syntax is easy. It's the libraries and actually thinking in the different languages that take a while to pick up.
Sure, the more languages you've learned, the easier it is to pick up a new one. But, if you aren't careful, you'll wind up being one of those Real Programmers who can write Fortran in any language.
Not if you're willing to cheat. There are plenty of websites that post the most common questions and answers to the popular cert exams. They're pretty much completely meaningless at this point.
The biggest problem is that there's almost no way to give an honest eval here.
The only way to know how good a programmer is is to work with him. And that really doesn't tell you anything about how much value he adds to your organization because of how familiar he is with the details of your business.
Sure, there are those rare instances where one person invents adwords, and you can pretty definitively say "He added $x billion dollars to our company value." Later, I saw a blog post where he admitted that he had an intern do all the hard work.
Then again, that was pretty much a total flash in the pan. A once-in-a-lifetime level of genius inspiration that he'll almost definitely never repeat. So, you're correct. The answer starts with "It depends," but it also has to include "It's really complicated."
There's very little science involved in the computer industry in general, and not much involved in programming.
Well, the scientific method comes into play when debugging, or working with unfamiliar code, but the field's so young that it's still really more of an art or a craft.
Doing Java Servlets is quite a bit different than doing MVC in C#. And those two are practically the same language.
Sure, it isn't that difficult to bounce back and forth between one or the other. But neither one would be a good foundation for switching to Zope in Python. The language is dead simple to pick up, but the paradigm shift is pretty significant.
Jumping to something significantly different (like mobile applications, or programming embedded whatsits in Erlang) involves a much bigger mental leap.
Experience can help or hinder there. Someone who's stayed flexible, learning new (or old) languages, technologies, approaches, and ways of thinking in their spare time is going to be much more likely to pick up something new more quickly than someone who's spent his entire career working in, say, Foxpro.
The vast majority of your code doesn't need to scale. Most of what does probably needs a better algorithm.
Since you mentioned Python and the GIL: write your first draft in Python. Profile to figure out where your bottlenecks are and tweak your algorithms there. If you still have noticeable bottlenecks, re-write those pieces in C. Feel free to throw multi-threading into that.
Sure, if you have to get down to that level, you've gotten into a much more complicated situation than if you'd managed to just stick with Python or single-threaded C. But it's still going to be much faster to write than if you'd just done it in C from the ground up.
Slashdot Mirror
I think you're exactly correct with that last paragraph.
It seems as if almost every social movement I hear about is really about replacing one form of unjust coercive authority with another.
Anyway, good luck.
I'm not a Libertarian, and I've read a lot more Dickens than Darwin. But I'll answer this anyway.
You are absolutely correct that class structure is real in the US, and growing.
I also agree with you about the absolute uselessness of trust fund babies who grow up rich...like, for example, George W. Bush or the Kennedys. You're dead wrong about how they got rich in the first place, though. At least one of their ancestors worked really hard, provided something lots of people wanted, and made wise investments. And decided he'd rather his descendants be useless parasites than be forced to do it over again.
Fair enough. Whatever. That's one motivation for working hard, and it's not like they actually hurt me (well, except for the ones who get into Congress and spend their days schmoozing for campaign bucks or figuring out ways to control my life).
Then again, we also have a few self-made billionaire monsters like George Soros. No system's perfect (although he seems to have gotten where he is by exploiting the collectivism in the system).
The gap isn't there because the rich just magically get richer and the poor get poorer. And mugging the rich to feed the poor doesn't make the poor more wealthy. It just makes them dependent on the mugger.
Most of the problem is class envy, people's world view, and the government interfering in the free market.
You create your own reality. Sure, some people are born with advantages, and others seem to have insurmountable disadvantages. But, sooner or later, people have to grow up and accept responsibility for their own fate. See Shawn Stephenson.
How do you get that utopia where "workers self management that allowed everyone to receive the product of their own labor"?
IIRC, there have been at least a couple of countries that tried to make that happen. Seems like they generally wound up with genocide, a dictator, and a bunch of miserable people who did their lazy best to contribute as little as possible.
Capitalism stinks...but it's still the closest thing we've discovered to a "fair" system that has a prayer of working in the real world.
Well, it would be if we could just convince the government to give it a chance. Which may mean that it's just another utopian fantasy.
But that's precisely what schools (especially primary) are designed to produce.
It's as if they've been intentionally designed to take all the joy out of learning and thinking.
Trying to judge intelligence is a loosing
Please tell me you did that on purpose. You were doing so well up to that point.
game -- even more so when intelligence is defined narrowly as proficiency in the maths and sciences.
This is so true. Most measures of intelligence are based on tests written by white males who consider themselves intelligent.
A really fantastic salesman doesn't need a product to sell.
Please mod parent up. Too many people ignore this fact.
That's why you need both. Always assume the system's been hacked and do what you can to minimize the damage.
Sure, if you take a few steps back and look at everything from a different angle.
The "field" I'm talking about is the one that involves the Von Neumann implementation of the Turing machine we're using to have this discussion.
You are correct that "formulating algorithms" is at least as old as recorded history. But that's math. "Computer science" is a specialized branch of that field that has something to do with creating machines to implement those algorithms. I'd say that programming is the practical application of that "science" to the real world.
Maybe the communication problem here is that, in general, most people equate "computer science" with "anything dealing with computers." I have a friend with a master's degree in computer science who never got deeper into computers than Power Point.
You're very welcome, I'm glad it helped and I didn't come across as an ass. :-) Just remember to keep it fun.
It depends on the project and the programmers, obviously.
It'll be a lot faster and easier to tweak algorithms in Python than C.
Michael Abrash had a series of columns, ages ago, about code optimization. They started out in assembly language. Then he did a few exploring the differences between the 286, 386, and 486.
Not long after that, he switched to the model I've suggested: write the bulk of your program in a high level language (he used C++). Optimize the algorithms in the bottlenecks. Then, if it still makes sense, switch to something lower level (a lot of times, for his examples, it just wasn't worth it. Something along the lines of "If I take my bottleneck and cut it out completely, the program runs in 4.95 seconds instead of 5. So we're done for this month").
The articles are still interesting, fun, and worth reading. Also kind of mind-bending to consider how much computing's changed since then. And how much it's stayed the same.
I wouldn't generally start with Python on a project that I knew, from the beginning, would need to use lots of cores/threads [precisely because of this]. I'd probably start with something that's designed for that, and widely deployed in the real world, like Erlang.
Then again, that was the first language Google introduced for App Engine. I suppose that having Guido on staff might give you some extra flexibility.
I'd rather crank out a project quickly, get it in front of customers, have them love it, and realize that I need to rewrite one specific part in C than spend years writing it in C, hand-tuning it to handle millions of hits a second, and find out that absolutely everybody hates it after I finally get it released.
It's good to have twitter's problems.
And yet, OTOH...if you're writing something to track the trades in a stock exchange...well, you won't have any say in the matter.
I'm sorry about your dad, and I'm glad you're getting your zest for life back. And I totally agree that having interests away from computers is vital to living a happy, balanced life.
The "one new language a year" pretty much is just an arbitrary rule, but it's pretty common advice. It's turned up in _The Pragmatic Programmer_, Scott Hanselman practices it (http://www.hanselman.com/blog/ProgrammerIntentOrWhatYoureNotGettingAboutRubyAndWhyItsTheTits.aspx), http://norvig.com/21-days.html recommends learning 6 different languages that support different paradigms in 10 years. Eric S. Raymond points to the Norvig essay in the "Learn how to program" section of http://www.catb.org/~esr/faqs/hacker-howto.html. He also mentions that, after you've learned a few, you should be able to learn a new one in just a few days.
OTOH, there's probably a point of diminishing returns, where the only way you're really going to get any better is by stepping away from the computer and getting interested in other things: http://www.codinghorror.com/blog/2007/01/how-to-become-a-better-programmer-by-not-programming.html
Like I said, it's just a general observation, and it wasn't meant to be anything personal at all.
It depends on the individual, the company, the quality of the code base, and the industry, of course. Off the top of my head, I'd guess that most places I've worked took an average developer about 2 years to really get to know the environment, the business domain, and the code base.
Sure, an experienced programmer can hit the ground running and start contributing immediately, but it'll take anyone a while to become an "expert." (Of course, getting someone who already has experience in the the field helps).
I totally agree with you about breadth and stagnating. That's one of the biggest reasons I prefer working at small companies. There seems to almost always be plenty of variety.
I wonder if the high turnover is one of the real reasons that most bigger companies prefer average drones they can mix and match? Rock star programmers are great for tiny startups, but a cubicle row of Wally's is a lot more stable and predictable than Wozniak.
It depends on what the company's doing, and the reason those programs are getting written.
If you're in some corporate IT position, on a staff with 300 different coders, and they're just there to keep track of whatever your actual business is, then, yeah, you want average, mindless drones.
If you're some hot-shot startup that produces software for its livelihood, with 2 programmers on staff, then you want the smartest people you can get. Then again, in this case, you probably shouldn't be using asp.net for much.
Nah, that's what interviews are for. Technical questions and coding exercises are much more fair in this respect.
Unless you're involved in a process that involves days (and how many companies can afford to devote that much time and effort, much less convince candidates to do so?), with several different people, these are only going to give you a drop-in-the-bucket sampling.
Sure, you'll usually be able to quickly tell the difference between someone who pulled his resume out of thin air and one who has a vague clue. But that's really just a finger-in-the-wind test.
Even if you do devote multiple days to the interview, these things will only give you an idea how well the candidate knows whichever technology you're checking. Your point about javascript is great. In the long run, how much effort will it take any given developer to switch from whatever you're using today to whatever the company happens to switch to in a couple of years?
I know several really good, experienced developers who refuse to sit through an interview where they got grilled like that. Well, one of them does so every few years when he re-applies to Microsoft, but only because he's a fanboi.
Anyway, it seems to me that you're the exception that proves the rule. The GP's mostly correct: kids fresh out of school are, for the most part, completely worthless.
(I know exactly one guy who successfully invented 2 years of experience to lie his way into a job after school. Everyone else gets caught in the interview or within a couple of weeks).
Actually, the language does matter, although probably not in the way you're thinking. See Paul Graham's "Beating the Averages."
Syntax is easy. It's the libraries and actually thinking in the different languages that take a while to pick up.
Sure, the more languages you've learned, the easier it is to pick up a new one. But, if you aren't careful, you'll wind up being one of those Real Programmers who can write Fortran in any language.
Studying for certs is hard
Not if you're willing to cheat. There are plenty of websites that post the most common questions and answers to the popular cert exams. They're pretty much completely meaningless at this point.
The biggest problem is that there's almost no way to give an honest eval here.
The only way to know how good a programmer is is to work with him. And that really doesn't tell you anything about how much value he adds to your organization because of how familiar he is with the details of your business.
Sure, there are those rare instances where one person invents adwords, and you can pretty definitively say "He added $x billion dollars to our company value." Later, I saw a blog post where he admitted that he had an intern do all the hard work.
Then again, that was pretty much a total flash in the pan. A once-in-a-lifetime level of genius inspiration that he'll almost definitely never repeat. So, you're correct. The answer starts with "It depends," but it also has to include "It's really complicated."
There's very little science involved in the computer industry in general, and not much involved in programming.
Well, the scientific method comes into play when debugging, or working with unfamiliar code, but the field's so young that it's still really more of an art or a craft.
Doing Java Servlets is quite a bit different than doing MVC in C#. And those two are practically the same language.
Sure, it isn't that difficult to bounce back and forth between one or the other. But neither one would be a good foundation for switching to Zope in Python. The language is dead simple to pick up, but the paradigm shift is pretty significant.
Jumping to something significantly different (like mobile applications, or programming embedded whatsits in Erlang) involves a much bigger mental leap.
Experience can help or hinder there. Someone who's stayed flexible, learning new (or old) languages, technologies, approaches, and ways of thinking in their spare time is going to be much more likely to pick up something new more quickly than someone who's spent his entire career working in, say, Foxpro.
Heh. One of the first posts I ever saw about Linq had a headline along the lines of "C# finally catches up to COBOL!"
You might want to take another look at Erlang, its history, and where it's used. Not much lab involved there at all.
The vast majority of your code doesn't need to scale. Most of what does probably needs a better algorithm.
Since you mentioned Python and the GIL: write your first draft in Python. Profile to figure out where your bottlenecks are and tweak your algorithms there. If you still have noticeable bottlenecks, re-write those pieces in C. Feel free to throw multi-threading into that.
Sure, if you have to get down to that level, you've gotten into a much more complicated situation than if you'd managed to just stick with Python or single-threaded C. But it's still going to be much faster to write than if you'd just done it in C from the ground up.
So...are you saying "Don't bother learning anything, until either x or y [or some unknown competitor] has proven itself a clear winner?"
Seems like a great way to miss a lot of opportunities to me.