cpprototypes

Remote from anywhere in the world has a lot of issues. The benefits are well known. Time flexibility and it forces management to focus only on results. However, doing face to face meetings is extremely difficult due to distance. Even tools like skype and hangouts are not effective when big time zone differences exist. Face to face communication has a lot of advantages and it's missing in this kind of workplace.

Forcing everyone to be in the office everyday also has a lot of issues. Going to the office and staying 8 hours or more regardless of productivity is a waste of time. There is also the wasted time commuting and it allows management to be lazy by focusing on hours in the office instead of actual results.

Allowing remote anytime anywhere, but hiring only within 50 miles of the office has the advantages of both. Face to face meetings are easy to schedule since everyone is only 50 miles away or less from the office. There are no time zone issues so skype and hangouts are very effective. It also allows all the flexibility of working remote.

http://www.nytimes.com/interactive/2014/08/13/us/starbucks-w...

There could be a lot of turmoil in the next few decades as society adapts to this new world of increased automation.

I think the culture is a far bigger issue than the language. Java is good when used properly, especially with the Java 8 updates. I don't think it's fair to blame Java for the culture issues. During the 90s and early 2000s, an "enterprise" culture formed using Java. However, that culture used Java because it was the new, popular language at the time. If Go or C# or Scala was released back then and had the same position as Java, that culture would've also produced very bad code in those languages.

Fortunately, the Java culture seems to be changing. There is now a more noticeable division between the old style "enterprise" Java code and newer, modern, and simpler ways of using Java.

These days it's important for a developer to know one static language and one dynamic language well. And that doesn't mean just knowing the syntax. It also includes learning the idioms and best practices in those two languages. The actual combination doesn't matter. It can be Java/JavaScript, C#/Ruby, C++/Python, Haskell/Closure, etc. For example, I focus mostly on Java and JavaScript because I use one for server and the other for front end. My JS knowledge made it easy for me to understand the lambda addition in Java 8. My Java knowledge allows me to understand the advantages of optional typing such as Typescript and Flow.

I've seen Java-only developers struggle with lambda in Java 8 because they've never written functional style code. And I've seen JS-only developers fail to understand how optional typing could be helpful because they've never seen the power of static typing in IDEs.

I used to dabble in languages, but I don't have time for that anymore. I've found that focusing and keeping track of changes in Java and JS are enough for me. JS is changing with ECMAScript 6 and includes good ideas from other dynamic languages such as Python. I'm hoping that Java starts to get some of the best ideas from Haskell and Scala.

LA is currently investing a lot into building more light rail infrastructure. However, regardless of how much LA invests in rail, for most commuters the rail will only get them most of the way to their workplace. Before UberX and Lyft, the only options for the last leg of the trip were bicycle (which has a lot of limits), bus (too unreliable), and taxi (too expensive).

UberX and Lyft provide an option that didn't exist before. And it's cheap and reliable enough to a be a very good option. As LA continues to build more rail, I think it has the potential to greatly change commuting in the future. Maybe it will become common for young single people to not own a car and rely on Uber/Lyft combined with rail. And then when they get married and have kids, then buying one car makes sense. The result would also greatly reduce traffic and air pollution.

The key is balance and part of growing up is recognizing where hard work should be focused on. Parents can help their kids with this by observing what they're good at. And it can also help teach an important life lesson which is knowing when to cut your losses and move on.

But this discussion ignores the third component of success which is opportunity (luck). Hard work and talent are useless without the chance to do something with it. It's important to teach this as well since without knowing this, you could have adults who are hard working and know what to focus on, but just wait for opportunity to come to them. Opportunity is a dice roll and you have to keep going out there and rolling that dice until you get a good one. And I think knowing this teaches humility as well which is important for social cohesion. Some people just get a lot of bad rolls and society should help in such circumstances.

1) Each jump becomes less and less. There's an invisible salary cap for software engineers. By the time a software engineer is in their 30's, they've jumped a few times and are already close to the maximum.

