chandler

> Yeah, except 10 years at certain companies could teach you less than 6months to 1 year at one company that's actually doing it right.

Is it common for programmers that have been on a job to not realize the ways in which their software sucks? Knowing what to avoid and the consequences of doing things wrong is an important factor of experience; additionally, maintaining a bad system gives insight into mitigating problems.

That said, I do agree that experience isn't just a passive function of time (as in "interest earned"). Instead, it's more like a landscape that needs to be explored (and to your point, some companies will allow a programmer to explore more productive areas).

> ...the equation you posted wouldn't the intellect variable be pretty much equal to experience, and you could make up for one with the other?

I suppose the answer to your question would depend on just how much variance you place on intellect. Is it:

- 0.0 (rock) to 1.0 (cleverest human on earth)

- 0.0 (rock) to 1.0 (cleverest intelligence across time and space)

Either way, I wouldn't take the equation too seriously--it was just a model to show a trend :/

Consider smartness as "what you can do with what you know," while experience is "what you know"--then, what follows is that having more experience makes up for not being as clever.

    Able to make good choices = Intellect * Experience

Moreover, employers can _try_ to assess intelligence with whiteboard interviews...but the easier factor to evaluate is experience. It's right there on the resume!

A simple thing is to figure out if you can restrict the runtime environment during development (available memory, clock speed, network speed, etc), and develop to that. The nice side effect is there's more of your computer available for IDE's and browser tabs.

Secondly, abstraction doesn't necessarily track with efficiency/inefficiency.

> Our raw mental capabilities may have always been the same, but how smart we are also depends on our learning.

FWIW, I tend to equate "smart" with "cleverness," as a separate measure distinct from "experience," for the same reason you describe--so what I usually go by is something along the lines of:

Cleverness is a measure of "what can you do with what you have," whereas experience is a measure of "what do you have?"

> Over the centuries we've made great gains in mathematical tools, scientific knowledge, in democratizing education and in disseminating knowledge. And this means over the centuries we've (as a species) obtained more leverage that we can apply to our raw mental capabilities, giving us (overall) greater intellectual capabilities.

I don't think we've gained greater intellectual capabilities--our intellectual capabilities are the same, we just operate in a completely different mental environment than our priors did.

Moreover, having a different view of the world allows for different connections to be made, and different potentials to be expressed (irrespective of one's individual level of cleverness).

So, for example, by placing a priority on stories & views that encourage greater investigation of the physical world, we get to where we are today. And we can teach the next generation slightly different stories that optimize for different kinds of usefulness.

To bring it to the HN contingent--if I learn a new programming language, I've gained experience in different ideas and operate in a different mental landscape. But I'm not smarter afterwards, and I wasn't dumber before.

> ...but why did they do it like this?

...because people are smart. People have _always_ been smart, it's one of the defining attributes of humanity.

It strikes me oddly (not specifically your comment, but the general color accompanying these kinds of articles)--there's a kind of ground assumption that by looking into the past, one sees nothing but a gradually descending IQ.

> I imagine piping in bash feels similar...

It is. Piping is akin to an untyped subset of working with Scala's collections, and there's a similar workflow between the two, e.g.:

In bash, you build up a command line with something like (as a stupid example, the number of unique file sizes in a directory):

    Step 1) $ ls -l
    Step 2) $ ls -l | awk '{print $5}'
    Step 3) $ ls -l | awk '/\d+/ {print $5}'
    Step 4) $ ls -l | awk '/\d+/ {print $5}' | sort -n
    Step 5) $ ls -l | awk '/\d+/ {print $5}' | sort -n | uniq

You can see the correspondence with collections--typically building up in the editor in a similar staged manner ending with something like:

    Process("ls -l").lines   // ls -l part
      .map(_.split("\\s+"))  // awk part {
      .filter(_.length > 4)  //   ...
      .map(_.apply(4).toInt) // }
      .sorted                // sort -n part
      .distinct              // uniq part

The tradeoffs between the two are essentially verbosity versus data safety (perhaps not important with a throwaway inspection, but more important when working on larger programs...).

However, the building process is the same--you don't write the latter all at once, you gradually mold the pipeline until you get the output you want.

Yeah, but where are you going to get the skills of interacting with strangers?

Eliminating baseball practice doesn't seem like a way to encourage more games :/

> So while our system would be able to say "I have seen person 1234 at locations 4,7,9,11 on dates x,y,x" we had absolutely no way of knowing who 1234 was or anything about them...

Minor nitpick, but giving someone a nickname isn't the same as anonymization.

"Hey Bob, thanks for logging on. Did you know we've been calling you 1234 these past five years!"

When a passive recognition system _uniquely_ tracks & identifies a person, it just takes time before that gets cross-referenced.

(different story if the data gets aggregated, or you scrub the uid completely after some window)

>> It seems like there's a fine line between being clever and being morally bankrupt.

Actions can only be evaluated as moral/immoral/amoral when you've taken the time to define a system of morals.

It's the difference between a requirements document and an implementation--just as you can't determine the suitability of software without knowing its requirements, you can't determine the suitability of an action without knowing your morals.

Suppose you've decided you want to live in a society that respects the "Don't lie, steal, or cheat" maxims (for whatever reason--I've chosen this here because they're explicatively short!):

Then determining what's moral/immoral/amoral becomes an application of: 1) Does this encourage me (or someone else) to intentionally misrepresent the truth? 2) Does this encourage me (or someone else) to take something that hasn't been given? 3) Does this encourage me (or someone else) to misrepresent the truth for gain?

On the other hand, consider a company's system of "Maximize profit while minimizing legal liability": 1) Does this encourage me (or someone else) to maximize our company's profit? 2) Does this encourage me (or someone else) to expose our company to legal liability?

Notice that these two systems don't address the same concerns.

So the fine line exists because what's moral for the company MAY conflict with what's moral for the individual, and many of us don't like to think about /any/ ethical system (after all we're being paid to work in the latter!).

Sure, at a prior job we passed out hardcopies of a side-by-side diff before scheduling a peer review (including only the affected methods/functions).

No syntax highlighting, but it was quite useful. Off the top of my head, the two main benefits are: 1) You free up your computer for the review 2) You get a different form factor to interact with.

Regarding the first benefit, having a printout means you can use your computer to run the application, look up docs, and even (ironically) navigate the code in your IDE.

As for the second, having a printout means you can spread out the pages to compare different bits of code, draw diagrams, connect arrows, circle bits of code for notes, etc.

It was pretty useful.