cpprototypes

There is an easy solution and I don't know why so many companies can't understand this. It's simple, pay a fair amount and there will be lower turn over. Every employee should be evaluated every two years so that their salary is at least the market median. And a raise doesn't even have to match what an employee would get from switching jobs. For example, if an employee could get 10k raise by changing jobs, many would stay if given a raise half of that. The reason is, switching jobs is risky. Next job could have a bad boss, bad coworkers, etc. If offered, it would often make sense to stay at a good job and take the 5k instead of going for the 10k with unknown risks.

But instead they just give no raises, or even insult their high performers with a "generous" 3% and cause resentment and lower morale.

I agree that the current state of Node.JS is not good, however there is potential for a brighter future. The language itself is improving (such as ECMAScript 6 including yield/generators which will allow things like this https://github.com/visionmedia/co ) which should reduce the callback hell situation. Besides popularity and momentum, the language and runtimes have solid engineering talent behind them (Google, IBM, Microsoft, and others are on the ECMAScript committee and there's several big corporation supported JS engines (V8, SpiderMonkey, Chakra, etc.))

Experience matters a lot in software development. For example, after many years as a software developer this is one of the valuable lessons I've learned:

Outside data is ALWAYS dirty.

There is no clean data. And part of the value of experience is knowing how to handle this. For example, assume I get a very large data set from a third party that is crucial to my project. Unfortunately, all the fields are strings. Years of experience have taught me the following ways to deal with this:

1) Implement a lot of logic and validation into the program itself or as a pre-process step. This is a lot of work, requires a lot of domain knowledge, you may still miss a few edge cases, it will force the deadline to be pushed back, and increase the budget. However, those are the disadvantages. The advantages are that this could become a competitive advantage. Maybe no one else knows or has tried to clean up this data before. Identifying and doing this work can lead to a whole new business. A classic example of this is GIS data. GIS data is very very dirty. Street, St, St., Highway, Hwy, Freeway, Fwy, all typical examples of how dirty the data is. Companies like Navteq are based on their ability to clean up GIS data. Apple's Map app was a disaster because Google is so good at and has years of experience cleaning up GIS data.

2) Push back on the third party to clean up their data. Doing this takes some finesse and social/business skills. You can't just say, the data is hard to handle. That sounds like whining and laziness. Your manager can't do anything to help you if that's all you have. Instead one tactic is to make a schema (this is what WSDL and XML Schemas were invented for) and tell the third party that their data must conform. Then it becomes their problem. They might push back, but now your manager has something to fight with. But if they agree to conform and the schema is bad, then it will become your fault (the third party will just say, hey it conforms to your schema so that's your problem). So you better make sure the schema is good (experience helps here). And it may require meetings with the third party's technical team to compromise or figure out what a good schema is (which requires social/business skills and experience).

3) Identifying these problems early. If these data issues are not considered or found early, they will lead to big issues later. This is why senior developers get their work done fast and go home early. They don't make mistakes like using floats for currency or assuming a string is always a certain format. Junior developers make those kinds of mistakes and spend 80 hour weeks fixing it in the code, rewriting unit tests, and running scripts against the database to carefully migrate the data. They may seem more "productive" but they created the work (like the broken windows fallacy).

I think this may contribute to a trend away from mobile native apps to web apps (or web apps in native wrapper like phonegap). It's already difficult supporting iOS and Android. But what if WP and maybe Firefox OS also gain significant market share? How many companies can support 3+ dev teams for an app?

I remember a simple tactic that I used in the WoW AH to make some money:

1) Buy bulk of item X.

2) Divide item X into single units and post on AH with a markup in the price.

People would then buy it because they would need only 1 or 2 of X instead of 10. It only worked for some items and under the right market conditions, but when it worked, it was a simple way to make money. From this I learned some important lessons:

1) Convenience == profit. This is the basis of a lot of business and industry. Why do people use and pay netflix instead of downloading shows? Convenience. Why do supermarkets exist? Convenience. And this is just a specific form of a more general rule, time == money. If you can save people time (convenience) then they will pay you for that service.

2) It made me appreciate and respect more how difficult this must be in the real world. In the WoW AH, I don't have to worry about things decaying or transportation or other things. But the supermarket down the street with shelves full of food? How do they know how much to buy in bulk and sell in units before the food expires? What do they do if they're wrong? I realized that just managing the inventory at a store could be an interesting computer problem. Models, simulations, even some AI could be used to try to figure out the best decisions. And companies already do this and those that do it well have a massive competitive advantage.

Most of the articles and blog posts about Google are about Mountain View. Does anyone know if the satellite offices are good? I think I've read some good things about New York, but haven't heard much about any others.

What happens to these developers after a few years in the industry? Is there an invisible salary ceiling they hit faster than developers in non-SV areas? Or does it increase at the same rate as developers in non-SV areas? I don't live in SV so I'm curious how high a typical senior dev salary is if the junior dev salary is already so high.

