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).
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.
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.
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.
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?
I think that introverts who can fake extroversion make the best leaders. Natural born extroverts are often selfish and can't relate to others on a deeper level - Only on a superficial level (catch phrases and the like).
I think that good leaders need a high level of self-reflection otherwise they will sound like a self-absorbed, out-of-touch jerk - These people are just not motivating to work with.
Developers who say that JavaScript is bad are ones who haven't seriously used it recently. Personally, I've come to prefer (by a long shot) JavaScript's prototype-based OO over traditional class-based OO.
JavaScript is a great language with a dark past and it suffers from its legacy.
I've programmed in C/C++, C#, Java, AVR assembly, PHP, ActionScript and Python among others and I would not hesitate to say that JavaScript is my favourite.
Why are there so many NPM modules?
- Because people who know JavaScript love it. I'm yet to see the same kind of passion in any other programming community.
Yes, it has some gotchas, but so does every other language.
When used correctly, function closures are awesome! REALLY awesome. I pity the poor, poor fools who misuse them and end up with callback hell.
People mention 'callback hell' a lot, but no one talks about callback heaven.
I think cloud providers are mostly good for small/medium, fast growing startups. Big companies need more granular flexibility.
The path to vertical integration in the software indsutry is a lot smoother than in many other industries, there are many levels:
You can...
1. Make your own hardware
2. Own/manage your own hardware
3. Rent commodity hardware from a standard hosting provider
4. Use IaaS (e.g. EC2)
5. Use PaaS (e.g. AppFog, Nodejitsu)
6. Use BaaS (e.g. Firebase, PubNub, Pusher.com)
The higher the level, the more technical flexibility you lose.
The bigger the company, the more it makes sense operate at a lower level because there is no significant wastage being introduced as you move down the levels (you remove the middlemen so you can pocket their profits) and the capital cost to move between levels is relatively low.
If you compare software to another industry like cheesemaking for example, if you're a cheesemaker and you want to make your own milk, the next step is to buy the whole farm and then you have to figure out what do do with the meat (wastage). Going between these two levels is expensive and could mean doubling or tripling your expenses so it's not an easy move to make.
I think transparency is good. The secretive (and superficial) society we have now favors cheaters and liars.
If there was a way to publicly expose everyone for who they really were, maybe society would start to value those individuals who have real integrity (as opposed to greedy, manipulative, two-faced individuals). Absolute social transparency would allow power to be placed in the hands of people who are actually worthy of trust.
That said, I'm skeptical about Facebook's intentions. It looks like they just want to take people's personal information and use it for their own benefit. Their primary goal is not to make society more transparent for everyone - They just want to keep this information for themselves and keep everyone else in the dark - That way they get leverage over everyone else.
You are putting too much time into it. If you can't do something in under 50 hours per week, then you're not being efficient with your time.
I have a day job at a startup (maybe 45 hours per week) and I also have my own side project (about 30+ hours per week on top of that) - So I'm working a lot but these 30 extra hours are easy because I literally work on my laptop from my bed.
Because I know that I only have 30 hours per week for my side project, I am very careful about how I choose to invest my time.
You need to be thinking about how you can make the most of every line of code that you write. You have to reduce your project down to the simplest form that will still meet your goals. This could mean reaching a certain number of users, becoming profitable, etc...
Note that better funded competitors are always going to be able to get more work done than you will - So if you want to compete with them, you have to make sure that your product is simpler than theirs and try to use that simplicity to your advantage.
If a simple solution is just not viable in your chosen area (if you can't break your project into smaller, individually marketable parts), then you should cut your losses and choose a different area altogether.
If you have funding then you should think about hiring people to whom you can delegate some of your workload.