jonpress

This guy has everything. Why is it that people feel an urge to praise him right to his face? His ego is going to start leaking out of his eyeballs.

Also, I think it takes a long time before you can judge if an engineer is really good - Many months, sometimes it takes years before you see any payoffs!

Also some engineers might not be great, but they are good at picking the right tools for the right job and as a result the whole company ends up doing well. I don't believe in 10x developers because sometimes small engineering decisions can have a disproportionally big impact on company success.

I have worked with a lot of people in a number of different companies (including a few startups) and I can think of a couple of engineers who really stood out.

When discussing engineering problems with these individuals, I never had to explain twice - Often, I didn't even need to finish my explanation and they already knew the optimal solution for that problem.

These people are impressive to work with but I think it often comes down to experience more than intelligence (but they are usually very intelligent too). When an engineer has mastered a particular set of tools/languages/frameworks, they can come up with more optimal solutions and they can do it faster.

A deep understanding of tools and techniques allows developers to look beyond the most obvious 'naive' solution to find the one which is the most suitable (using existing tools to do as much of the heavy lifting as possible).

Also, when a developer cares deeply about a particular project, they will invest more time reading about relevant technologies in their own time.

When it comes to learning new tools, most engineers are content to 'learn as they go' - That's OK, but it means that they are not as well equipped when it comes to finding that optimal solution.

I think engineers should take time to familiarize themselves with tools REALLY WELL before they start using them, especially if such a tool/framework/technology will impact the project for many years in the future.

The problem is that as requirements grow, class structures are often kept the same but the 'glue logic' which operates on these structures becomes increasingly complex (you have to handle a growing number of edge cases).

There is a point where the glue logic becomes very complex (and brittle) - At that point, the best thing to do is to redesign part of the system's class structure.

If your components (at all levels of your class hierarchy) are specific about their own behaviors, it means that you can use simpler glue logic to make them work together.

When you need to handle a lot of complex use cases, it's often useful to have many specific classes which share the same interface and can be used interchangeably.

This makes sense for backwards compatibility reasons since it fits in with the existing REST API. An alternative if starting from scratch would be to design an event-based realtime API that uses WebSocket with long polling fallback.

I usually bookmark the page then later when I have the time I will read the parts that could be useful for my project.

Meteor is monolithic in that it forces your app to be structured in a particular way - It dictates how you should handle your data and how your scripts get loaded/bundled into your app. That said, I think it's much more flexible (and scalable - In a business sense) than a closed solutions like Firebase. I think Meteor is suitable for most projects and monolithic isn't always a bad thing - There is some negative stigma around the term but it's not entirely fair. People don't go around calling Linux 'monolithic' even though it is!

I have experienced this personally in a couple of companies I worked for - Just like mentioned in the article, they had high staff turnover. What happens is that nobody truly understands the codebase and it requires many more employees to maintain. To make matters worse, it's also a self-perpetuating cycle. It's more a management issue than an engineering issue.

A lot of wisdom there. I had similar experiences with SocketCluster.

It used to be a full-stack framework (with a heavy, opinionated client-side part) but I was the only one working on it and when Meteor, SailsJS etc came along, I understood it didn't stand a chance so I pulled out the realtime and clustering features and used them to focus on just the realtime part and it picked up!

What I noticed is that the more opinionated (and more complete) your framework is, the harder it is to build a community around it.

Developers like to use custom combinations of small, SPECIALIZED tools that only handle a SMALL part of the big problem.

... Unless you're a HOT startup with crazy funding... In this case, developers will trust your product by default. Developer trust is hard to gain - If you're small, you have to play for the long term and keep reinventing and rewriting parts of your project over and over as technologies change.

Another alternative is to use process-based concurrency with SocketCluster http://socketcluster.io/ - It runs on top of plain Node.js (or io.js) - It's just a module.

I don't think people should be given special treatment because they belong to a particular group. It's not a HR problem - It's a problem with society itself. Certain groups will inevitably lag behind (in terms of number of candidates) in certain fields because of complex social factors which companies cannot really change (and maybe it's even wrong to try to change them).

There are complex social and psychological reasons why people choose to work in particular fields - I oppose the idea of using marketing to steer people into choosing careers which they have no natural interest in.

People spend most of their lives working - It's cruel for companies to manipulate them into lifelong commitments that they never really wanted.

I agree with all your arguments. I even have a project to back you up (it's Node.js multi-process based): https://github.com/topcloud/socketcluster - It scales linearly. I just ran a benchmark on a 16-core machine and was able to reach 126k concurrent 'active' virtual users sending messages ever 6 seconds. To put it in perspective, I was only able to reach 55k concurrent users on an equivalent 8-core machine using the same benchmark test.

I wrote SocketCluster. I haven't tried that yet, it would definitely be interesting to test.

They don't. You can have fewer stores than workers. In the benchmark, we could in fact do with very few stores because they are not really used. I'm sure you could fiddle with the worker, load balancer and store count to get better performance (it depends on the system's requirements).