HN user

bbarthel

138 karma
Posts3
Comments28
View on HN

My problem is that I want a comparison of syntax so I can see exactly how Coffeescript is an improvement over the equivalent Javascript.

When I visit the site and I see a table with CoffeeScript on one side and Javascript on the other, my brain sees just enough to verify that the expected elements are all there before it says, "Yep - there is the comparison you wanted".

So while it does clearly state that the JavaScript is the output of the tool, my brain has already decided that it is exactly what I was expecting, and it takes me a second to re-adjust my thoughts.

Ironically, if the output looked less "normal" I probably wouldn't have the same problem, but it is formatted nicely and is good enough that subconsciously my brain tells me "equivalent syntax" and not "compiler output".

I have the same problem. Once I realized that I was not just stupid and the other person was simply not communicating well, I began to try repeating what they just said back to them in "normal language" to ensure I had understood them correctly.

When I did this, two things happened: people began to think that I was really smart, and I realized that I could usually repeat whatever I wanted and the person would agree with me.

I disagree. Knowing the details of an apprenticeship program upfront are critical to attract and retain both the "apprentices" and the "masters" necessary to make a program work. It would be unfair to both groups to have divergent programs and skill levels being passed off as apprenticeships.

There are plenty of successful models that a program could be based on. In the US, electricians require 5 years of work with a journeyman + classroom instruction. Professional Engineers require a degree in their discipline, 2 examinations, and 4 years of relevant experience, usually under a licensed engineer before they can get their PE license (its not called an apprenticeship, but an EIT - Engineer-in-Training. You are expected to learn from a more experienced engineer who is responsible for overseeing your work and providing a recommendation before you are licensed).

Privacy - Normally my interests are more technology-oriented, so I would expect my ads to target computers and technology. However, every year around the holidays and my wife's birthday my browsing takes a more practical turn. If she were to hop on my laptop and notice that all my ads are now for jewelry, it doesn't take a genius to put 2+2 together, and the surprise is ruined. And this is just a benign example of how targeted ads might "leak" undesired information to third parties (imagine some of the more embarrassing things that might be targeted).

