Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. ×

Comment Re:Smart enough to REALLY f*ck things up??? (Score 1) 212

two people with high IQ will out-perform a single person of super high-IQ

Out-perform them in what? One of the biggest issues in programming is a group of programmers is only as smart as the least smart of the group, unless the rest of them just ignore the lesser. I've had it where about 5 of the most senior programmers in my company where stuck a problem for several days with code that they wrong. I just so happened to have walked by and overheard them discussing the issue and I solved the problem in less than a minute. It was a 100% custom built system, so I had zero knowledge or experience. This pretty much sums up every experience I've ever had.

Another example. My ISP was having a network issue. I was working with one of their senior engineers for nearly 6 months. I kept telling them what the problem was and where they need to look, but they couldn't figure it out. They eventually hired a 3rd-party firm that specialized in fixing complex network issues for large ISPs. Even they could not figure it out for several days. My ISP called me and asked me to talk to these people. I got on the phone with 3 "specialists", and I went over the data I sent them, explaining what I thought the issue was and the reasoning behind my thoughts. I got off the phone, 1 hour later, the problem was figured out.

My background in networking is I took an entry level class in college and I have a pfSense box at home, and I diagnosed an ISP level network issue with nearly zero experience.

Comment Re: What's with this fixation? (Score 1) 328

Google and Facebook have stated that there is zero correlation between ability and experience past 6 months. If you had a collection of programmers, all with at least 6 months experience in whatever software field, the skill distribution would be nearly identical between those with less than 1 year and those with more than 5 years. Experience is a nearly worthless requirement.

Comment Re: Indeed (Score 1) 328

Talent recognizes talent. Fake talent thinks it recognizes talent, but it's really recognizing other fake talent creating en echo-chamber. Turns out talent is incredibly difficult to measure objectively. How do we collectively decide who is talented without creating an echo-chamber of people who are only seemingly talented? There is also the issue that talented people tend to not be very social, making them outcasts.

Comment Re:No (Score 1) 328

Coding is orthogonal to programming. Just wait until AIs are doing the coding for the programmers. Coding is just the act of translating ideas into a language that computers understand. Or as "Uncle Bob" says, the code is just the exact detailed requirements. Programming is the act of creating those requirements.

Comment Re:No (Score 1) 328

The problem is the lack of "real" programming classes and the false sense of accomplishment a child can get from "doing well" in the fake programming class. You can balance on one leg?! You're going to be a great gymnast! The even bigger problem is the crazy high amount of Dunning–Kruger effect going on in the programming industry as a whole. Someone may not know they're bad at programming until it's too late.

Letting children try new things to see if it's not only something they like, but something they do well at is a great idea. The elephant in the room is the "doing well at" part. Even CS professors at ivy league Universities are pretty much all saying that 80% of their graduates should not do programming, but they can't fail them because they technically passed. And that 80% is already after the first 80% of failed to graduate. This means that about 96% of people who apply for programming can't or shouldn't. And that's after weeding out all of the other people by having high requirements just to apply.

Then you have the other elephant in the room. Dunning–Kruger effect is a side-effect of a lack of meta-cognition, which is intern a lack of fluid intelligence, which is required for abstract reasoning, deductive reasoning, and inductive reasoning. Of which all 3 are fundamental requirements for any good programmer. There are no known ways to increase fluid intelligence, only ways to get better at specific fluid-intelligence tests, but the benefits are non-transferable, aka don't actually help.

As far as we can tell, increasing fluid intelligence requires meta-cognition to recognize what you don't know and why you are failing, but at the same time, it takes high enough fluid intelligence to have the meta-cognition to do so. It's a catch-22 where people below a threshold have virtually zero ability and those above it are exponentially better for small improvements.

If we want children with better fluid intelligence, one possible way is we need to start them very young on being very introspective about their own thoughts and reasoning.

Comment Re: Don't look at it that way... (Score 1) 161

That only applies to many-to-many relations and overly-normalized is nearly as bad as under. Not including that if you have 2 tables with a 32bit int vs one table with a 64bit it, it's a wash. Even in these situations, if you're doing seeks of large many-to-many tables, the random access out-weighs the cost of the extra 4 bytes per field.

I recently was doing performance testing of a tight loop and was comparing 32bit vs 64bit on a 32bit CPU, and the performance was within 10% of each-other. Even when having to do two register loads and combining the registers to emulate 64bit arithmetic, the CPU was able to OoO+pipeline most of the cost. In the end, I have had more situations where using 32bit ints was slower than 64bit.

Comment Re:Even programmers should know better though (Score 1) 161

Indexing UUIDs on a large table is a management nightmare. Take about page fragmentation. Joining two large GUID based tables can cause horrible performance corner cases even when clustered. UUIDs should be limited to public data/APIs, but not actually used internally. I do love them for keeping my data sane, but the performance optimizations and management overhead means you need to really think about the issue before you index them. NEVER cluster index them.

Comment Re: Don't look at it that way... (Score 1) 161

Unless your table only has an index, doubling the size of the index is quite moot. IF you knew anything about data alignment, SQL data page layouts, or the slew of meta-data stored along with the data, you would realize it does not matter in nearly every case. It will matter if you're programming in a compile language that allows you to control structure layouts and you need to do a lot of CPU intensive work or need to work with SIMD, but outside of that, 64bit.

Comment Re:Confirmed Existence? (Score 1) 162

I had to look up "Primordial black holes", and that's an interesting theory. These blackholes could actually pass through the Earth on a semi-regular basis.

Nutshell: Blackholes that formed during the early Universe, allowing them to be much smaller because they did not have to form from a dying star. Think in the range of less than a Moon mass.

Slashdot Top Deals

This is an unauthorized cybernetic announcement.