EDIT: I just looked up Software Engineer III in San Jose on salary.com. The median is $108k and the upper 90% is $130k. So how can the salary for someone who just graduated be 100k+? Is that just for google and facebook? And all other companies in SV pay much less?

AngularJS is a level of abstraction above the old JQuery and Backbone style of app. It frees the developer from worrying about the tedious details of updating the DOM. For example, a typical old style app would do something like this:

  function updateCheckoutButton(cart) {
    if (cart.length === 0) {
      $('#checkoutButton').addClass('light-blue');
      $('#checkoutButton').prop('disabled', true);
    else {
      $('#checkoutButton').addClass('dark-blue');
      $('#checkoutButton').prop('disabled', false);
    }
  }

And in the HTML:

  <button id="checkoutButton"></button>

Compare that to how it would be done in AngularJS

(In the controller code)

  scope.isCartEmpty = function() {
    return cart.length === 0;
  }

(In the HTML)

  <button ng-class="{'dark-blue':!isCartEmpty(), 'light-blue':isCartEmpty()}" ng-disabled="isCartEmpty()"></button>

The AngularJS style has the following advantages:

1) Code reduction - The C language was invented to be an abstraction above assembly. Assembly code has a lot of low level details of moving values from registers, adding them, etc. The C language abstracts that away. In a similar way, AngularJS abstracts away the low level details of DOM manipulation.

2) Data binding - In the first example, it's important that updateCheckoutButton() is called wherever it's necessary for it to be called. Otherwise bugs could appear when the button is not updating when it should. AngularJS simplifies this to just listening for changes in the scope. It's possible to achieve the same thing using events, but again that's a lot of low level details of managing events and event propagation.

3) Declarative UI - <button id="checkoutButton"></button> tells me nothing about how this button behaves. The AngularJS example is immediately obvious on the button's behavior.

4) Unit testing - I can write a unit test to ensure that the value of scope.isCartEmpty is updating correctly. This test can be pure JS without any DOM support. It's much harder to test the DOM manipulation code style.

Yeah it's similar to some Java technologies, especially Spring or Guice.

I think this depends on a developer's background before using AngularJS. I've used Spring (Java DI framework) for a while and AngularJS DI was easy to understand. However, the first time I was introduced to the DI concept, it took a while for me to understand it. Some of the complaints about the difficulty of AngularJS DI could be because for some JS developers it's the first time they've been introduced to the concept.

This is a bad example. Why do that when you could just bind directly:

  <span>{{ someValue }}</span>

And in the controller JS file do

  switch (foo) {
    case 'bar':
      scope.someValue = 'hello';
      break;
    ...

If technical competency has already been established, then there should be no problem with asking these kinds of subjective questions since it's meant to screen for a subjective area (team/culture fit).

Does anyone else think like we're already in the "core 2 duo" era of smartphones? I look at my galaxy s3 and the newer phones and don't feel much motivation to upgrade.

For me, what helps a lot with tech interview stress is to already have a job. It turns the tables so that I don't really need them, they need me. The change in attitude is powerful and gives confidence.

If someone is married and has children, then it's likely they've been working for a while (for example, assuming a typical graduation at 22 and kids at 30, that's 8 years in the industry). In that situation, technical interviews require a lot of time preparation. It would require looking at old college textbooks/notes, doing practice interview questions, etc. The amount of time required is probably about the same as a "make a webapp".

I've been a developer for 8 years. I have a good job already. When I get an email from a google recruiter, I usually think this:

My free time is very limited and valuable. Google sounds interesting, but here are my options:

a) Spend my free time exploring and building small projects with new technologies and techniques. Maybe work on a mobile app that could make some money.

b) Find my old CS textbook and notes and do algorithm studying and exercises just to prepare for an interview.

Doing a) directly improves my skills and has lots of benefits. I've been able to improve projects and gain a lot of good reputation at work because of things I discovered doing a). a) could also lead to making a revenue-generating mobile app. And perhaps most important of all, a) is FUN.

Doing b) just feels like a giant waste of time. Doing b) is a direct opportunity cost of not doing a). The potential return for b) is what? Going through a day long interview with judgmental engineers trying to look smart? And it's boring. It was fun learning in college when it was the first time and I had that aha moment of understanding. Now its just boring to go over it again and again just to rote memorize things. I would rather be building or learning something new.

ES6 generators will be the solution for callback hell in node.js. Node 0.11 already has generators support hidden behind a flag (--harmony-generators) and eventually it will be enabled by default. Generators + libraries like this

https://github.com/jmar777/suspend

will make node.js code more readable.

The UI performance for your web app is impressive. Did you use any other libraries besides fastclick? Or was it a lot of manual work and research to make the UI perform well?

Apple partly helped make Samsung popular with their ridiculous patent lawsuit. It was a lot of free press for Samsung.

I just ordered through amazon, but am I too late for the 3 months? Is there any way to check?

