Vacant-land mythology impedes serious energy discussions - <AUTHOR> https://thehill.com/opinion/energy-environment/430992-vacant-land-mythology-impedes-serious-energy-discussions <comment><USER2> What? Nobody believes that you can just saddle up, head to Montana, and homestead yourself a wind farm. (It'd be a cool sci-fi setting, though).

People do think that there are vast areas of cheap and lightly utilized land outside of the urban corridors which could produce more money with solar, wind, etc than they do today. They believe this because it is 100% correct, and would be correct whether you were talking about renewable energy or any other light industry.

The author seems to think that because this land is used at all and not free solar etc cannot go there, which is a baffling claim to me on both points.

<comment><USER3> Worth noting the author's fellowship at the Manhattan Institute. This is essentially paid content from a very well-funded outfit with pretty clear ideological objectives.

</comment></comment><comment><USER4> Well, yes, NIMBYism is a thing. But most oil and gas operations, while they take up less space, are more than toxic and smelly enough to make up the difference- and pipelines are regularly routed through public lands, skirting highly populated zones, in the face of massive public opposition. The reason those get built where renewables don't is simply that the oil industry is _massive_ and knows how to work the necessary politics.

The renewable industry will need cultivate its clout, and learn to work the system just like the oil players have- and then, NIMBYism and lack of space will just mysteriously cease to be problems.

</comment><comment><USER5> Is "nearly ten square miles" supposed to be a lot? The Black Thunder coal mine occupies a lot more land than that and the railroads needed for its 25 trains per day of coal occupy more space than any HVDC transmission system. The fact is we have more than enough free space for all the solar and wind America needs. Put PV all over Edwards AFB and you'd supply a substantial fraction of all of it.

By the way the USA has over 2 billion parking spaces. Somehow we find the space for what we value.

</comment><comment><USER6> Maybe he has a point to make. But he doesn't make it very well in this opinion piece.

I am currently traveling through the south-western, and mountain-west states. (Arizona, New Mexico, Colorado, Wyoming, Montana, etc).

Vacant land is not a myth.

</comment><comment><USER7> Author is a climate change denialist and the institute he works for is funded by the Koch brothers and Exxon mobile.

<comment><USER8> Well, yes, it's understandable why traditional energy companies have all sorts of government support including eminent domain and why he wouldn't wish that those protections extend to the competition in the renewable sector.

<comment><USER9> Why is that understandable?

<comment><USER8> Energy is a matter of national security and a source of big money, it's easy to see why the government would protect these interests against the pesky locals.

<comment><USER10> What do you mean? I really don't understand the point you are trying to make. Energy is a matter of national security primarily because our energy sources and distribution are destroying our own country. Quickly, too. Miami will not recognizably exist for the lifetime of the kids growing up in it now.

It is the purpose of the government to serve and protect those "pesky locals" (ew...do you really call your fellow people 'pesky' who want a better world for you?) and the best way the government can do that is to shut down oil/coal/polluting technologies and move to renewables as fast as possible.

<comment><USER11> > Energy is a matter of national security primarily because our energy sources > and distribution are destroying our own country.

Really?

Then how come Saudi's are "nice good guys" and Iranians are "scary bad guys", when neither is an 'enlightened' western-style democracy?

truth is a bit more complicated i'm afraid.

see also: Clash, The. "Rock the Casbah", CBS Records, 1982.

<comment><USER10> > Really?

Yes, really.

> Then how come Saudi's are "nice good guys"

I have never heard that in my life. Saudi is one of the scariest places on Earth to me, I don't see anything nice or good there, and neither does anyone I know. What do you mean?

> Iranians are "scary bad guys"

I've never heard this either??

What on Earth does any of this have to do with my post?

<comment><USER11> > I have never heard that in my life.

check us foreign policy. it's pretty clear.

>Saudi is one of the scariest places on Earth to me, I don't see anything nice or good there, and neither does anyone I know.

hey great, your opinion here doesn't matter. you were commenting on national security and energy policy, which may or may not reflect your personal opinions.

> What on Earth does any of this have to do with my post?

that energy policy is also related to geopolitical concerns and protecting strategic interests in other areas (e.g. financial system / allegiances in other areas / petrodollars, etc) and, i posit, not simply "because our energy sources and distribution are destroying our own country" as you claim

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> From a British perspective, this argument seems utterly absurd. We generate almost twice as much of our electricity using renewable sources, but our population density is eight times higher. If we can find the land to accommodate wind turbines, so can you. There are a heck of a lot of rooftops that don't currently have solar panels on them.

