Multi-threaded programming is getting to be like artificial intelligence. People flip out about how hard it is, and when you point out mundane, useful, easy kinds of multi-threading, they say, "Well, that's not really what I was talking about." If multi-threading only means scalable performance-critical code, or code with lots of fine-grained locking, or code written with no language or library support, then hell yeah, it's hard. Multi-threaded programming is full of hard problems, but you can get plenty of work done without ever facing up to them.
Yes; and in fact I haven't found another safe way to feed parameters to a database in Java. There doesn't appear to be any kind "sanitize/escape" function nor paremetrized input for non-prepared statements in the JAVA SQL API, so either you write one yourself or stick to PreparedStatements.
I think this is intentional. Aren't effective sanitization functions essentially impossible to write, given the huge variety of vulnerabilities in different database back-ends? You have to know every little detail of every dialect of SQL that you might run against some day. Plus, putting your data through such a complex munging/demunging process makes it likely that your system will corrupt some kinds of text data, such as foreign names and addresses.
No, the cool, unique properties of a web app are pretty much entirely the user experience -- the fact that there's nothing to download, and no updates to manage.
I develop a rich client application for internal corporate use, and I find that casual users really miss web-style navigation. I get a lot of requests that are essentially requests to simulate a web experience by providing a bunch of screens that users can click through to find the information they want, instead of using traditional (perhaps formerly traditional?) GUI ways of exposing functionality.
Also, these days, mashups and Greasemonkey scripts really magnify the value of web applications. Deprecating a web application in a big company can be nearly impossible because you find out that there are a bunch of business processes that depend on mashups and fancy Greasemonkey scripts that have been hacked together (usually by interns, IT guys, and other random people) and that provide substantial business value.
As a student, don't bother learning frameworks with the idea that you will use them later. There are only two good reasons to learn a framework. The first is to use it right away on a project you want to get done. The second is to get experience with frameworks in general and particular types of frameworks. It is valuable to be able to:
Learn a framework quickly.
Understand the advantages and disadvantages of frameworks, as opposed to lightweight approaches.
Evaluate and compare frameworks for a given task.
Knowing a framework is, in itself, pretty useless unless you are going to use it right away or apply for one of those mythical Monster.com jobs where companies hire people to work with version 2.37a of Ridiculously Specific Technology Z. I don't know of any companies that actually hire that way unless they need a consultant to work with a legacy system whose developers have long since disappeared. In other words, you won't be hired for your experience with a specific framework until that framework is obsolete.
Now, setting aside the proper way to study frameworks, why are you even thinking about frameworks as an "investment" at your age? You sound like you're in way too much of a hurry. If you learn one distributed N-tier application framework, one web application framework, and one rich client application framework, then you will have much more industrial-type experience than most developers ten years older than you. The downside is that industrial-type experience, while it helps you make better decisions about large-scale software development, also tends to dull your brain. If you're already focusing on frameworks in college, you're going to be burned out and useless by the time you're thirty. You'll end up quitting and starting over from scratch in a new career, just to get away from software. Unless you're just one of those precociously responsible (*cough* boring *cough* *cough*) kids who tracked his gas mileage in high school and thought the coolest thing about the Science Fair was having an excuse to wear a suit and gesture at graphs.
In college, you should be implementing your own language, becoming a whiz at Emacs Lisp, mucking with kernel modules, starting your own web business, building natural language parsers, and doing all the other silly, vain, perfectly useless (Emacs Lisp excluded) things that end up making you into a smart, versatile programmer.
It isn't an intrinsically "bikeshed" problem. There are things of value to be said about it and legitimate points to be argued.
To pick a simple example, when you add code to a project, you should conform to the standards that are followed in that project: naming conventions, indentation standards, documentation standards, error handling conventions, logging formats, everything. It's a no-brainer, but it's worth repeating because there are so many people who just don't get it.
Coding practices are for the latter. I'm sure Bell Labs let their guys write any damn kind of code they wanted. I can't imagine the team at PARC getting told by management where to put their braces and semicolons.
The team at PARC didn't have to be told where to put their braces and semicolons, because they were smart enough to know already: you put the braces and semicolons wherever is consistent with the existing code in the project.
Even the GNU style guide says:
If you are contributing changes to an existing program, please follow the style of that program.
I've worked in corporations where coding guidelines were adopted. Coding guidelines sound pretty ambitious and draconian, and they may be sweated and obsessed over by the committees that produce them, but in my experience, they exist solely as an excuse to crack down on really gross offenders, such as people who contribute inconsistent code to existing projects or randomly reformat existing source files.
You need a bureaucratic tool like coding standards because sometimes the moronic offenders are at the managerial level or have staunch managerial support. "He's a real star; I just let him do his thing and get out of his way." Uh, yeah, if he's such a star, why does he reformat every code file he checks in? Can this "star" not figure out how to edit a source file without reformatting it to match the default indentation style of his IDE?
So in my experience corporate coding standards are applied only to the most egregious dumbasses in a corporation. Even low-level corporate drones can get away with violating corporate coding standards if they observe basic common sense and common courtesy.
It only stands to reason. The vast majority of code in any corporate codebase was written before the current standards were put in place, so it's inevitably a hodge-podge of coding styles. If your project doesn't follow the guidelines, people will just assume it grew from a codebase that existed before the guidelines were adopted.
It is far more likely that interviewer and the candidate, both being engineers who are almost by definition NOT people-oriented, are unable to communicate properly.
If the technical interviewer and the candidate can't communicate about technical topics, whether it be past work or a problem on the whiteboard, they shouldn't be working together. The candidate shouldn't be hired. End of story. Even if the candidate deserves to be hired (in some abstract moral sense) he's better off not working for a company where he would be a useless dead weight.
Engineers are too used to dealing with machines. They are the absolute worst when it comes to interacting with other people, even though they often think otherwise, like you.
Are you saying we should leave hiring to the HR people, or we should only hire machines?
Xopher: "I AM PROGRAMMER BOT. I HAVE TEN YEARS C/C++ EXPERIENCE."
Interviewer: "Do I know you? I feel ready to work with you already!"
Xopher: "DO NOT ASK ME ABOUT JAVA. I HAVE FIVE YEARS JAVA EXPERIENCE, BUT PLEASE DO NOT ACCESS THESE PAINFUL MEMORY SEGMENTS. HA HA HA HA."
Interviewer: "And a sense of humor, too! Let's make this guy an offer."
If they know that "this many" units of food was enough to feed them last time, then "this many" units of food will likely serve that purpose next time.
If the size of the group grows, then they need "this many" plus "some more". And that "some more" will then be wrapped into "this many" the following year.
When "this many" or "some more" are under ten, any inaccuracy at all is an error of more than 10%. I doubt errors of 10% in resource estimations (food, shelter, social capital) are insignificant for hunter-gatherers.
Why do we assume that the Piraha's vague quantity words are actually sufficient for their handling of quantities? I would guess that the Piraha are aware of the deficiencies of the "this many" or "some more" words and don't rely on them when they need to be precise. You can reason precisely about the relative sizes of small sets without using names for the integers -- it's just a huge pain in the ass.
For instance, instead of saying, "Bring four baskets," you say, "Bring baskets for Jim, Dan, Doug, and Sue." Instead of looking at your pile of plums and counting them with, "One, two, three, four, five, six," you count them with, "Dan today, Doug today, Jim today, Sue today, Dan tomorrow, Doug tomorrow."
It is not at all obvious that the effort of learning and passing on words for the integers under ten would not be repaid in the Piraha's ecological niche. Unfortunately, even if the Pirahas would benefit from those words, the words will not automatically leap into existence, just as the deficiencies of the English language that may be observed today will not be corrected by the time you wake up tomorrow.
"As they are needed" is not quite how it happens. They are probably just like every other technology: they may pop up before they're needed and then vanish into obscurity, or they may not materialize until the need becomes very acute. I would put numbers under ten into the latter category -- I can't imagine anyone who could not get enough use out of them to make learning them worthwhile, simply because everyone has to reckon with a small number of comrades and close relations.
For instance, suppose we got really lucky on a hunting trip: we cornered a group of peccaries and killed five of them. We're half a day's walk from the village, there are three of us in the hunting party, we can each carry one peccary except for Hans who can carry two small ones, and there are two more guys nearby who will join us later (probably empty-handed, since hunting is pretty hit-or-miss.) Should we bother chasing down the wounded one that got away?
You could figure that out by pointing to each peccary and saying the name of the person who will going to carry it, but meanwhile the wounded peccary is getting farther away and harder to follow.
Or, to take a much scarier example, suppose you bring home four small pieces of fruit and start handing them out one-by-one to your five small children. BIG mistake. You might survive, but you will wish you hadn't. If the children aren't all by the same mother, you will probably commit suicide rather than face the consequences.
Why do "forward-thinking" designers keep trying to force tried, rejected, unwanted features on consumers? Are they hoping that the new, improved consumers of 2015 will accept keyboards with zero key travel and no tactile differentiation of the keys?
Oh, wait, I forgot about force feedback -- now there's a good reason to give up half my typing speed! It's not like entering text into a computer is an important, time-limiting part of my lifestyle or anything.
That's because the summary is wrong; "webinar" does not come from the geek world. It comes from the Dilbert world, where marketroids are compelled to make up stupid names for every mildly novel thing. Also, "pretexting" comes from the worlds of crime and espionage. The submitter learned about it in a geeky context (hacking) because the submitter is a geek and learns about most things in a geeky context.
I can not believe that the great John Brunner hasn't been mentioned.
I remember enjoying The Sheep Look Up when I was a kid, though I don't remember what it was about besides pollution.
I liked Stand on Zanzibar, too, though it was a tough slog, and the rewards were not that great given how much work I put into it. I got more out of it as an adult. Stand on Zanzibar would be perfect for an older kid (or adult, of course) who is interested in recent US history, because the most fascinating thing about it is how it reflects how people in the Sixties saw the world and its future development.
Where did we get the idea that pre-teens can't be exposed to sex in any way? It's a good idea to read books before recommending them to your children to make sure the presentation of sex isn't sinister in any way, but the mere presence of sex shouldn't disqualify a book.
I see several posts on this page where people rule out any sex whatsoever, but nothing at all lamenting the fact that most classic sci-fi is absurdly sexist. Usually naively and unintentionally sexist, perhaps, and only occasionally misogynistic, but not suitable to be the bulk of your kid's literary diet.
In fact, the best reason for tolerating a little sex is that most of the non-chauvinistic sci-fi does contain sex. Plus, it is a good idea for kids to be self-consciously, abstractly wondering about sex before they encounter their own urges in a concrete form. They aren't going to take their ideas from you, their parents, and the alternatives are books, movies, TV, and peers. Obviously, good books and a few movies are your best hope if you want your kids to take a thoughtful, critical approach.
I don't know ANYTHING about pre-teens except what I know from being one, but I know I read several books about sex as a pre-teen and was alternately amused and horrified by the unreflective, superstitious, fetishistic approach to sex that my peers took to sex. Whatever they heard from anyone between their age and twenty-one, they took as gospel truth. Whatever they knew at a given time was assumed to be pretty close to the whole truth. Good science fiction is a wonderful inoculation against those attitudes. (Unfortunately, it seems that most science fiction is optimized to sell to people who would rather fantasize about sex than think about it, but you just have to find the exceptions.)
Here are a few books that might be suitable for preteens.
Island, by Aldous Huxley. I actually read this as a pre-teen. The main thing I took away from it is that sex and love present some thorny problems, and different people have come up with many very different ways of coping with them. It influenced me to approach sex with a combination of compassion, love, and pragmatism, in that order. I learned to keep that attitude to myself in the macho culture I grew up in, and gave up on it altogether by the time I went to college, but eventually my adult experiences with sex brought me right back to where Aldous Huxley started me out. This is a no-brainer choice to give to freethinking kids. It does advocate judicious use of hallucinogens for spiritual purposes, but I read and admired it as a preteen and was never tempted to test that particular idea. (Twenty years later, I still haven't.)
Fledgling, by Octavia Butler. Perhaps this one should be saved for older teens. I really don't know what to say about this book except that it made me think. I'm normally a pretty quick reader, but I kept putting this one down just so I could think for a while. (I know, I'm supposed to do that with every book. So I'm a philistine; sue me.) The takeaway lesson from this book is that people have to be very ethically careful about relations of power and dependency.
Stranger in a Strange Land, by Robert Heinlein. The older I get the more I realize that Heinlein was a pompous dick who loved to put ridiculous ideas over on people, take undeserved adulation from naive people (like my teenage self,) and then defend himself against the critics by saying he was just "throwing things out there" or "seeing who would take him seriously." So I would definitely rer
For many, dialup does what they want. email, low bandwidth browsing etc. Low-tech folk.
I'm surprised to see this opinion on Slashdot. I used to hear it a lot from non-techy folks like my parents.
It's wrong, and it's closer to the opposite of the truth than to the truth itself. Nerdy, tech-loving people such as myself spend a lot of time using low-bandwidth things like news, Google groups, mail, ssh, and googling for error messages. We exchange source code. I usually don't need much bandwidth while I'm doing my very high-tech programming job.
In contrast, "low-tech folk" spend the vast majority of their online time watching media or visiting media-rich web sites. They exchange vacation photos and funny videos. My parents finally broke down and got broadband because it was taking too long for my mother to download her friends' photos of the outings they went on. Now my parents consider it a necessity -- they can't imagine waiting for pages to load like they used to. Who has that kind of time? Not even low-tech retired folk, evidently.
Here are a bunch of choices. (See links to Lisp, Java, Latex, and Perl samples here.)
The one I use is Jedit Gray, altered to use a slightly darker background. I bet you can achieve the same effect in Vim. (If not, neener neener neener!)
Personally, for me, ambient light is a much bigger deal than the colors on the screen. I get eyestrain when my screen is significantly brighter than the room around me. Even when I'm staring directly at the screen for hours, my eyes seem to adjust themselves to the brightness of my surroundings instead of to the brightness of the screen.
I first noticed this playing Doom fifteen years ago. When I got really tired near the end of a long session, I sometimes had to turn the lights on for bright maps.
Ah, but what other distro can you get preinstalled and supported (for a very reasonable price) on a new ThinkPad?
*shakes fist at Lenovo*
I lived through some of the years growing pains of Linux on the desktop and am not willing to go through it again with a laptop. A bunch of people have posted how-tos recording how they "succussfully" installed Linux (notably Ubuntu) on their T61s, but when you read the details, you find out that none of them really got it working right. They're just enthusiasts who are willing to put up with a laptop that doesn't, say, hibernate, or let you adjust the screen brightness over the halfway mark, or some other thing that would be intolerable in the long term.
Emperor Linux sells T61s with what appears to be full hardware support, but they charge a hefty markup, which strengthens my suspicion that it's not a reasonable thing for one guy to try to accomplish in a weekend.
That leaves me with pre-installed OpenSUSE, but buying service from Novell leaves me with a bad taste in my mouth.
The one ray of hope currently is FLOSS, whose projects are often free of this particular sort of nonsense. The big problem, of course, is that there seems to be no good, general way to compensate good people for working on these projects... I have a similar problem. I know this beautiful, pristine beach. The sand is fine and white, the water is clean, and best of all, it's never crowed. There aren't any tourists except the ones who are willing to hike ten miles in. No fat chicks at all! The only problem is that there isn't any infrastructure. But I'll fix that. I'm going to pull some strings and get a freeway built, and a parking lot, and a McDonald's, and then it will be perfect!
I will take your word for it. My company is not typical. We have fewer than four hundred employees, but we have half a dozen admins and ten developers working on internal systems, plus some QA resources assigned to internal products, plus a few miscellaneous managers.
You'd think we would be close-knit, but I am completely isolated from the other developers working on internal systems, and at various stages in the process I have received at least four different sets of requirements from people I didn't know, who had been assigned to gather requirements for the project, who had gathered requirements for a previous incarnation or failed start in the past, or who found out about the project and realized their department would be impacted. All of the requirements were gathered manager-to-manager (or rather, manager-to-self) and were supposed to be filtered through another manager (whom I impudently cut out) before I saw them. Of course, the end users were not consulted until much later in the process.
You are absolutely right about testing, by the way. No QA resources have been assigned to my project, and as far as the QA manager is concerned, I am doing a fine job and should keep it up. Scary, ain't it?
In these small development shops, you are not likely going to be hired on as a 'coder'. Yeah, I am officially a "Software Engineer" and have previously been a "Software Developer" and even (probably inappropriately) a "Member of Technical Staff." I like to call myself a "coder" or a "programmer" anyway, because I think the term "programming," like "writing," should encompass all the activities, high-level and low-level, social and solitary, that contribute to the finished product. If William Faulkner is known as a "writer" and not a "Senior Literary Engineer," then I would like to be known as a "programmer";-)
I agree with what you're saying but would put a more pessimistic slant on it. A programmer shouldn't take a personal, face-to-face, cube-to-cube interest in what goes on in other departments hoping to make improvements on business processes. A programmer should do that because otherwise the specs will be wrong, the design will be flawed, and the tests will be lacking.
You will be told, "There are people whose job it is to talk to all the stakeholders, understand their disparate needs, and assemble the requirements." This is correct. There are also people whose job it is to design the system, other people who are supposed to implement parts of the system, and other people who are supposed to test the system. Odds are that many of these jobs will be assigned to incompetent, clueless, and/or underworked people. Odds are that even the competent people will miss things that might cripple the design later. It improves your odds immensely if you do some reconnaissance work on your own.
Don't duplicate the work done by others (unless you figure out that a particular person is useless.) If somebody talked to the manager in group X, then you should talk to the second in charge. If someone talked to a supervisor, talk to the grunts. Read their requirements first, then go casually chat with them as if the requirements were correct. Observe their looks of panic and horror. Then start taking notes. Requirements are often collected manager-to-manager and leave out vast swaths of essential functionality.
After you feel good about the requirements, review the test plan. If anything is obviously missing, mention it. If anything looks suspiciously underspecified, chat innocently with the testers about it. "I bet testing internationalization is gonna be a bitch. How the hell do you even type right-to-left text in Windows, anyway?"
This is your job as a coder -- to have the backs of the people you work with and save them from themselves. If you're lucky, someone is doing the same thing for you. The guy who wrote the test plan might look at your issue tracker to see what features you plan on implementing. Maybe you missed something. The guy who wrote the high-level specs might look over your design docs to see if you've made any obvious mistakes with respect to deployment requirements.
A lot of people see this kind of behavior as being absolutely contrary to fundamental engineering principles. On the contrary; it is sound human engineering. It shouldn't even be a political problem. The only people who won't appreciate the feedback and correction are the ones who are consistently shown to be incompetent.
However, if you look up the definition of girl it contains the same denoted meaning as senorita. Actually, of all the sources aggregated at dictionary.com, WordNet is the only one that lists a definition matching señorita:
a young woman; "a young lady of 18" American Heritage and Webster's list definitions that come close to matching señorita. American Heritage provides notes that the the usage is offensive, which is not the case for señorita:
(Often Offensive) A woman, especially a young woman. And Webster's says that "girl" implies immaturity when applied to a young woman:
a young, immature woman, esp. formerly, an unmarried one. The usage as applied to grown women is basically a diminutive. Like other diminutives, its effect is based on the mismatch between the literal meaning and the person or thing you apply it to, and like other diminutives the context determines whether it is perceived as affectionate, jocular, or insulting -- you can't use it as a neutral term. In a context where precise, neutral language is expected, such as when delivering a news report or making a statement to the police, using "girl" to describe a young woman would be considered to be either inaccurate or inappropriately informal.
As for the other issues, my observation about Spanish speakers was an observation, not a generalization, and it's a necessary one when dealing with matters of usage. For example, the word "cochino" when applied to a man means a lewd, lecherous man who has a predatory attitude towards young women. Does this word have a positive or negative connotation? Is it a term of abuse or sly admiration? It depends on who's talking.
And I'm a gringo, by the way, so it is my right to co-opt this verbal weapon and use it as I please:-)
not every geek is so successful at applying his intellect to understanding the social environment that others navigate by intellect Sorry, I meant "navigate by intuition."
I'm not sure how you get that image when the name itself suggests a more appropriate one: the gnashing of teeth as Linux users are forced to use the closed-source, out-of-date Adobe player because all the open-source implementations suck.
And lest anyone cry, "Open source software will only get better when people use it," get real. Lack of stuff to work on is not the problem with gnash:-)
The good news is that it's a young project that only started in late 2005, so it's far too early to give up on it.
"Señorita" does not translate directly to "girl." "Young eligible woman" is a better translation. When you call a señora "señorita," you are essentially flattering her about her age, whereas if you call a woman "girl," you are implying she is a child.
Many Spanish speakers would call an attractive fourteen-year-old "señorita," but that is essentially sexist -- it implies that sprouting tits is all the growing up that women need to do. That is a pretty common belief among Spanish speakers (at least in the United States) so it's not surprising that a gringo would think "señorita" implies "adolescent."
Sorry to say this, but how great of a coder you are is inverseley proportional to the quality of your social life. It depends. Holing up with a computer is associated with a "turtling" approach to life where you curl up, erect your defenses, and avoid outside influence. Been there, done that, have the scars. It happens to people who:
Have difficulty empathizing.
Have become used to the idea that they are better than other people (because they are smarter or because they don't understanding why other people do what they do) and are hostile to the idea of adjusting their behavior to accomodate those other, inferior people.
Insist on seeing life in hypercompetitive terms and therefore must nurture and protect a weird, often delusional view of life in which they are winners rather than losers.
Maybe all good programmers have been through a period of life like that, but nobody who still lives and thinks like that is a good programmer.
Take RMS as an example. He was a typical socially-challenged geek, but the first insight that made him famous was a social insight into how the MIT hacker community worked. He wasn't turtling; he was analyzing his community and figuring out how to be a part of it. Eventually he even became a leader of a subgroup of that community.
Unfortunately, not every geek is that brilliant, and not every geek is so successful at applying his intellect to understanding the social environment that others navigate by intellect. Often geeks are so alienated that they cannot reconcile themselves even to the idea of working productively with their peers in a corporation.
Every good programmer has to make concessions to the practices of his peers, and every good programmer has to let go of the need to feel smart. Further, every programmer who isn't brilliant -- i.e., 99% of them -- will stagnate if he (or she) isn't capable of learning new ideas from his colleagues. Someone who has a nonexistent social life is probably not the kind of person who can listen to someone else and model the potentially valuable thoughts in that person's head.
Slashdot Mirror
Multi-threaded programming is getting to be like artificial intelligence. People flip out about how hard it is, and when you point out mundane, useful, easy kinds of multi-threading, they say, "Well, that's not really what I was talking about." If multi-threading only means scalable performance-critical code, or code with lots of fine-grained locking, or code written with no language or library support, then hell yeah, it's hard. Multi-threaded programming is full of hard problems, but you can get plenty of work done without ever facing up to them.
Yes; and in fact I haven't found another safe way to feed parameters to a database in Java. There doesn't appear to be any kind "sanitize/escape" function nor paremetrized input for non-prepared statements in the JAVA SQL API, so either you write one yourself or stick to PreparedStatements.
I think this is intentional. Aren't effective sanitization functions essentially impossible to write, given the huge variety of vulnerabilities in different database back-ends? You have to know every little detail of every dialect of SQL that you might run against some day. Plus, putting your data through such a complex munging/demunging process makes it likely that your system will corrupt some kinds of text data, such as foreign names and addresses.
No, the cool, unique properties of a web app are pretty much entirely the user experience -- the fact that there's nothing to download, and no updates to manage.
I develop a rich client application for internal corporate use, and I find that casual users really miss web-style navigation. I get a lot of requests that are essentially requests to simulate a web experience by providing a bunch of screens that users can click through to find the information they want, instead of using traditional (perhaps formerly traditional?) GUI ways of exposing functionality.
Also, these days, mashups and Greasemonkey scripts really magnify the value of web applications. Deprecating a web application in a big company can be nearly impossible because you find out that there are a bunch of business processes that depend on mashups and fancy Greasemonkey scripts that have been hacked together (usually by interns, IT guys, and other random people) and that provide substantial business value.
As a student, don't bother learning frameworks with the idea that you will use them later. There are only two good reasons to learn a framework. The first is to use it right away on a project you want to get done. The second is to get experience with frameworks in general and particular types of frameworks. It is valuable to be able to:
Knowing a framework is, in itself, pretty useless unless you are going to use it right away or apply for one of those mythical Monster.com jobs where companies hire people to work with version 2.37a of Ridiculously Specific Technology Z. I don't know of any companies that actually hire that way unless they need a consultant to work with a legacy system whose developers have long since disappeared. In other words, you won't be hired for your experience with a specific framework until that framework is obsolete.
Now, setting aside the proper way to study frameworks, why are you even thinking about frameworks as an "investment" at your age? You sound like you're in way too much of a hurry. If you learn one distributed N-tier application framework, one web application framework, and one rich client application framework, then you will have much more industrial-type experience than most developers ten years older than you. The downside is that industrial-type experience, while it helps you make better decisions about large-scale software development, also tends to dull your brain. If you're already focusing on frameworks in college, you're going to be burned out and useless by the time you're thirty. You'll end up quitting and starting over from scratch in a new career, just to get away from software. Unless you're just one of those precociously responsible (*cough* boring *cough* *cough*) kids who tracked his gas mileage in high school and thought the coolest thing about the Science Fair was having an excuse to wear a suit and gesture at graphs.
In college, you should be implementing your own language, becoming a whiz at Emacs Lisp, mucking with kernel modules, starting your own web business, building natural language parsers, and doing all the other silly, vain, perfectly useless (Emacs Lisp excluded) things that end up making you into a smart, versatile programmer.
It isn't an intrinsically "bikeshed" problem. There are things of value to be said about it and legitimate points to be argued.
To pick a simple example, when you add code to a project, you should conform to the standards that are followed in that project: naming conventions, indentation standards, documentation standards, error handling conventions, logging formats, everything. It's a no-brainer, but it's worth repeating because there are so many people who just don't get it.
Coding practices are for the latter. I'm sure Bell Labs let their guys write any damn kind of code they wanted. I can't imagine the team at PARC getting told by management where to put their braces and semicolons.
The team at PARC didn't have to be told where to put their braces and semicolons, because they were smart enough to know already: you put the braces and semicolons wherever is consistent with the existing code in the project.
Even the GNU style guide says:
If you are contributing changes to an existing program, please follow the style of that program.
I've worked in corporations where coding guidelines were adopted. Coding guidelines sound pretty ambitious and draconian, and they may be sweated and obsessed over by the committees that produce them, but in my experience, they exist solely as an excuse to crack down on really gross offenders, such as people who contribute inconsistent code to existing projects or randomly reformat existing source files.
You need a bureaucratic tool like coding standards because sometimes the moronic offenders are at the managerial level or have staunch managerial support. "He's a real star; I just let him do his thing and get out of his way." Uh, yeah, if he's such a star, why does he reformat every code file he checks in? Can this "star" not figure out how to edit a source file without reformatting it to match the default indentation style of his IDE?
So in my experience corporate coding standards are applied only to the most egregious dumbasses in a corporation. Even low-level corporate drones can get away with violating corporate coding standards if they observe basic common sense and common courtesy.
It only stands to reason. The vast majority of code in any corporate codebase was written before the current standards were put in place, so it's inevitably a hodge-podge of coding styles. If your project doesn't follow the guidelines, people will just assume it grew from a codebase that existed before the guidelines were adopted.
It is far more likely that interviewer and the candidate, both being engineers who are almost by definition NOT people-oriented, are unable to communicate properly.
If the technical interviewer and the candidate can't communicate about technical topics, whether it be past work or a problem on the whiteboard, they shouldn't be working together. The candidate shouldn't be hired. End of story. Even if the candidate deserves to be hired (in some abstract moral sense) he's better off not working for a company where he would be a useless dead weight.
Engineers are too used to dealing with machines. They are the absolute worst when it comes to interacting with other people, even though they often think otherwise, like you.
Are you saying we should leave hiring to the HR people, or we should only hire machines?
Xopher: "I AM PROGRAMMER BOT. I HAVE TEN YEARS C/C++ EXPERIENCE."
Interviewer: "Do I know you? I feel ready to work with you already!"
Xopher: "DO NOT ASK ME ABOUT JAVA. I HAVE FIVE YEARS JAVA EXPERIENCE, BUT PLEASE DO NOT ACCESS THESE PAINFUL MEMORY SEGMENTS. HA HA HA HA."
Interviewer: "And a sense of humor, too! Let's make this guy an offer."
If they know that "this many" units of food was enough to feed them last time, then "this many" units of food will likely serve that purpose next time.
If the size of the group grows, then they need "this many" plus "some more". And that "some more" will then be wrapped into "this many" the following year.
When "this many" or "some more" are under ten, any inaccuracy at all is an error of more than 10%. I doubt errors of 10% in resource estimations (food, shelter, social capital) are insignificant for hunter-gatherers.
Why do we assume that the Piraha's vague quantity words are actually sufficient for their handling of quantities? I would guess that the Piraha are aware of the deficiencies of the "this many" or "some more" words and don't rely on them when they need to be precise. You can reason precisely about the relative sizes of small sets without using names for the integers -- it's just a huge pain in the ass.
For instance, instead of saying, "Bring four baskets," you say, "Bring baskets for Jim, Dan, Doug, and Sue." Instead of looking at your pile of plums and counting them with, "One, two, three, four, five, six," you count them with, "Dan today, Doug today, Jim today, Sue today, Dan tomorrow, Doug tomorrow."
It is not at all obvious that the effort of learning and passing on words for the integers under ten would not be repaid in the Piraha's ecological niche. Unfortunately, even if the Pirahas would benefit from those words, the words will not automatically leap into existence, just as the deficiencies of the English language that may be observed today will not be corrected by the time you wake up tomorrow.
"As they are needed" is not quite how it happens. They are probably just like every other technology: they may pop up before they're needed and then vanish into obscurity, or they may not materialize until the need becomes very acute. I would put numbers under ten into the latter category -- I can't imagine anyone who could not get enough use out of them to make learning them worthwhile, simply because everyone has to reckon with a small number of comrades and close relations.
For instance, suppose we got really lucky on a hunting trip: we cornered a group of peccaries and killed five of them. We're half a day's walk from the village, there are three of us in the hunting party, we can each carry one peccary except for Hans who can carry two small ones, and there are two more guys nearby who will join us later (probably empty-handed, since hunting is pretty hit-or-miss.) Should we bother chasing down the wounded one that got away?
You could figure that out by pointing to each peccary and saying the name of the person who will going to carry it, but meanwhile the wounded peccary is getting farther away and harder to follow.
Or, to take a much scarier example, suppose you bring home four small pieces of fruit and start handing them out one-by-one to your five small children. BIG mistake. You might survive, but you will wish you hadn't. If the children aren't all by the same mother, you will probably commit suicide rather than face the consequences.
Why do "forward-thinking" designers keep trying to force tried, rejected, unwanted features on consumers? Are they hoping that the new, improved consumers of 2015 will accept keyboards with zero key travel and no tactile differentiation of the keys?
Oh, wait, I forgot about force feedback -- now there's a good reason to give up half my typing speed! It's not like entering text into a computer is an important, time-limiting part of my lifestyle or anything.
That's because the summary is wrong; "webinar" does not come from the geek world. It comes from the Dilbert world, where marketroids are compelled to make up stupid names for every mildly novel thing. Also, "pretexting" comes from the worlds of crime and espionage. The submitter learned about it in a geeky context (hacking) because the submitter is a geek and learns about most things in a geeky context.
I can not believe that the great John Brunner hasn't been mentioned.
I remember enjoying The Sheep Look Up when I was a kid, though I don't remember what it was about besides pollution.
I liked Stand on Zanzibar, too, though it was a tough slog, and the rewards were not that great given how much work I put into it. I got more out of it as an adult. Stand on Zanzibar would be perfect for an older kid (or adult, of course) who is interested in recent US history, because the most fascinating thing about it is how it reflects how people in the Sixties saw the world and its future development.
Where did we get the idea that pre-teens can't be exposed to sex in any way? It's a good idea to read books before recommending them to your children to make sure the presentation of sex isn't sinister in any way, but the mere presence of sex shouldn't disqualify a book.
I see several posts on this page where people rule out any sex whatsoever, but nothing at all lamenting the fact that most classic sci-fi is absurdly sexist. Usually naively and unintentionally sexist, perhaps, and only occasionally misogynistic, but not suitable to be the bulk of your kid's literary diet.
In fact, the best reason for tolerating a little sex is that most of the non-chauvinistic sci-fi does contain sex. Plus, it is a good idea for kids to be self-consciously, abstractly wondering about sex before they encounter their own urges in a concrete form. They aren't going to take their ideas from you, their parents, and the alternatives are books, movies, TV, and peers. Obviously, good books and a few movies are your best hope if you want your kids to take a thoughtful, critical approach.
I don't know ANYTHING about pre-teens except what I know from being one, but I know I read several books about sex as a pre-teen and was alternately amused and horrified by the unreflective, superstitious, fetishistic approach to sex that my peers took to sex. Whatever they heard from anyone between their age and twenty-one, they took as gospel truth. Whatever they knew at a given time was assumed to be pretty close to the whole truth. Good science fiction is a wonderful inoculation against those attitudes. (Unfortunately, it seems that most science fiction is optimized to sell to people who would rather fantasize about sex than think about it, but you just have to find the exceptions.)
Here are a few books that might be suitable for preteens.
Island , by Aldous Huxley. I actually read this as a pre-teen. The main thing I took away from it is that sex and love present some thorny problems, and different people have come up with many very different ways of coping with them. It influenced me to approach sex with a combination of compassion, love, and pragmatism, in that order. I learned to keep that attitude to myself in the macho culture I grew up in, and gave up on it altogether by the time I went to college, but eventually my adult experiences with sex brought me right back to where Aldous Huxley started me out. This is a no-brainer choice to give to freethinking kids. It does advocate judicious use of hallucinogens for spiritual purposes, but I read and admired it as a preteen and was never tempted to test that particular idea. (Twenty years later, I still haven't.)
Fledgling , by Octavia Butler. Perhaps this one should be saved for older teens. I really don't know what to say about this book except that it made me think. I'm normally a pretty quick reader, but I kept putting this one down just so I could think for a while. (I know, I'm supposed to do that with every book. So I'm a philistine; sue me.) The takeaway lesson from this book is that people have to be very ethically careful about relations of power and dependency.
Stranger in a Strange Land , by Robert Heinlein. The older I get the more I realize that Heinlein was a pompous dick who loved to put ridiculous ideas over on people, take undeserved adulation from naive people (like my teenage self,) and then defend himself against the critics by saying he was just "throwing things out there" or "seeing who would take him seriously." So I would definitely rer
For many, dialup does what they want. email, low bandwidth browsing etc. Low-tech folk.
I'm surprised to see this opinion on Slashdot. I used to hear it a lot from non-techy folks like my parents.
It's wrong, and it's closer to the opposite of the truth than to the truth itself. Nerdy, tech-loving people such as myself spend a lot of time using low-bandwidth things like news, Google groups, mail, ssh, and googling for error messages. We exchange source code. I usually don't need much bandwidth while I'm doing my very high-tech programming job.
In contrast, "low-tech folk" spend the vast majority of their online time watching media or visiting media-rich web sites. They exchange vacation photos and funny videos. My parents finally broke down and got broadband because it was taking too long for my mother to download her friends' photos of the outings they went on. Now my parents consider it a necessity -- they can't imagine waiting for pages to load like they used to. Who has that kind of time? Not even low-tech retired folk, evidently.
Here are a bunch of choices. (See links to Lisp, Java, Latex, and Perl samples here.)
The one I use is Jedit Gray, altered to use a slightly darker background. I bet you can achieve the same effect in Vim. (If not, neener neener neener!)
Personally, for me, ambient light is a much bigger deal than the colors on the screen. I get eyestrain when my screen is significantly brighter than the room around me. Even when I'm staring directly at the screen for hours, my eyes seem to adjust themselves to the brightness of my surroundings instead of to the brightness of the screen.
I first noticed this playing Doom fifteen years ago. When I got really tired near the end of a long session, I sometimes had to turn the lights on for bright maps.
Ah, but what other distro can you get preinstalled and supported (for a very reasonable price) on a new ThinkPad?
*shakes fist at Lenovo*
I lived through some of the years growing pains of Linux on the desktop and am not willing to go through it again with a laptop. A bunch of people have posted how-tos recording how they "succussfully" installed Linux (notably Ubuntu) on their T61s, but when you read the details, you find out that none of them really got it working right. They're just enthusiasts who are willing to put up with a laptop that doesn't, say, hibernate, or let you adjust the screen brightness over the halfway mark, or some other thing that would be intolerable in the long term.
Emperor Linux sells T61s with what appears to be full hardware support, but they charge a hefty markup, which strengthens my suspicion that it's not a reasonable thing for one guy to try to accomplish in a weekend.
That leaves me with pre-installed OpenSUSE, but buying service from Novell leaves me with a bad taste in my mouth.
You'd think we would be close-knit, but I am completely isolated from the other developers working on internal systems, and at various stages in the process I have received at least four different sets of requirements from people I didn't know, who had been assigned to gather requirements for the project, who had gathered requirements for a previous incarnation or failed start in the past, or who found out about the project and realized their department would be impacted. All of the requirements were gathered manager-to-manager (or rather, manager-to-self) and were supposed to be filtered through another manager (whom I impudently cut out) before I saw them. Of course, the end users were not consulted until much later in the process.
You are absolutely right about testing, by the way. No QA resources have been assigned to my project, and as far as the QA manager is concerned, I am doing a fine job and should keep it up. Scary, ain't it? In these small development shops, you are not likely going to be hired on as a 'coder'. Yeah, I am officially a "Software Engineer" and have previously been a "Software Developer" and even (probably inappropriately) a "Member of Technical Staff." I like to call myself a "coder" or a "programmer" anyway, because I think the term "programming," like "writing," should encompass all the activities, high-level and low-level, social and solitary, that contribute to the finished product. If William Faulkner is known as a "writer" and not a "Senior Literary Engineer," then I would like to be known as a "programmer"
I agree with what you're saying but would put a more pessimistic slant on it. A programmer shouldn't take a personal, face-to-face, cube-to-cube interest in what goes on in other departments hoping to make improvements on business processes. A programmer should do that because otherwise the specs will be wrong, the design will be flawed, and the tests will be lacking.
You will be told, "There are people whose job it is to talk to all the stakeholders, understand their disparate needs, and assemble the requirements." This is correct. There are also people whose job it is to design the system, other people who are supposed to implement parts of the system, and other people who are supposed to test the system. Odds are that many of these jobs will be assigned to incompetent, clueless, and/or underworked people. Odds are that even the competent people will miss things that might cripple the design later. It improves your odds immensely if you do some reconnaissance work on your own.
Don't duplicate the work done by others (unless you figure out that a particular person is useless.) If somebody talked to the manager in group X, then you should talk to the second in charge. If someone talked to a supervisor, talk to the grunts. Read their requirements first, then go casually chat with them as if the requirements were correct. Observe their looks of panic and horror. Then start taking notes. Requirements are often collected manager-to-manager and leave out vast swaths of essential functionality.
After you feel good about the requirements, review the test plan. If anything is obviously missing, mention it. If anything looks suspiciously underspecified, chat innocently with the testers about it. "I bet testing internationalization is gonna be a bitch. How the hell do you even type right-to-left text in Windows, anyway?"
This is your job as a coder -- to have the backs of the people you work with and save them from themselves. If you're lucky, someone is doing the same thing for you. The guy who wrote the test plan might look at your issue tracker to see what features you plan on implementing. Maybe you missed something. The guy who wrote the high-level specs might look over your design docs to see if you've made any obvious mistakes with respect to deployment requirements.
A lot of people see this kind of behavior as being absolutely contrary to fundamental engineering principles. On the contrary; it is sound human engineering. It shouldn't even be a political problem. The only people who won't appreciate the feedback and correction are the ones who are consistently shown to be incompetent.
As for the other issues, my observation about Spanish speakers was an observation, not a generalization, and it's a necessary one when dealing with matters of usage. For example, the word "cochino" when applied to a man means a lewd, lecherous man who has a predatory attitude towards young women. Does this word have a positive or negative connotation? Is it a term of abuse or sly admiration? It depends on who's talking.
And I'm a gringo, by the way, so it is my right to co-opt this verbal weapon and use it as I please
I'm not sure how you get that image when the name itself suggests a more appropriate one: the gnashing of teeth as Linux users are forced to use the closed-source, out-of-date Adobe player because all the open-source implementations suck.
:-)
And lest anyone cry, "Open source software will only get better when people use it," get real. Lack of stuff to work on is not the problem with gnash
The good news is that it's a young project that only started in late 2005, so it's far too early to give up on it.
"Señorita" does not translate directly to "girl." "Young eligible woman" is a better translation. When you call a señora "señorita," you are essentially flattering her about her age, whereas if you call a woman "girl," you are implying she is a child.
Many Spanish speakers would call an attractive fourteen-year-old "señorita," but that is essentially sexist -- it implies that sprouting tits is all the growing up that women need to do. That is a pretty common belief among Spanish speakers (at least in the United States) so it's not surprising that a gringo would think "señorita" implies "adolescent."
Maybe all good programmers have been through a period of life like that, but nobody who still lives and thinks like that is a good programmer.
Take RMS as an example. He was a typical socially-challenged geek, but the first insight that made him famous was a social insight into how the MIT hacker community worked. He wasn't turtling; he was analyzing his community and figuring out how to be a part of it. Eventually he even became a leader of a subgroup of that community.
Unfortunately, not every geek is that brilliant, and not every geek is so successful at applying his intellect to understanding the social environment that others navigate by intellect. Often geeks are so alienated that they cannot reconcile themselves even to the idea of working productively with their peers in a corporation.
Every good programmer has to make concessions to the practices of his peers, and every good programmer has to let go of the need to feel smart. Further, every programmer who isn't brilliant -- i.e., 99% of them -- will stagnate if he (or she) isn't capable of learning new ideas from his colleagues. Someone who has a nonexistent social life is probably not the kind of person who can listen to someone else and model the potentially valuable thoughts in that person's head.