If you are achieving that much at that time in your life, why on earth would you be going to community college? Either make sure that their high schools can challenge them, or get them to a college with an academic environment that will.
A community college does not have that environment.
Bullshit. Depending on the type of community college you are referring to. I spent my freshman and sophomore years at Miami Dade College, the largest center of higher learning in the US, the top center for learning of English-as-a-Second-Language at an academic level (catering to many university students from around the world), with superb facilities and labs, decent AA and AS degrees.
I got far more exposure and training in programming there than at the 4-year college I went after graduating from there. I shit you not. Its calculus, differential equations and physics classes were much better. We got full courses in x86 and mainframe assembler, programming with Mathematica, classes on expert systems, a full-time math/physics lab, theaters and fine arts stuff up to the wazoo. Broward Community College, a smaller community college in adjacent Broward county is not shabby either.
There is nothing in these community colleges that lack in academic environments compared to most 4-year schools. There are many other community colleges out there that are the same. In many cases, it is better to take your freshmen and sophomore science science courses at a community college than at a 4-year university because a) they are of a better quality, and b) they are cheaper.
Maybe you have never sat foot on a good community college or you went to a shitty one. But you are completely mistaken if you think the best chance to study at an academic environment is only at a 4-year school (sometimes it's just the opposite.)
I am an old programmer. Yes I did learn about hashes and btrees in school but frankly this new hire made me doubt what they where teaching in University these days.
I have found that experienced programmers will will take a look at a task and know immediately that they should use this algorithm or that. Also from experience you tend to learn to look past the initial requirements of an application and see what a user may want in the future and design for those. Of course in a larger institution you will have a project architect that will handle that type of planing. I work in a small development house so the programmers are given a large amount of freedom and responsibility.
In that case it was the programmer's at fault for not knowing about it, or there was something missing in his education. That type of data structure and algorithm knowledge is still being taught by the time a student enters his junior years (if not before).
But it is also the case that many CS schools (not all thank God) have turned into lame Java learning centers (they don't even teach Java right anyway).
I know of this student who I corresponded with e-mail until recently. He graduated with a B from a 3000-level class in data structures and algorithms, and he didn't know how to use for loops. No exaggeration. I peeked at the school curriculum (his school will remained unnamed.)
The curriculum was pathetic. Superficial teaching of Java as the first programming language, with, maybe 3 weeks of C++ at the end of the course, superficial computer org class with another 3 weeks of assembly, and then BOOM, right into data structures and algorithms. Grading is such that anyone but a lobotomized retard can pass... with a B or better. And the sad thing is that the curriculum and the requirements at that school weren't like that 15 years ago.
The things I mentioned as basic are still taught and reinforced at good schools, but there are other schools that have turned shitty just to increase their enrollment numbers... ergo producing a shitload of people that are not qualified at all and that would have never graduated 10+ years ago.
That is what is taught but did they learn it? I ran into a "programmer" from a local university with a degree that had no idea what a hash was much less when to use it.
The either he was a lame programmer or his education was lame. As I mentioned in a previous post in this thread, I learned that stuff on my second 2000-level programming class, in my second year at university. It is fundamental knowledge. The only thing more fundamental than that is control structures (structured program theorem), and the basics of structured programming and top-down design.
Also, who cares if "they" learn it or not. Who's "they". What about you? You claim that experience is where you learn that, which I and others tells you is fundamental. Was that YOUR experience? YOUR education? If you don't have formal computer science education, that is fine. Some of the best programmers I've known never had any formal training in computer science.
But by and large, when referring to programmers with a computer science background, if they don't know that, then they weren't paying attention, or their education was shit.
The thing with programmers is that they don't (should not) need to use a language with support for RAII to understand the concept of defensive resource management.
A programmer who miss that in PHP would most likely miss that in C and also is likely to create leaks in garbage-collected languages.
It is a matter of education (and to a point lack of foresight) more than anything else.
"The fact that you have 30 years of COBOL experience doesn't help you if you don't learn new technologies."
learning a new language is easy. Learning to program is hard.
c, java, c#, php, perl, are all very much alike.
Barring the curly braces and common control structures, no, they are not. Not even freaking close to be alike by any stretch of the imagination. C very much alike to Java, C#, PHP? Perl? I mean, C???? Of these bunch, only Java and C# are mildly similar, and only superficially.
Once you know one learning the rest are easy.
The problem with that thinking is that you only think about trivial code examples of any of those languages. When you start using them for non-trivial tasks, you find that there are obscure semantic idiosyncrasies that either make or break you. There are APIs, infrastructures, architectural considerations and limitations that are unique to each and which is the meat of the knowledge required to actually program non-trivial systems.
This is not taking into account that in almost all non-trivial systems (specially in IT computing), you do not develop in one single language.
I do agree that learning (minimal learning of) a new language is easy but learning to program is hard.
I do not agree though, that the *rest* is easy. It is not. It takes months of immersion to get minimally proficient any each one of them.
In your typical application program so much code is now offloaded to the libraries that once you leave school you are unlikly to have to write a HASH or a sort every again.
Exactly the point. You still have to learn how to program by using those libraries. And you can't effectively know how to use them if you haven't burn the midnight oil in school doing many of those libraries from scratch. Because each of those libraries, each of those data structures and algorithms have pros and cons, run-time penalties and characteristics that you need to be aware of, and doing them from scratch is the only way to truly understand them.
What experence teachs you is when you need to use a hash vs a btree.
I don't know about you, but I learned that on my first 2000-level CS class in college, before even entering a 3000-level class devoted exclusively on data structures and algorithms.
Work is not the place to learn the basics. Employers don't pay us to learn the basics while we program for them. Work is where you get your experience which should consist of team work, domain specific knowledge, working under prolonged schedules (as opposed to working on throw-away programs for every class assignment), working with source control on a true system, knowing how to go live with a product, etc, etc.
Either you weren't paying attention in school, or your education was atrocious. Experience *is categorically NOT* the place where you learn how and when to use basic and fundamental 2000-3000 level data structures.
Actually, school teaches you that. If it didn't, you were not paying attention in class.
You make a common mistake. Teaching is not the same thing as learning. Learning is what sticks and it includes knowledge that didn't come from the "teaching" end.
I have a hard time picturing a CS education where they didn't *teach* the difference in purposes of a hash vs a btree (unless the instructor/curriculum is atrocious.) It is such a basal, fundamental principle that it *must* come via *learning* from *teaching* (assuming a decent instructor and curriculum.)
Knowledge: that's the sum of everything that has/should have been appropriately learned in school plus everything that has been learned at work... plus everything that can be correctly deduced/reasoned from that.
The fact that someone thinks that it is from experience that we (should) learn when to use a hash over a btree makes me wonder what the fuck they are teaching in CS schools nowadays.
At least here in North America, our general aversion to unions is entirely rational. Unions here do not foster creativity - they foster group think.
And management does the same, and uses their group think to destroy our creativity.
Though it is true that some management (not all but some, a reality that does not fit well in slogans), do impair programming productivity, there is this fact: We don't get paid purely to be creative, but to use our creativity to solve problems in the most efficient way that can help our employer's bottom line.
Management exists to provide the plumbing that we engineers need to do our job: manage billing, infrastructure, benefits, cash flow, repairs, to make sure the building you work on meets regulatory standards, to deduct your taxes, to provide strategic planning and to make sure there are earnings at each quarter because that's the only fucking way in which you not only get paid but also get a chance to get a damned raise.
We, software engineers/computer scientists, exit to solve problems in ways that improve our employer's chance to improve their bottom line... cuz that's where the money come from for our chairs, our cubicles, the monitors and laptops and that interesting shit called electricity that runs your work computers, your networks, the A/C, the coffee machine and the vending machine from where we get our doritos, sodas or whatever shit we eat and drink when we bang at the keyboard solving problems and helping our employer's bottom line... cuz that's where the money come from for our chairs, our cubicles...
You get the idea.
If I wanted to be measured strictly on the basis of my creativity, I would not have opted and loved to be an engineer/scientist in the field, in the heat, getting paid to solve shit that changes due to dynamic external pressures.
Instead, I would have chosen to be, I dunno, a dancer, a musician, or a painter and either paint the second coming of the Sistine Chapel or crap on a canvas and call it an exquisite sample of some avant-garde sounding artistic movement.
The problem is not that "anybody can program any system," because as you said that's not true. The problem is the gatekeepers of salary and status simply cannot tell the difference between those who can and those who cannot. Thus there is not much career progression in programming.
Depends. For people that have degrees in CS and EE (specially advanced ones) and years of experience, it is very rare that they don't have a career progression in programming.
Or, in IT Computing, career progression depends on the degree of specialization and breath of knowledge. In the Java world, for example, it pays not only to be a good Java programmer, but also
to have one or more specializations (.ie. web/RIA development + ejb/spring or web service development + jee architecture),
a good understanding of databases (not only on database theory and SQL, but on vendor specific DB infrastructure, configuration, tablespaces, rollback segments and so on.)
a good understanding of distributed computing
a good understanding of network infrastructure (because then you know that there is a shitload of things like DNS servers, caching devices and the like between your users and your app that can affect the performance and behavior of your app)
a good understanding of operating system configuration (because then you can detect your OS TCP timeout settings are not tuned and are thus wreaking havoc between your Apache servers and your JEE containers.)
... and so on and so on...
The thing is that, it is true that there is no career progression in programming. But that is true because programming by itself is not the only thing at play, nor the one isolated thing in which we build specialization and breath of experience.
I'd consider getting a managing position as being demoted.
Depending on where you work. In some companies (specially the shitty ones), this is true.
But in others, specially good companies (either engineering ones or IT ones that value technology), being a manager after being a techie is a good way to go.
For me, I'm 41 now, programming for 15 years now, 18 if we count school work. Been a senior soft.eng for a while now. By 50 I intend to be either at an architect position, or an engineering management position (different challenge and - usually - more money). Either that or I'll "retire" by 55 to teach programming or math at a university or community college and do some part-time consulting gig on the side (less money but more enjoyable.)
At least that's the plan.
I love pure, raw and unabashed coding, but I don't feel that I will have the passion for doing so beyond another decade. I do some very interesting software programming work, but still. Been there, done that, what's next? Meh, working my way to promotions.
Unless there is something like, oh, I dunno, some new, revolutionary industrial research shinny thingie that gets my programming panties all curled up again in frenzy, moving up the (engineering) management ladder (in a good tech company, that is) looks like a good deal to me.
What about motivation? People tend to write more lines of code if they are motivated. I've written most of my lines of code driven by motivation of their usefulness rather than my age.
Although, at my age, I rather write more lines of code that do stuff for me quicker. Maybe I've become lazy AND old.
Motivation != efficiency (or even knowing how to program well).
Lines of Code != good indicator of programming productivity, experience or efficiency.
I've known a lot of motivated programmers, motivated for sure, but ones I wouldn't trust anything beyond maintaining JSP pages. Motivation by itself doesn't mean much, not unless it is accompanied by hard-earned elbow-grease and experience (or when inexperienced, at least a firm knowledge in programming principles, a sharp mind, and good intuition about complex problem solving.)
Might be wrong, but that's what I see as a good indicator for desirable programming attributes. Not motivation alone. Certainly not rate of production of lines of code.
Could we stop arguing whether Google is doing this because they have too few or too much minority workers or the merits of Affirmative action and start talking about how hypocrite and wrong is that corporations can have private secrets as if they were people but those same corporations routinely down play or right out ridicule the idea that privacy is a natural right and need of actual people?
Yes that's one sentence.
So you think talking about corporate hypocrisy is more important (and possibly more evil) than exploring the causes of the very important social and economic problem of having so few members of a given ethnic group in one of the most important sectors of the industry?
That's... uhm... an interesting way of prioritizing social issues I guess.
Makes me wonder about previous posters claiming they've never seen an African-American engineering student in their classes. Its possible that they are there and yet unseen by certain people.
Stop that bull.
I don't know to which posters you are referring to, but the number of US-born Hispanic and African-American students in engineering fields is dismal.
I am Hispanic, and this I have discussed with the very few African American and Hispanic engineers I've worked with (we, minority engineers concerned about increasing awareness of science and engineering into our racial groups as opposed to ignore the fact, or worse, assume racial profiling in the corporate sector.)
This disparity is not originated by companies doing racial profiling. It is an ethos problem, and it is a problem mutually shared by the government, the education sectors and the minorities in question.
People can choose to surreptitiously turn the statement of this fact into a race game, or they can choose to acknowledge the nature of that disparity (which is necessary for exploring solutions for it.)
It is easier to say that "they" are there, but are not seen "by certain people" than to really dig deep into a very complex problem for which there is no simple (read simple-minded sloganish) explanation or solution.
Equal opportunity is not flawed... everybody should have the equal *opportunity* to work for Google. Should everybody actually get hired equally? No, absolutely not... that should depend entirely on aptitude, effort, suitability, etc.
For starters, there is some cognitive dissonance between these two things you said:
everybody should have the equal *opportunity* to work for Google.
and
Should everybody actually get hired equally?
You can't work on google equally if they don't get hired equally. Perhaps what you want to say is that everyone with the minimum requirements for a job should have a right to apply for that job. And this I totally agree.
As a minority myself, I got to say, indeed equal opportunity in many cases *is flawed*. It works in education. It levels the entrance (and playing fields) for ethnic groups that have historically been at a disadvantage (there is a racial component to this which makes the topic rather inflammatory *for some*, there is no way around it, and it's a topic better served with its own thread.)
It works in at work (no pun intended) as it makes it illegal to use race, ethnicity (and similar attributes) as factors in the hiring process. But that's about it.
But, as you have said, getting hired should strictly depend on qualifications. And this is where affirmative action is flawed.
I am a Latino, and do you know how many Latinos I've seen in engineering and science schools? Not that many, even perhaps in areas with a high % of relatively affluent Latinos like Miami-Dade County.
How many African American students I saw in engineering and science schools? Not that many either unfortunately. The number of African American IT/engineering colleagues I have had in the last 15 years is very small, almost dismal.
What are predominant groups studying and working IT/Engineering fields in the US? Non-Hispanic US-born Whites (the majority), and South Asians (India/Pakistan), Chinese and Eastern European immigrants (three minority groups.)
The problem certain (not all) minorities face in this respect are of a cultural nature and multi-variable. This is a problem to be fixed by the government, by minority leaders, and to a large degree, by the minorities themselves. It is in large part an ethos problem and lack of information and role models conductive to the pursuit of education in the engineering and science fields.
It is not up to corporations to execute social policies.
If the overwhelming majority of students in science and engineering fields *are not* Hispanics or African Americans, in proportions that are substantially smaller than their proportions with respect of the total population, then it is obvious to anyone that is not a retard (or a sensationalist politician), that overwhelmingly you will have a truckload of White and Chinese/South Asian people next to a miserably small number of equally qualified Hispanics and African American applicants.
Let me re-iterate this again: It is not up to corporations to execute social policies.
If I create my own software company, and in my hiring process I overwhelmingly get resumes only from white people or say, just 3% (a # I just pulled out of my ass for the sake of argument) from Hispanics and African Americans, and if race is not a factor in favor or against anyone, obviously then, my employees would be predominantly white.
Would that be my fault? Would the white dudes who got hired be at fault? My business is to make business and only hire those that qualify, independently of race.
And that's primarily a function of who applies, itself a function of who studies in science and engineering fields.
Unless we have evidence that google is doing racial profiling (do we actually believe that shit), the onus is on the government (local and federal) to investigate why certain mi
Whilst stealing enough to live on *might* be acceptable if he couldn't even get a minimum wage job (which should be enough that a person doesn't need welfare, but that is a rant for another time), couldn't get welfare payments, and didn't have anyone else to support him, he didn't need 27.5GUSD, which is more than most people earn in their lifetimes and would be enough to love pretty luxuriously. Hell, for that much money, the prospect of having to spend the rest of one's life living in countries without extradition treaties with the US would be very tempting to most people.
The hypothetical rapist you mentioned is almost certainly mentally ill, and as a danger to society should be kept in a secure hospital until he is cured.
When I was a kid, I grew up almost barefoot and, at one point, really this close to get food out of a trash can. And I saw people in worse situations that my family. I've really seen what it is like to be poor and unemployed in a third world country, and even in those dire situations, people still choose not to steal. People would feed tomatoes out of trash cans to their kids before stealing.
In 20 years here in the US, I have not yet seen an example of excruciating poverty (not that there is no poverty here) that would actually take one to steal as the only way out.
Right now there are hundred of thousands of people unemployed right now, some of them for long periods of times.
How many engineers are out there that don't have jobs for quite some time? Many. How many people with college degrees have gotten the short end of the stick with this economic crash and are now doing part-time jobs flipping burgers, serving tables or cutting grass to make ends meet?
How many of them steal, much worse incur in sophisticated and rampant cybercrime?
What this guy really that deprived of getting a job, any job, however menial that would be?
Illegal aliens get jobs for pennies by picking tomatoes? And him, what about him? Not a single opportunity to earn his bread and climb his long way up from the hole he put himself into in the first place?
This guy wasn't even close to the point where he was justified to steal a piece of bread. He should burn in hell, with a pitchfork rammed up his ass.
Not necessarily. If its a quick and dirty hack to get something done in a short period of time on a "temporary" basis, then its quite possible the programmer intentionally wrote "shitty code" - and KNEW it was shitty code.
Shitty code by itself doesn't mean much in terms of quality without the context in which it is written.
A quick and dirty hack that is considered shitty by the creator(s) s not necessarily a terrible piece of crap. When the hack is,
at least, sufficiently documented in code and
when the author and his team are fully aware that it is supposed to be a temporary hack (independently of whether it gets fixed or not), and
the hack is not one that by itself will lead to an major change (which is different from major changes required by the error which required the hack in the first place), and
the hack was done as a concession to external pressures and actual issues to resolve a real problem
then there is nothing more to say beyond saying that the hack is shitty.
That is, what matters is both, intention, awareness and knowledge. That's what differentiate shitty code that inevitably crops out as required hacks in non-trivial systems (that is, engineering trade-offs with a known risk) and what we truly consider as shitty code, shitty code written by shitty code monkeys either due to ignorance/incompetence and/or a lack of professional ethics that'd make one give not a shit about quality.
It might seem like trivial hyperbole, but it is a critical distinction to make.
Perhaps we should blame both the person who broke into your car as well as the user of the lock for the break-in. You incorrectly assume that blaming the perpetrator and blaming the victim are mutually exclusive.
There is nothing in my post that says I consider them to be mutually exclusive. On the contrary, the post that I was replying to does exactly just that, by implication, by shifting the blame to an industrial flaw while simultaneously omitting the personal blame that squarely falls on Iceman.
And this is while ignoring the fact that a discussion on the personal and moral blame of executing a malicious and criminal act (which is what he did) does not require a simultaneous cause/effect or correlation discussion on an industrial flaw that whose moral nature is questionable and debatable at best (given that it is more a matter of incompetence).
Only on/. you can find that type of argument where finding blame on the technological incompetence (or lack of moral foresight) takes precedence over the undeniable, unquestionable and irrefutable moral blame of a criminal act that is beyond argument, discussion or scrutiny.
"It is a shame that someone with so much ability chose to use it in a manner that hurt many people," Dembosky said in an e-mail message."
That in light of
"Butler served an 18-month prison term for the crime and fell on hard times after his 2002 release, he said in a sentencing memorandum filed Thursday. "I was homeless, staying on a friends couch. I couldn't get work," he wrote. In desperation, he turned again to cybercrime."
I'm not saying he's right, but it does highlight something interesting about finding work as an ex-con.
What type of work was he trying to get? Not that it is easy to find work as an ex-con, but it isn't impossible either (so long as the person lowers his expectations... read flipping burguers.) That is part of the cross an ex-con got to carry, right or wrong.
I hope that he has to serve the full sentence, and doesn't get out on parole. Credit card fraud is not fun. I can only hope that more people convicted of credit card fraud receive sentences like this.
Yeah, blame the criminals for exploiting a system designed to dispense cash based solely on a 4 digit number; That makes sense. Credit card fraud wouldn't happen nearly to the degree it does if financial institutions had designed the system to be more resiliant to attack. And by more resiliant, I mean doing something other than coating the cash in BBQ sauce and waving it in front of the hungry and unemployed masses while chanting "Hell no, we won't upgrade!"
Oh wow, so I guess by your logic, I should not blame the person who broke into my car and stole just because the lock wasn't designed against simple lock-picking (it isn't hard to pick a lock.)
Blame the faults of the implementation of a technology, and absolve the criminal of his own personal and moral responsibility. Awesome display of stupidity.
But where is the combined evidence (archeological and genetic) that says the Inuit (or any extant New World group for that matter) came into the Americas as far back as 20,000?
Let me re-phrase the question, just so that there are no misunderstandings: is there any particular native group X in the Americas for which there is enough combined evidence (BOTH archeological and genetic) that can firmly clock their (either unique or last) trek and permanent move into the Americas to a date as far back as 20,000?
Although both contemporary Inuit and the extinct Saqqaq migrated from Siberia across the Bering Straits, the Saqqaq migration was a much later one (5,000-10,000 years ago, compared with 20,000 for the Inuit).
Where did you get these age ranges? 20,000 years for the Inuit? Correct me if I'm wrong, but AFAIK, and except for tentative sites in Alaska, existing migratory evidence that we have today for the peopling of the Americas does not go back that far back in time. We believe that the people in Beringia were isolated between 10K and 20K, but we do not know precisely when they made the trek to the Americas.
Now, the linguistic and genetic evidence DO suggest that the peopling of the Americas started that far back in time as a whole. There are findings in Alaska, the establishment of the linguistic connection between the Na-Dene languages (.ie. Apache, Navajo) and the Yenisean languages, or sites like Monte Verde in Chile (which challenges the "Clovis First" theory).
But where is the combined evidence (archeological and genetic) that says the Inuit (or any extant New World group for that matter) came into the Americas as far back as 20,000?
Now, let's consider what the article says:
His ancestors split apart from Chukchis some 5,500 years ago, according to genetic calculations,
The Saqqaq split from the Chukchis about 5,500 years ago. That date alone does not provide any window by which to speculate when the Saqqaq entered into the Americas. They could have split off when they entered, say, a thousand years before. Or they could have split off after their common ancestor entered the Americas with the ancestors of the Chukchis moving back into Siberia. Purely speculative I know, but the models of migration does not preclude back-and-forth migration over the ice sheets/along the Beringian corridor (which if you think about it, it's very sensible and pausible.)
Moreover, the ancestors of the Inuit and Saqqaq could have split off back in Siberia and way before their independent entrances into the Americas. I just don't see how TimFinger came up with this 10K-20K year range.
Just out of curiosity, what is your opinion of a "Large" codebase then?
That depends on the language, but anything starting above a quarter of a million starts to get large. Consider the Linux kernel - not a typical distro, or the dev tools, or even a minimal bare-to-the-bones distro, but the kernel. The 2.6.0 kernel is over 5 million lines. Later kernels are twice as large.
30-40K is about the lower threshold of a mid-size stand-alone system or a component in a much larger system. For example, at one job I worked on a component that was about 200K LOC. That was one piece in a distributed system containing several dozen vertical components on top of vertical layers of stuff summing up to several dozen million LOCs. This is only considering source code. Once you start considering configuration files, deployment and installation scripts, it gets more complex.
There is now a classification for ultra large systems that in the near (and very likely) future could easily go into the billions, posing new challenges on project management, source control, and just about anything relating to the question "who the fuck knows what this gigantic shit is supposed to do."
Now, difficulty of maintenance is not just a function of code size, but also code structure and organization and documentation.
You can work with a monster system that is in the millions of LOCs and not have a substantial problem implementing new functionality or bug fixes, and then in another job you have to maintain poorly written JSPs that collectively are in the 50-100k (with the later job being a mutant klingon bitch.)
When you get into a corporate environment, "cheating" is actually preferred. No reason to re-invent the wheel when there is existing code that gets the job done.
Need a report that's "like this one except for..."? Take the code for that report and add some mods and there ya go. Your manager would consider you an idiot if you started each project from scratch, re-writing all the functions and methods that already exist in other applications and have perhaps already gone through rigorous QA.
Uh dude, that is so wrong in so many levels.
First, cheating =/= reuse.
Second, being measured for competence =/= being paid to implement cost-effective, efficient solutions by reuse rather than by reinventing the wheel.
Anyone who pays attention to this in school and in real life knows that difference.
Besides, how many ways can you write a QuickSort?
First, there are several ways, believe it or not. Second, non-sequitur. Most of the work done out there is not about implementing new and radical, novel algorithms but on intelligently engineer solutions that maximize re-use as much as possible. This can only be done by have a degree of competence, the one which we get tested for... and in which losers and incompetent people cheat.
Slashdot Mirror
If you are achieving that much at that time in your life, why on earth would you be going to community college? Either make sure that their high schools can challenge them, or get them to a college with an academic environment that will.
A community college does not have that environment.
Bullshit. Depending on the type of community college you are referring to. I spent my freshman and sophomore years at Miami Dade College, the largest center of higher learning in the US, the top center for learning of English-as-a-Second-Language at an academic level (catering to many university students from around the world), with superb facilities and labs, decent AA and AS degrees.
I got far more exposure and training in programming there than at the 4-year college I went after graduating from there. I shit you not. Its calculus, differential equations and physics classes were much better. We got full courses in x86 and mainframe assembler, programming with Mathematica, classes on expert systems, a full-time math/physics lab, theaters and fine arts stuff up to the wazoo. Broward Community College, a smaller community college in adjacent Broward county is not shabby either.
There is nothing in these community colleges that lack in academic environments compared to most 4-year schools. There are many other community colleges out there that are the same. In many cases, it is better to take your freshmen and sophomore science science courses at a community college than at a 4-year university because a) they are of a better quality, and b) they are cheaper.
Maybe you have never sat foot on a good community college or you went to a shitty one. But you are completely mistaken if you think the best chance to study at an academic environment is only at a 4-year school (sometimes it's just the opposite.)
I think those that can fit in academically are the least likely to fit in socially.
Because? Academically speaking, how would you support that statement?
I am an old programmer. Yes I did learn about hashes and btrees in school but frankly this new hire made me doubt what they where teaching in University these days. I have found that experienced programmers will will take a look at a task and know immediately that they should use this algorithm or that. Also from experience you tend to learn to look past the initial requirements of an application and see what a user may want in the future and design for those. Of course in a larger institution you will have a project architect that will handle that type of planing. I work in a small development house so the programmers are given a large amount of freedom and responsibility.
In that case it was the programmer's at fault for not knowing about it, or there was something missing in his education. That type of data structure and algorithm knowledge is still being taught by the time a student enters his junior years (if not before).
But it is also the case that many CS schools (not all thank God) have turned into lame Java learning centers (they don't even teach Java right anyway).
I know of this student who I corresponded with e-mail until recently. He graduated with a B from a 3000-level class in data structures and algorithms, and he didn't know how to use for loops. No exaggeration. I peeked at the school curriculum (his school will remained unnamed.)
The curriculum was pathetic. Superficial teaching of Java as the first programming language, with, maybe 3 weeks of C++ at the end of the course, superficial computer org class with another 3 weeks of assembly, and then BOOM, right into data structures and algorithms. Grading is such that anyone but a lobotomized retard can pass... with a B or better. And the sad thing is that the curriculum and the requirements at that school weren't like that 15 years ago.
The things I mentioned as basic are still taught and reinforced at good schools, but there are other schools that have turned shitty just to increase their enrollment numbers... ergo producing a shitload of people that are not qualified at all and that would have never graduated 10+ years ago.
That is what is taught but did they learn it? I ran into a "programmer" from a local university with a degree that had no idea what a hash was much less when to use it.
The either he was a lame programmer or his education was lame. As I mentioned in a previous post in this thread, I learned that stuff on my second 2000-level programming class, in my second year at university. It is fundamental knowledge. The only thing more fundamental than that is control structures (structured program theorem), and the basics of structured programming and top-down design.
Also, who cares if "they" learn it or not. Who's "they". What about you? You claim that experience is where you learn that, which I and others tells you is fundamental. Was that YOUR experience? YOUR education? If you don't have formal computer science education, that is fine. Some of the best programmers I've known never had any formal training in computer science.
But by and large, when referring to programmers with a computer science background, if they don't know that, then they weren't paying attention, or their education was shit.
A programmer who miss that in PHP would most likely miss that in C and also is likely to create leaks in garbage-collected languages.
It is a matter of education (and to a point lack of foresight) more than anything else.
"The fact that you have 30 years of COBOL experience doesn't help you if you don't learn new technologies." learning a new language is easy. Learning to program is hard. c, java, c#, php, perl, are all very much alike.
Barring the curly braces and common control structures, no, they are not. Not even freaking close to be alike by any stretch of the imagination. C very much alike to Java, C#, PHP? Perl? I mean, C???? Of these bunch, only Java and C# are mildly similar, and only superficially.
Once you know one learning the rest are easy.
The problem with that thinking is that you only think about trivial code examples of any of those languages. When you start using them for non-trivial tasks, you find that there are obscure semantic idiosyncrasies that either make or break you. There are APIs, infrastructures, architectural considerations and limitations that are unique to each and which is the meat of the knowledge required to actually program non-trivial systems.
This is not taking into account that in almost all non-trivial systems (specially in IT computing), you do not develop in one single language.
I do agree that learning (minimal learning of) a new language is easy but learning to program is hard.
I do not agree though, that the *rest* is easy. It is not. It takes months of immersion to get minimally proficient any each one of them.
In your typical application program so much code is now offloaded to the libraries that once you leave school you are unlikly to have to write a HASH or a sort every again.
Exactly the point. You still have to learn how to program by using those libraries. And you can't effectively know how to use them if you haven't burn the midnight oil in school doing many of those libraries from scratch. Because each of those libraries, each of those data structures and algorithms have pros and cons, run-time penalties and characteristics that you need to be aware of, and doing them from scratch is the only way to truly understand them.
What experence teachs you is when you need to use a hash vs a btree.
I don't know about you, but I learned that on my first 2000-level CS class in college, before even entering a 3000-level class devoted exclusively on data structures and algorithms.
Work is not the place to learn the basics. Employers don't pay us to learn the basics while we program for them. Work is where you get your experience which should consist of team work, domain specific knowledge, working under prolonged schedules (as opposed to working on throw-away programs for every class assignment), working with source control on a true system, knowing how to go live with a product, etc, etc.
Either you weren't paying attention in school, or your education was atrocious. Experience *is categorically NOT* the place where you learn how and when to use basic and fundamental 2000-3000 level data structures.
Actually, school teaches you that. If it didn't, you were not paying attention in class.
You make a common mistake. Teaching is not the same thing as learning. Learning is what sticks and it includes knowledge that didn't come from the "teaching" end.
I have a hard time picturing a CS education where they didn't *teach* the difference in purposes of a hash vs a btree (unless the instructor/curriculum is atrocious.) It is such a basal, fundamental principle that it *must* come via *learning* from *teaching* (assuming a decent instructor and curriculum.)
Knowledge: that's the sum of everything that has/should have been appropriately learned in school plus everything that has been learned at work... plus everything that can be correctly deduced/reasoned from that.
The fact that someone thinks that it is from experience that we (should) learn when to use a hash over a btree makes me wonder what the fuck they are teaching in CS schools nowadays.
At least here in North America, our general aversion to unions is entirely rational. Unions here do not foster creativity - they foster group think. And management does the same, and uses their group think to destroy our creativity.
Though it is true that some management (not all but some, a reality that does not fit well in slogans), do impair programming productivity, there is this fact: We don't get paid purely to be creative, but to use our creativity to solve problems in the most efficient way that can help our employer's bottom line.
Management exists to provide the plumbing that we engineers need to do our job: manage billing, infrastructure, benefits, cash flow, repairs, to make sure the building you work on meets regulatory standards, to deduct your taxes, to provide strategic planning and to make sure there are earnings at each quarter because that's the only fucking way in which you not only get paid but also get a chance to get a damned raise.
We, software engineers/computer scientists, exit to solve problems in ways that improve our employer's chance to improve their bottom line... cuz that's where the money come from for our chairs, our cubicles, the monitors and laptops and that interesting shit called electricity that runs your work computers, your networks, the A/C, the coffee machine and the vending machine from where we get our doritos, sodas or whatever shit we eat and drink when we bang at the keyboard solving problems and helping our employer's bottom line... cuz that's where the money come from for our chairs, our cubicles...
You get the idea.
If I wanted to be measured strictly on the basis of my creativity, I would not have opted and loved to be an engineer/scientist in the field, in the heat, getting paid to solve shit that changes due to dynamic external pressures.
Instead, I would have chosen to be, I dunno, a dancer, a musician, or a painter and either paint the second coming of the Sistine Chapel or crap on a canvas and call it an exquisite sample of some avant-garde sounding artistic movement.
The problem is not that "anybody can program any system," because as you said that's not true. The problem is the gatekeepers of salary and status simply cannot tell the difference between those who can and those who cannot. Thus there is not much career progression in programming.
Depends. For people that have degrees in CS and EE (specially advanced ones) and years of experience, it is very rare that they don't have a career progression in programming.
Or, in IT Computing, career progression depends on the degree of specialization and breath of knowledge. In the Java world, for example, it pays not only to be a good Java programmer, but also
The thing is that, it is true that there is no career progression in programming. But that is true because programming by itself is not the only thing at play, nor the one isolated thing in which we build specialization and breath of experience.
I'd consider getting a managing position as being demoted.
Depending on where you work. In some companies (specially the shitty ones), this is true.
But in others, specially good companies (either engineering ones or IT ones that value technology), being a manager after being a techie is a good way to go.
For me, I'm 41 now, programming for 15 years now, 18 if we count school work. Been a senior soft.eng for a while now. By 50 I intend to be either at an architect position, or an engineering management position (different challenge and - usually - more money). Either that or I'll "retire" by 55 to teach programming or math at a university or community college and do some part-time consulting gig on the side (less money but more enjoyable.)
At least that's the plan.
I love pure, raw and unabashed coding, but I don't feel that I will have the passion for doing so beyond another decade. I do some very interesting software programming work, but still. Been there, done that, what's next? Meh, working my way to promotions.
Unless there is something like, oh, I dunno, some new, revolutionary industrial research shinny thingie that gets my programming panties all curled up again in frenzy, moving up the (engineering) management ladder (in a good tech company, that is) looks like a good deal to me.
What about motivation? People tend to write more lines of code if they are motivated. I've written most of my lines of code driven by motivation of their usefulness rather than my age. Although, at my age, I rather write more lines of code that do stuff for me quicker. Maybe I've become lazy AND old.
Motivation != efficiency (or even knowing how to program well).
Lines of Code != good indicator of programming productivity, experience or efficiency.
I've known a lot of motivated programmers, motivated for sure, but ones I wouldn't trust anything beyond maintaining JSP pages. Motivation by itself doesn't mean much, not unless it is accompanied by hard-earned elbow-grease and experience (or when inexperienced, at least a firm knowledge in programming principles, a sharp mind, and good intuition about complex problem solving.)
Might be wrong, but that's what I see as a good indicator for desirable programming attributes. Not motivation alone. Certainly not rate of production of lines of code.
Don't get me wrong, I also think racism is bad, I take this pretty much as a given and I'm not interested in dicussing it any further.
And unless someone here can start an investigation whether Google is guilty or not is just speculation although another poster confirmed it isn't the case ( http://news.slashdot.org/comments.pl?sid=1552430&cid=31165762 )
On the other hand people are taking seriously the idea that privacy is dead, that, still show some room for discussion.
Ok, I understand now where you were coming from. I misunderstood your first post.
Could we stop arguing whether Google is doing this because they have too few or too much minority workers or the merits of Affirmative action and start talking about how hypocrite and wrong is that corporations can have private secrets as if they were people but those same corporations routinely down play or right out ridicule the idea that privacy is a natural right and need of actual people?
Yes that's one sentence.
So you think talking about corporate hypocrisy is more important (and possibly more evil) than exploring the causes of the very important social and economic problem of having so few members of a given ethnic group in one of the most important sectors of the industry?
That's... uhm... an interesting way of prioritizing social issues I guess.
Makes me wonder about previous posters claiming they've never seen an African-American engineering student in their classes. Its possible that they are there and yet unseen by certain people.
Stop that bull.
I don't know to which posters you are referring to, but the number of US-born Hispanic and African-American students in engineering fields is dismal.
I am Hispanic, and this I have discussed with the very few African American and Hispanic engineers I've worked with (we, minority engineers concerned about increasing awareness of science and engineering into our racial groups as opposed to ignore the fact, or worse, assume racial profiling in the corporate sector.)
This disparity is not originated by companies doing racial profiling. It is an ethos problem, and it is a problem mutually shared by the government, the education sectors and the minorities in question.
People can choose to surreptitiously turn the statement of this fact into a race game, or they can choose to acknowledge the nature of that disparity (which is necessary for exploring solutions for it.)
It is easier to say that "they" are there, but are not seen "by certain people" than to really dig deep into a very complex problem for which there is no simple (read simple-minded sloganish) explanation or solution.
Equal opportunity is not flawed... everybody should have the equal *opportunity* to work for Google. Should everybody actually get hired equally? No, absolutely not... that should depend entirely on aptitude, effort, suitability, etc.
For starters, there is some cognitive dissonance between these two things you said:
everybody should have the equal *opportunity* to work for Google.
and
Should everybody actually get hired equally?
You can't work on google equally if they don't get hired equally. Perhaps what you want to say is that everyone with the minimum requirements for a job should have a right to apply for that job. And this I totally agree.
As a minority myself, I got to say, indeed equal opportunity in many cases *is flawed*. It works in education. It levels the entrance (and playing fields) for ethnic groups that have historically been at a disadvantage (there is a racial component to this which makes the topic rather inflammatory *for some*, there is no way around it, and it's a topic better served with its own thread.)
It works in at work (no pun intended) as it makes it illegal to use race, ethnicity (and similar attributes) as factors in the hiring process. But that's about it.
But, as you have said, getting hired should strictly depend on qualifications. And this is where affirmative action is flawed.
I am a Latino, and do you know how many Latinos I've seen in engineering and science schools? Not that many, even perhaps in areas with a high % of relatively affluent Latinos like Miami-Dade County.
How many African American students I saw in engineering and science schools? Not that many either unfortunately. The number of African American IT/engineering colleagues I have had in the last 15 years is very small, almost dismal.
What are predominant groups studying and working IT/Engineering fields in the US? Non-Hispanic US-born Whites (the majority), and South Asians (India/Pakistan), Chinese and Eastern European immigrants (three minority groups.)
The problem certain (not all) minorities face in this respect are of a cultural nature and multi-variable. This is a problem to be fixed by the government, by minority leaders, and to a large degree, by the minorities themselves. It is in large part an ethos problem and lack of information and role models conductive to the pursuit of education in the engineering and science fields.
It is not up to corporations to execute social policies.
If the overwhelming majority of students in science and engineering fields *are not* Hispanics or African Americans, in proportions that are substantially smaller than their proportions with respect of the total population, then it is obvious to anyone that is not a retard (or a sensationalist politician), that overwhelmingly you will have a truckload of White and Chinese/South Asian people next to a miserably small number of equally qualified Hispanics and African American applicants.
Let me re-iterate this again: It is not up to corporations to execute social policies.
If I create my own software company, and in my hiring process I overwhelmingly get resumes only from white people or say, just 3% (a # I just pulled out of my ass for the sake of argument) from Hispanics and African Americans, and if race is not a factor in favor or against anyone, obviously then, my employees would be predominantly white.
Would that be my fault? Would the white dudes who got hired be at fault? My business is to make business and only hire those that qualify, independently of race.
And that's primarily a function of who applies, itself a function of who studies in science and engineering fields.
Unless we have evidence that google is doing racial profiling (do we actually believe that shit), the onus is on the government (local and federal) to investigate why certain mi
Whilst stealing enough to live on *might* be acceptable if he couldn't even get a minimum wage job (which should be enough that a person doesn't need welfare, but that is a rant for another time), couldn't get welfare payments, and didn't have anyone else to support him, he didn't need 27.5GUSD, which is more than most people earn in their lifetimes and would be enough to love pretty luxuriously. Hell, for that much money, the prospect of having to spend the rest of one's life living in countries without extradition treaties with the US would be very tempting to most people.
The hypothetical rapist you mentioned is almost certainly mentally ill, and as a danger to society should be kept in a secure hospital until he is cured.
When I was a kid, I grew up almost barefoot and, at one point, really this close to get food out of a trash can. And I saw people in worse situations that my family. I've really seen what it is like to be poor and unemployed in a third world country, and even in those dire situations, people still choose not to steal. People would feed tomatoes out of trash cans to their kids before stealing.
In 20 years here in the US, I have not yet seen an example of excruciating poverty (not that there is no poverty here) that would actually take one to steal as the only way out.
Right now there are hundred of thousands of people unemployed right now, some of them for long periods of times.
How many engineers are out there that don't have jobs for quite some time? Many. How many people with college degrees have gotten the short end of the stick with this economic crash and are now doing part-time jobs flipping burgers, serving tables or cutting grass to make ends meet?
How many of them steal, much worse incur in sophisticated and rampant cybercrime?
What this guy really that deprived of getting a job, any job, however menial that would be?
Illegal aliens get jobs for pennies by picking tomatoes? And him, what about him? Not a single opportunity to earn his bread and climb his long way up from the hole he put himself into in the first place?
This guy wasn't even close to the point where he was justified to steal a piece of bread. He should burn in hell, with a pitchfork rammed up his ass.
Not necessarily. If its a quick and dirty hack to get something done in a short period of time on a "temporary" basis, then its quite possible the programmer intentionally wrote "shitty code" - and KNEW it was shitty code.
Shitty code by itself doesn't mean much in terms of quality without the context in which it is written.
A quick and dirty hack that is considered shitty by the creator(s) s not necessarily a terrible piece of crap. When the hack is,
then there is nothing more to say beyond saying that the hack is shitty.
That is, what matters is both, intention, awareness and knowledge. That's what differentiate shitty code that inevitably crops out as required hacks in non-trivial systems (that is, engineering trade-offs with a known risk) and what we truly consider as shitty code, shitty code written by shitty code monkeys either due to ignorance/incompetence and/or a lack of professional ethics that'd make one give not a shit about quality.
It might seem like trivial hyperbole, but it is a critical distinction to make.
Perhaps we should blame both the person who broke into your car as well as the user of the lock for the break-in. You incorrectly assume that blaming the perpetrator and blaming the victim are mutually exclusive.
There is nothing in my post that says I consider them to be mutually exclusive. On the contrary, the post that I was replying to does exactly just that, by implication, by shifting the blame to an industrial flaw while simultaneously omitting the personal blame that squarely falls on Iceman.
And this is while ignoring the fact that a discussion on the personal and moral blame of executing a malicious and criminal act (which is what he did) does not require a simultaneous cause/effect or correlation discussion on an industrial flaw that whose moral nature is questionable and debatable at best (given that it is more a matter of incompetence).
Only on /. you can find that type of argument where finding blame on the technological incompetence (or lack of moral foresight) takes precedence over the undeniable, unquestionable and irrefutable moral blame of a criminal act that is beyond argument, discussion or scrutiny.
"It is a shame that someone with so much ability chose to use it in a manner that hurt many people," Dembosky said in an e-mail message." That in light of "Butler served an 18-month prison term for the crime and fell on hard times after his 2002 release, he said in a sentencing memorandum filed Thursday. "I was homeless, staying on a friends couch. I couldn't get work," he wrote. In desperation, he turned again to cybercrime." I'm not saying he's right, but it does highlight something interesting about finding work as an ex-con.
What type of work was he trying to get? Not that it is easy to find work as an ex-con, but it isn't impossible either (so long as the person lowers his expectations... read flipping burguers.) That is part of the cross an ex-con got to carry, right or wrong.
I hope that he has to serve the full sentence, and doesn't get out on parole. Credit card fraud is not fun. I can only hope that more people convicted of credit card fraud receive sentences like this.
Yeah, blame the criminals for exploiting a system designed to dispense cash based solely on a 4 digit number; That makes sense. Credit card fraud wouldn't happen nearly to the degree it does if financial institutions had designed the system to be more resiliant to attack. And by more resiliant, I mean doing something other than coating the cash in BBQ sauce and waving it in front of the hungry and unemployed masses while chanting "Hell no, we won't upgrade!"
Oh wow, so I guess by your logic, I should not blame the person who broke into my car and stole just because the lock wasn't designed against simple lock-picking (it isn't hard to pick a lock.)
Blame the faults of the implementation of a technology, and absolve the criminal of his own personal and moral responsibility. Awesome display of stupidity.
Isn't the iPad essentially a netbook of the future?
Take away the restrictions of installing software, and add multitasking, and then, maybe.
But where is the combined evidence (archeological and genetic) that says the Inuit (or any extant New World group for that matter) came into the Americas as far back as 20,000?
Let me re-phrase the question, just so that there are no misunderstandings: is there any particular native group X in the Americas for which there is enough combined evidence (BOTH archeological and genetic) that can firmly clock their (either unique or last) trek and permanent move into the Americas to a date as far back as 20,000?
Although both contemporary Inuit and the extinct Saqqaq migrated from Siberia across the Bering Straits, the Saqqaq migration was a much later one (5,000-10,000 years ago, compared with 20,000 for the Inuit).
Where did you get these age ranges? 20,000 years for the Inuit? Correct me if I'm wrong, but AFAIK, and except for tentative sites in Alaska, existing migratory evidence that we have today for the peopling of the Americas does not go back that far back in time. We believe that the people in Beringia were isolated between 10K and 20K, but we do not know precisely when they made the trek to the Americas.
Now, the linguistic and genetic evidence DO suggest that the peopling of the Americas started that far back in time as a whole. There are findings in Alaska, the establishment of the linguistic connection between the Na-Dene languages (.ie. Apache, Navajo) and the Yenisean languages, or sites like Monte Verde in Chile (which challenges the "Clovis First" theory).
But where is the combined evidence (archeological and genetic) that says the Inuit (or any extant New World group for that matter) came into the Americas as far back as 20,000?
Now, let's consider what the article says:
His ancestors split apart from Chukchis some 5,500 years ago, according to genetic calculations,
The Saqqaq split from the Chukchis about 5,500 years ago. That date alone does not provide any window by which to speculate when the Saqqaq entered into the Americas. They could have split off when they entered, say, a thousand years before. Or they could have split off after their common ancestor entered the Americas with the ancestors of the Chukchis moving back into Siberia. Purely speculative I know, but the models of migration does not preclude back-and-forth migration over the ice sheets/along the Beringian corridor (which if you think about it, it's very sensible and pausible.) Moreover, the ancestors of the Inuit and Saqqaq could have split off back in Siberia and way before their independent entrances into the Americas. I just don't see how TimFinger came up with this 10K-20K year range.
Just out of curiosity, what is your opinion of a "Large" codebase then?
That depends on the language, but anything starting above a quarter of a million starts to get large. Consider the Linux kernel - not a typical distro, or the dev tools, or even a minimal bare-to-the-bones distro, but the kernel. The 2.6.0 kernel is over 5 million lines. Later kernels are twice as large. 30-40K is about the lower threshold of a mid-size stand-alone system or a component in a much larger system. For example, at one job I worked on a component that was about 200K LOC. That was one piece in a distributed system containing several dozen vertical components on top of vertical layers of stuff summing up to several dozen million LOCs. This is only considering source code. Once you start considering configuration files, deployment and installation scripts, it gets more complex.
There is now a classification for ultra large systems that in the near (and very likely) future could easily go into the billions, posing new challenges on project management, source control, and just about anything relating to the question "who the fuck knows what this gigantic shit is supposed to do."
Now, difficulty of maintenance is not just a function of code size, but also code structure and organization and documentation.
You can work with a monster system that is in the millions of LOCs and not have a substantial problem implementing new functionality or bug fixes, and then in another job you have to maintain poorly written JSPs that collectively are in the 50-100k (with the later job being a mutant klingon bitch.)
When you get into a corporate environment, "cheating" is actually preferred. No reason to re-invent the wheel when there is existing code that gets the job done.
Need a report that's "like this one except for..."? Take the code for that report and add some mods and there ya go. Your manager would consider you an idiot if you started each project from scratch, re-writing all the functions and methods that already exist in other applications and have perhaps already gone through rigorous QA.
Uh dude, that is so wrong in so many levels.
First, cheating =/= reuse.
Second, being measured for competence =/= being paid to implement cost-effective, efficient solutions by reuse rather than by reinventing the wheel.
Anyone who pays attention to this in school and in real life knows that difference.
Besides, how many ways can you write a QuickSort?
First, there are several ways, believe it or not. Second, non-sequitur. Most of the work done out there is not about implementing new and radical, novel algorithms but on intelligently engineer solutions that maximize re-use as much as possible. This can only be done by have a degree of competence, the one which we get tested for... and in which losers and incompetent people cheat.