> As a hiring manager, I can tell you that I almost never have the time to go dig through a prospective candidate's open source code

I also have had the responsibility for hiring people from time to time. And OMG you are hiring a *programmer*. This is the *primary* thing they are going to be doing after you hire them. Their code is their main work product. The information is available to you and you're just going to *ignore* it? Who cares how charming and articulate they are if their code is crappy?

You could assess these things in 15 minutes in a 13kLOC code base. Did they write clear and useful comments? Is the code well organized? Is the high-level structure obvious? It's an excellent second- or third-pass method, and I've always found it pretty weird that it's not a more common practice.

Okay, maybe you have some reason to doubt that they actually wrote it or whatever. And of course they will be showing you the awesomest, cleanest little gem they ever wrote. Weigh it appropriately. But don't weigh it at 0%!

I want programmers who can write code AND are articulate and charming. Someone who is articulate and charming but cannot write code should not be hired as a programmer.

OTOH someone who can write code but is not particularly charming can still be a great contributor if they are not a total asshole, and can explain their code clearly in comments or in small meetings.

Probably the reason most hiring managers don't want to review candidates' code is because they are not particularly skilled at reading code quickly and making a useful judgment about its quality. This just means that the hiring manager isn't qualified to judge the candidate on this critical dimension. They should admit this limitation and farm out the task to someone else in their company whom they trust. (If there is no such person in their company then their company is pretty well fucked anyway.)

> Not to mention, most of the time open repositories like that are blocked from my work network anyway

Okay, but this is not a statement about the objective predictive utility of a hiring process that involves code reviews. It's just a statement that your company is toopid. :-) And you can always have the candidate email you the code. They key problem here is that *you* do not believe that reviewing people's code adds a lot of value, and on that point I believe you are quite mistaken.

> can the candidate speak, in detail, to their resume. Many can't, by the way

Totally agree with you on this point. It's amazing how many people just blatantly lie on their resume. In my experience it's, like, way more than half.

This makes it frustrating for people who are honest on their resumes, since managers have to take steps to weed out the significant population of liars out there.

"So what's the difference between TCP and UDP?"

"I have been writing network protocol stacks for 138 years. I sleep with a printed copy of the TCP state machine under my pillow, and all night little synsies and finsies dance through my dreams. I hang out with Vint Cerf every weekend. It says so right on my resume. Why don't you believe me?"

"Because 95% of people who say that cannot articulate a reasonable answer to my question. :-("

I guess until we can get most people to stop lying on their resumes, that will just be a fact of life.

It would have been even better if it were not wildly incorrect. You can't cancel an order once it has been executed. The grandparent sounds super confident, but is largely making stuff up.

My personal programming hero, D. Richard Hipp, works with a very small team on SQLite (which you may have heard of). He uses his own, home-grown SCM called fossil. It probably doesn't scale to a zillion contributors but, like all of Hipp's work that I'm aware of, it's super clean and easy to use. Sounds pretty great for your use case.

And, as other people on this thread have already said: your habit of throwing stuff into production without testing it is similar to playing Russian Roulette with your company. Stop that. Stop that right now.

1. Install your own wireless hub and 3G station in your store.
2. Actively inject fake higher prices into competing web pages' HTML as it flies through your local router. Customer thinks the price in your store is the best one.
3. Profit!

Informative?! This post is so, so terribly wrong.

Wrong. We're not on the wrong track. Databases don't only handle "homogeneous data" sets. You just don't know how to use them flexibly.

Wrong. Databases abstract away I/O primitives and file formats, making creating/accessing your data much simpler than using (e.g.) flat text files.

Wrong. A great many things beat flat text files, under a great many use cases. The capabilities of (e.g.) a sqlite database are a strict (and much larger) superset of those of flat text files, while usually being *less* burdensome to their users.

You can always dump your db contents to a flat ascii format if you need to (like to send the data to gnuplot).

Just because *you* don't know how to properly use a db doesn't mean you should shoot down the very idea in such broad strokes.

