jonpress

The programmer is only as good as his manager. If a 10x programmer is working under the leadership of a 1x programmer, he will probaby turn into a 0.5x (due to lost motivation). A 10x programmer in a decision-making position will actually bring up the output of all other programmers. In reality, a 10x programmer doesn't have to be fast at programming themselves, they just have to be able to foster good habits which make everyone else faster. That's why it's dangerous to promote 'fast programmers' to leadership positions. Fast doesn't mean good - In fact, most of the time, 'fast' is bad/suboptimal (especially when it comes to design decisions).

That's why I'm not a huge fan of Coffeescript or even convenience utility libraries like underscore/lodash. They save you a couple of lines or a few opening /closing braces but they make code more difficult to understand (to the average programmer) and (in the case of utility libraries) increase your reliance on reference documentation.

I generally prefer simple constructs that require multiple lines over complex one-liners. Although it depends on who is on the team. I prefer to write code that any polyglot programmer with a modest level of mastery in any specific language can understand.

Being an asshole isn't that effective. Not as effective as being a scheming, manipulative backstabber.

JavaScript is object oriented just like any other language. The difference is that it is prototype-based OO instead of class-based OO.

I would say that JavaScript's OO is actually more powerful/flexible than other languages but it is less readable and more error prone if you're not careful - For example, the fact that objects can 'borrow' a method from other object an apply it to themselves is a common source of issues for beginners.

The earth and the universe will cease to exist eventually so we might as well make the most of them.

This sounds like it could be useful if you want to have a bunch of IoT devices (possibly on the same network) which interact with each other directly without going through a central server.

In most cases though, your IoT devices do need to interact with a central authority (not just with each other). For example, if you have a web-based dashboard which displays the devices' state, it means that the devices will need to send that state to a central authority from time to time (in order to keep the web-based dashboard updated). Also, if you want users to interact with these devices from that dashboard, then the devices will need to receive commands from that central authority too.

What I'm getting at here is that in many cases, it's more practical to make all your IoT devices talk to each other through remote servers than directly with each other because usually there is an element of 'monitoring and coordination' which means that you need one or more remote servers to act as a central authority for the IoT network.

It may be more efficient to just make all the devices talk to each other through pub/sub hosted by a central authority than directly with each other... Unless your IoT devices are fully autonomous and that data doesn't need to be aggregated (which, to be fair, may cover some use cases).

Or maybe also this could be useful if this network of devices works in isolation - For example, the dashboard connects directly with your devices without needing to coordinate with external data from devices owned by other users.

Oops I forgot to add <sarcasm></sarcasm> tags around it. My bad.

I think it's important for you and your competitors to be aware of how much value you've added to society at any given time - Your company's valuation does that pretty well. It holds people accountable. I'm sick of hearing the "it's outside of my control" argument when things go bad - The moment you "lose control" of the market, that's the moment you failed. When you are a leader in your field, there is no excuse for not understanding the market - It just means you got lazy.

Wow, how did you manage to do the thoracic vertebrae? I have been trying to achieve that one for years! On the plus side, I was able to master repeated ankle cracking without refractory period - So I haven't exactly wasted my life.

Failure is the normal state of things. You should aim to be comfortable with failure. If you don't enjoy the process, then you probably shouldn't be doing it.

Most people don't succeed financially. You could make all the right moves and still not get there. It's something you have to accept. There is a lot of luck involved - Especially the first time.

Yes, socket/pipe-based IPC is more expensive than shared memory up to a point, but it's more scalable since you don't have to deal with locking (mutexes, semaphores) and the limits this imposes.

The root of the eventloop issue is not Node-specific. The real underlying issue here is that one CPU core is given too much work while others are more or less idle. Offloading some of the work to another process naturally solves this issue - It doesn't really matter that this other process is a Go program or a Node.js one - Both approaches would have solved the problem. Attributing credit to Go itself for solving the issue is disingenuous.

If you ran Go as a single thread, you would also run into similar issues. The main advantage of Go is that it makes it easier to parallelize your code thanks to goroutines and channels (a single source file can encapsulate the logic of multiple concurrent processes).

That said, I find that this 'ease of concurrency' makes Go code less readable. In Node.js, it's really easy to identify process boundaries since the child_process module forces you to put code into different files and communicate via loosely coupled IPC channels.

Most of the Node.js vs Go arguments are weak. It's surprising that Node.js is still outpacing Go in popularity in spite of all this slander.

It's a personal observation and also a big generalization. I think maybe it's because extroverts often derive their self-worth from their interactions with others instead of basing it on intrinsic characteristics that nobody else can see.

I think it was a huge mistake to announce Angular 2.0 so long before its release date. In the open source world, you should aim to release the product BEFORE you even announce its existence, not the other way around!

When you release first, you get valuable feedback from early adopters and you get an opportunity to add finishing touches without upsetting too many users.

When you announce first, you are effectively labeling your current release as stale/outdated and no one wants to build a new project on legacy technology!

As for AngularJS itself; I think it's fine structurally. I don't find it too 'monolithic' - I think it strikes a good balance.

You could use something more modular (single purpose) like React, but then you'd end up building a whole custom framework on top of it (made up of a large range of small libraries) to handle things like routing and data/validation layer, etc... Is using your own custom framework (made up of so many small <and potentially less than compatible> open source components) really better than using a single cohesive solution which is maintained externally (for free) by the open source community?