Quality - My experience with targeted ads usually involves them lagging behind my purchase or interest. So if I set out to buy a new saw, by the time I start getting ads related to new saws, I have already purchased it. Everybody loses (Advertisers waste money targeting a purchase I already made, and I keep seeing ads for a product I don't need anymore).

Both of these scenarios occurred recently, and I don't really know a good solution to the problem.

Unless something has changed, you need a minimum level of reputation to upvote. If you are not a member of the site (I have a vague memory of starting with only 10 rep - I have no idea now) you have no mechanism to actually do as you suggest until after you've posted or asked a question that has gotten at least one vote.

Asking me to look at code on github is not that different from just sending me all the code (other than the fact that you aren't cluttering my inbox with it). What code do I look at? Why is it interesting to me? I understand your point about having a discussion about your code, but you are again asking me to find those interesting bits that are relevant to the position I want to fill. You are familiar with the code base already - it is not difficult for you in your cover letter to indicate that I might be interested in x,y,z in project foo because they demonstrate a,b,c, and I can find the code on github. Now I know what to look for, and I am very likely to go and look for it. That may lead me to explore some other things and will lead to an interesting interview. Even if I don't consider the code interesting and relevant, it still lets me ask about why YOU thought it was. If you don't point me to that, I may just flip through a couple of methods and never find anything that interests me enough to talk about it.

And for the record, I don't like "puzzles" either - even if I know the "trick" to the puzzle, sometimes my brain doesn't work right and I can't think of it after a long day of interviews. I would much prefer to be evaluated on how I work in a real environment, seeing my real code and my approach to real problems as opposed to impossible problems whose solution hinges on an obscure bit of semantic parsing in order to arrive at the solution. But as an interviewer, I don't have unlimited time to evaluate candidates so if you want me to do something, it helps to make it as easy as possible for me to do it.

In the end, I don't disagree with you, but I can understand interviewers that don't make the effort if you don't also make an effort.

Please don't ask me to review your "massive amounts of code" - I guarantee you will not come out ahead in that evaluation, if I even have time to properly evaluate it (according to Code Complete, you can properly review code in a high-level language at about 100-500 lines per hour).

If you consider the fact that:

- It is unlikely I am well-versed in the problem domain of your code,

- I am unlikely to be aware of external design constraints or coding pressures,

- I am probably going to randomly select the worst section of code to review,

- I have no context for how the code evolved

the chances that I walk away with a negative impression are high enough that it should give you pause. If I do manage to walk away with a positive impression of your code, it will be offset by the perception that you believe your time is more valuable than mine (why else would you send me a massive amount of code and ask me to review it to determine your suitability for a position) - and you still haven't answered the other big question I need answered which is whether you are a good "fit" for the team from a personality/cultural perspective.

If you really want to impress me, go ahead and send me a list of your projects and contributions and then slice a relevant sample of code from it. Describe what the problem was and how you solved it so I can understand the context. Try to make it relevant to the position, but failing that describe how you could utilize that experience in the relevant domain. Keep it small enough that I can review it in under an hour or two.

Is it a lot more work for you? Absolutely, but if you do this I guarantee you I will look at your code and will likely call you for an interview because you are demonstrating a high level of competence and professionalism while still respecting my time and needs.

Much has been written and disseminated about their culture, benefits and compensation practices. They are one of the largest software companies in the world with a publicly recognized name. Their product offerings span just about everything you would want to do with a computer. They have (historically) been a very stable source of employment, with a good compensation and benefit package, along with a full career path for developers (a rarity in most companies it seems).

Unfortunately, their business practices have also left some developers with a bad taste in their mouth (whether through their previously predatory nature, or their current lack of a cohesive approach to the web). Given that Microsoft is a well-known entity in the developer world (and frankly the larger US-culture), I will assume that you fall into on of those categories, in which case Microsoft will need much more than perks and salary (of which they apparently have many - I am not affiliated nor have I ever been affiliated with them) to sway you.

On the other hand, there are plenty of folks out there who may not have the same negative experiences with MS and, based on everything I said above, would consider the company an excellent place to work.

From a hiring standpoint its not something I look for in recent graduates. I also don't ask whether you have learned to use an IDE. Those just aren't things I expect you to have been taught in a high-quality cs program because those are things I expect to teach you on the job in under a week - along with all the other project specific things you will need to learn (like which frameworks we are using, what coding standards we use, our check-in policy, etc.) If you have learned to use them and are familiar with them, great. It won't really affect your chances of being hired though because in our next project we may be using a completely different set of tools, and I will expect you to learn how to use those instead.

Now if you are claiming 5+ years of professional experience and have never used a source control system that is likely to trigger a whole set of negative questions surrounding what kind of experience you actually have, but it isn't a deal breaker - just a warning sign.

Is source control considered that large an educational opportunity that the lack of classroom discussion is a barrier? When I hire someone that is a 15 minute conversation and maybe a cheat sheet taped to their monitor - regardless of education. If they can't pick it up by the end of the day that's usually a good sign that things aren't going to go well.

Not that there aren't plenty of educational opportunities surrounding the implementation of a good control system, just that teaching basic usage just seems to be a little simple.

Now not being able to write running code is a serious problem and it is frightening that someone could graduate after 4 years of computer science and never have written a working program.

I don't think I understand what they are proposing here. When I read this it sounds like a simple return to client applications. The workflow sounds like:

1) I go to the web to download the application.

2) Once I have the application I run it locally.

3) I encrypt and save the data back to "the cloud". Since I own the data, I can specify where to save it and the "web" becomes nothing more than distributed storage.

This is nothing I can't already do if I choose. We already have things like Silverlight applications, Java applications, Flash applications, etc. that all run client-side in the browser. Throw in ClickOnce deployment from Microsoft (which installs a .NET application directly to your computer by visiting a website and agreeing to the install), the linux app repositories, or even just the old "purchase and download" model, and I do not see how this proposal solves a technical problem we currently have - and if it is not a technical problem, then proposing a technical solution isn't going to solve it.

If I understand the intent, it is to prevent companies from owning the data that we create. Where the code executes does not seem to be relevant.

I don't see anything in the article to suggest he is attaching special prestige to his education, instead he seems to be stating that Mr. Thiel would better serve entrepreneurship by simply focusing on all young entrepreneurs and helping them achieve their ideas as opposed to artificially limiting it to teenagers so that he can condition the money on them dropping out of school.

As an example, when I was in college, I received a grant from the Kauffman Foundation( 1 ) to pursue an idea myself and some friends had for a new type of 3-d visualization device. In the end we determined our idea was infeasible as a commercial technology (technical limitations based on our design), but through an arrangement between the Foundation and my college, we were able to work on the prototype and still receive credit so that all of us graduated on time (we were required to use the prototype and lessons learned as a senior project, paper and presentation, along with intermediate documentation to prove we were progressing and continuing our education).

Had we been forced to drop out, we would have failed and not even had a degree to show for it. Had we chosen to drop out, it would have been our decision based on our belief in the idea, instead of as a requirement for pursuing it.