The "Buy Now" page has two options now: Google Play and Amazon. If I buy it through Amazon, do I get the 3 months netflix? Or is it only through Google Play?

The biggest issue with public transit in LA for commuting is the last mile problem. It's similar to the "last mile" problem of fast fiber optic cables to slow copper wires to homes. Here the issue is efficient and fast rail transit to extremely inefficient bus system for that last few miles from stations to work. I once tried to plan my commute using public transit and here's what I found:

1) Drive to rail station for park and ride? About 10 minutes, great.

2) Light rail to station nearest to my work place? About 30 minutes and covers 90% of the distance, awesome.

3) Station to my work place? About 1 hour using bus system...

I'll just drive instead since even with bad morning traffic I'll still get there faster because the bus system is really really bad.

I get a bit upset when I think about it because I can get there 90%, but that last bit is ruined by the stupid bus system.

I agree that it's enough to know well one low level (or medium level) language and one high level language. For me, I decided a while ago that the two languages will be Java and Javascript. It was an easy decision since I use those languages at work, they both have healthy and growing ecosystems, and active communities.

I wish V8 already had generators back when node.js started. It would've been a true solution to callback hell. There's libraries like async to help with that, but it's not as good as something like tasks.js could be.

I have a question about asm.js. My understanding is that it's only useful for (static typed language) -> asm.js, is that correct? It doesn't make sense for (dynamic languag) -> asm.js because there's no type information to optimize with.

I have a question for you since you have a lot of experience with async. Eventually node.js will have generators (when V8 implements ECMAScript 6) which should allow node.js to have something like gevent. What kind of effect do you think this will have on the node.js world?

Just curious, what were the tradeoffs for profiling the Python code and rewriting slow parts in C vs total rewrite in Go? For high level languages, the usual argument has been to rewrite just the slow parts in C or some other low level language.

I agree, but I think the age of the language and community is another factor. Java, Python, C++, these are all old languages with decades of history and habits. Newer things like Node.js and Go have no history, no baggage to learn or avoid. I think starting in something with such a clean slate is somewhat easier because there is less ecosystem to learn.

How did you convince them to hire you when you had no professional experience? Did you have to take a pay cut to do it?

As I'm getting older, efficiency in use of time is becoming a very significant constraint. And I've found that learning a lot of languages is a waste of time. It's mostly enough to just know two types, one static, somewhat low level language (Java, C++, etc.) and one dynamic, high level language (Ruby, JS, Python, etc.) I've decided that for me, those two languages will be Java and Javascript. Not because they are vastly better than the alternatives. But for the following reasons:

1) I already have years of experience in Java. And it's not a dead field. There's Java 1.8 coming out, new libraries, frameworks etc. And there's the added benefit that I can convince my workplace to adopt these things since they use Java. That way I can efficiently use my work time to make money and learn new technologies at the same time.

2) I also have years of experience in Javascript. And I've discovered that Node.js can cover all the areas that I wanted Python to cover. It's good enough for rapid prototyping web apps, command line scripts, and quick testing of algorithms.

I came to this conclusion after time spent fighting a futile battle to become good at Python. Learning the syntax was easy, there's nothing in Python that was difficult to understand. However, I ran into the following issues trying to truly master Python or any other language I don't use at work:

1) Zero reinforcement unless I spend my own personal time doing it. At work, I'm using Java and Javascript 40 or more hours per week. And those hours are when I'm at my most alert and energetic. Python could only be at night and when I'm tired. Marriage will reduce that free time, and kids will reduce it further.

2) Zero synergy from other developers. A workplace is also a community of developers. My Java and JS skills stay sharp and increase because I can constantly talk and discuss with other developers. I learn best practices, things to avoid, trends, etc. I get none of this with Python unless again I spend personal time to do it.

3) I made some small projects with Python. But a moment came when I realized, it doesn't matter, I'll never even come close to how good I am at Java and JS with Python. It was when I read some random post somewhere about how requests library is so much better than urllib/urllib2. And indeed it is. But if I had not seen that random post, how long would I have stayed ignorant until I found out? For someone who uses Python at work, such knowledge spreads quickly. Also just staying up to date on what's happening in the Python world can help gain such knowledge. I was already spending time keeping up to date with the Java and JS worlds. I just didn't have time to keep up with Python too.

I really liked Python a lot. It's a clean and practical language. But node.js fits much better with my skills and although I like the Python language better than JS, I'm a lot better at JS and will continue to be so since I use it at work.

I guess the TLDR of this is that yes you can try to learn and become good at a language and its community of libraries and frameworks in your personal time. But it's so much more efficient to just become better at the languages and frameworks you use at work and then use that experience to become good at new technologies for that area.

Perhaps the final breaking point that lead me to abandoning Python in my personal time is when I realized, I could've spent all that time building something on the side. I could've used my existing Java and JS skills to make an app or website or anything. And I could've done it fast, quickly, and with the confidence that comes from truly mastering development tools. Instead I wasted it to gain a useless amateur understanding of Python.