RyanZAG

Best example are drugs like marijuana or even the limits on high fat foods - which research is now showing is not as bad as some other older research thought.

This is very much on purpose. Capital is extremely mobile and not part of a market transaction, while most labor is immobile and constrained as a market transaction.

It is easy to take tax from a labor market transaction, and this tax is borne just as much by the capital employing the labor as by the labor itself. Taking tax from capital appreciation is far more difficult - if you put your capital tax too high, the capital just moves to a different market with better dynamics.

Of course if you go overboard with your labor regulation and tax, then other labor markets are able to out compete your own labor market, and that is even worse.

Basically: you don't have free reign to decide on these labor and capital taxes and regulations. Any policy change you make is going to have consequences. You can't just say "OK, we will just double capital tax! Money for all!" and not face extreme changes in your entire base.

I'm in South Africa and watching this unfold as the socialist government continues to raise capital taxes each year, and now faces enormous foreign capital flight and lack of investment in the economy, destroying GDP growth and pushing the more vulnerable parts of the population out of jobs and into extreme debt and poverty. Believe me, you don't want that in USA just to get rid of some mythical '1% problem' that hurts your sensitivities.

Now a man might be able to deceive me by simply not disclosing this while a woman is going to have a very difficult time. But I wouldn't say this is unfair: the man is simply easier able to pass off his awfulness than the woman.

It's like saying a woman is more likely to be able to shoplift and get away with it than a man and this is unfair. I don't know if that is true, but if it is, it's certainly not 'unfair'.

Same for crypto - you need a crypto phd for a fully secure novel crypto implementation, not a cs student.

Woah you're way off here! Java is still used very heavily in new SaSS. Very very heavily. Easily in the top 5 languages used by new SaSS companies for backend servers.

How do you feel about the common case where there is one person for both coder and designer roles? This is extremely common. Your comment makes it sound like the coder and designer are always separate people when in reality, for most websites, the front end coder is the designer.

People who can't cook still get through life without that much trouble though.

So I would change your statement as well.

Free trade is a huge benefit for humanity as a whole.

Open borders may or may not be a huge benefit for humanity, as we have not tried it yet. The current economic migrant crisis will be a good starting point for an investigation and we will see if they integrate well.

However, I have seen developers who are incredible in all of those aspects and simply run rings around regular good developers. People who you can give a problem and they've already designed a fairly novel algorithm for best case complexity in 15 minutes to handle it. These people exist and they are not 1x developers, unless creating novel mathematical proofs in 15 minutes counts as 1x ....

I've seen some people read through a bug report and have the area found and fixed in a couple of minutes, and the bug passing QA first time.

I've seen other people take almost the whole day just to track down that same bug in the code, let alone fix it or get it past QA. By that time, the first guy had finished a whole stream of other tasks.

10x definitely exists - hop around a few companies and you'll come across one pretty quick. They are rare, but easy enough to find if you've been through a few startups.

If you see one of your co-workers doing 10x the work of your other co-workers at high quality, then it's much easier to label them at a 10x engineer than trying to label yourself. Objective vs subjective.

> Most of the 10x factor is most likely explained by team and company factors (process, tech stack, etc) and applies to everyone in the team/company. Intra-team variation is thus much smaller than 10x (even controlling for the fact that companies tend to attract people of equal caliber). Nature vs nurture…

Definitely not true! I have been in companies where 1 engineer outperformed 10 others with everything else being the same and on the same team. It was really obvious too. It does happen. eg, he could handle 10 bug or feature requests in the same time it took some of the other engineers to handle 1.

This is far better than simply talking to many people 1 to 1. It creates a written history indicating why each design element was chosen. It allows stakeholders to understand the requirements behind a particularly strange UX choice and allows them to give suggestions for better UX in a way that takes those requirements into account. Iteration can be faster as comments can be taken from all sides at the same time instead of having to seek people out and set up meetings.

I only see positives for a UX designer given the nature of their work is highly visual, functional and is cross-organizational. In fact, I think any company NOT doing UX design this way is probably being inefficient?

This part is really interesting considering how other tech companies put a huge amount of effort into acquiring that exact female crowd from their mostly male mid-to-upper crowd.

The article is talking specifically about "simple one-page performant servers that easily get into the 100k requests/second territory", which can see very large throughput increases with direct NIC access.

