bsaunder

Farmland and mines (or the minerals in them) seem to be limited world-wide and maybe good investments (though we may improve artificial ways to produce food that are less dependent on land).

Water is a regional thing (for some places it's less of a problem). Not really sure how one effectively "invests" in water.

Solar is entirely different. I think solar has a great future, but as an investment, I'm not so sure. It seems highly likely that we will needs lots more power in the future and it does seem that much of it would come from solar. Current solar technologies are still relatively young, inefficient and (relative to future technologies) expensive. Investing in solar at this point would be like investing in an car manufacturer in the early 1900s.

I have similar work experience (though no patents or start-up success credentials). I did run the Google interview gauntlet (unsuccessfully - so far) over the last year.

From my experience, it's less the on-command hypothetical coding exercises (which you will get, and they will be challenging), but more so if you pick up an unfortunate draw of one of your anti-loopers (see famous Steve Yegge post).

I ultimately interviewed in early January with a team that really wanted me, but was rejected at a late stage executive committee review (surprising even my potential hiring manager and the recruiter). While I can't say for certain the precise factors that impacted my candidacy, I'm reasonably sure a significant component was one particular on-site interview that was almost a year ago. That particular interview was awkward right from the opening non-technical questions. Not sure if my interviewer was having a bad day. I'm not sure how I was scored, but I feel it was a "B" performance for me, the others felt like "As". I will say that its sometimes hard to gauge one's on performance as the interviewers were all nice and innately would not display much signs of frustration or dissatisfaction for a candidate to get the feedback signals that might be noticeable at other job interviews.

In the end, they seem to require near unanimous consent to complete the hiring process.

For those reluctant to try, I'd strongly recommend making an initial attempt at a Google job. You'll meet some remarkably nice, smart people and have some great discussions. While I can't be certain (as I didn't succeed), you don't need to be 100% perfect on your interviews. Quick, insightful and on the right track are important though. You do need to be smart, know what you are doing, and practice a bit on programming brain teasers (which should be fun for the right person).

IMHO, its worth the initial attempt, but if things don't work out the in first round of on-site interviews, it may be impossible to overcome that in later rounds, much to my dismay. The only downside is that you might convince yourself that you really want to work there and you'll have to face reality again if things don't work out. Don't be afraid to try.

Maybe it's me (I'm sure it is - I'm no ecomomist), but a basic income seems like a perfect counter to deflation:

1. It seems like it should increase consumption as everyone would simply have more money to spend. Even if things are cheaper (and seem to be getting cheaper), you now have a new stream of income that, for some people, will burn holes in pockets and beg to be spent.

2. It would allow some employees in the labor market to "opt-out" (as the basic income supplants the "need" for a minimal wage job) and decrease the surplus labor pool. This would seem to require wage growth as employers now need to make the job proposition more compelling. Maybe they would even treat their employees better. Bonus.

3. "printing money" to pay for (or maybe just a portion of) the basic income seems like it should be a nice inflationary counter to the natural deflationary pressures.

I'm sure there are other pros and some cons of this approach, but those seem like good starting points.

Consider the wide economic effect of self-driving cars (once finally highly reliable). This one application of AI could almost single handedly push us over the edge.

The job decimation will be huge: truck drivers, delivery drivers, taxis, bus drivers, automotive insurance industry, traffic enforcement, collision repair shops, emergency services, car sales, car manufacturing (less accidents more vehicle sharing).

I'm sure it will create a few new job types, but a couple of orders of magnitude less jobs than the destruction. Hopefully the world considers this a good thing.

Honestly it seems that most people are too ignorant to see economic pain this will cause until it has happened. Unfortunately, I'm sure unions and industry groups see this train coming and will put up road blocks (pun intended) to delaying an inevitable roll out of the technology.

"In the short term, this could mean research into the economic effects of AI to stop smart systems putting millions of people out of work."