2) There are costs associated with switching jobs. There's a risk that the new job could be far worse (team, boss, culture, etc.). And you start at zero reputation and connections at a new company. The lack of reputation often means less flexibility and influence since the others at the company don't trust you yet. The rewards are greater than the costs in the 20's, but usually not in the 30's.

3) It also happens to be the time when many get married and have babies. This increases the risk factor.

4) For total compensation there seems to be two tiers of companies, the top tech (google, facebook, amazon, etc.) and everyone else. I've noticed the big difference is not the base salary (top tech only pays a few % more). The really big difference is cash bonus + stock (RSU).

5) Unfortunately, the interview skills required to get into the top tech companies is biased against older software engineers. For an engineer in their 30's college is a long time ago. They could spend time getting algorithm books and studying, but there's less free time at this stage in life. So the only big jump that's worth it financially (top tech company) is very difficult to do.

  DBObject r = collection.find(query);

  for (int x=0; x < 100000; x++) {
    new Thread(() -> DBObject r = collection.find(query))).start();
  }

  for (int x=0; x < 100000; x++) {
    new Fiber(() -> DBObject r = collection.find(query))).start();
  }

  No one likes working on a problem with someone watching them constantly.

The effect is not limited to physical presence, it can also happen over a phone interview with screensharing. Consider all these thoughts that a candidate is probably thinking while trying to solve the problem:

What's this person thinking? Am I working too slowly? Should I type code faster? Is this solution what he/she is looking for? Should I talk more? I'm not sure what to say, ok stop panicking, just focus on the problem. Should I say I'm focusing on the problem?

The problem is not the whiteboard. The problem is that there is someone constantly looking at the whiteboard.

The solution is simple and I'm surprised that I've never seen a company try it.

Give the candidate a big whiteboard or a laptop with no network connection. Give a problem and leave the room. Come back later. When depends on the size and scale of the problem. Put the code on a projector and get other engineers in the room. Now discuss the code. Run the code through some sample data. Make some criticisms and see how the candidate defends their decisions. It's like a long code review session. Digressions are ok. Maybe talking some data persistence will lead to a discussion about caching. Maybe asking why the candidate did something will lead to talking about concurrency.

A bad candidate can't BS through this. They wrote the code, they have to either explain or defend it. And the way they talk about things also gives a chance to show their level of experience. The way a junior dev talks and a senior dev talks is very different.

The key thing is, let the candidate have some time alone to work. Stop pressuring them with having an engineer there constantly. The engineer doesn't like it because they would rather be working on something. The candidate doesn't like it because it's stressful. And there's no benefit to having someone there constantly. You don't need to hear their thought process in real time. You don't need to see the iterations they went through before the final solution. If you really want to know, you can find out all these things in the discussion session afterwards.