( 1 ) http://www.kauffman.org/about-foundation/foundation-overview...

[edit] formatting.

Unless I am misreading the terms you are only submitting a URL to a REST webservice you create:

...Once you submit the URL of your service at the evaluation web site http://spellerchallenge.com/, a job will be scheduled to call your web service and post a status update to the Challenge’s community page...

Basically it sounds like you are giving them the right to use whatever service you create for the purpose of the contest. It would be hard for them to evaluate your entry if you didn't give them the right to do so. After reading through the rest of the terms, I can't find any requirement to give them access to anything other than that webservice and, if you win, a paper describing your research (no code requirement specified in any of the submission requirements and if you don't want their money, you don't even have to write a paper to participate).

The problem is it is not an all or nothing situation most of the time. Usually you get paid part of it and they have some convincing explanation of why they can't pay the rest. Suppose they paid all your wages but not your travel expenses - pending verification of some receipt or something. They paid all your regular time, but not your overtime charges, claiming that payment had to be approved by someone higher-up. I've had both of these happen to me (both were legitimate situations and I did eventually get paid hassle-free) - but how do you know it is legitimate until after you are paid? You can stop working until you get paid entirely, but if you have bills due, it can be better to get some money than none at all. There is also the whole issue of the relationship - if it is just a legitimate hiccup you might not want to sour a good long-term opportunity, so you make a judgement call - he's a good guy and would never screw me - and next thing you know you next months check is missing too and you are down thousands of dollars.

It is always easy in hindsight to say it should never have happened but that does not make it anyone's fault other than the people who agreed to pay them and didn't.

True but here in the US "engineer" is not the term that matters. "Professional Engineer" is the term given to licensed and accredited engineers - generally identified by the initials "p.e." after their name, and you usually include some indication of the state you are licensed in.

Since graduating with an engineering degree is not enough to become a "Professional Engineer" in the US, you can actually argue it makes some sense to differentiate the terms - being licensed as a PE requires 6 years of professional engineering experience before you can even take the exam. So simply listing a job title of "engineer" might help demonstrate relevant engineering experience but means nothing with respect to your actual license.

"Don't view getting a job as failing. "

I was actually going to post this exact same advice. Getting a job is not failing. You graduated college so obviously you place some value in having a structured environment to learn. If done carefully, a good job can provide you with a whole new set of skills (and contacts) that may prove invaluable, in much the same way college did - only you are getting paid for it and building up that independence. On top of that, you can still work on your project - it is not one or the other.

Also, I actually believe that learning how to release is very important. A good job will teach you that skill. How do you decide what is the "minimum" set of features? How do you decide which bugs have to be fixed and which can be ignored for now? How do you decide when a feature is "complete"? How do you balance the need for a new release yesterday versus the need to address issues and add value. These are all things that it sounds like you are having trouble with - and a good job will show you how other people make these decisions, which you can then apply to your own project.

1) No about page? Who is Dropjobs, LLC? The about page is one of the first things I look for when dealing with a company I've never heard of. See http://www.readwriteweb.com/start/2010/08/what-does-your-abo... for some thoughts on what to include. I am basically just looking to connect the company to something - otherwise you are just another faceless internet page and I tend not to trust those.

2) FAQ link does nothing for me on Chrome. I don't care if anyone has actually asked the questions - but several popped into my head while looking at this page. (What do you mean by "X Jobs" - do you count open positions or just posted? If I post a job in one month does it count against next months quota? How do I post jobs? How do I review resumes? How do I select a resume for interviewing? Am I always billed or only when I have positions posted?)

3) I am also in the "Where is the demo page" category.

Except Microsoft and Yahoo already negotiated with Facebook for access to their contacts:

"And it has also forged deals with both Hotmail and Yahoo that will let those services access its contact data. Google didn’t do a partnership with Facebook, so it doesn’t get the goods."

Which makes me more curious why Google did not negotiate a similar deal and why they are trying to force the issue now.

This is actually a perfectly legitimate practice - there are various regulations that govern these types of single-vendor/single-product requests. Usually you have to show (based on an analysis of currently available solutions) that no product except the one named could possibly meet your requirements.

In this case, it appears that the DOI actually followed those rules and came to the conclusion that only MS could provide a working solution. Google is essentially saying in the complaint that

a) Their solution meets the stated requirements and the DOI knew about it.

b) It is unclear if Microsoft's solution even meets all the requirements (specifically the security requirements since Microsoft is not currently FISMA compliant and has a bunch of known problems in its exchange server)