This seems unfortunate and somewhat challenging to do. Our current economic model encourages improving efficiency of systems. This seems like a good thing. Its really too bad that people "need" jobs. Jobs should be creating value or they shouldn't exist. Artificially "creating" jobs to prop up the systems feels like fighting against reality and a bad long term plan.

Great write-up. I like the perspective of a 30 year jump. In retrospect it feels like we are lobsters slowly boiling. When looked at from a distance, these observations become much clearer.

> It's time to be using all of those high-level languages that are so fun and expressive

I think for most of us, programmer efficiency is more important than program efficiency. IMHO, in these cases, there's much to be gained from the scripting languages. For many programmers though, these seem to push some comfort zones too much. There are obviously some domains were performance is still king and the high-level languages won't cut it.

> Highly optimizing compilers aren't worth the risk.

For some they sure are. Probably would have been better stated with "not worth the cost" rather than risk. I don't see much risk here, more so cost (in the terms of effort and opportunity cost). I'd rather not worry about the details of bit twiddling on things if my current problem is plenty efficient on the small n's I'm dealing with. Compilation time can be a real cost as well. I have much faster code-test cycles in scripting environments.

> Something is wrong if most programs don't run instantaneously.

I think many people don't comprehend how true this is. Its truly mind boggling to consider how many instructions a second are run these days. What could your program possibly be doing with all of them in one second? Again, for some folks there are very good answers. For most of us, its loading and initializing layers upon layers of classes. I routinely see some stack traces dozens of lines deep. I'm sure each one is providing some useful abstraction of something, but.. really?

We have a Java based application that was written without any external libraries, just straight up Java. It compiles down to a 120KB jar and provides significant real-time functionality with phone systems. Meanwhile some of our Java based web apps provide a 50MB war, but probably use every relevant Java library out there to help.

> Design applications as small executables that communicate.

Yes! I've gotten a lot of mileage out of this. Many would to well to read Eric Raymond's book: "The Art of Unix Programming". The only thing I'd like a better solution for is a nice mechanism to set-up and configure the deployment of said "small executables that communicate". I'd like programming to be as easy as building chain of commands in a Unix command line. Yet setting up a production environments with chains of commands seems a bit.. ugly.

> Don't write temporary files to disk, ever.

Once upon a time, those in the know would set-up RAM disks. These days with SSDs, it seems that's effectively what we are doing. Probably a negligible gain to use RAM over SSD. Only slight advantage of RAM over SSD I see is that things get cleaned up on a reboot (does anyone still reboot regularly?).

> Everything is so complex that you need to isolate yourself from as many libraries and APIs as possible.

I think this is behind the recent backlash against frameworks. Unfortunately, many raw languages still lack some basic utilities that make it just a bit painful to use without any libraries. Seems many people will be migrating towards unobtrusive libraries that add value in the places needed without requiring a cascading set of components and tight coupling with the application being coded. This is a good thing.

> C still doesn't have a module system?

I've got nothing here. In general, I've been migrating towards a more data driven approach rather than native code. I wish we'd start loading code modules the same way we would load a piece of data from a file or database. At the end of the day it's all the same. Obviously you need to be sure of the sources you are loading code from, but you should be protecting your data the same way.

UPDATE: Minor editing for clarity. UPDATE2: And math.

It depends a lot on unmentioned details. What's the opportunity cost for you (what are you giving up to go for a one-week trial)? Why would you think it would hurt your chances with other companies? I'd imagine they would pay you. If not, that's a bit of a red flag against the culture.

If the opportunity costs aren't too great, I'd go for it. But I'd make sure it was clear that it was a bi-directional arrangement. I'd be evaluating their culture and my potential co-workers as well to see if that would be a mutually beneficial long term solution. At the end of the week I'd be able to make a more informed decision if the work environment would work out for me.

Not sure how to deal with the compensation on that, maybe 1099 if you are in the US.

I'd look at it (as much of life) as a positive learning experience. Even if you learn nothing technically, every interaction with someone is a chance to see alternate perspectives. In the long run, that's highly valuable.

