cpprototypes

As ad blocking increases, browser makers should add a type of "in web-page" payment system directly built into the browser. Paywalls are annoying because of friction. But imagine this instead:

  1) open page
  2) short preview and button "5 cents to read all"
  3) click button and browser opens built-in dialog similar to how appstore/play store in app purchase works.
  4) since its part of the browser, no concerns about trust or security.

This kind of frictionless and cheap paywall has the potential to replace ads. But browser makers must build it into the browser.

I think another factor is the salary sites such as salary.com, payscale, glassdoor, etc. These sites often don't include RSU in comparisons among companies. If it was included, many could see just how underpaid they are and there would be more pressure on companies.

It's unfortunate that this practice of giving almost the entire base salary amount as additional stock (RSU) has not spread outside the bay area. In other regions (such as LA, NY, Seattle, etc.) engineers only get base salary and sometimes a very small bonus. These base salaries are often competitive with the bay area, but the lack of the enormous RSU makes the total comp often 2x or more worse.

EDIT:

After writing this, I was curious how the BLS calculates wages. Here is the answer from their FAQ: http://www.bls.gov/oes/oes_ques.htm#overview

  The following are excluded from the collection of OES wage data:
    Attendance bonuses
    Back pay
    Clothing allowances
    Discount
    Draw
    Holiday bonus
    Holiday premium pay
    Jury duty pay
    Meal and lodging payments
    Merchandise discounts
    Non-production bonuses
    On-call pay
    Overtime pay
    Perquisites
    Profit-sharing payments
    Relocation allowances
    Severance pay
    Shift differentials
    Stock bonuses
    Tool/equipment allowances
    Tuition repayment
    Uniform allowance
    Weekend premium pay
    Year-end bonuses 

This means that BLS data is basically garbage for software engineers. And it's somewhat harmful, because companies probably use this trusted government data to check market rates. Even if a company has good intentions and wants to pay market rate, if they use this data they won't realize just how little that is compared to the true market rate.

99% of the blame should go to the banks and credit agency. The book The Big Short explains this well. Yes, the public participated in bad loans. But there was a natural limit to this, there's only so many people and homes. If it stopped there, the crisis would have been much more limited.

But what did banks do once they hit the limit? Invent CDO and then synthetic CDO to create "artificial" supply for the bad loans. These derivatives are what really made the crisis very bad.

Yeah, Jigsaw will provide the base primitives which will allow what I described to happen. But it's up to the Java ecosystem to create or update the dependency layer above it. I'm assuming Maven will, but if they don't this is an opportunity for another dependency system to replace it. I think fixing the version conflict issue is enough of a killer feature to overcome even something as entrenched as Maven. I'm hoping Maven keeps up with these changes because I really don't want to rebuild existing build systems.