therefore the justification for naming Microsoft's solution is invalid and solutions involving Google's product should have been allowed for consideration.

Since I didn't actually read the DOI justification (only Google's summary of it) and I am not familiar enough with the specific regulations that govern this sort of thing to comment on its validity, I simply wanted to point out that "naming the winner" in the RFQ is not enough to invalidate it and is not necessarily a problem if the proper research has been done.

Please don't mistake my comment as an argument for using email in all situations. I think that source control is widely accepted and about as frictionless as it should be. There are a variety of task-management tools and processes that can be used pretty easily within a team and also generally hit about the right level of friction. I love being able to integrate the two and further reduce needless friction. It is all the different discussions and conversations that go on around those items that are difficult because I don't want any friction in those discussions. I should be able to see what my client thinks of the new GUI, or ask an old roommate of mine to review some performance-critical code and see how he would approach it without requiring them to create a new account, get access from IT, purchase a license, or any of the other impediments usually placed on using these sorts of tools.

Basically, my thought is that if you are attempting to compete with/replace email, you need to address the friction issue for those items. Otherwise people will eventually revert to email at which point updating the repository becomes another item in the todo-list, and the reality I've experienced is that it will ALWAYS be the bottom item.

In short, I agree with all the problems you cite, I simply have not been able to experience the ideal because none of the systems I have attempted to use reduce the barriers to communication sufficiently to replace email.

I agree that web-based solutions could reach enough people for them to be a feasible replacement for email in terms of availability. The point I was trying to make by talking about access is that everyone has an email address I can send mail to, but generally access to project-specific tools are limited to folks on the project. So if I hash out an interesting technical approach with someone outside the project or outside the company, it will likely be done in email or via the phone.

Once I have resorted to using email, eventually I will forget to move a conversation over or I don't think it will be important and our "repository" has gotten out of sync, which leaves me with a merging issue (do I trust what my email says or the website), and eventually a duplication of effort (I know we talked about this, but my email says x, and the website says y)

As an aside, as I was writing this, I also realized that I tend to use email as my "archive of knowledge". When I move on to a new project I can search back through my email to find relevant discussions and apply them to my new work. I have not seen a tool with a similar ability to archive and take with me my lessons learned (whether because of company policy or lack of feature in the tool). I know lots of managers who religiously archive their email to avoid losing some obscure piece of information or process from years ago.

My basic formula runs like this - when I'm negotiating, I cite my previous salary as everything I earned - salary + all bonuses plus any other perks I can cite.

When I'm comparing, I use only money I'm guaranteed: salary plus any guaranteed or performance bonuses I am confident I can hit (with targets in writing as part of my job agreement). Bonuses that are based on nomination or any other "approval" type process are really just too risky for me to consider as part of my overall compensation package. They will only factor if all else is basically equal.

The problem with trying to force people out of email is that everyone

a) Knows how to use email

b) Has access to email

Don't underestimate these things. If I'm at home and I need to log into a company VPN just to update my status for my manager, that's a lot more effort than sending off a quick update via email or just picking up the phone.

Conversely, if someone asks me for some help on a project and then asks me to learn an entirely new system for an hour of my time (including new logins, new bookmarks, possibly installers, etc) it is often a net loss for me and for them - by the time I am up-to-speed I am done with what they needed anyway.

Basically, I am happy to use whatever system can help me do my job better, but too often I am forced to drop back into email anyway. Eventually I am trained to just use email first, because once your tool gets out of sync, its usefulness decreases.

If he is a good fit and would add value to your company, hire him. Presumably he would still have the necessary contacts at his original company to help you get in the door, and it sounds like he could probably introduce you to other decision-makers in the industry.

If you wait until after he has signed his current company up for a contract, you are going to create a perception problem, regardless of the reality of the situation. It simply looks like a setup to the majority of people who won't be privy to the entire context of the hire.

Just a couple of words of warning on government contracts.

1) Some will require a government clearance. This will take time, and you will be competing against folks who already have the clearance. So you will need to convince them you are worth the wait - a notoriously difficult proposition unless you already have work with them.

2) The timeline from lead to getting paid is long. I would expect at least a month or two from when you start working on the contract until the money comes in, to say nothing of the time to actually get started on the contract.

3) The end of the year is a tough time to try to get added to a contract - everyone is running out of money. In some cases you might get lucky and find a project with a surplus that is looking to spend it before the end of the year, but in my experience those are usually the exceptions as opposed to the rule.

In short, unless you already have the paperwork in hand, I wouldn't bother if you are only looking for 6-12 months.