Each core can only handle a fixed number of instructions per second regardless of number of threads assigned to that core. If a core receives 100 requests, it could handle them all sequentially with 1 thread, or utilize 2-100 threads to handle them.

When using 1 thread, the first request will be completed within the minimum amount of time the core is able to do the work. The second request will complete in the same amount of time after the first.

When using 2 threads, the core will carry out the work an in interleaved fashion between the 2 threads. Both requests will complete at the same time as the 2nd request completed in our 1 thread example above.

I'll try make it clearer - assume a request takes 5 ms:

  1 Thread
    Request 1: start processing at 0ms, complete at 5ms
    Request 2: start processing at 5ms, complete at 10ms

  2 Threads
    Request 1: start processing at 0ms, complete at 10ms
    Request 2: start processing at 0ms, complete at 10ms

Throughput should theoretically remain the same if you disregard context switching time and cache invalidation. In the presence of both, the single thread method should outperform in terms of throughput as well.

How can adding a large app that sends data to Microsoft help with bloatware or security..? I've used Cyanogen a little before on certain Android devices that had tons of built in bloat and themes to slim it down a bit. I definitely wouldn't want to swap one type of bloat for another.

Time to use a different slim rom from XDA I guess?

Woah, he actually writes this off as a bad thing. The only real issue here is that he just created himself a new essential department with himself as the head. Most people would be thrilled - he needs to go approach executive leadership with a simple report on how much he is helping the company and how he needs to hire on additional help. It doesn't really matter that there are possible 3rd party solutions that would work - his solutions are already working and creating obvious value.

This is the opposite of a bad thing - he's probably just created himself a new position and massive raise. I think people talk a lot about all sorts of things missing from CS education, but clearly the best thing a school could do is shove in a bunch of business classes into the CS curriculum to prevent people thinking this is somehow a bad thing.

That said, polymer with GWT is really nice and works as well as most web things. Stuff like Angular has so many problems of it's own that it's just plain false to say GWT is obsolete when it actually solves some of the problems Angular still has.

https://drive.google.com/file/d/0BwVGJUurq6uVR1Y5anV5TC1SQkk...

https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1...

Persistent globals takes debugging a step further. We wouldn't be able to know if the globals value is being changed by another page, an earlier version of the script, etc. It would create true 'nightmare bugs'. Glad it didn't get into javascript.

> Finally, I increasingly wonder where else diseconomies of scale rule? They can’t be unique to software development. In my more fanciful moments I wonder if diseconomies of scale are the norm in all knowledge work.

They apply to every known form of manufacturing, such as vehicles or genetic engineering of vegetables (the more parts of a vegetable you try to engineer, the more difficult it gets). The author seems to have missed this, which is what I was pointing out.

And on the idea that even developing software does not have economies of scale, I present the following: Linux. Linux is what we build everything on top of. Without Linux, we'd have to start from scratch. Linux is just code. Databases are the same way. We build our applications on top of thousands of lines of code and we utilize the economies of scale of everyone building off the same code to make our code easier to create.

So I'd say that not only does software have economies of scale in distribution, it must have economies of scale in production or we would not have operating systems or databases. The issue he is dealing with is a simpler one - complexity is hard to manage.

If you manage your complexity well and create a Linux or an Apache web server, then you have economies of scale. If you create a ball of mud, you have diseconomies of scale. If you build your 1km long truck out of well designed modular blocks, you have economies of scale in transporting massive amounts of goods along flat roads. If you try to custom build the whole 1km of truck, it will be a disaster. Nothing unique to software here, and diseconomies of scale are a failure of software design, not an inherent property.

Let me try another way to explain this: if software had diseconomies of scale, then selling each successive copy of your software that you made would make all the software more expensive. Eg, if I made a computer game and sold it to 1 person, I could do it for $10. If I sold it to 10 people, I would no longer be able to afford selling it for $10 and would need to sell it for $20 (x10 = $200 total). Makes no sense right? That's because software enjoys economies of scale. If I sell 1 copy of my game and want to make a profit, I need to charge $500000 to 1 person. If I sell it to 500000 people, I can get away with charging each person $0.99. The more software I sell, the better my economies of scale become.

abrgr explains it nicely in a sibling post here.