Android does not have any of this (http://developer.android.com/reference/packages.html) because the Apache Harmony project died before it could implement Java 7 API changes.

This is a much bigger issue for Java 8. Just supporting only Java 8 syntax changes greatly reduces the benefits of the new lambda and default methods. Much of the power of the changes, especially lambda, require the changes to the collections API.

- Fast refuel time (Only a few minutes to fill a tank)

- Ubiquitous (Gas stations everywhere)

- Standardized (Gas station nozzle works in any car)

EV is currently very weak in these areas. Recharge time is orders of magnitude longer than filling a gas tank. The common expected use case is to charge at home overnight, but this excludes a huge fraction of the population (anyone living in an apartment/condo). Apartment owners have little incentive to install chargers. And there's a standardization problem. Nissan Leafs cannot charge at Superchargers. There's a lot of fragmentation in this field.

The fuel cell cars are avoiding these issues and they may take a lot of the market that EV currently doesn't serve well. Hydrogen stations are often publicly funded and not tied to a specific auto manufacturer. Refuel time is similar to gas stations. And they are slowly building more and more hydrogen stations (in California). It seems California is being used as a test market for fuel cell cars. If it succeeds, then there could be a strong nationwide push. To someone living in an apartment/condo, fuel cell cars have a lot of advantages.

Many assume that the EV is the successor to the ICE vehicle. But that may not be true.

And random apps on the app store from unknown developers? I trust those even less. I may install one if the list of permissions is very restricted and reasonable. But I don't like spending time looking at the permissions and trying to figure out if it's ok.

Another example is banking apps. I remember there was news a while ago that many banking apps were not handling passwords properly. If I use the web, I can see the SSL lock icon, inspect the certificate, and know that it's properly handled. I can't do that for a native app.

"a) never cold call each other’s employees; b) notify each other if making an offer to an employee of the other company, even if that employee applied for the job on his or her own without being recruited; c) any offer made would be “final” so as to avoid a costly bidding war that would drive up not just the employee’s salary, but also drive up the pay scale of every other employee in the firm."

I think it's clear how this would affect wages.

For example the OS desktop metaphors could finally be taken to the next level. Files, recycle bins, folders these were mapped concepts in the 80s to try to transfer the office to a 2D computer screen.

But now we can simulate a true desktop. Imagine you enter a room, a nice wooden desk in front of you. On the desk are documents that could be web pages videos word docs anything. You touch it and a floating screen appears to display contents. To your right is an infinite capacity filing cabinet. A trash bin under the desk. Its like the real world but without the limits of the real world.

Another interesting effect is memory. I remember reading somewhere that in ancient times they would memorize lots of data by imagining walking through a house. As you walk you would place relate objects like a closet to the item you want to remember. In this way you memorize the data and its order. This is where the phrase "in the first place...and the second place..." came from.

And its something I've noticed in real life. My desk looks like a mess except to me. There's a order to it I understand and I can find things. A similar thing happens with the mess of icons on my desktop. I can often find something because I know I put it in some folder on some place on the desktop. But in both the real desktop and my windows desktop I sometimes need help finding things and use the search tool.

The VR desktop can be the best of both worlds. It allows that natural chaotic organization I do with my real world desktop. But a floating search box can appear anytime to help me.

1) I understand the C/C++ -> LLVM -> Emscripten -> asm.js process. But I heard they're also working on supporting GC languages (like Java and Go). How would this work exactly? Wouldn't they first have to port the entire JVM or Go runtime into asm.js? And every time a Java/Go -> asm.js program is downloaded, it would basically also download the entire JVM/Go runtime as well?

2) Would it be possible to use GUI frameworks (like Qt for C++ and maybe Swing for Java in the future) to build GUIs and directly output to canvas?

C# is technically a superior language to Java. Combined with an excellent IDE (VS), the .NET platform is probably technically superior to the Java platform. However, .NET did not destroy Java. And it's because Java is superior to .NET in many non-technical areas (such as a better open source community). And other solutions appeared to help the Java platform with the language stagnation issue (Scala, Clojure, Groovy, etc.). Now Java itself is somewhat catching up (Java 8) and the JVM platform remains a powerful and thriving community.

The situation with Dart and JS seems to be similar. The JS language has stagnated for a long time. Google is trying to be like MS with C# and created Dart to fully replace JS. And Dart is probably technically superior to JS. But just like Java vs C#, I don't think technical superiority will be enough.

The JS platform is addressing the language issue with CoffeeScript, TypeScript, and others, just like Scala and Clojure appeared for the JVM. And JS itself is improving slowly (ECMAScript 6) just like Java 8. And the JS open source community is very very strong (all the web related libraries and frameworks and now additional strength from Node.JS) and it's unlikely Dart will have a comparable community. I think that Dart may achieve some success like .NET/C# did. However, I don't think it will destroy JS like Google hopes it will. The JS platform is just like the JVM platform. Has so many flaws, but is good enough.