My understanding of the practical benefits is this (someone please correct me if I'm wrong)

Java currently doesn't have true packages. There's namespacing (com.companyname.abc.xyz), but it's all on a single classpath (java -cp). Dependency management like Maven gives somewhat of an illusion of packages. The end result of a Maven build is still a bunch of jars running with "java -cp".

For example, in Maven, imagine there's a json-lib 1.0 and 1.2. Library A needs json-lib 1.0 and Library B needs json-lib 1.2. Project X is using both Library A and Library B and when Maven tries to build, there will be a version conflict between json-lib 1.0 and json-lib 1.2. There are no good options at this point because the single classpath forces the selection of one version for json-lib. The developer has to either pick json-lib 1.2 and hope Library A can run with it. Or pick json-lib 1.0 and hope Library B can run with it. This is assuming Library A and Library B are external libraries that the developer has no control over and hasn't been updated in a long time.

With packages (Jigsaw), it's possible to let both versions exist in a project. It will be possible for Library A to be a package and use json-lib 1.0. And Library B will be another package and can use json-lib 1.2. During runtime, each package will have an isolated classpath and so the dependencies won't conflict. I'm assuming the Maven developers will update Maven to do this once Java 1.9 is released.

This will remove a big headache that currently exists for Java developers. The chances of a version conflict approaches 100% as the number of dependencies grows in a project.

There is a common assumption that humans = bad drivers. And that these self driving cars will be much better than people at driving. I think this belief greatly underestimates the difficulty of what Google and others are trying to do.

Humans are actually great drivers when the situation requires thinking. Lot of snow and can't see the lane markers? Millions of people adapt every day to this during winter. Lots of pedestrians, bicycles, motorcycles, etc. doing somewhat unpredictable things? Again, look at any Asian mega city, people can adapt very fast. Basically, if the situation requires being alert, people are very good at driving.

When are people bad a driving? Whenever it's monotonous. Bumper to bumper traffic or a free flowing freeway. Constant repetition of red/green cycles while going down a suburban street. These boring situations make a lot of people basically turn off their alert thinking. Then they do other things like texting, talking on phone, etc.

And these boring situations are exactly where AI self driving is better at driving than people. Computers never get bored. The self driving car will be at 100% attention even during the most boring traffic. But when boring suddenly turns to not boring? The current state of AI is very very bad at this.

And unfortunately there's no easy way to use the best of both sides. If the AI is fully driving, then it will do great while the driving is boring. But by the time the AI decides, this is too much, can't handle this, it's too late to alert the human driver to take over. But if the human driver is required to always pay attention, what's the point of the self driving car?

Self driving cars will get there someday, but I think it's much farther away than many assume it will be.

The S3 feels like the "core 2 duo" of smartphones. Clearly not as fast as new phones, but still good enough.

For the bay area, I think compensation drop will be far worse. The base salary of bay area companies has never been that impressive. Even the big tech companies like Google and Facebook, base salary is not much more than other regions. The impressive compensation numbers are always because of bonus+RSU. These will probably be massively reduced or even eliminated completely if the tech downturn gets bad enough.

Mozilla/Firefox has a serious issue marketshare issue and it's not clear if they're aware. I'm beginning to see pages that break on Firefox or have warnings that Safari, Chrome, IE must be used. If Firefox doesn't find a way to gain or at least maintain marketshare, they risk becoming irrelevant. Since Firefox is their main revenue, this should be considered a company survival situation. But they're not acting like it.

This is what I dislike most about free wifi. It's completely lacking in security and most are not aware of the issue. the use of mobile apps makes it worse. At least with a browser, the browser will warn if something suspicious is happening. But there's no way for a user to know if a mobile app is using https and using properly (not ignoring certificate errors).

Please consider making the black bar a link. When I first saw it, it wasn't clear why there's a black bar. Especially later if the post goes to the second page.

The common factor is lack of respect for software. They did very well when focused on just hardware with simple software. For example the hardware part of robotics and very advanced features phones. But the next stage requires advanced software such as AI and the iPhone. This is an issue not just in Japan, but Asia in general. Their history had a lot of hardware success, but no major software success. In the US there is both Intel and Microsoft, major success in both hardware and software.

This is actually a competitive advantage of software engineering in the US. We have a history and culture of respecting software. This is passed down generation to generation and allowed more success like Google and Facebook.

In Asia, software is a low status job with little pay and status.

Gasoline - Audi is working on the technology http://www.audiusa.com/newsroom/news/press-releases/2015/05/...

The first version requires biomass, which means it has all the disadvantages of current biofuels. But their next goal is to remove that requirement. If they succeed, then they will have a process that only needs power, water, and CO2.

It's early stage technology and investment is probably very small right now. Why wouldn't it be when oil is so cheap. But someday the oil fields will start running dry and peak oil will truly come. When oil hits $200, $300 per barrel, the demand for this kind of technology will be immense. EV sales will increase dramatically, but many will be unable to use EV due to lack of personal garages (even Supercharger times are not enough if thats the only way to charge. And only Tesla has access to that, what about Leaf, Bolt, etc?).

A brand new hydrogen infrastructure doesn't seem to fit anywhere in the future. It's too expensive and the benefits are marginal compared to gas (a lot of legacy infrastructure) or EV (an entirely new paradigm using existing electric infrastructure).

Hydrogen cars are probably a dead end. Not enough benefit for the infrastructure costs required. I think the future options will be EV and synthetic gas. As batteries improve further, EV will have a lot of advantages. But it will only be available for those who have personal garages. For everyone else, it makes more sense to create gasoline instead of building an entirely new hydrogen infrastructure. There is already technology in early stages that can create gas from just electricity, water, and CO2 from the air. It seems refining that technology is a much better idea than trying to use hydrogen.

He is probably referring to other pollutants such as NOx. It is unavoidable to produce some amount of these pollutants in an oil combustion process. But California has shown that it's possible to get this down to a low level. Smog used to be really bad in LA. But a combination of catalytic converters, strict emissions testing, and oil refinery requirements to make cleaner burning gas has dramatically reduced smog. The oil refinery requirements make CA gas very expensive compared to the rest of the nation. But I think it's worth it for the air pollution improvements.

If cars and all the oil infrastructure didn't exist, EV and batteries are superior. They have far better efficiency and are a much more elegant solution. But all the oil infrastructure does exist and is a huge advantage for oil producing solutions. Consider asking a random person, would you rather keep your current car and use oil that has a side benefit of being carbon neutral or throw away the car, buy a brand new EV, and all the other associated costs (like upgrading the electric sockets in the garage). I think most would keep their car. And for someone living in an apartment without a personal garage, it's not even an option.

If we someday convert our deserts into massive solar energy farms, it may not even matter much that the oil technology is less efficient. There would be so much excess energy during daytime, the greater efficiency of EV wouldn't be a big advantage.

And gas engine technology itself isn't standing still. The traditional ICE engine efficiency of 25% is pathetic compared to the EV 80%. But the Prius combines both technologies and gets 40% thermal efficiency which is a big improvement. It's possible this could be increased further with more improvements in hybrid technology.

Many think that hybrids and plug-in hybrids are a bridge technology to a pure EV future. But the future may end up being a lot more similar to the present than expected. Maybe the typical car purchase in the future will be a 100 mpg hybrid with 60 mile plug-in battery range as an option. Those who have personal garages would buy the option, those who don't would not. And it would be all powered by massive solar power farms in the Mojave desert and wind farms in the mid-west. And the output from all this would be electricity and carbon neutral oil.

There's possibly a better alternative to batteries:

http://www.audiusa.com/newsroom/news/press-releases/2015/05/...

https://en.wikipedia.org/wiki/E-diesel

This type of technology can allow the extra power generated by solar/wind to be used to create oil. If this technology is developed further, I think it could be a better alternative to batteries. Imagine a desert full of solar panels creating oil with excess electricity during the day. And at night the oil can be used to either provide night time electricity or directly in the existing oil infrastructure (cars, gas stations, etc.) The oil would be effectively carbon neutral.

It's laughable to think about this now. But nature doesn't care about liberal/conservative or democrat/republication. The effects of climate change are already happening (California drought). As the effects become more obvious and clear, and the younger generation replaces the old, the political climate can change quickly. EV is simply not a general solution. People keep their cars for a long time and there's no way that infrastructure can change fast enough (for example, all the urban areas with apartments and no personal garages).

Nature won't wait for us to upgrade and change our infrastructure to be EV friendly. So what if there's a way to keep the current system but reduce CO2 at the same time? Fracking was once laughed at as not economically viable. Then it suddenly was. Technologies to make oil is now laughed at. Will it still be when oil is at $200 or $300?

The recent oil price changes made me wonder if the future of cars will be EV or continue to be ICE. It's not because of the current low price of oil. It's what caused it, which is fracking. Fracking has been known for a long time. But it suddenly became viable when oil was at $100+. And it was so successful it crashed the global price of oil.

When oil reaches $100 again, what other new technologies will be viable? What about $200, $300? This could easily happen due to decreasing oil reserves and increasing demand for a carbon tax due to climate change. Many assume that the path from here is EV.

But at $200, $300, the technologies to make oil may become viable. There are technologies right now (I think Audi demonstrated something last year) to take CO2 from the air and combine with hydrogen to make oil. This kind of technology also goes very well with renewable power like wind and solar. The big issue with wind and solar is storing excess electric generation. Most think batteries are the solution. But what about just making oil instead?

All of this works directly with the huge current infrastructure and investment in oil and cars. It even provides a much easier solution to reducing climate change than EV. Just create a government regulation that requires all gas to be at least 10% from carbon neutral source. They already did it with ethanol (E10). And if more CO2 reduction is required, they can just keep increasing the percentage mix.

When all of these technologies are viable, gas will probably be very expensive. I don't know what the number will be, but let's imagine it's $10 per gallon. That's very expensive, but is it enough for everyone to throw away their cars and buy EV? Is it enough to pay the premium for EV?

An interesting idea related to this: Would high income people pay extra to buy gas from a carbon-neutral gas station? It could be designed and marketed as an environmental/elite gas station (something much better than the usual mini-mart).

The functional style eliminates types of bugs that can happen with for loops and makes the code easier to read. For example, consider the task of removing names that start with "B" from a list. This is the for loop way:

    List<String> names = Lists.newArrayList("Alice", "Tom", "Bob", "Brandon", "John", "James", "Ben");
    List<String> bNames = new ArrayList<>();
    for (String name : names) {
        if (name.startsWith("B")) {
            bNames.add(name);
        }
    }
    names.removeAll(bNames);

And the functional way:

    names = names.stream().filter(name -> !name.startsWith("B")).collect(Collectors.toList());

The basic problem with the for loop is that you need create a temporary list to do the work. It's low level coding that requires telling the computer exactly where to put the temporary results, then what to do with it. I've seen bugs where developers accidentally return the wrong list (such as bNames in this example) or later modify the wrong one. When the code becomes more complicated, there's often a lot of these temporary variables that greatly reduce code readability and allow subtle bugs to occur.

The whiteboard is actually not the main problem, it's the other things that often come with whiteboard coding. The main problem is that these type of interviews expect you to master the skill of talking, thinking, and coding simultaneously. The reason given is to "see how you think" but there's no reason this must be in real-time, questions could be asked after allowing the candidate some quiet privacy to work on a solution. To illustrate the main issue, replace the whiteboard with a computer connected to a projector instead. The main issue is still there. A group of engineers silently sitting there, judging, watching every move, and expecting you to keep talking while thinking and coding. This is NOT how programmers work. Most programmers sit down, think about a problem silently, then try out a few quick code snippets to explore the problem, then create a design, and then begin coding.

It would be a huge improvement if companies just gave the candidate a problem, left the room, and came back an hour later. Then they can discuss the solution, ask questions about the code, etc. The key thing is, let them do some quiet alone thinking instead of having to worry about someone watching every move and expecting constant talking.

LA is working on greatly expanding rail. Denser development will slowly occur near the new stations to make walking to the station an option for some. However, LA will never have the density of NYC and so walking to a station will never become an option for most in LA.

But Uber/Lyft (especially Uberpool and Lyft Line) are potential solutions to this. I don't think they have the critical mass yet to be a true solution. But if they ever reach that point, it may become viable someday to commute to/from work by using only a mix of Uber/Lyft and rail. It's already possible today, but only for high income jobs. For this to have a big effect on LA transportation, it must become an option for middle class jobs.

It's possible that the critical mass of Uber/Lyft can only be achieved with self driving cars. Some think that self driving cars will mean the end of public transportation. But I think they will instead complement each other well. The roads are already at capacity. Self driving cars will help improve the efficiency, but traffic is like a gas, it simply fills to the new available space. It's why adding a new lane to a freeway usually doesn't help much. The main reason is that a single occupant in a vehicle that can seat 4 or more is fundamentally a very inefficient way to travel. Making the car self driving doesn't change this fact.

There is potential in the future for rail and cars in LA to work together to truly improve transportation. Uber/Lyft and self driving cars could solve the "last mile" issue of getting to/from stations. Rail can provide the high efficiency and density that freeways can never provide. I hope this is the future of LA transportation because I don't think cars alone or rail alone will be enough to truly solve the traffic issue.

The rest of the nation's attitude to California's water problem is very short sighted. I don't think most people realize how much food is produced in California. If California agriculture goes down, the result will be high food price increases everywhere. Many just have a cavalier attitude of "the market will adjust". There are big issues with just assuming "the market will adjust"

1) There is a big lag time for some crops to grow. Something like corn is no problem. But apples or anything else grown from a tree? Or any other crop that requires years of growing before it's productive? It will be many years until the California output could be matched.