[https://en.wikipedia.org/wiki/List_of_countries_by_electrici...](https://en.wikipedia.org/wiki/List_of_countries_by_electricity_production_from_renewable_sources)

[https://en.wikipedia.org/wiki/List_of_countries_and_dependen...](https://en.wikipedia.org/wiki/List_of_countries_and_dependencies_by_population_density)

<comment><USER13> You British also have a history of pulling together when times get tough. Maybe it's because of our lack of density, or maybe it's just the people who up and moved here, but as Churchill supposedly said: "Americans can always be trusted to do the right thing, once all other possibilities have been exhausted."

</comment></comment><comment><USER9> >They also are concerned about impacts to property values.

What's going to happen to your property values when climate change renders your region uninhabitable?

<comment><USER14> The expected change for the next hundred years is only a few degrees, it will not make the region uninhabitable this century. People doesn't care too much about the price of the property in a few centuries.

<comment><USER15> The few degrees is a global average. It won't be evenly distributed, so some areas will suffer more from rising temperatures.

<comment><USER14> I agree, but for this particular area I think that the estimation is nor far away from the average.

</comment></comment></comment></comment><comment><USER16> There's obviously some amount of truth to this considering we recently discussed [1] the largest county in the USA (San Bernardino) restricting large-scale solar and wind farm projects.

[1] [https://news.ycombinator.com/item?id=19277653](https://news.ycombinator.com/item?id=19277653)

</comment><comment><USER11> of course 'the hill' blames the backwards people in flyover states in need of superior bicoastal enlightenment for resisting the change to renewables, rather than looking for the lobbyists hiding out in their own full-of-hot-air backyard..

reality is probably some combination of both, minus the whole false- superiority bicoastal enlightenment thing..</comment>


Musk hung up on NTSB chief during call about Tesla crash probe - <AUTHOR> https://www.bloomberg.com/news/articles/2018-05-04/musk-hung-up-on-ntsb-chief-in-testy-april-call-about-tesla-probe <comment><USER2> Perhaps it is time for Mr Musk to hand-over Tesla to someone boring but production-focused. He has done the entrepreneurial work, made Tesla a well- known brand. But now it is time for rivet-counting and process optimisation. Ugh.

</comment><comment><USER3> Url changed from [https://arstechnica.com/tech-policy/2018/05/elon-musk- hung-u...](https://arstechnica.com/tech-policy/2018/05/elon-musk-hung-up-on- ntsb-chief-during-call-about-tesla-crash-probe/), which points to this.</comment>


Ask HN: Best DevSecOps Literature - <AUTHOR> I am wanting to learn more as a working SWE how to learn and implement DevSecOps best practices. Any literature recommendations? <comment><USER2> Genuine question: why is DevSecOps a thing? What is the difference between it and DevOps? Or separate DevOps and SecOps teams? Or InfraOps? At what point does it become systems administration with inflated titles? I've even seen business people call themselves "BizOps".

<comment><USER3> Devops/InfraOps/SRE - Engineer/Sysadmin with infrastructure experience focused on reliability. May have some security knowledge but not a security expert.

SecOps/Security Engineer - Typically focused on responding to security incidents and proactively preventing security issues. Typically this involves threat detection, pen testing, security reviews. They can often reverse- engineer malware but they may or may not be able to write a web app. Probably can't set up the infrastructure to run their security platforms.

DevSecOps - Security focused Devops engineer. Expected to have significant security experience, but probably not doing pen-tests. Likely working on container security, setting up and running security platforms. May be a security consultant for devops engineers the same way a security engineer is a security consultant for app engineers.

</comment></comment><comment><AUTHOR> The deeper inquiry of mine is best practices on containerization, continuous development/integration and where security fits in the loop.</comment>


The 25 Tools Every Entrepreneur Should Know About - <AUTHOR> http://www.entrepreneur.com/article/237608

<comment><AUTHOR> I would be curious to know how many of you use these, and which you find most useful. Some of these seem odd as the top 25. I can't imagine many that have missed Google Drive, Pinterest, Buffer or even Audible. Meetup wouldn't be my go-to, but maybe I should reconsider this. Wix is not the newest or greatest for simplistic website building, and many platforms offer comparable and equally if not more simplistic interfaces for design.

HelloSign is new to me. I hadn't heard of Fiverr either, more familiar with the more currently popular crowdsourcing sites. I've only recently discovered TalkWalker, so I'm still seeing how that fits into my social media plan.

At the risk of seeming like I'm just tearing down the author, I must admit that I'm hard-pressed to come up with a better list of "must-have" tools. I use Google Drive religiously, but not sure what I would tell someone else I couldn't live without...</comment>


'Hello World' from the Stanford AI Lab Blog - <AUTHOR> http://ai.stanford.edu/blog/hello-world/ <comment><USER2> CSAIL vs SAIL..... Fight!</comment>


Lakota Indians Adopt New Digital Currency, Mazacoin, as Legal Tender - <AUTHOR> http://blogs.wsj.com/moneybeat/2014/03/07/lakota-nation-strives-for-independence-with-digital-currency-mazacoin/

<comment><USER2> Current source article title: "Lakota Indian Promotes New Digital Currency, Mazacoin" (there is a correction notice in teh source article.)

No one has adopted it as "legal tender", one guy is promoting it, and has duped a few news outlets (including Forbes and the WSJ) by issuing false press releases about official adoption by either the Oglala Sioux Tribe or the Lakota Nation. An article [1] linked in the corrected WSJ article notes (but the WSJ does not) that the tribe has denied that the person promoting it is even on their roles as a member; the corrected WSJ article does note that the member of the Lakota Nation governing council that they discussed it with had never heard of it and seemed suspicious of it.

[1] [http://www.indianz.com/News/2014/012781.asp](http://www.indianz.com/News/2014/012781.asp)

</comment><comment><USER3> Post title misleads: the article does not say the Lakota have "adopted" this currency.</comment>


Canada's R&D tax credit program hurts R&D in Canada - <AUTHOR> https://medium.com/@wwhchung/sr-ed-hurts-canadian-innovation-4fbcf4898d7d <comment><USER2> SR&ED is a terrible program that is actively hostile to software startups.

To begin with under the definition of what the program considers claimable, in the strictest sense, most software work doesn't actually qualify, but the program is so poorly administered that most of them are able to successfully claim it anyways so they try, however you are always under the risk that your claim will be denied or clawed back.

Adding to this problem for startups, first time claimants have a much higher chance of being audited, as well as any time a claim increases significantly over the previous year (think high growth company). If an audit goes poorly enough you can also have previous years claims clawed back.

Then there is the time wasted in preparing and submitting, the pedantic time tracking that startups implement which is a drag on development teams in order to file these claims.

Finally, because the process is confusing and daunting enough most companies will hire a SR&ED consultant to file the claim for them where they will likely pay around 20% of the total claim.

In short, SR&ED is a great program for consultants to siphon money from tax payers but a terrible program for funding innovative startups.

<comment><USER3> On one hand you are saying that there's bad claims and on the other hand you complain about having to document and having audits.

All you are saying is true except the conclusion in the last sentence, which may be a valid point but doesn't follow from the other facts.

<comment><USER4> That's how poorly administered the system is. I've seen companies go through SR&ED and it's fairly random whether the paperwork is going to be accepted.

Some companies document everything and end up being rejected for a random formerly unknown minutia, whereas other companies document less, and ultimately get approved for a bad claim.

Anyone I've talked to who's even been close to the process (a claimant, a technical contact, an interviewee, an administrator) have had traumatic experiences with the process.

</comment></comment></comment><comment><USER5> This post is a load of shit, serious shit.

Claim 1: > Promotes excessive executive compensation

You can not claim executive compensation in a SRED claim. If you do it is fraud.

It is an excluded expense see here:

[http://www.cra-arc.gc.ca/txcrdt/sred- rsde/clmng/ttlqlfdsrdxp...](http://www.cra-arc.gc.ca/txcrdt/sred- rsde/clmng/ttlqlfdsrdxpndtrsfrtcprpss-eng.html#s10_0)

Claim 2: > We're paying foreign entities to take IP and profits out of Canada. Not a very good use of taxpayer dollars, is it?

Actually that is illegal, see this:

[http://www.cra-arc.gc.ca/txcrdt/sred- rsde/clmng/ttlqlfdsrdxp...](http://www.cra-arc.gc.ca/txcrdt/sred- rsde/clmng/ttlqlfdsrdxpndtrsfrtcprpss-eng.html#s9_0)

Claim 3: > Removes emphasis on sustainable growth

It isn't meant to be sustainable, it is mean to fund the initial R&D in something that is risky. As you grow, and you slow down R&D, yes it gets smaller -- by design.

This is a really weird post and seems to be spreading FUD.

SRED is not a perfect program, but the main faults outlined in this article are complete wrong.

<comment><AUTHOR> Hi there. Claim 1 is not incorrect. I am not stating executive compensation is used to claim SR&ED. I am stating it is used to suppress net profits to qualify for the higher rate. Also,

Claim 2, there is no requirement for IP to be owned by the Canadian entity for its development to be qualified for SR&ED (I've verified this from multiple accountants and the CRA).

As for Claim 3, you realize that this is indefinite right?

<comment><USER5> If you say these are major issues, how often have you seen these two instances in the real world as a percentage of total SRED claims? Are these theoretical concerns or do you know that these are very serious practical concerns about SRED?

Regarding Claim 1, you are advocating that company will sacrifice its growth in order to live off of SRED. The larger one's SRED claims and the larger they are in respect to total expenditures, the more likely to gain scrutiny and audits. I've been SRED audited, it isn't fun. If a company could make $1M, why couldn't it make $2M? This seems like a contrived scenario.

Regarding Claim 2, if a company is not going to act in its own best interests, it doesn't matter who owns the IP. The company could license it for nothing to other companies even if it owned the IP.

In both scenarios you are outlining companies acting against their own best interests. Maybe it is possible, but it doesn't seem like a very common case. Do you have numbers to back it up, or just the theoretical possibility that it could technically happen?

<comment><AUTHOR> Yes, it happens a LOT. I can't point fingers (it's not polite, and I'm Canadian), but it's what prompted me to write the article.

And yes, it does matter who owns the IP. If a sale happens, the proceeds to to the residing country's tax base. If it's not in Canada, we lose out on those gains.

<comment><USER6> Why can't you point fingers? If you know this is happening, which is supposed to be illegal, then blow the whistle.

<comment><AUTHOR> Because it's not illegal as my post points out. It's a flaw in the structure.

<comment><USER6> So? Nobody says that you're supposed to claim they're breaking the law. You're just pointing out a company abusing the law.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> The SR&ED reporting process is a nightmare. I once spent 170 hrs. defending a piddling $100K claim. Hell is spending 8 hrs. in a room trying to explain polymorphism and encapsulation to an accountant. The whole process is geared towards engineering, physical processes and manufacturing. The subtleties and abstraction of software development make it look like we take no risks.

The time-tracking requirements seriously degrade your productivity.

I joked that if you discovered time travel, you wouldn't qualify for SR&ED because you were successful, so there was obviously no risk involved, ergo you don't qualify.

<comment><USER8> It's pretty difficult to get software development to qualify for SR&D. The way it was explained to me by a consultant was to qualify there had to be technological risk of failure (i.e. it is unknown whether or not it is possible to do task X via software).

So your average SAAS startup doesn't face technological risk, even though they face lots of business risks (might not be able to hire good enough developers, might not be able to produce bug free app, etc).

However the first few companies using deep learning to do facial recognition from photos (eg. facebook automatic tagging)... well they would have faced technological risk. It wasn't known at the outset that deep learning would produce sufficient quality matches to be useful.

On the downside... big organizations that can pay big bucks for assistance with writing SR&D applications can qualify for S&RD. Several of the big Canadian banks have recovered considerable amounts. Which is pretty outrageous on the face of things... how much actual SR&D and technological risk is being faced in a banking environment? None that I've ever seen (well... except for one project I was involved in... but that was a trivial "lets try this and see if we can use shared record locks as activity signals for a job scheduler").

In a way scientific/technological risk is a bad measure for software R&D. In general there is very little technological risk, and what risk there is is generally tackled via prototyping and/or early testing. The meat of the development costs comes much later... and there's no gov't tax support for that at all.

<comment><USER9> > The way it was explained to me by a consultant was to qualify there had to > be technological risk of failure (i.e. it is unknown whether or not it is > possible to do task X via software).

Ok...

> However the first few companies using deep learning to do facial recognition > from photos (eg. facebook automatic tagging)... well they would have faced > technological risk. It wasn't known at the outset that deep learning would > produce sufficient quality matches to be useful.

This is a wildly different standard. It certainly _was_ known at the outset that facial recognition from photographs is possible to do in software, because people do it all the time. They just didn't know how.

</comment></comment></comment><comment><USER10> In my experience, SR&ED is a system that exists to employ government bureaucrats and their symbiotic ecosystem of consultants and auditors -- everyone else is a loser. And I felt this way _before_ we at Joyent were audited; after we were audited (which came back clean, but was incredibly time consuming and extraordinarily painful) my opinions on SR&ED are much more pointed: we still have a Canadian office and it hasn't affected our hiring there (Joyent is hiring in Vancouver![1]), but I want absolutely nothing to do with SR&ED ever again in my life. (That is, we have not applied for SR&ED credits since and will never do so again.)

If Canada wants to do something for startups, they should setup a sovereign wealth fund that does early stage investment in Canadian companies -- and then it should actively help make those companies successful. SR&ED is a transfer payment from Canadian taxpayers to Canadian consultants; it should be scrapped, not fixed.

[1] [https://news.ycombinator.com/item?id=10312448](https://news.ycombinator.com/item?id=10312448)

<comment><USER11> This is nonsense.

SR&ED is not a grant you apply for, it is a tax credit that you are ENTITLED to for taking technical risk and venturing into areas of technical uncertainty.

SR&ED is a tax credit and a perfectly reasonable one. The problem with SR&ED is that it is a badly abused which leads to painful auditing processes for everyone.

Since Joyent Canada is (as far as I'm aware) a 100% wholly owned subsidiary of a US corporation it doesn't surprise me the CRA took a close look at the claims as Canadians ultimately wont see the extent of the benefits that the program hopes to achieve for Canadian corporations. The fact that you call it the "Canadian office" rather than the "Canadian company we own" illustrates a frame of thinking that likely makes the CRA uncomfortable. The program is designed to help Canadian companies.

So.. you are an American, working for an American company, managing a team that is receiving Canadian tax breaks for generating I.P. for the American corporation and you are complaining that you received friction from the CRA? Yeah, no shit.

> SR&ED is a transfer payment from Canadian taxpayers to Canadian consultants; > it should be scrapped, not fixed.

No, SR&ED is not funding from Canadian tax payers. Once again it is a tax credit for money spent on salaries for performing tasks that have abnormally high risk. Its critical to understand the difference before voicing an opinion on the matter.

edit: wording

<comment><USER10> You fundamentally misunderstand SR&ED: it has nothing to do with "helping Canadian companies" and everything to do with encouraging companies to do R&D work in Canada. That Joyent Canada is a fully owned subsidiary of a US corporation is immaterial (indeed, SR&ED is designed to attract R&D investment from multinationals not based in Canada!), and as a I learned as part of the audit, the audit that we received is considered "routine" for the first year that a company applies for SR&ED credits. Our consultants didn't think it was a big deal, and Revenue Canada was very polite about it; they (apparently) just wanted to make sure that we employed everyone that we said we employed and that they were engaged in eligible activity (which we did and they were -- it was all fine). But the audit was expensive for us in terms of time, and we made the decision that SR&ED wasn't worth it. That's not nonsense; that's a business decision.

</comment></comment></comment><comment><USER12> SR&ED was pretty decent for me this year. I claimed almost $120k in qualifying expenses (a roughly $90k salary for myself and the proxy amount).

I spent about two weeks putting together the application (along with the rest of my corporate tax return, so time was spent there too), and wrote up a few pages about the software development work that we did.

It took about 2 months for them to respond, and I was approved without a request for additional supporting documents. I received $48k.

I don't think I'll try and apply for it again next year, since I think it's going to be harder to justify the time expense, but overall, it wasn't so bad for a small claim.

I can certainly see how larger claims than mine become onerous though.

<comment><USER13> Two weeks! Neglecting the rest of your startup for 2 weeks can easily kill 10% of its long-term potential. For $48k, so if you value your startup at more than $480k, you shouldn't do it.

(Taking a 2-week vacation doesn't do that, because you're fresh and energized afterwards, rather than beaten down by the grim bureaucracy).

<comment><USER12> Precisely why I wouldn't do it again. Right now, $48k was the difference between paying myself, or not. In the future, as we grow, that hopefully won't be the case.

</comment></comment></comment><comment><USER14> I'd also mention that what counts as 'R&D' is often paper thin. Normal developer activities can count if they are spun correctly.

Whether that's a problem depends on the amount that you think of this as a general small business tax credit vs an incentive to do research.

<comment><USER15> I was once told of a _restaurant_ that managed to get SR&ED for their chefs.

Second-hand, and supposedly they've tightened the rules since then, but I feel like it's really telling of the flaws with the program at a fundamental level.

Either make it a handout directly or tighten up the rules so that it can only apply to things with really rigid processes that are capital intensive, imo.

</comment></comment><comment><USER16> As a Canadian, I'd prefer it if the government took the entire SR&ED budget and put it into an early/mid-stage venture fund like VCAP: [http://www.actionplan.gc.ca/en/initiative/venture-capital- ac...](http://www.actionplan.gc.ca/en/initiative/venture-capital-action-plan)

I've seen SR&ED abused at companies I've worked at, and on the flip-side I've seen claims that _should_ qualify as R&D get denied.

By investing in startups (doing some due-diligence up front as any venture fund would), we can increase the amount of R&D in Canada while simultaneously reducing the operational cost of running it dramatically.

Big companies can take advantage of this program by acquiring earlier-stage startups in their field.

<comment><USER17> Since only a small percentage of startups are doing significant R&D, that seems likely to just direct money towards general business development, the majority of which ends up being "business model innovation" combined with straightforward web development, vs. science/engineering innovation. Granted, that may not be much worse than the status quo if it's currently funding a ton of non-R&D things anyway, but it doesn't seem likely to really stimulate R&D, either.

</comment></comment><comment><USER18> It's great getting that money back and the author makes some good points about the shortcomings of the program, but as a recipient of this credit 3 years in a row now (just got our 2015 claim approved in record time), here's my issue with it: It just seems like a handout for optics' sake.

In my circle of fellow SR&ED recipients, none of us have ever said "Well if it wasn't for this program, we wouldn't have hired these people, built that, researched this etc."

Although in spirit it's meant to act as incentive to take risk, profit is all the motivation you need. I can't help but think that $4B could have been better spent on a few km of track for the subway in Toronto, for example.

<comment><USER19> Isn't the goal to keep the R&D in Canada? It might make no difference to _how_ a startup is run, but I could see it making a difference of _where_ the startup is run.

</comment></comment><comment><USER20> This is definitely true, but not news to anyone who has followed how government program "X" for business actually works. These programs are defined by who they favour, and it has nothing to do with merit as defined by business or legislators; it is defined by bureaucrats who invariably favor things that benefit them directly.

I managed to get a decent amount of money back from SR&ED, but it required (as expected) an incredible time investment. A time investment that was negative to our business in every way; there's no way to reap a return on that later unless you return to SR&ED in the future.

The best thing, as always, would be for the government to simply lower taxes and eliminate these circuitous loops.

</comment><comment><USER21> SR&ED can work very well for its intended audience. Most of the really vocal complaints I've heard were from people and companies that really shouldn't have applied in the first place.

However, I agree that there is confusion and external pressure to apply which doesn't help things at all.

Most startups, don't do this sort of R&D at all (or hardly at all).

</comment><comment><USER3> "there are some bad unintended consequences" != "SR&ED Hurts Canadian Innovation"

<comment><AUTHOR> Bad unintended consequences was a nice way of phrasing 'it sucks and is draining money away from real R&D/innovation'

</comment></comment><comment><USER22> France has something like that as well, and boy, you wouldn't believe the number of software companies which totally do massive amounts of R&D. And they really do, it's just that for them, R stands for Read and D for Debug.

</comment><comment><USER23> It's really important that programs like Canadian SR&ED are being scrutinized in the context of startups, and on that theme I'm really happy to see this discussion.

I think it's more interesting to see how Canadian founders can shape these sorts of policies over the next 5-10 years, and this is a great starting point.

</comment><comment><USER24> For all its faults, Zite/Worio would've surely folded without SR&ED credits.

(In the end, we launched and were acquired by CNN.)

<comment><AUTHOR> Or, it could have folded and made something else. Or any number of other scenarios. But debating SR&ED being good or bad is too theoretical and everyone can point to examples on all sides. This is why I chose a very specific issue with SR&ED and proposals on how to fix it.

I'm not stating that SR&ED does not have its benefits, but there are some glaring flaws that need fixing. Others include the SR&ED process itself, evaluation of SR&ED claims and more. However this is the first one I could concretely back up with examples and math and give real solutions to.

</comment></comment><comment><USER25> I actually had this discussion with my accountant yesterday: it only makes sense if you're so profitable that you're paying taxes.

Guess who that favours ;)

Not me!

<comment><USER26> Get a new accountant.

<comment><USER25> That's the thought I had for other reasons, but good to know that it was justified.</comment></comment></comment>


Re-inventing Android : Ice Cream Sandwich - <AUTHOR> http://microreviews.org/re-inventing-android-ice-cream-sandwich/ <comment><USER2> The thing that really stands out to me about ICS is the focus on user experience. Duarte seems to have addressed all the little complaints I've always had, and some I never realized I had.

* Moving away from long-presses.

* More consistent app navigation via swipes.

* More usable but still powerful task management/switching.

* Better representation of useful data like contacts and calendars.

* Order of magnitude better camera app, faster, cleaner, with extremely easy sharing built in.

Apparently the UI is finally hardware accelerated as well (though apps have to opt-in), so hopefully it means an end to Android's historically jittery interface.

<comment><USER3> The hardware acceleration opt-in is just one line in the AndroidManifest.xml file, so it should be widely adopted.

<comment><USER4> It's actually enabled by default on Android 4.0. It's optional only in Honeycomb.

<comment><USER5> It depends on your targetSdk. It can't be enabled by default because it breaks a lot of apps.

<comment><USER6> You're currently downvoted, but you're correct. Apps targetting older sdks will need to opt-in to make use of the acceleration, even on ICS. But it's an easy switch to flip, assuming it doesn't cause visual glitches, which it can in some cases.

</comment></comment></comment></comment></comment><comment><USER7> Any word on fixing stability issues? In my experience that's by far the number one issue with the OS (keyboard crashes, slowing down after about a day without reboot, the actual phone app acting up, the call not going through, not being able to answer, text messages not being delivered all the time, etc etc)

<comment><USER8> I've never experienced any of those issues in my 2+ years with Android. I've always used stock Android (on the MyTouch 3G and then the Nexus One) -- I think you must be using a buggy build.

<comment><USER7> It's definitely something weird going on, but I can promise you I'm not alone. Starting with 2.1 (Nexus One stock, no tweaks) every version got worse. Tried a reset, wipe, and eventually installed CyanogenMod. CM is actually a bit more stable, but those weird things happen on it as well. A daily restart is a must if I want a functioning phone. I know others that have Eris, Droid, and MyTouch 4G devices (all stock) that experience similar issues. For example, here's a thread about the keyboard issue: <http://code.google.com/p/android/issues/detail?id=15311>

It's very eerie when you click the phone app to make a call and it freezes for a second, then half the app is drawn, you shake it a bit and it sometimes comes back, but then the call doesn't go through. Then you go to send a text and it won't load your messages or the keyboard doesn't show, or it pops up but you can't see any keys, or you see the keys but when you type nothing shows up until you close the keyboard, or it takes two seconds before what you typed shows up. All these are symptoms that you need to restart.

</comment></comment></comment><comment><USER9> Is Android going to be open source again? (Well, I say open source, but what I mean is--will the source code be available, as opposed to development being open. Google doesn't tend to take patches from outside contributors anyway...)

<comment><USER4> Yes, about 2 weeks after Galaxy Nexus is launched I believe, so sometime in December.

</comment></comment><comment><USER10> One small thing which I haven't yet understood is Why Google is supporting so many (latest) versions of Android yet again. We have Android 2.3.2, Gingerbread and now we have Ice Cream Sandwich. This is confusing. Isn't it?

<comment><USER11> Gingerbread is 2.3.x branch, perhaps you meant Honeycomb?

And while it is a little bit confusing, it _kinda_ makes sense. Gingerbread is latest phone release, Honeycomb was tablet-only thing, and with Ice Cream Sandwich they're merging it into one release.

<comment><AUTHOR> Will this not cause fragmentation again in the near future?

<comment><AUTHOR> Developers have to develop for all three versions. Right??

<comment><USER12> (Android dev here)

No. You release one .apk file (the Android equivalent of .app). Within a manifest inside it, you can specify a "target" release API version and a "minimum" version. No one running a device below the minimum can see or install your apk. The target one is more of a suggestion to the Dalvik VM with how to approach running your application (if it know you're targeting the latest release, it can expect you to use some new features and adjust accordingly, etc).

Just like with web sites, you progressively enhance an Android app during development using Java's reflection, and/or gracefully degrade by bundling up back-ported modules and UI components in your apk. If you absolutely can't get around a particular function not being present in an old version of the API, then you just don't have that feature even visible to the end-user.

The current recommendation is to set your min level to 7 (which is Android 2.1), and as of a few days ago, to set your target to 14 (Android 4.0, or Ice Cream Sandwich). According to raw statistics of devices active and in the wild, this hits 97% of all potential Android customers. Fragmentation used to be an issue back when supporting the Android 1.x line of APIs was still necessary. Now it's nice and streamlined, and I barely notice writing for compatibility any more.

And if you really can't get around some problems, the Market now lets you upload multiple apks for a single "release" of your app, each targeted towards different ranges of API levels.

<comment><USER13> Are there Android devices released with 2.1 that have not received an update to 2.2?

<comment><USER14> Some. [http://developer.android.com/resources/dashboard/platform- ve...](http://developer.android.com/resources/dashboard/platform- versions.html)</comment></comment></comment></comment></comment></comment></comment>


"Dignity is deadly." - Paul Graham - <AUTHOR> http://headrush.typepad.com/creating_passionate_users/2005/09/dignity_is_dead.html

<comment><USER2> _"... When you evolve out of start-up mode and start worrying about being professional and dignified, you only lose capabilities. You don't add anything... you only take away. Dignity is deadly. ..."_

This is the crux of the article. If you have to get dressed up and wear a _"suit"_ , it doesn't make your software better. If you subscribe to the latest theory of " _foo_ " because the " _bar_ " association thinks it's good, it wont help you get more customers. The ideals of Professionalism and Profession are a mismatch for the Startup world.

The creation process in Startups is new markets, products and services. Not old ones. In fact, the best are trying to displace the old entirely. Put them out of business and make them extinct. It's messy, full of unexpected stops and starts. Not the calm, orderly and mastered process with known results as the ideals of Professionalism enshrine.

Professionalism has its place where the benefit of improvement has to be weighed with the risk of damage to the old and existing. An insurance policy against risk but a barrier to innovation.

 _"... Living only on take-out and caffeine. Working in a [small] living room. Crazy, stupid, unprofessional behavior. Wearing nothing but shorts and ripped t-shirts ..."_

I love this quote. It neatly sums up the informality of the startup process and something people from more structured backgrounds have trouble grokking. At least it's another excuse get around in shorts + t-shirt, think and code up ideas rather than waste money on clothes.

</comment><comment><USER3> There are two different markets.

One is turned off by stuffiness (as proxied via "business-speak" and "dignity") and one is turned off by, I don't know, "unreliability" (as proxied by profanity, not sure what else).

You can serve one or other, but not both (unless you have two separate brands and learn to fake the one you're not sufficiently well).

(I'd say that 'professionalism' in itself doesn't turn anyone off. Except that lots of people would have different definitions, including only the qualities they care about, so that's kind of a null statement.)

</comment><comment><USER4> It's easy to get caught up in the profanity segment of this article, but I don't think that's the main point. I personally am not a fan of profanity in my personal or professional life, so I agree with edw519, but I get the feeling that the gist behind the article was more like "Why focus your energy on things that make you seem professional rather than doing a great job?" It's the difference between going out to get your haircut the morning of a big meeting or sitting in front of your computer burning code trying to put in that last feature you've been thinking about before you have to present. It's tossing ideas around through conversation and prototypes rather than through a monolithic "Business Requirements Document". Perhaps the suggesstion is that a common feature for small businesses that don't do so well is worrying first about the clothes and the office and the letterhead and the large staff, and second about the product.

</comment><comment><USER5> The article really just shows that business is creating artificial barriers to determine competence. Because not everyone can determine who is competent, we use proxies like a suit or one's manner of speech.

Unfortunately, it creates a group of people who benefit from that barrier and distracts from product and creative thinking.

</comment><comment><USER6> I look at profanity in business the same way Groucho Marx looked at it in comedy. Comics resort to it because they're desperate; they can't get laughs any other way.

If you need to use profanity to get your point across in business, maybe you should pause and take a good hard look at your message.

This has nothing to do with "professionalism" vs. "passion". You could (and should) do both.

It has everything to do with how you treat other people (whether you know them or not). Shouldn't be so hard to do it all: be yourself, have passion, treat others well, be professional, and succeed like crazy.

<comment><USER7> Bah. Using profanity has more to do with the fact that established business doesn't like it. ("Look at me! I can break all the rules and still turn a handsome profit. Maybe someone has been lying to all of you.")

I love stepping on the limits of what is appropriate, just to see how people react... It's never any fun when it happens by accident, but it can be a real blast when I have figured out beforehand just what phrasing will make my counterpart slightly uncomfortable.

Probably this is why the paraphrased subjects use the words "penis" and "kick- ass". And it might also be that it is closer to the way they interact in their daily lives. My life certainly gets easier when I don't have to worry all the time about whether something is appropriate or not.

As far as I can tell (being an outsider) being "professional" in contemporary American business culture means subordinating by wearing a suit and tie, working exactly when the boss tells you to and doing unpaid overtime whenever it is required. That's hardly something to strive for, due to a host of obvious reasons that anyone younger than 30 should be able to figure out. An alternative interpretation would be that being profesional is to serve your customers, but that's not what I hear whenever someone mentiones the word.

<comment><USER6> Yes, you are an outsider. I haven't seen what you describe as "contemporary American business culture" in at least 10 years.

As far as "stepping on the limits of what is appropriate, just to see how people react" goes, fine. Whatever turns you on. Just don't be surprised when the other person's reaction costs you. It can happen (and probably will).

Personally, I'd rather spend my energy doing great work and succeeding, whatever it takes.

</comment></comment></comment><comment><USER8> Did anyone notice this article is from September 2005?</comment>


Collection of Technical Writing resources - <AUTHOR> https://github.com/sixhobbits/technical-writing/ <comment><AUTHOR> Hey HN! I'm putting together a collection of technical writing resources, including resources that help you become a better writer, and lists of places that pay for freelance technical articles.

PRs welcome!</comment>


Show HN: Retrograde – The best jobs in tech, all in one place - <AUTHOR> https://retrograde.io/

<comment><USER2> I like the clean, simple interface.

I assume the listings are aggregated automatically - does it scrape each company's job listings? Or did they manage to get these companies to send them data? Will they add more companies in the future?

<comment><AUTHOR> Thanks Arcsech!

We're currently indexing each individual company's job site and standardizing the data on the backend.

We're adding more companies daily, if you have any suggestions we'd love to have them.</comment></comment>


I'm an Engineer, Not a Compiler - <AUTHOR> http://www.numbergrinder.com/2009/02/im-an-engineer-not-a-compiler/ <comment><USER3> Imagine interviewing carpenters:

Method 1:

      How many ten penny nails in a pound?
      Who makes better screwdrivers, Craftsman or Snap-on? Why?
      What's your favorite toolbox? Why?
      How can you tell when wood has been treated?
      Why should you measure twice, cut once?
      Which end of the hammer do you hold?

Method 2:

      Show me something you built. Describe what you did.
      Cut this piece of wood according to these specs.

If you needed someone to build your house, which method would you choose?

<comment><USER4> Differences between programming languages are much bigger and more important than differences between different brands of toolboxes or hammers.

If you realise you made a poor choice of screwdriver it is trivial to replace it with a different one and carry on working almost immediately since it's operation is basically the same.

Choosing your language or platform poorly and running into issues later once you have an app close to release or already running in production is going to cause much more difficult problems.

Essentially our tools end up embedded inside our product itself.

It's close to impossible to reliably compare programming to any other profession simply because there is nothing else quite like it.

<comment><USER5> I don't think this is borne out by reality.

Making a general contracting mistake such as accidentally compromising the structural integrity of a building by making a poor choice on where to run the plumbing can easily result in a lot of work having to be re-done, at significant cost.

</comment></comment></comment><comment><USER6>
      IDE dependency? Perhaps, but that isn't necessarily a bad
      thing since that is representative of the tools they will
      be using in the office.

Mine is perhaps an unpopular view.

I have come to believe that a decent programmer can and should be able to work well enough without an IDE. Presence of an IDE should be a sufficient condition not a necessary condition and I see so much of the latter.

IDEs are a crutch and there is a minimum level of "walking" that I expect from you without a crutch. If you have to reach for a crutch even for the simplest tasks you will earn my suspicion that you are not as comfortable as the other guy in more complicated operations. As for the claim that IDEs are a representative tool, it need not be true, more for a start up pushing the envelope. Who knows which new or non mainstream language/technology will be most suited for the job. There may not be any mature tooling available yet. I would want my co-hacker to be able to cope.

To give an example, there was this guy who claims he knows scala, but loathes working on a scala project because apparently there are no mature debugger for scala in eclipse. For him a eclipse plugin is a necessary condition.

I have seen too many programmers who program in the following mode - let me type something in the IDE. No errors detected ?, good. Let me test it on a few cases. Didn't work ? let me bump up the loop bound by one, no cookie ? let me decrement it by 2, didnt work, let me change the sign of this expression from positive to negative -...ad infinitum. I am more scared when such a code passes a few half assed test cases and the author cannot explain why the fix works.

I am not saying IDE are universally bad, quite the contrary. I advocate IDEs, but under two scenarios - (i) you are learning a new language (ii) you are an expert in that language. It is the overly populated middle ground, where it is used as a substitute for (a) thinking about your code or (b) knowing the language, that worries me.

<comment><USER7> If you _have_ to use an IDE to program, you're not programming in the language, you're programming the IDE.

There are many times I have to log into remote systems and all I have are nano or vi. Not even emacs. If I have IDE-dependancy, I'm up a creek without a paddle.

<comment><USER8> If you're hot-patching code in a remote environment, you have much bigger problems than "I don't have an IDE!".

I use an IDE--and for many languages, ex. Java, Scala, and C#, would say I _have_ to--because my time is worth something to me.

<comment><USER9> _I use an IDE--and for many languages, ex. Java, Scala, and C#, would say I have to--because my time is worth something to me._

For the languages you've mentioned. Java and C# do you really have any other option, but to use an IDE? Its like, goes without saying and assumed that you are and every body is programming with an IDE.

In case of Java. You must know eclipse today is nearly a part of the language and not a separate tool.

<comment><USER8> I can write Java without an IDE. It's not that hard--it just takes additional time. Valuable time that I could spend writing other code or sleeping or drinking beer.

The assumption that it would be Eclipse, however, is hilarious.

</comment></comment></comment></comment></comment><comment><USER10> > My favorite phone interview question? "What's your favorite language?" > followed by "What are it's weaknesses?"

This is also one of my favourite questions to ask when I'm interviewing someone. Unfortunately most of the time the only response I get is confused stares. Maybe this is just a UK culture thing but it feels like many people are not prepared to display critical thinking on a job interview.

<comment><USER11> I have seen so many programming languages that my only answer to the first question can be, "None".

Haskell is too restrictive, OCaml too verbose and inflexible, Java lacks closures, Javascript has weird equality semantics, C lacks garbage collection, Python lacks static typing, Clojure has too many `)))`s, Ruby is inconsistent, ... I could go on.

In the end, I just settled on a language that I have to use at work (currently Python), but I'm wishing for something better to come along...

<comment><USER12> You should try C#. It's like Java with closures (and some other nice features: [http://stackoverflow.com/questions/610199/the-art-of- program...](http://stackoverflow.com/questions/610199/the-art-of-programming- java-vs-c-sharp) )

<comment><USER11> C# is one of the most interesting languages, really. It's been developing really fast, and along with F#, it shows that MS is really putting an effort into programming language progress. However, my main concern with C# is not the language, but the libraries/ecosystem. It's so tightly bound to Windows that it hurts. There are no good cross-platform implementations, poor IDE support, and I'm pretty concerned developing for a runtime that might go away...

Now, if only MS would open-source their implementation, most of these arguments would become void.

<comment><USER13> Mono is pretty good. F# also runs on the Mono runtime.

<comment><USER8> Mono is a _great_ attempt done by great people (I did Google Summer of Code for Mono and it was a blast). However, its utility is hit-or-miss; performance is a concern relative to Java-on-Unix or .NET-on-Windows and I'm starting to find that a lot of the cross-platform usefulness claimed by stuff like MonoTouch to be a lot less than I originally bought into. I can get most of the same out of C++ (and most of the same, iOS excepted, from Java), and I know it'll be there in the next few years.

Couple that with the future of .NET itself not looking terribly bright thanks to WinRT _, and I'm personally getting more and more concerned about the viability of .NET, and implicitly Mono. I'd dearly love to be wrong, but I don't think I am.

_ \- This is one of the things about Microsoft that infuriates me. I've heard from people in Microsoft that "developers have told us they want C++"--well no shit, really, when you've jerked around .NET as much as you have, people are going to assume there's little future for the platform. Self-fulfilling prophecy.

<comment><USER7> Back around 2000 I was studying graphics programming as a hobby, and the DirectX APIs were moving pretty quickly at that time. It seemed as if a new version was dropping every 6 months. I got tired of playing catch-up to Microsoft and switched to OpenGL. Much better experience; got code running much faster.

I saw the same pattern begin with .NET; you had to keep playing catchup and buying into the New Hotness. I realized that this seemed to be a Microsoft strategy: obsolete the old knowledge and watch the developers pay money for the new hotness. I'm not saying that MS needs to be static, but there appears to _me_ to be a deep seated instability in their approach, which implies pretty heavy retraining every five years. Contrast this against C++, which has been more or less standard since the mid-90s, _especially_ for the common cases.

I get tired of running on a tech treadmill. Learning how to crap out the same concept in yet another language (much the same as the ones I already have used) has nil interest for me. I am tired of wasting my life figuring out the subtleties of a Java clone, or a C++ clone, or a Perl clone, or... etc.

I look for a stable, long-term language, on fairly stable core technologies, so I can build really _amazing_ new technology without throwing it out and restarting due to the New Hotness. I personally have picked Common Lisp for my long-term code and projects. Others might pick C++, Perl 5, or Fortran. I look over new languages and technologies as they come out and see if they have something meaningfully innovative that really merits learning and/or switching. Some do. Most don't. Haskell looks like it has a good future right now.

<comment><USER8> That sounds about right. I've gone back to Java and C++ for most of my own projects because of the uncertainty factor.

(OpenGL is a festering mess, though. DirectX is a wonderful API in comparison.)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> This story is a bit embarrassing to me, but I'll tell it anyway, I went for an interview a while ago, where I got asked a basic Javascript question ... problem is, I haven't actually written actual javascript in almost 3-4 years (not simple, but not really that hard either) ... I've been writing jQuery, which is supposed to be javascript, but I digress ...

I know how Javascript works, scoping, hoisting blah blah blah, but I haven't written a for loop, or used an actual getByTagName or whatever in a long long time ... I told the interviewer this, and they seemed cool with that, they asked me to write in pseudo code and I did that, then they asked me to convert it to javascript ... hunh?

Well, I started going through line by line and started doing just that, asking them to refresh my memory about the syntax of stuff, even how to write a for loop (yup, its amazing what spending years using jQuery.each or $.each will do to you :P). Anyway, we concluded and though I was annoyed at how out of practice I was, I thought I did okay.

Well the recruiter who set it up, called me back (very nicely I might add) and gave me the feedback on the interview. The interviewer, (who had been very nice to me too btw), had eviscerated me, writing that I displayed a lack of Javascript fundamentals ... saying I didn't even know how to write a for loop.

I don't blame them, because we clearly shouldn't have been talking in the first place, they were obviously looking for a hard core Javascript guy ... and not person who could just build complex front end UIs & interactions using backbone/ember/spine/jquery/whatever, which is what I was more interested in.

But it also got me thinking about how some engineers fixate on syntax, and use it in judging other programmers, and I realized that in some circumstances it is pretty appropriate.

For example, if you're looking for a specialized dev, then that kind of stuff probably does matter; in that, it can help you spot a star very quickly ... but I also think that over reliance on it could let you miss out on people who could easily specialize to the level you want, but might not have that immediate level of familiarity with the language. But when you have to go through 100's of candidates, is that something you're willing to take the time to look out for? Should you?

Sorry for the rambling, just been thinking about it for a long time now.

<comment><USER15> You have your specialization / generalization axis the wrong way around, I think. Knowing what a for-loop looks like in a C-derived language is correlated with broad experience; once you know it in C, you know it in Java, JavaScript, C++, C#, etc. But someone who knows primarily jQuery / backbone / ember / spine etc. is much more of a specialist, not a generalist. They have deep specific knowledge of a narrow toolset, rather than broad general knowledge of a wide toolset.

That is, knowledge of language over libraries indicates generality (if you know the language and its idioms well, you should pick up most libraries fairly easily); knowledge of libraries over language indicates specialisms, because you end up a little out of your depth when not wading through the library's DSLs.

<comment><USER16> I assumed he meant a _for(obj in list)_ , not _for(int x = 0; i < foo..._.

It's pretty natural to forget the first syntax if you haven't used it in a while because there's no real standard for it across languages.

<comment><USER14> Actually its the latter ... I do a lot of python, ruby and jquery (almost exclusively), so I really can't even remember the last time I had to do a for loop.

I've done, C, C++, C# & Java so the syntax wasn't unfamiliar to me at all, and I probably could have recalled it if I had taken 2 minutes to do it, I just didn't think it would be a big deal to ask so I could get on with the code.

</comment></comment></comment></comment><comment><USER17> I disagree with some parts of the post. I think good engineers have to be able to work effectively at a high "system" level of abstraction as well as at a low "compilation" level of abstraction. If you can't look at a chunk of code and know enough about the language to know that it could throw a ClassCastException, then it is quite likely that you will fall prey to other language gotchas which can bubble up and destroy the entire design of the system you're trying to build.

I don't think the current state of the art in software development has yet advanced to the point where we can just black-box away all of the entire "compilation" stuff such that it never affects the "system" stuff. I really would like that to be the case, because it would eliminate a lot of unnecessary complexity in software development.

I think asking a limited number of compiler-level questions (less than 5) in an interview doesn't take up a lot of time, and can allow you to get an idea of how much actual experience the candidate has with the language as well as dealing with nitty-gritty problems that come up while you're coding. The value and time spent are both small, so the value/time ratio is probably in the same ballpark as any other question you might ask.

<comment><USER18> I don't know. I remember problems with different classloaders, old versions of classes being deserialized, different versions of classes being sent over RMI, etc. Some of these probably resulted in ClassCastException. Some had thrown more specific Exceptions, am I supposed to remember the exact Exception that was thrown in each case? I'll probably know if you show me stacktrace. But I only know because I've encountered such problems. People working on the other end of our system would recognize different set of problems that results in this Exception or similiar.

Nano questions are bad, because you are really asking if candidate has had the exact same experience that you had. Some did, some didn't, it doesn't matter. Anybody will solve the problem within minutes, most probably googling the most promising lines of the stacktrace, and ctrl+clicking around in Eclipse (or grepping the source tree, whatever).

Even auto-importing packages in IDE can cause problems - sometimes it imports from the wrong package. Is it enough reason to ask questions about "which package contains Hibernate Session class?" or even "which package contains ArrayList class?". I don't think so. Being aware of the problems good abstractions can cause (there's always a few problems) is IMHO enough, no need to remember everything you can google in 5 seconds.

EDIT: or maybe you meant that you just check if people know casting can throw ClassCastException, with that I'm OK.

</comment></comment><comment><USER19> I for one would be grateful if an interviewer asked me this kind of question. It gives me an instant and unambiguous indication that this is _not_ a place I want to work, saving me a lot of wasted time - and God forbid if I'd otherwise actually ended up accepting a job there.

<comment><USER20> It's usually a bad sign about the interviewer's interviewing skills, not always them as a person or the team.

I have worked for some nice, amiable smart folk who interview like crazy people. It's the whole > IT skills < social skills thing.

But I empathise - I really don't like interviews which are like that, especially when they're usually a game to try and make the interviewer seem smarter than the interviewee.

</comment></comment><comment><USER21> To me, a perfect interview would be:

"Here's a coding challenge, go home, write the code to solve this, come back tomorrow and tell me three things: \- How you did it, - Why you pick this solution, - How it could be improved"

by doing this I could see how he writes code, if he's just a google copy&paster, and what's his skills in algorithm optimization etc...and specially, how he/she thinks.

Quite frankly I don't care if someone doesn't know what Polymorphism is right from his head. I didn't knew what polymorphism was until a few months ago, and yet I was applying the same principles in a lot places in my code. That's the downside of being a self-taught you don't get to know a lot of theory, but on my work I know I'm doing it right. (Also because polymorphism is a very abstract thing to be honest....)

In a nutshell, get developers who can show you their code and can it explain it, don't rely on theory, you are not hiring a college professor.

</comment><comment><USER22> I believe Any senior engineer worth his salt should be able to do lint style verification of someone else's code quickly. When I am expecting someone to be a senior enough engineer, they should be able to look at someone's code during Code reviews and find the issues in it that can lead to problems without resorting to IDE/debugging.

I do agree that nano-questions are not useful _except_ in situations where you get a resume with keyword bonanza: You know the kind, ones with every language,OS in the first page listed so that they will pass through the corporate recruiter filter. For those, nano-questions trip up but that will give me an indication to dig a little deeper into their IDE usage pattern. If they show some proficiency in it, (for e.g., tell me the command in Eclipse to find all the references to a particular method, if the answer is search in files, .. :)).

<comment><USER23> If you want to someone to do lint, why not just run lint and save on an expensive hire?

Code reviews are there to find problems with the code that are not found by trivial static verifiers and/or IDEs. This requires a level of understanding of the language and experience in reading (instead of writing) code, but has nothing to do with regurgitating keyword definitions.

Better in that case to just give a code fragment and make them spot the (algorithmic, logic, security, not spelling) errors.

<comment><USER22> Ok. I was making a point but I guess you are right about lint. I

was trying to point out that it is easy have developers write code that can easily be O(n2) vs O(n log n) because this did not use the right kind of the maps when they were initially building the code. Or I can see developers using HashTables vs HashMaps interchangeably and not see the threading impact. In these cases, some basic questions about their understanding of the classes seem to be a good indicator. Would you consider that a nano-question? I was..

</comment></comment></comment><comment><USER24> If you happen to be asked such questions it might be a good indication that the type they are looking for is code monkey. Or they are just not good enough to assess engineering skills. In both cases it's a red flag.

<comment><USER25> Yeah, basically one should always remember that interview with a company always works both ways. It's OK to ask questions or just listen to your internal BS-o-meter while talking with company reps.

</comment></comment><comment><USER26> I'm kind of on the fence on this.

These questions might seem pretty lame, but as an interviewer it does tell you something about the candidate's level of experience with a language.

If you've worked with a language for any decent amount of time. There are things that you really should know without having to look it up all the time.

This is especially true if you mention on your resume that you're an expert at something. I'm definitely going to ask you a difficult question about it and I'll expect you to answer in some depth.

If you mention you're a Java pro but can't tell me what the 'synchronized' keyword does for example. I'd be concerned.

<comment><USER27> If you are trying to hire an "expert" and ask him questions like that, you are doing it really wrong, unless you are trying to scare him away. If anything you want to actually talk to him about what he has done, about the languages, his thoughts and passion in the subject... not ask him first programming classes in college questions.

However if you are trying to hire some kind of junior-like engineer who has never had a job before, i can see why questions like this could be asked, but i still dont think it's the best way to gather knowledge about the person you are interviewings level of expertise.

<comment><USER26> Don't get me wrong. I ask all those other questions as well.

The problem is: people lie.

It's the old thing where if you want to hire a juggler, don't you want to see them juggle?

<comment><USER28> So ask the programmer to program or debug something, give him a decent IDE and access to Google. Don't ask him to answer trivia. 'Can you fix this simple 10 line function' is much less insulting.

It is a huge turn off for a lot of people and indicates that the interviewer is either too lazy to make the question interesting, or not technical enough to generate an actual good question. Either way it is a red flag.

</comment></comment></comment></comment><comment><USER29> I'm going to take the incredibly unpopular stance that nano-questions are _not_ considered harmful. It's true that only asking nano-questions, or emphasizing them, or thinking that a good engineer must necessarily be able to answer all of the nano-questions perfectly are all broken ways of thinking.

But I look upon them as a kind of FizzBuzz. I know for a fact that while you _can_ look them up in Google in 500 nanoseconds, experienced people doing hands-on work are going to be able to answer 2/3 nano-questions instantly. A few such questions sprinkled in the opening part of the interview are useful for weeding out the AbstractArchitectureAstronautFactoryFactories from the Programmers.

I'm not talking about esoterica, e.g. "What is protected inheritance in C++?" Lots of practitioners might say, correctly, that they never use it and can easily look it up if you need to know how it works. And sometimes answering esoterica correctly has negative correlation: You end up hiring people who are SmartButTooBusyPlayingWithCoolIdeasToGetStuffDone (I'm a prize example of this). But if a programmer says he's working with jQuery and I ask him to explain the difference between $('.foo.bar'), $('.foo,.bar') and $('.foo .bar'), I don't want to hear from him that he can look it up on the Internet, a jQuery programmer _knows_ the answer.

It's acceptable for someone to say, "I don't know jQuery, but I'm a smart guy, I can figure it out on the job by looking stuff up," but if he says he's been using it to build awesome HTML5 applications, I want to ask a _few_ of these questions to make sure that I'm interviewing the person described on the resumé. A working programmer will know the answer to all of them, they shouldn't be hard. Interview pressure will cause some fuzz, so I don't expect perfect, maybe get 2/3 or 3/5 right and then we can talk about composition vs. inheritance or whatever other pet "Start a conversation with a smart person" question.

I want to be incredibly clear about this: I don't think that there is some strong correlation between memorizing things and being a good programmer. I don't think programmers should rush out and memorize trivia just to "pass" an interview. I look stuff up all the time in my job. But I do think that if the questions are easy and obvious to the working programmer, a few of them are an appropriate FizzBuzz for weeding out the folks who have falsified their hands- on experience.

By and large, interview questions are a touchy subject because they serve as a kind of metric for valuing people. So when I say I think it's cool to ask a few of these questions, some folks are going to think that I say that I measure their worth by whether they know a handful of bits of information. That's not the case. I'm not saying you're unworthy if you don't memorize things. But I am saying that if you claim to have a certain type of experience, there are some questions that are going to be dead easy for you to answer, and those questions are going to help us get to the good part of the interview very quickly.

p.s. List vs Set is a funny question. I can't imagine anyone with a degree being ignorant of the difference regardless of the programming language! It's also a good lead-in to a more experiential question: "Okay, can you describe a time you've used a set of some kind? What were you trying to accomplish? ..."

<comment><USER30> _List vs Set is a funny question. I can't imagine anyone with a degree being ignorant of the difference regardless of the programming language!_

That's not what he's complaining about, though, he said that question was perfectly fair game. Because it _is_ something that, as a Java programmer, you actually need to know to do your job. Similarly, the difference between the jQuery selectors _is_ relevant, because those things actually do different things. I'd argue that even your joke example, "What is protected inheritance in C++?" is still relevant, if esoteric, because it's knowledge that could potentially be relevant to how code works and what it does.

You truly never need to know what package List or File is in, though, in the real world. If you're programming Java like 99% of the other people out there (i.e. you're not the type of masochist that thinks they can be productive in a boilerplate-heavy language like Java with nothing but a text editor), your IDE will fill in those blanks, and quite literally hide the import statements from you so you never need to think about them again (unless you mis-selected the class, in which case the fast solution is _still_ not to remember the actual package name, but to delete the offending import statement and "Optimize imports" again, this time picking more carefully rather than mindlessly selecting the first one in the list...).

That said, most Java experienced programmers would probably know that stuff like List is somewhere in java.util, and stuff like File is going to be in java.io, just from having auto-completed them so many times, so it could be a very weak filter against people that are lying about their experience. But I still don't think it's a useful question, at all - if they get it right, it _very weakly_ confirms that they're not lying, and if they get it wrong it's nothing more than a minor eyebrow-raiser, suggesting that possibly they've exaggerated their familiarity (though again, any practicing Java programmer could be very good but still be weak at the "Name That Package!" game, because it's 100% irrelevant to the job). The thing is, you'd get far more information either way by just having them rant about Java in general, or asking them to talk about what pieces of the standard library they use the most, etc.

<comment><USER31> I program Java in emacs. I work with many people who do. Of course, it's hard for me to say _objectively_ that I'm productive, but my peers seem happy with my work.

<comment><USER9> I think you deserve appreciation for showing such patience and bravery to be programming Java in Emacs.

On any other day, if the choice of eclipse or equivalents(IntelliJ etc) is not available it practically makes zero sense to deal with monstrosity and needless complexity Java has with a ordinary text editor. Even if that is Emacs. Emacs is still a text editor.

On any given day Java development makes sense only if done on a IDE. And that's nearly every Java programmer works. Exceptions exist, but they only prove the rule.

Having said all that, These days eclipse really does 90% of the coding. You job is only to tell eclipse what needs to be auto completed.

<comment><USER32> I'm in a similar position as the grandparent - Java coding in Emacs. For various reasons using a smart Java IDE is a pain in our environment (multilanguage code with Java parts). Emacs just works.

Emacs has working autocomplete from Java, especially with Semantic. It's far away from being as smart as something like IntelliJ, but it works well enough. Most functions and arguments you remember after a while. I can type much faster than I can think, so less autocomplete doesn't slow down. In fact, not having to watch if the autocomplete gets it right frees the brain to think ahead more. Maybe it's because I'm used to this.

Import statements are one of those things where you have to switch to Google, though.

<comment><USER9> I do most of my other stuff Perl/Python and any other stuff apart from Java on Emacs. Some times on Sublime Text 2.

I am now planning to shift to ST2.

Even on an editor like ST2 which is awesome anyway. You get to see what an editor is designed for. Its supposed to make 'Text' manipulation easy. So that is what it is, after everything.

So Emacs with all its power is still a Text editor, albeit a very powerful one.

Every time I work on Text editor I focus on reading manuals and understanding stuff no matter which editor that is. But with Java,IntelliJ and Eclipse its different, I just throw in whatever little is there on my mind and just wait for the autocomplete to do the magic.

Some of my colleagues go a step far. They just can't write any Java code without an IDE and I see that's the case with nearly every Java programmer I've met so far! Even in interviews. Its sort of like if you are talking of Java development its taken for granted that its is happening on an IDE. You never know, a few days from now the Java language specification my include a IDE specification.

According to me tools and languages must enable you think more than you write. Unfortunately in case of Java(and now growingly Python) you just can't work without an IDE.

</comment></comment></comment></comment></comment></comment><comment><USER33> I had a company that was ready to give me a job make me take a PHP test on <http://www.123assess.com>

After the 10th question asking me to debug 30 lines of obfuscated code in my head while a 3 minute countdown ticked away, I called it a day and decided these were people I didn't want to work for.

</comment><comment><USER34> "A good engineer thinks abstractly in terms of designing and building systems, they think in terms of algorithms, components, and engineering design. They do not necessarily know all of the details of syntax of a given language"

Precisely. I'll take someone who can think this way before someone who can rattle-off all of the minutiae about a particular language. I've run across too many programmers who don't have a clue about project organization, MVC, data representation, optimization, etc. Yet, they can pass minutiae-filled tests about a particular language.

Unless you've been programming in a single language for an extended period of time you will not have encyclopedic knowledge about that language and its libraries.

Get 15 to 20 languages under your belt and the effect is more pronounced.

I know exactly what it takes to write a number of sort algorithms, genetic solvers, neural networks, real-time embedded OS and more. No, I can't rattle off exactly how to write it in the language of the day. When switching to a language I haven't touched for a while it takes me two to four weeks to "task switch". I surround myself with reference books, use the IDE and any available online resource. Somewhere during that period I start to rock. I get the job done and produce clean and efficient code, fast.

I would probably fail the kind of questioning the article describes. Yet I've been solely responsible for large projects using languages spanning from assembler to Forth, C, C++, Verilog, Lisp and, lately, Objective-C.

Bad programmer! No doughnut!

</comment><comment><USER35> The real problem is what knowledge the question is supposed to test - is it testing whether you know the answer to the question, or is it testing something else altogether?

Put another way, the problem is less the specificity of the questions and more the ease with which you can expect to earn them.

I haven't used Swing/AWT in two years, and I couldn't really tell you what inherits from what. But after a weekend of breaking through the rust, I'd get back into it, so it's of no consequence to any potential employer.

However, some language-specific questions are very telling. For example:

        How many arguments does type() take in Python?[1]

If you answer '1' or 'either 1 or 3', that tells me two very different things about you. The latter tells me that you may understand that Python uses prototypical inheritance, rather than 'pure' class inheritance, and it tells me that you may have done a non-trivial amount of Python metaprogramming before. If you understand Python's inheritance structure in this way, you're a much more valuable candidate to some companies than you are for simply knowing syntax errors and interpreter-specific quirks... and the opposite may be true at another company).

(Of course, it's possible that you know that and have simply forgotten, or were confused by the phrasing, etc. - no question is perfect, but after enough of these, you start to piece together a picture of the candidate).

The point is, the former question is something that you can reasonably learn during a training period and which asks little more than face value. As for the latter question - you all know that now, so you can also learn it during a reasonable training period. But actually applying that knowledge (which comes with the followup questions) is something that would require a significant level of familiarity with the subject in question, which is what they are really trying to get at.

[1]This may not be the best wording for the question, since it tips the interviewee off to the trick beforehand, but I can imagine a way to present this question so that it wouldn't.

<comment><USER36> My standard approach to the "determining their depth" problem is to give them a problem where detailed knowledge provides an obvious (or perhaps more elegant) answer, but there are other possible answers.

For example, "how would you implement a least recently used cache in Java" can provide a wide array of answers and tells me a lot about the person's knowledge of the SDK and overall algorithm design. The details of their solution and the ensuing discussion tells me a lot more, no matter what their level, than whether they simply know that LinkedHashMap.removeEldestEntry exists.

</comment></comment><comment><USER37> This is why as a 20 year veteran of Windows C/C++ programmer I no longer bother applying for C/C++ software development contracts.

I really don't give a stuff that your Boost/STL trick question is missing a semi colon, which in reality would result in pages and pages of false compiler error messages.

I really don't want to try an second guess the compiler and tell you where the missing semi colon should go.

I use the compiler to detect my mistakes. I read the compiler output error messages, understand the message and fix my mistakes.

But I don't pretend to be a compiler. I'm a software developer. I use the tools available to me to write software.

</comment><comment><USER38> I think it is important for questions to be within the scope of the resume. If the applicant claims 20 years of Java only experience, throwing in a few of those questions is just a sanity check for that claim, especially if that claim is one of the reasons you are hiring them.

A sportswriter who claimed an expertise in basketball wouldn't feel it unfair to be asked a few trivia questions in an interview. If he didn't know how may winning seasons the Chicago Bulls had with Michael Jordan then maybe he isn't as expert in basketball as he claims.

Where these questions are unfair is when the applicant is more of a generalist. They have worked on very diverse projects in multiple paradigms and multiple languages. Their skill lies not in knowing how to use their tools, but in approaching new tools and quickly understanding how to use them. If you are a Java shop and someone comes into the interview with little Java experience then asking questions about Java specific type enforcement is going to leave them a little flustered.

Cater the interview to the applicant, not necessarily to the position. Then evaluate your understanding of the applicant with respect to the position and see how well they fit.

</comment><comment><USER39> I'm coming at this from the perspective of someone with a pretty good memory for things like this, but those particular "nano questions" seem pretty damn fair to me. They're fundamental enough that it's not really relying on random trivia; they're testing things that you need to know 90% of the time to write a program, no?

<comment><USER40> You don't need to 'know' them because you can literally find them out in 500 milliseconds. There's no value whatsoever in memorizing it. It's a useless factoid.

I use C# almost every day and if you quizzed me about what namespaces certain types are in, I'd probably get it wrong. That's not because I haven't been using it regularly for years (I have), it's because that shit isn't worth wasting brain cells on.

Even worse, though, the modern programmer ends up using a lot of languages. I have, in the past few years, had cause to write C#, Python, C++, C, Perl, JavaScript, ActionScript, PHP, SQL, Lua, Objective C, and Ruby. All for work. Each one has its own syntax, semantic quirks, standard library, etc. Out of all of the important things for someone to understand about a language - <USER2> would you care about something as unimportant as the exact namespace/package path of a particular type? Does that matter? Would you rather know whether I know the exact namespace Adobe's JSON parser lives in, or would you like to find out whether I'm familiar with the ins and outs of the ActionScript runtime?

Honestly, if you think the kind of minutiae this article mentions is a good interview question, there's no way I'd want to work for you, because you don't care about things that matter - culture, candidates' desire and ability to learn, candidates' willingness to teach others, etc.

</comment></comment><comment><USER41> Fully agree with this post, even not being a programmer 8I'm slowly asking myself why anyway...) I'm not thrilled by the prospect of answering detail questions out of my head. Things like, I already hated them back in university. Nice to check if the candidat can remember the basics, but I'd actually prefer a guy who can not only remeber them but actually use them in context. Coming more from the classical engineering fields, you don't want a guy who can write in norm script on hand written drawings, you want a guy who can use Catia (or what ever) AND can actually design good, working parts. And that actually has nothing to do with Catia skills. Nothing different to my current field in Supply Chain Management, but there I'd strongly suggest using some basic nano questions, sad as it is.

</comment><comment><USER42> On the list vs. set... This is an "easy" one if you just stick to the standard CS def, or you just know a language that has a clearly defined library offering that... But in PHP, there's technically _no difference_ between a list and a set: _An array in PHP is actually an ordered map. A map is a type that associates values to keys. This type is optimized for several different uses; it can be treated as an array, list (vector), hash table (an implementation of a map), dictionary, collection, stack, queue, and probably more. As array values can be other arrays, trees and multidimensional arrays are also possible._

<comment><USER43> _But in PHP, there's technically no difference between a list and a set_

Sure there is. In a set, you can't have repeated values. PHP arrays can. Of course, you can implement a set using a PHP array.

<comment><USER42> I'm well aware of the difference between a set and a list.

My point, which was apparently lost, is that _the underlying implementation_ of these structures is the same in PHP.

</comment></comment></comment><comment><USER44> I wonder, how would someone interview a doctor. Asking him more of theoritical questions ? Or asking him to do practicals, which I believe might be completely off the books depending on the situtation :). Anyways, there are 1) people who pass the interview very well, and cannot perform the duty on the job. 2) people who do fair on the interview, but are very well executors of the duty. 3) People who really become the backbone of the feature, and become the go to guy for everything and anything, they may or may not perform at the interview.

</comment><comment><USER45> There seems to be trend toward ever increasing absurdity when it comes to interviewing for Software Engineers. In fact some of the recent HN posting about interview techniques are verging on being a parody of the Knights who say Ni from Monty Python and the Holy Grail ("We want you to cut down the largest tree in the forest...with a Herring !!").

As the post says find the Person who is the best fit for your team/company. Everything else can and will be learned on the job if you get the right candidate.

</comment><comment><USER46> So an interviewer asked dumb questions, and sometimes they get my orders wrong at McDonalds. NEXT.

</comment><comment><USER47> I usually open with some nano questions. Sorry, but if you say you have 5 years of experience with C# but can't tell me which namespace List<T> or Stream or SQLDataReader is in, then we're done, because you're lying.

<comment><USER48> I have eight years of C# experience, and I don't really know. I think the generic list is in System.Collections.Generic or something, but no clue on the SQLDataReader. ADO something something?

I don't think I've ever written an import statement by hand, it really, really isn't important to know.

<comment><USER47> And ya' know, that would be a fine answer, "I use resharper and haven't even had to think about that in years". I would also accept "System.Collections" as a reasonable answer. You should here some of the responses I get:

What's a namespace? Uhmmm, HashTable? I don't use collections.

Also, if they can't name some namespaces I'll usually ask them what classes they're familiar with for accessing a database or opening a file. If you can't name parts of the framework you use on a daily basis by namespace of class name, you're not going to be a very _productive_ programmer.

If knowing this stuff isn't important, than I'm an expert Java programmer too. I just can't name any of the packages or classes, but I can tell you all about inheritance.

<comment><USER48> Fair enough. :)

</comment></comment></comment></comment><comment><USER49> Great post. I felt the same way recently in a few interviews.

</comment><comment><USER50> Excellent article, totally relevant, thanks.

</comment><comment><USER51> > Basically: Any question that takes 5 seconds to answer with Google is not a > good question.

Can't argue there. I haven't done a ton of interviewing in my career so far, but it is important to me to find out how the other person thinks. Being able to cite function names and package identifiers from rote is not important, at all.

<comment><USER52> From another POV, I would argue that being able to use Google-searchable resources effectively is a very important skill that should be explored more thoroughly in the modern interview process. The examples and code snippets available on the web (e.g., Stack Overflow) can save hours and hours of time (= money), particularly when the official documentation is crappy.

Coupled with that, maybe some questions would be in order about how and when you're legally allowed to use the stuff you find using Google (MIT license? GPL? Creative Commons? How do I have to attribute this stuff? Do I have to release the source?).

</comment></comment><comment><USER53> I guess it's hopeless.</comment>


Perfect Automatic Reference Counting (PARC) with no retain cycles - <AUTHOR> http://www.newlispfanclub.alh.net/forum/viewtopic.php?f=15&t=3151

<comment><AUTHOR> Someone reminded me of this post I made back in 2009 (pre Apple's ARC). I never implemented it, but maybe someone will.</comment>


Google Visualization API - <AUTHOR> http://code.google.com/apis/visualization/ <comment><USER2> Looks like an extension on the Google Charts API. Google Charts offers an incredible API, and for the low cost of free, but I'm disappointed that Google still hasn't made any inroads into offering an secure HTTPS interface.

Google actually has a secure version online that they use on internal projects, but it's been strictly hands-off for third parties until now.

</comment><comment><USER3> There really isn't a good way to do an annotated timeline without Flash?

<comment><USER4> You could use canvas or SVG, although they're less portable than Flash.

<comment><USER3> Flot plots vector graphs on "Internet Explorer 6/7/8, Firefox 2.x+, Safari 3.0+, Opera 9.5+ and Konqueror 4.x+." That sounds more portable than Flash to me.

<comment><USER4> OK, canvas is less portable than Flash but canvas plus VML kludge is more portable than Flash. Maybe Google is using Flash for the performance.</comment></comment></comment></comment>