My thoughts exactly. But, then again, I'd have to think that the people law enforcement is seeking aren't all that bright to begin with. Even if they used the software, they'd likely ignore its warnings in favour of satisfying their sick cravings.
Indeed, because it's pattern based - it does not automatically assume that the adult is "smarter", but that any person whose communications are too far off the normal curve will, presumably, get flagged. Kids, be like everyone else, or we'll send the SWAT after you! (j/k - I do think this is a good thing)
There are lots of things you can do - many of them depend on exactly who you are (ie. what jobs you're applying for as well as the experience you have), and some on the specific posting / submission engine you're facing.
Terms like "proficient" and "excellent" are usually not needed: you list your skills in order of your abilities - the most proficient are at the top / front of the list, so you can leave out those extraneous words.
Also, a lot of what you write will sound like standard tripe, but that's a good thing ... to an extent. You want to stand out from the crowd, but you also want to demonstrate that you understand the game being played here. In short, your resume should make it as easy as possible for the person reviewing it to match you to the job posting.
An example of where you should follow the same style as others is in using "action words". Don't say you are familiar with / proficient in project management, for example; say you have managed projects [of X size and scope]. Don't say you know Python; say you have contributed to an open source python project (and provide a link!).
Keywords are good. You can adapt / evolve your resume and cover letters based on the words and phrases you're seeing in postings. This is especially important when the target is not an employer, but a recruiter who might not even understand what a "J2EE Deployment Engineer" is, precisely. And how Weblogic is different than JBoss. So use their terminology - it shows you care. In times when I've been looking for work (or even just polishing off my resume for good measure), I start by gathering together a number (say, 20) of postings that sound like jobs I'd like - regardless of whether I'm actually qualified for them. I then look at the phrases and skills they're asking for; which ones are most common, etc.; and start creating a list. I will then review that list, refining it as I contemplate my own skills and experience, and then building up the terminology I'm going to use to describe myself.
Master these things, and then you can start working on how to stand out. I'm going to cut my comment off here for the moment, but here's one more thought: when listing past experience and when writing cover letters, an example can say a thousand things that will expand out your bullet points. As an example, say you're applying for an intermediate programmer job - they're asking for someone who knows php, and is a "front end rockstar" and works well under pressure, blah blah. You start off by saying "I've been building php websites for 5 years." (or whatever) And then you give an example "At my last employer, we were under extreme pressure to deliver a custom solution for a fortune 500 company. After helping our team derive a scalable architecture based on my DAL model, I was given sole responsibility for implementing the UI by building on the originally approved comps." With two sentences like that, you can show that you know your php, that you can handle the deadlines; that you know your way around the back end as well as the front, etc. And, again, provide a link!
HTH ... if you have any other specific points, I'd be happy to give you my $0.02.
I find this a very interesting topic. Character sets and their encodings are usually completely invisible to the end user, and often even to the engineers working on the system. But, when a problem rears its head, it can be nasty.
A great example is certain api calls in legacy Windows code that modify registry keys. Using the legacy api call can lead to a single-byte encoding of the key, making it un-editable by multibyte methods (i.e. the newer methods that are supposed to depricate the old ones). As much as people love to hate on MSFT, I've often felt honest pity for the programmers who have to build on top of 20+ years of code without breaking backward compatibility.
Also, there was an interesting discussion on slashdot recently:
I wouldn't argue with the notion of Jobs being "delicate", that's for sure. And, apparently same goes with the feelings of the HN crowd toward all things Apple.
TRWTF is that it took Jobs and Apple's thousands of employees how many years to notice this? Either that, or his answer is pure BS and has nothing to do with why Apple made this decision now.
I agree. I think HN is becoming a victim of it's own success, and it's UI wasn't built to scale. (aside - that's a challenge to all you folks interested in ux ;) ).
I would say that we definitely need a way of detecting duplicate submissions. And I would also add another suggestion: categories (or tags) for filtering.
Haters gonna hate, bro! I'm sure there's a reasonable explanation as to why TechCrunch and other industry insiders are swooning over their newest darling startup. I'm sure it has nothing to do with who's in the in crowd and who's not. After all, silicon valley, and the tech industry as a whole, is a pure meritocracy!
I wondered what exactly was being measured here too. I checked around the site quickly but found no answers. Bah. Might as well be made up numbers as far as I'm concerned.
The tests for BRCA1 and BRCA2 have been around for decades. Here in Evil Socialist Canada, our governments have been paying the patent holders for this genetic test $200 a pop and providing genetic screening to our citizens for free for at least 10 years.
I forget the name of the company holding the patent at the moment. But, a bitter battle was fought around the world against these patents. Eventually it was the US's views that were upheld at WIPO, protecting the company who made their "discovery" on the backs of hundreds of millions of dollars in public R&D funding, including the Human Genome Project.
23 and Me didn't save anyone's life. The US Congress muscled through a patent regime that prevented anyone except private companies like 23 and Me from being able to provide this basic health procedure to the masses of American citizens.
You can go and celebrate this company because this guy and his wife had the money to afford to pay for this test. I see it as a loss for all the Americans who can't afford to pay. And therefore a loss to American society as a whole.
I hate url shorteners too, for all the reasons the author lists and more. But the article is wrong in stating "They serve no purpose other than to create a short link..."
Actually, while that is their primary purpose, they are very attractive to the people who use them because they give you a click tracking on your instance of the URL post, regardless of who owns the target website.
For me, this is actually another negative of the whole concept of URL shorteners. But it's a huge draw for the people using them.
If you buy a copy of a copyright-able work, you are a licensee. The "copyright holder" is the person who owns the legal ability to specify and grant the rights under which the work may be copied.
I've long used jEdit as my text editor of choice for coding html, perl and php. jEdit is pretty much just another in its class that will give you syntax highlighting, regex search and replace, macros, and a few other nifty programmer-friendly features, just like BBEdit, UltraEdit, etc. What I really like about jEdit, personally, is that it's built in Java, and so it's pretty much identical on Mac, Windows and Linux. This is key when moving back and forth a lot, as I sometimes do.
Depending on what kind of programming you do, though, I'm going to have to agree with the other posters who've suggested vim or emacs. I'm a vim person, myself, but there's nothing wrong with emacs at all. I guess, go for vim if you really want to go minimal; go for emacs if you want to simplify with the ability to build out your text editor into an IDE.
The big reason I say you might as well go for vi or emacs, though, is because without an IDE, you will likely need to spend more time at the command line - whether that means running your compiler, firing up your debugger, etc.
I never bothered learning some of the more advanced techniques with vi, but I've written some fairly big projects in a terminal using screen, vi and "perl -d". One little tip I think is worth passing along: I declare my functions in perl like this:
sub my_method_name # the method that does that thing and returns a hashref
{
..
}
The reason I think this is worth mentioning is because it saves me so much time when working in a terminal with a minimal toolkit: I run "grep -nr ^sub" and it returns all my method definitions with a brief (one line) description. The output from that grep is like a mini "whatis" database o my codebase.
Yeah, I agree with your overall point. In general, a sign of mediocrity in any field is someone who over-uses jargon in any field. As much as I hear people throw around "design pattern" terminology, I also see overkill on the now-en-vogue topic of "useability", with phrases such as "use case" being applied at any and every possible opportunity.
In fact, though, what has proven my comment wrong is that the HN community has not chimed in as I predicted. This is a(nother) really informative and thoughtful conversation... I love it here! :D
I wasn't sure whether to upvote this article, until I got to this line:
> Design patterns are a universal language that few people speak, a sort of Esperanto for programmers.
Exactly. And I fully expect many of the hackers here to chime in with 'oh, that article is so wrong'. But, the thing is, HN geeks, you are that rare breed that knows and applies the patterns. I've met you, and I've worked with you. And for every one of you I've met in my career, I've met 200 who couldn't give a damn what a DTD is, let alone a pattern.
Design patterns are actually an excellent concept, but they won't really help programming for the masses. And, the more we depend on computing in our lives, the more we need programming as a technical discipline to be able to accomodate the masses. For every structural engineer out there in the real world there are probably a thousand architects. And for every architect, ten thousand carpenters. I know an expert carpenter and I'm pretty sure he couldn't calculate the tensile strength of a basswood 2x4, but he can sure build me a deck!