2) Other places like the Midwest have potential water issues too. For example, look at the history of the Ogallala Aquifer. If a greater strain is put on the aquifer, it's possible they will also have the same water shortages that California has now.

The California water crisis is a national issue, but the rest of the nation would rather just laugh at us. The western states should be discussing serious proposals to build more aqueducts or pipelines to divert water from water-rich states to California. Maybe the Federal government could help with financing desalination plants. But this kind of cooperation isn't happening. I'm worried that what will happen is everyone will continue to just laugh at us until they go to the grocery store one day. Then they will care, but by then it will be much too late.

Node has a lot of flaws today. But, even with those flaws, it's very useful for quick prototyping (discipline is required here since it must be a true prototype which means throwing away the code) and command line scripting (for me, it has mostly replaced python for small scripting tasks). Using it in a production service is possible, but should be limited to simple services (not too much business logic and it should be IO heavy).

But there is a lot of potential in the future. ES6 greatly improves the Javascript language and it's possible ES7 or 8 will add types. If something like TypeScript becomes standard Javascript and async/await is added, the language will become a "serious" language for many developers.

I think the Node of the future will look nothing like the Node of today. When Javascript/Node gains these features, it has the potential to become a true server side language.

I think this would be a fair and effective interview system:

1) College graduate: Keep the traditional algorithm programming tech interview. But allow the use of a laptop (no whiteboard)