Pro tip: this should have been posted as a "Ask HN:" not so much "Help me out:". Also I believe this has been asked here before over the years. You might to well to research some of those posts.

Run externally accessible applications under a user id with no login and no ownership of the application files it's running. Make sure that the euid of the process can only write to the specific areas of the system that are absolutely necessary. This would help quarantine the system impact of remote code execution like this.

Make sure tripwire is installed/configured/monitored.

Watch for unexpected changes to public servers.

Block outbound request from publicly accessible servers (or white list them if necessary).

This would make it harder for attackers to fetch/install more tools.

Also blocking outbound requests from publicly accessible servers (i.e. from a public web server, it should be hard to make an outbound request to fetch more stuff to install).

Probably a good idea to check that tripwire is installed/configured/monitored in all the right places.

Inkscape

So I can see where Bret is coming from, many of this thoughts resonate with my ideas, but I'm not so sure there's an intentional conspiracy so much as just a simple alternate perspective that hackers have.

We naturally think of things slightly different than non-programmers. Part of the reason the tools he mention were despised by "all true hackers" is that they were limiting frameworks. We, almost by definition, tend to dislike limitations (especially when we can wield all of the power of lower level languages).

I was just pondering the other day with a co-worker, what it would be like to write a web server in xl (not sure you could, or would, but what would the mental model be like). It was an interesting experiment.

It's a similar reason to why we tend to prefer libraries to frameworks. I like code that helps me get things done quicker, but not if it enforces some mental models or comes with implementation limitations. Just yesterday I was working around a problem with a certain framework that wasn't making the right system calls the way I needed it. I knew what I wanted from it but couldn't twist the right nobs to get it to happen.

There's much that goes on in the technology world that surprises the general public that doesn't surprise people here. This is more of the same.

It's much deeper than that. A full-stack "backend" developer also understands networking and how to fully use HTTP headers as they were designed (or maybe even stretch things a bit as necessary). They understand that even though their ORM tool makes it easy to individually fetch a dozen objects from one database table, the particular method they are writing right now, will get heavily called in production and they should configure the ORM tool (if possible) or hand roll the code (if necessary) for a custom query to fetch exactly what they need in one call.

In short, full-stack developers just "get it": network, database, ui-design, system calls, OS configuration, software construction, front-end, back-end, etc. There are trade offs everywhere: risk, complexity, effort, cost. Usually solving improving conditions for one area of the system just push these trade offs to other areas. Full-stack developers get this and can help make better architectural and implementation decisions.

I think we are seeing the beginning of innovation from Silicon Valley. We are just starting to apply computers to everyday life. We've largely tackled communications. The next things seem to be more interactions between the real and digital worlds (which self-driving cars seem to be an early example of). 3D printing (and the things it enables) and more widespread robotics seem like obvious next innovations.