Others have already mentioned SQLite. Let me briefly expound on the features that are likely the most important to you, assuming (if you'll permit me) that you don't have much experience with databases:

1. 0. The basic idea here is that you are replacing this whole hierarchy of files and directories by a single file that will contain all your data from an experiment. You figure out ahead of time what data the database will hold and specify that to SQLite. Then you to create, update, read, and destroy records as you see fit--pretty much as many records as you want. (I personally have created billions of records in a single database, though I'm sure you could make more.) Once you have records in your database, you can with great flexibility define which result sets you want from the data. SQLite will compute the result sets for you.
2. 1. SQLite is easy to learn and use properly. This is as opposed to other database management systems, which require you to do lots of computery things that are probably overkill for you.
3. 2. Your entire data set sits in a single file. If you're not in the middle of using the file, you can back up the database by simply copying the file somewhere else.
4. 3. Transactions. You can wrap a large set of updates into a single "transaction". These have some nice properties that you will want:
   1. 3.1. Atomic. A transaction either fully happens or (if e.g. there was some problem) fully does not happen.
   2. 3.2. Consistent. If you write some consistency rules into your database, then those consistency rules are always satisfied after a transaction (whether or not the transaction was successful).
   3. 3.3 Isolated. (Not likely to be important to you.) If you have two programs, one writing a transaction to the database file while the other reads it, then the reader will either see the WHOLE transaction or NONE of it, even if the writer and reader are operating concurrently.
   4. 3.4. Durable. Once SQLite tells you the transaction has happened, it never "un-happens".
   5. These properties hold even if your computer loses power in the middle of the transaction.
5. 4. Excellent scripting APIs. You are a physical sciences researcher -- in my experience this means you have at least a little knowledge of basic programming. Depending on what you're doing, this might greatly help you to get what you need out of your data set. You may have a scripting language that you prefer -- if so, it likely has a nice interface to SQLite. If you don't already know a language, I personally recommend Tcl -- it's an extremely easy language to get going with, and has tremendous support directly from the SQLite developers.

Good luck and enjoy!

My god. What are the moderators thinking?

I've been playing the game for 23 years, was trained by world-class coaches, and I'm here to tell you that you don't know what you're talking about.

It's part of the joy of the game, part of the culture of the game to wish and hope for your team to win. But just because a fan thinks something doesn't make it so.

If that were true, a group of randomly-chosen people would have a similar chance of winning the world cup as e.g. Germany. Which is, of course, ridiculous.

Obviously the game has a lot of problems, and some of those topics are hot today. The game arguably needs to be refined in a couple ways.

But it is absolutely *not true* soccer "isn't about making the best team win" or that it's "mostly luck". The overwhelming majority of the time, the best team *does* win. It's just that when that happens, it isn't big news.

I read all the +3 -> +5 comments here and am shocked to see no one mention the importance of referrals!

You already know people connected to the industry -- talk to them! Ask your profs if they know anybody in the industry. Ask your jobful friends to pass your resume along. Is there a famous prof at your uni? Did you take a class with them? Bring your chutzpah to their office and ask for a rec.

A referral from a trusted third party is thousands of times more likely to get your foot in the door than your resume, no matter how bloody sparkly the thing is.

Case in point, I graduated summa cum laude from an Ivy school, and no one really gave much of a shit. Until I knocked on my algo prof's door once during his office hours, asked him whether he knew someone in industry looking for a smart hard-working youngster. He gave me the name of his contact (the CEO of a tiny co). (I didn't even do that well in the Prof's class, slightly below median IIRC.)

Next thing I know the CEO's shaking my hand congratulating me on my new 50%-pay job. He's telling me "boy have you ever got a lot to learn, but Prof so-n-so says you're smart and you do seem to come off that way". Worked my arse off til it turned into a real job. And now there are *2* people out there who think I'm smart, so, you know, twice the network :)

If you don't have a network, make one. Think about doing an unpaid internship at a company that has a future. (Look into funding options from your uni for this kind of stuff.) Be careful with this one -- the network you create here must be valuable to justify the work and the resume gap.

I had the privilege once to speak with the former-CFO of Coke, and asked her (rather lamely) how one winds up being the CFO of Coke. She said, "If you really want a big-time job you gotta be aggressive and you gotta be charming."

Note that "qualified" is not a part of that sentence.

Broken thinking. Getting hired isn't about being good at the job. It's about being good at getting hired, which is a largely orthogonal skill set.

Need new skill set = need to practice. Interviews are like first dates: they pretty much all suck, but get less nerve-wrecking with practice.

I should mention that once you have job 1, the network it creates (or doesn't create) will bear heavily on how your search for job 2 goes. So take good care of your network at job 1. I've seen a ton of smart people with amazing resumes, who are actually quite good programmers, who can't find jobs because they are huge pains in the ass. The days of the cranky-bitch-genius-programmer are limited (if not completely over), because there are plenty of pleasant-genius-programmers out there who need jobs too.

Approach your job like a pro: learn the politics and the people, be friendly, be polite but not stodgy. Choose very carefully which personal details to share with which people. Never express a negative emotion unless you've thought about it extremely thoroughly. Never write an email to/from a work account that you wouldn't want the CEO to read. Get people to like you: morally it shouldn't matter, but practically it makes a gigantic difference to how your career will go.

Finally and of course most importantly, work your ass off and get results. Nothing will make boss-man like you more than if you are generating two times the output as everyone else, with a smile and a joke handy at lunch time. It makes him look fabulous to his boss, and ten years from now when he's working at google (or whatever the "google" of 2020 will be, probably "google"), guess where you can ship an email and probably get a job.

My fiancée IAL working in a federal district court. I have mod points, but I guess it's more illuminating to reply than mod down this ridiculous comment.

Stuff is filed under seal in court all the time. The idea is that you don't want the defendant you're pursuing to know you're pursuing them if there's a high chance they can cover their tracks. You can't just make a "mere accusation" and get a court to do whatever you want. That, of course, would be silly.

Most judges are really quite reasonable about the decision to keep things sealed. In any event, all the docs will become unsealed relatively quickly -- and if you think the court was *unreasonable*, that they abused their discretion somehow, you can take your complaint to the appellate court.

Court proceedings are slow, but some crooks (especially intelligent, well-funded crooks) can move fast. This is the balance we've found between thinking things through carefully, and satisfying the public's right to this information, while still prosecuting agile crooks.

In copyright infringement cases, the plaintiff would probably have a hard time convincing the judge that docs need to stay sealed.

Believe it or not, the system actually works pretty well sometimes.

Look, I'm all for an intelligent discussion of the shortcomings of the legal system, of which there are plenty. But you should really try to learn something about it before criticizing it. Otherwise you're just wasting everyone's time.

That depends on your threat model. Your cron job might keep your kid brother from discovering your cookies. If you *really* don't want people to know what flash is caching, I'd s/rm -rf/shred -uf/ there for starters. Then I'd think about putting my whole OS on an encrypted partition (trivial these days with Fedora, not sure about other distribs).

Of course, you still have problem with sniffing and all manner of malware, all of which could defeat your goal of preventing people from knowing what kind of flash content you're downloading.

I hung out with Bruce Schneier for a 1-hour talk once. If you want to scale up your paranoia further, you can do what he does: never let your computer touch a network or another person's hands. He has no wireless card, never plugs an ethernet cord into the slot, and never gives his compy to anyone else. Very difficult to sniff traffic that doesn't exist (but not impossible).