18 karma · joined February 25, 2010
ddg rules and this finally puts my pov into nice, simple, pretty pictures.
W00t!
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.
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:
http://developers.slashdot.org/story/10/10/31/2127201/Mr-Pik...
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.
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.
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.
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.
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
> 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!
Sorry, I tried to reply to your post about 4 times yesterday, and it never went through for some reason. I agree with what you're saying about self-signed certs being not necessarily broken. Maybe I mis-read your original message, but what I was objecting to was the idea that a site that apparently has the same content available over http and [broken] https is not a problem; I'm saying that broken is broken regardless of the content it's protecting. As to what constitutes "broken" ... I think we agree - that would be SSL. :P
The fact is, my real-life identity was never verified as the owner of the domain by a "trusted" third party. However, the encryption key comes from the same server serving the content, so what, really, is not to be trusted? I.e. the cert applies to "domain.com" and is being used on "domain.com". There is no risk of MITM attack, only that "domain.com" is not what you think it is.