I think visual feedback is very important in teaching kids how to program. Several months ago, I installed Alice (v2.2) (http://www.alice.org/) for my kids to explore. They generally enjoyed it but the UI was a bit cumbersome in some respects. Looks like there's a new version that seems worth upgrading to.

In hind sight was it a good decision? Would you do it again? How are things going one year in?

Maybe not the best forum for this, but, Thanks Mike! I've been exploring d3 for a few months now. IMHO, it's one of the cleanest, most powerful JS libraries out there. The examples are great.

Pretty cool, but I wonder if the author realizes that you can steganographically encode data in any format including HTML and even JS itself.

Bonus points if you can split the steganographic data into multiple domains, where building the original message requires finding and assembling the pieces in the canvas, HTML and JS sections.

Also, I believe there may be blurring techniques you can use to smooth out the dense randomness that is a signature of encryption.

If he's right about the incentive for internal code sabotage, I wonder if this will strengthen the security perceptions of open source software. Particularly strongly curated open source software.

He somewhat alludes to this with his comment:

"No commercial vendors perform the level of code review that would be necessary to detect, and prove mal-intent for, this kind of sabotage."

I think the general difference is the location of the controller. On more traditional web frameworks, the controller is typically entirely on the server. The model twitter adopted moves the controller to the browser which just invokes services on the web server via API calls.

Not really sure "web application architecture" unambiguously indicates "client side controller", but it does in this dialog when contrasted with "server side architecture".

Here's the problem with your comment:

It's not one sided. As you point out, "Point of View is worth 80IQ points". The more productive point of view is external to both the product people and the engineer.

IMHO, I think it's wrong to think one guy "the product guy" (or the engineer) forms the vision, culture, management. A well run, modern start-up is an all-in collaboration with equal participation from all involved. Everyone contributes to these things in one form or another (each in their own sphere of influence).

Top down management is going the way of the dinosaur. Sure, someone has to be CEO, but I think things work best when they view their role guiding the organization and providing a productive environment for their fellow employees. The CEO should be "working" for the other employees as much as they are "working" for him/her.

If your view is "You, engineer, work for me, product guy", I can understand exactly why it may be hard for you to find a technical co-founder.

I'm continually frustrated by the false dichotomy presented by the mainstream media between "government cut spending"/"government spend more/go into debt".

Clearly another option is central bank bail out. I can accept that some people don't like that option, but it almost seems manipulative by the media to consistently not mention it and call it for what it is. Quantitative Easing = Printing Money. Have a public discussion of its merits.

If a problem seems hard, its because you don't have enough information or aren't seeing all possible solutions. (someone famous must have said this).

I wish this had been a root level comment (so it would be more visible). I think this is by far the most plausible explanation especially if you think about human history and technology differences.

Imagine our current spy agencies with bleeding edge technology spying on the Romans. Its only a two thousand year difference, but there's absolutely no way they could detect our signals and/or equipment (unless we made a serious mistake).

It seems entirely reasonable that another civilization may be tens of thousands of years ahead of us in technological advancement. If you consider the increasing growth rate of technological advancement, its easy to see your explanation.

The post sounds like a rant when it really should be a glowing review (if it truly was a "Great Movie") and some recommendations for improvement. Get over it. There are many better things in life to focus your energy on.

I think I read about MQL a couple of years ago. I like it a lot. Not sure how/if it fits into the REST paradigm.

While I like the standardization afforded by REST, I frequently run into some artificial limitations that are imposed on the different request methods. For example, I find that I would frequently like to pass structure information in a GET that would be more useful to send in a body (as afforded by a POST).

One prime example relevant to this article would be a GET that was effectively a query by example. So a client could basically submit a skeleton of the data that it would like.

This would let a client "go deep" on some portions of the structure and shallow on other aspects. Imagine the following GET request for that calorie counting Android App in the post:

  GET /orders/432544
  { "toppings": 
    [{ "calories": ""}]
  }

With a response that would be:

  200 OK
  { "toppings":
    [ { "calories": 100 }
    , { "calories": 25 }
    ]
  }

This would give any client the ability to ask for exactly what it wanted with different depths to the structure if necessary. While you could serialize that into a URL, that seems like a kludge. I think in general, the HTTP methods made sense for their original design, but as we move on to building more flexible, integrated data system, a more powerful flexible API mechanism may be warranted.

Programmers in successful startups (like the ones producing the demos you mention) ignore what people tell them that they can't do. They just try and they get something done. Then they iterate as long as "the demo's ui sucks" is the number one problem.

Probably the designs are sourced from their experiences. Just like you, many of them have seen beautiful sites. It's not impossible to find a few you like and mix/match design elements plus some of your own originality to produce your own variant.

Vibe could address some of these concerns (and maybe already has done so) by encrypting the communications and blurring the time and the gps coordinates in the client prior to sending the data. Then server logs and network logs wouldn't line up with the application reported data. Additionally they could insert a random delay in the posting of any message so that it wouldn't be clear which application message went with which server communication message.