Sorry, I was responding to the weird view that/.'s filters were giving me.
There's something innate in being a good developer. Best I've heard seems to relate to being able to consciously build a mental model of a system and to use it for analysis. With that skill, a CS program can make someone pretty good. That skill without a CS program can still lead go a good developer, but they'll have to teach themselves a *lot*.
The CS program does distinctly alter the likelihood that someone will become a good developer. Point sample data doesn't mean much in anecdotal form. Take two people with the right innate skill, and run one through Hospitality Management and another through CS, and the latter is far more likely to be a better developer.
Hmm, when your algorithm is exponential to the input size, you can spike a cpu with 100 elements. That's a real example from a bug experienced by real paying customers.
Java's already stagnated and sinking (1 yr delta is -1.9%) Unless CS programs plan to stick to (the incredibly venerable) C, people will always complain that they're sticking to the wrong languages.
Unless you're working on scientific computing, OS development, or similar subjects, you will probably never need to ever write any of those things.
Or if you just can't find what you're looking for....?
Look, schools can't spend 4 years teaching you how to write release-quality code the first day at the job. First, there's a good chance that the language you'll be using when you get out of school wasn't the most popular one around when you went in. Second, that stuff is muscle memory that you'll develop normally at work. What school does cover is how to actually think about what code does, *in*aggregate*. You know, beyond a single function or object.
When you cover a couple dozen bugs where a routine ran instantaneously for an input list of 10 items, but spiked the cpu for 2 seconds when that list went to 100+ items, you'll see the value of big-O. It was "hey I can spell printf!" developers who somehow convinced themselves that what they don't see can't hurt (or help) them.
See no science, hear no science, speak no science.
bullshit. I work with groups of people in both categories. I see the code they put out, and often have to help them make it work.
Code that only depends on knowing your basic data structures or various apis falls into two groups pretty quickly:
1) Easily composed of library elements --- the code ends up being a driver for library data structures and routines, and really just ends up being friction between the underlying functionality and the client code.
2) A direct reification of business logic --- to write, linear (in time) to typing speed. To test, exponential, as knowing how to test that logic requires better knowledge than what was required to write it. Equivalent-State analysis will reduce it, but don't ask that of someone who thinks finite-state or (heaven forbid!) Turing machines are unnecessary formalistic gobblygook.
What's really going on is that people feel competent when they hit that point where they can write code well enough to be able to use the reference documentation effectively.
*THAT* *IS* *NOT* *COMPETENCE*
If they can't find an API for it, this is where the horror begins: they try to implement it themselves.
Imagine, if you will, a nightmarish world where half the type names and methods are synonyms, where the documentation screams that the author doesn't have the language (in English) to describe what terrible thing they've done in code -- because they don't understand the whole of it either. Often a tiny little language develops in there somewhere, primordial and malformed; hideous to the unsympathetic naked eye. Entire interfaces are inherited simply to perform simple transformations on their arguments and call other methods.
You go through it, slowly at first. Hoping that there's a genius that justifies the madness. Then you see that one routine, that shouldn't be a routine, but a simple (a || !b), and it's a stack of if-then-else branches. The code's written by morons.
The code has broken the author's mind. They're lost -- drowning -- in a sea of logic. No API or language built-ins to save them.
--
Call me what you want --- I know it'll be horrible. But I've seen it too often now. In most places, it was by people who were trained in other disciplines: EE or physics, who just did enough to get their primary non-programmatic work done. They have a good excuse, and they have other real work to do.
But if your entire job is to put out software, and you don't actually want to study software to do it, then where can you go? Do you think that the languages and tools are going to stay as stagnant as your skill level? Not afraid that a tool or API's going to replace the majority of your work?
Ugh, I can't stand Tortoise. It just *kills* the speed of my file-open/save dialogs. In exchange for a few labels (and not in visual studio! just the explorer) and right-click commands (hint: a menu and some dialog boxes do not constitute a GUI) I literally go get coffee when the dialog box is loading my checked-out repo.
psvn.el for Emacs, however, is an absolute dream. I see my repo (or subfolder thereof) as one dired-like list. diff, checkin/update, etc. are live and just update my buffer.
Sometimes a CS prof hasn't spent their entire career in the same area as a single undergraduate course, and just relearned enough to teach the course & answer student questions on it.
Yeah. The reason is lots of people are suddenly saving nontrivial amounts of data (primarily media-driven) and they want a moore's law of reliable backup. But, all the consumer-level stuff (HDD, optical) isn't good enough and the rest costs actual money.
Until backup is as cheap, reliable, and able to store as much as the rest of consumer tech, we'll get more of these on/.:-(
In the mean time, tape drives are worth the money if your data's the result of real work or investment. If it's archived video downloaded off the net, then a few throwaway drives are best.
Whatever personal reasons you have for the block are your own, and you'll have to deal with that yourself (boredom, burnout, etc.)
In the mean time, start writing out your code in near-final form on paper. I'm not talking design, I mean statement-for-statement.
Approach the computer. Kill email and the web browser. Maximize your editor, get rid of any file lists, error lists, status bar(s), and toolbars -- until you just have a plain white empty screen.
Sit up, have a drink (soda, tea, whatever relaxes you). You've already done the hard part and fought both demons (the code and the computer). Relax for a minute.
Type the code in. Treat it as a typewriter with glass paper.
Save the file. Close it up and bring up a new blank document.
Leave your chair, go somewhere else, and write out your next chunk of code.
Relax a bit.
Go back to the computer.
Repeat as needed.
Eventually, you'll have to compile the thing, but just worry about syntax errors for now.
Pencil-paper are best for debugging, so use them! It'll be faster than when you're on the computer, and you can basically program the same way most of our parents did: input program, wait a few days for it to run, analyze output. Repeat.
I hope I'm not the only one honestly disturbed that rape games have customers. Funny, as I'm a big fan of GTA4.
Two issues come to mind:
1. The harm of rape simulation
While there's evidence that violence and rape instincts live in ever man (and higher ape, for that matter), instinctively I believe there's difference between simulated rape and violent video games.
Violent video games are rather cathartic, and serve that need pretty well. Going around a fake city in a tank and blowing up every douchey car is just wholesome fun. But what does rape simulation appease? It's not sex, that's what porn is for.
2. Free speech
Normally I'm a blind attack-dog in favor of free speech. But here, no, I can't be. If free speech means anything more than "just let everyone talk," it has to have a purpose behind it -- such as letting different ideas being heard, or letting the truth be heard, then there has to be a some sorts of speech it encourages, and others it's agnostic to. I can't think of any case for free speech helped by defending a rape simulator.
They're not, nobody buys Itanium. They're going after SPARC and POWER. Lots of people are looking at the speed and throughput of modern x86 and noticing the price difference. Especially in this economy.
And with Ellison in control of SPARC, it's the best way to go.
The reason the big two (Vim, emacs) are so popular is that they honestly are better tools than you're getting with a normal IDE. The stuff you traditionally get with IDEs: code browsing, graphical debugging, etc. become less and less valuable the better you get as a programmer (the better programmers usually end up with specialized tools for that stuff, which are more powerful than IDEs). However, the advanced text editing you get in these tools only gets more valuable over time.
To each their own on their selection between the two, but I"ll describe my work in Emacs:
I use it on mac, and windows, and a few big-iron unixes.. I share most of my.emacs between them, with my own customizations. I use org-mode to make checklists and plans for my work (e.g. which code has testcases done, which ones have testcases to write?). I use yasnippet for a template/snippet library, which lets me embed lisp code that evaluates at snippet insertion time (like generating proper INCLUDE_FOO_BAR #defines, documentation blocks, or namespace declarations). ido-mode means I only ever have to specify a filename by substring (with tab-completion). CTags support means I hit Alt-. to lookup a symbol name in an arbitrarily-large project, without caring about how my project is built or the platform it's on. On windows Visual studio is my build tool, and debugger, and emacs handles the text itself. The difference is quite substantial, and worth the setup. The only thing I wish it had was a way to tell an external editor which line to highlight while debugging (I use the built-in editor to list code while debugging).
Assuming you're counting debugging, testing, and documentation.
I've heard, through oral history only, that good numbers for total-time-of-project / (LOC * number-of-programmers) is less than 30 lines per programmer per day.
Slashdot Mirror
Sorry, I was responding to the weird view that /.'s filters were giving me.
There's something innate in being a good developer. Best I've heard seems to relate to being able to consciously build a mental model of a system and to use it for analysis. With that skill, a CS program can make someone pretty good. That skill without a CS program can still lead go a good developer, but they'll have to teach themselves a *lot*.
The CS program does distinctly alter the likelihood that someone will become a good developer. Point sample data doesn't mean much in anecdotal form. Take two people with the right innate skill, and run one through Hospitality Management and another through CS, and the latter is far more likely to be a better developer.
Hmm, when your algorithm is exponential to the input size, you can spike a cpu with 100 elements. That's a real example from a bug experienced by real paying customers.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Java - 18%
C - 17%
PHP - 10%
C++ - 10%
VB 8%
Java's already stagnated and sinking (1 yr delta is -1.9%) Unless CS programs plan to stick to (the incredibly venerable) C, people will always complain that they're sticking to the wrong languages.
Or if you just can't find what you're looking for....?
Look, schools can't spend 4 years teaching you how to write release-quality code the first day at the job. First, there's a good chance that the language you'll be using when you get out of school wasn't the most popular one around when you went in. Second, that stuff is muscle memory that you'll develop normally at work. What school does cover is how to actually think about what code does, *in*aggregate*. You know, beyond a single function or object.
When you cover a couple dozen bugs where a routine ran instantaneously for an input list of 10 items, but spiked the cpu for 2 seconds when that list went to 100+ items, you'll see the value of big-O. It was "hey I can spell printf!" developers who somehow convinced themselves that what they don't see can't hurt (or help) them.
See no science, hear no science, speak no science.
Clearly:
Don't contribute significantly to what you learn.
bullshit. I work with groups of people in both categories. I see the code they put out, and often have to help them make it work.
Code that only depends on knowing your basic data structures or various apis falls into two groups pretty quickly:
1) Easily composed of library elements --- the code ends up being a driver for library data structures and routines, and really just ends up being friction between the underlying functionality and the client code.
2) A direct reification of business logic --- to write, linear (in time) to typing speed. To test, exponential, as knowing how to test that logic requires better knowledge than what was required to write it. Equivalent-State analysis will reduce it, but don't ask that of someone who thinks finite-state or (heaven forbid!) Turing machines are unnecessary formalistic gobblygook.
What's really going on is that people feel competent when they hit that point where they can write code well enough to be able to use the reference documentation effectively.
*THAT* *IS* *NOT* *COMPETENCE*
If they can't find an API for it, this is where the horror begins: they try to implement it themselves.
Imagine, if you will, a nightmarish world where half the type names and methods are synonyms, where the documentation screams that the author doesn't have the language (in English) to describe what terrible thing they've done in code -- because they don't understand the whole of it either. Often a tiny little language develops in there somewhere, primordial and malformed; hideous to the unsympathetic naked eye. Entire interfaces are inherited simply to perform simple transformations on their arguments and call other methods.
You go through it, slowly at first. Hoping that there's a genius that justifies the madness. Then you see that one routine, that shouldn't be a routine, but a simple (a || !b), and it's a stack of if-then-else branches. The code's written by morons.
The code has broken the author's mind. They're lost -- drowning -- in a sea of logic. No API or language built-ins to save them.
--
Call me what you want --- I know it'll be horrible. But I've seen it too often now. In most places, it was by people who were trained in other disciplines: EE or physics, who just did enough to get their primary non-programmatic work done. They have a good excuse, and they have other real work to do.
But if your entire job is to put out software, and you don't actually want to study software to do it, then where can you go? Do you think that the languages and tools are going to stay as stagnant as your skill level? Not afraid that a tool or API's going to replace the majority of your work?
Solaris Zones not doing it for you?
Ugh, I can't stand Tortoise. It just *kills* the speed of my file-open/save dialogs. In exchange for a few labels (and not in visual studio! just the explorer) and right-click commands (hint: a menu and some dialog boxes do not constitute a GUI) I literally go get coffee when the dialog box is loading my checked-out repo.
psvn.el for Emacs, however, is an absolute dream. I see my repo (or subfolder thereof) as one dired-like list. diff, checkin/update, etc. are live and just update my buffer.
But some setups are better with a centralized setup.
Merging isn't pretty. There are three things that help:
Wow, what an incredible advancement over erlang and tuples.
Sometimes a CS prof hasn't spent their entire career in the same area as a single undergraduate course, and just relearned enough to teach the course & answer student questions on it.
Google the term "out parameter." Or "Return a struct." Or "Bit-shift OR into a larger type."
If that's all too much. Remember that a double has 52 bits of mantissa.
They're not worth as much as you think...
x86 emulator to the Apple IIc, then put one in the box. It's the only way to be sure.
Mostly poly-sci student interns.
Oh good, I'll do the same thing for my Quicken data...
Yeah. The reason is lots of people are suddenly saving nontrivial amounts of data (primarily media-driven) and they want a moore's law of reliable backup. But, all the consumer-level stuff (HDD, optical) isn't good enough and the rest costs actual money.
Until backup is as cheap, reliable, and able to store as much as the rest of consumer tech, we'll get more of these on /. :-(
In the mean time, tape drives are worth the money if your data's the result of real work or investment. If it's archived video downloaded off the net, then a few throwaway drives are best.
Bill Gates is out on the wing, tearing apart the plane!
( http://en.wikipedia.org/wiki/Nightmare_at_20,000_Feet )
At 18, you'd think Ulysses would get a vote on the topic.
Whatever personal reasons you have for the block are your own, and you'll have to deal with that yourself (boredom, burnout, etc.)
In the mean time, start writing out your code in near-final form on paper. I'm not talking design, I mean statement-for-statement.
Approach the computer. Kill email and the web browser. Maximize your editor, get rid of any file lists, error lists, status bar(s), and toolbars -- until you just have a plain white empty screen.
Sit up, have a drink (soda, tea, whatever relaxes you). You've already done the hard part and fought both demons (the code and the computer). Relax for a minute.
Type the code in. Treat it as a typewriter with glass paper.
Save the file. Close it up and bring up a new blank document.
Leave your chair, go somewhere else, and write out your next chunk of code.
Relax a bit.
Go back to the computer.
Repeat as needed.
Eventually, you'll have to compile the thing, but just worry about syntax errors for now.
Pencil-paper are best for debugging, so use them! It'll be faster than when you're on the computer, and you can basically program the same way most of our parents did: input program, wait a few days for it to run, analyze output. Repeat.
Are you quoted with your real name, or as "paedobear"? :-)
I hope I'm not the only one honestly disturbed that rape games have customers. Funny, as I'm a big fan of GTA4.
Two issues come to mind:
1. The harm of rape simulation
While there's evidence that violence and rape instincts live in ever man (and higher ape, for that matter), instinctively I believe there's difference between simulated rape and violent video games.
Violent video games are rather cathartic, and serve that need pretty well. Going around a fake city in a tank and blowing up every douchey car is just wholesome fun. But what does rape simulation appease? It's not sex, that's what porn is for.
2. Free speech
Normally I'm a blind attack-dog in favor of free speech. But here, no, I can't be. If free speech means anything more than "just let everyone talk," it has to have a purpose behind it -- such as letting different ideas being heard, or letting the truth be heard, then there has to be a some sorts of speech it encourages, and others it's agnostic to. I can't think of any case for free speech helped by defending a rape simulator.
They're not, nobody buys Itanium. They're going after SPARC and POWER. Lots of people are looking at the speed and throughput of modern x86 and noticing the price difference. Especially in this economy.
And with Ellison in control of SPARC, it's the best way to go.
The reason the big two (Vim, emacs) are so popular is that they honestly are better tools than you're getting with a normal IDE. The stuff you traditionally get with IDEs: code browsing, graphical debugging, etc. become less and less valuable the better you get as a programmer (the better programmers usually end up with specialized tools for that stuff, which are more powerful than IDEs). However, the advanced text editing you get in these tools only gets more valuable over time.
To each their own on their selection between the two, but I"ll describe my work in Emacs:
I use it on mac, and windows, and a few big-iron unixes.. I share most of my .emacs between them, with my own customizations. I use org-mode to make checklists and plans for my work (e.g. which code has testcases done, which ones have testcases to write?). I use yasnippet for a template/snippet library, which lets me embed lisp code that evaluates at snippet insertion time (like generating proper INCLUDE_FOO_BAR #defines, documentation blocks, or namespace declarations). ido-mode means I only ever have to specify a filename by substring (with tab-completion). CTags support means I hit Alt-. to lookup a symbol name in an arbitrarily-large project, without caring about how my project is built or the platform it's on. On windows Visual studio is my build tool, and debugger, and emacs handles the text itself. The difference is quite substantial, and worth the setup. The only thing I wish it had was a way to tell an external editor which line to highlight while debugging (I use the built-in editor to list code while debugging).
10 lines per hour? That's way too high.
Assuming you're counting debugging, testing, and documentation.
I've heard, through oral history only, that good numbers for total-time-of-project / (LOC * number-of-programmers) is less than 30 lines per programmer per day.
People didn't design their own reflexes, survival instincts, or subconscious will to survive.