2) 2 - 7 years engineer: Require a github side project or give a home coding test. Interview will focus on discussing the project implementation. Also ask them to add a simple feature.

3) 7 - 15 years engineer: Ask them to come to the office and show them some bad code from the company source control. Ask them to explain why it's bad and to refactor it to something better.

4) Express route: Instant offer, no interview. Only "interview" is by a VP and it's more about trying to convince the candidate to join the company instead of the other way around.

The first 3 scale according to typical life situation and industry experience. The amount of free tend tends to decrease from college graduation to 30's and beyond. For example, a college graduate has lots of free time. Someone in their 20's has less, but still a significant amount. 30's and beyond tend to have little free time due to family responsibilities.

But the interview styles also match what they should know by that point. A college graduate doesn't know anything about real industry coding so the typical algorithm coding interview is ok. Someone with 2 - 7 years experience should be good at writing lots of code. But they don't yet have the experience to know that sometimes deleting code is better than adding more. They also don't have enough experience yet to read code well and refactor, their "code smell" sense is not yet developed and they think adding more code is the solution to everything. An industry veteran of 7 - 15 years should be able to read code well, spot all the issues, and be able to refactor into something better. These skills can only be gained after years of experience.

So the 3 interview styles scale well according to the free time they are likely to have and testing whether they've really grown as an engineer. The last one, the "express route" is reserved only by referral from the company's best engineers. For example, if the company has this tech ladder:

junior engineer, engineer I, engineer II, senior engineer, senior engineer II, principal engineer:

Then only senior engineer II or above AND being at the company for at least 3 years would be allowed to make ONE express route referral per year. The reason is that an engineer has to be in the industry for a while to meet other good engineers. And 3 years is enough to learn the company culture. This express route system effectively would give a competitive advantage over other companies. For example, imagine a very good engineer who is already employed. They are busy and don't want to go through any kind of interview process. But if they are given an instant offer, that greatly reduces the barriers for them and they are much more likely to seriously consider switching to the company. The main idea here is that good engineers have a lot of options but not much free time to interview, your good engineers should know a few in other companies, so the express route is a way to get more good engineers who would usually not consider moving because they don't want to spend time interviewing.

The software industry is broken for older engineers. Look at the typical algo/CS heavy interview today. It favors and selects for these characteristics:

1) Young, fresh graduates who still remember well the CS material. Or those who have a lot of free time and can study for these interviews (for example look at this Quora link http://www.quora.com/How-much-time-did-you-spend-preparing-f... the first reply mentions spending 28.5 hours per week for 5 weeks, which is 142.5 hours total) From a senior software engineers perspective that's a ridiculous commitment for something where an arrogant asshole interviewer can shutdown a whole onsite interview process because they're having a bad day or have some favorite question they think is the One True Question for determining if someone is a software engineer.

2) The software industry tends to overvalue youth. It has a very high salary at start, but also a very quick salary cap. And most companies have no technical ladder, and even those that do it's a joke compared to the manager ladder. All of this is not surprising. Since the industry is so heavily biased towards hiring and rewarding youth, older experienced engineers are not valued.

3) Senior software engineers have heavy pressure to leave the software field. I'm feeling this now. I'm a senior at my current place and my salary is basically capped. There would be little to no benefit going to another company. And even if I wanted to, I have a family now and don't have the free time to study for software interviews. My options are basically go into management, consulting, or start a business. I have no desire to start a business or go into consulting because I simply don't like doing those business related things. I want to be an engineer not a business person. But if I just stay an engineer, I will probably get laid off someday due to ageism. And if I'm an old engineer who is laid off, job mobility is basically gone due to ageism and the CS heavy interviews that I don't have the time or motivation to study for. So the only safe path is management. A lot of senior engineers face this decision. Which again reduces the number of mentors and experienced engineers to teach the new younger engineers.

4) And doesn't anyone notice just how wrong whole concept of studying for an interview is? There's a whole book publishing industry dedicated to technical interviews such as Cracking the Coding Interview. The technical interview has become like the SAT. Many could just study to pass it, but be horrible engineers.

I hate what Silicon Valley companies (Google, Amazon, etc.) have done to the software engineer interviewing process. It heavily favors recent college graduates and destroys job mobility for older senior engineers who have a busy life.

For example, look at the answers to this Quora question about interviewing:

http://www.quora.com/How-much-time-did-you-spend-preparing-f...

The first reply mentions spending 5 weeks of studying, 2.5 hours every weekday and 8 hours on every weekend day. That's 28.5 hours of studying every week. 5 weeks of that is 142.5 hours. And he also spent time doing mock interviews.

I have a family and as a senior engineer I'm busy with work. What little free time I have is spent keeping up with new technologies. It has been many years since college. This process is basically very hostile to most senior engineers who have years of experience. I wish more companies would recognize this and change their process.

Most discussions of FC and BEV miss the most important factor that will determine which one succeeds in the marketplace. Comparing engine efficiency, pollution, none of that matters compared to this single factor. And that factor is infrastructure.

BEV supporters often assume that everyone lives in a nice suburban home with a garage. But the reality is far from this. Millions live in apartments/condos with parking structures that contain hundreds or even thousands of cars. And there may be a trend of the younger generations favoring denser urban living instead of the suburban living of past generations. Installing a few charging ports in a parking structure that has hundreds of parking spots is not a realistic solution. Will the owners of apartments and condos be willing to install hundreds of electric plugs into parking structures? I think the answer is either no, or they would do it too slowly to determine the FC vs BEV fight.

So for the millions in this situation, there are only these options for the future. BEV battery swapping stations vs Hydrogen stations. Supercharger is too slow compared to hydrogen filling. Only battery swapping is comparable. Which infrastructure is built more quickly will determine if FC or BEV wins. Energy efficiency, pollution, none of that matters compared to this.