qwer

It does, but feature branches become pretty useless at that point. It makes a lot less sense to have a branch for something you plan to merge immediately after the first commit (though my team actually does this just to take advantage of github's PR functionality).

The pomodoro technique makes work easy to start because it's a promise to yourself that it will only be for a limited amount of time. If you break that promise to yourself by not stopping, you've lost the entire point.

Except your rspec example isn't a change to the underlying language is it? Also, Check out mocha for the JavaScript equivalent.

Also, when you use only one function of lodash, you can't call it a language, but there are chains and flows for creating powerful pipelines for collection processing.

"Made it possible", or "made it look like R"? add() vs. + is just a mild inconvenience IMO compared to the inconvenience of overloading abuse that I normally see ( like sqlalchemy IMO). I'd personally rather know what to expect from an operator.

DSLs are actually common in javascript. JQuery, one of the most popular libraries in all of javascript is mostly a DSL for DOM manipulation. Lodash/underscore is mostly a DSL for list manipulation.

Admittedly, JS doesn't have operator overloading, but I personally think that's a good thing.

These laundry lists of js warts get dragged out continually, so I really have to ask: How are you people actually developing in javascript and haven't yet discovered linters?

Linters have been around for over a decade and solve all of these issues (as they do in other languages as well). They're also easily integrated in every text editor and build system I've ever seen.

And why shouldn't the interpreter support these rules? Because a linter can do this almost as easily, and not break backward compatibility.

All of his arguments actually apply to all of javascript, and are not actually specific to node.js though.

That's a flaw in how you use node, not node itself. We run dozens of instances of node without internal process state, the need for sticky sessions, etc. You're losing a lot of load-balancing ability by not keeping this discipline too.

> You cannot write unit tests for all plausible values sent to your functions.

While this is true, static type checks do even less for this problem. Do you even create specific types for value ranges eg IntegerBetweenZeroAnd100? You're in a vast minority if so, and I'd be interested to see how tedious it is to construct all these non-native types everywhere.

> If you omit manual type checking in your code or in the respective unit test, you may miss some subtle failure scenarios.

There's generally not much that's subtle about a wrong type. If the code is executed at all, it will usually blow up. In my experience, the subtlety comes in the values.

> I personally find that type safety cuts down the number of unit tests I write by half

I just don't buy this (but then again my team goes for near total coverage). Nowhere near 50% of our tests are testing anything that would be solved by static types.

Since I unit-test the heck out of my code, this doesn't really do much for me. Unit-tests test actual values (which is where the interesting bugs come from IMO) and give me more powerful refactoring capabilities than an IDE.

The real benefit I'd be looking for is the chance to give the compiler hints to speed up execution times.

> I'm not quite as adverse to long lived branches as some seem to be, especially with CI systems that can automatically detect merge conflicts when they first occur and run automated tests on the merged code base.

This system of branching is clearly the best way to maximize large merge conflicts, if you think about it.

Let me restate this: The main reason that you branch (to avoid conflicts with other devs) is the single scenario that this system does the absolute worst at.

Conversely, if you're not having problems with this system, you never needed it in the first place.

> I never understood why some people are scared of branching.

Well this is branching (in the same way that if..else is branching), just not in the VCS. What's the advantage? This methodology can allow code to go to production for some or all users, either as dark launches ( http://agiletesting.blogspot.com/2009/07/dark-launching-and-... ) or as production code. VCS branching gives you none of that, and sometimes you need to roll things out sloooowly, either for quality control or for capacity monitoring.

> It seems to work pretty well for Linux development.

Well for example, if you're following the linux development model for webops, you're almost certainly doing it wrong. I'm sure your website doesn't have release candidates and LTS versions all at different URLs.

> As long as you merge continuously from upstream, you're golden.

This is not really true either. It's fine if you're the only one on a team following that model, but if everyone on your team follows that model, you're delaying collaboration and causing merge debt. Upstream ends up like a ghost town until someone like you dumps a week worth of work on it just before you're about to dump your week's worth too.

> I _do_ have some reservations against #ifdef-sprinkled code.

This is definitely a downside! You have to use a lot of discipline to keep this minimal and well-organized.

> How would Seth feel if I make the same amount of money as him just by sitting at home (obviously an extreme scenario from one aspect)?

That's the entire point of the article. He's saying your compensation for doing nothing at home should have no effect on how happy he is. It certainly doesn't change the actual buying-power of his income in any noticeable way.

Not only that but by finding themselves a scapegoat, management has ensured that in the future, honest mistakes will go completely unreported. These execs are clearly more interested in CYA than actual results.

None of your points are actually particularly necessary for agile. For example, I work on a team that does planning on demand (which is still many times per week) and deployments all day long, so we don't do iterations at all. Check the manifesto: Sprints aren't mentioned. We're definitely agile though.

I suggest you don't use the word Agile at all because everyone has different expectations of what it means and it detracts from good arguments about the right things to do. Agile should never be more important than doing the right thing.

And you can sell your ideas individually if they're worth doing. There's no need for an umbrella term. That will only tie the ideas together and create an all-or-nothing mentality.

Retros are my #1 as well. Retros can derive the rest of the changes that need to be made, and if you're doing them right, the team will be making the changes together.

My next two are:

#2 Never say "Agile" again. If you can't explain an idea from first principles without defending it as Agile then you're not ready to promote it.

#3 Never suggest a change that isn't a real solution to an actual major problem. You're only going to lose supporters if you're continually trying to get them to do things that don't help them.

If you do these things, you'll have a much greater chance of success, though the end result might not look anything like Scrum, XP, etc. (and that's okay).

So then there really isn't evidence is there?

And there's not going to be evidence like that any time soon. Software Developer productivity is extremely difficult to measure. It has very little to do with how busy you manage to keep yourself.

I agree. I've worked on small highly collaborative teams for the last 10 years and any time we're not in the same room, it's annoyingly and obviously less productive. I'm sure that the productivity studies are not taking this kind of work style into consideration.

Anyone who says this is a black and white issue and science has revealed the truth has somehow overlooked the long history of failed attempts at trying to measure productivity of software development teams (Most of which confuse activity with progress).

There's quite a lot more to programming than how many hours of uninterrupted typing you have.

> good communication out of the office is equally as much of a challenge as good communication inside the office

Working from home may have a bunch of advantages, but it's pretty tough to believe that it's anywhere near equal in your ability to communicate. Even if you had a permanent skype/hangouts connection, you still have a much lower fidelity communication medium than face-to-face.

That still doesn't explain how the singleton is better / easier. It just explains why it's not that bad.

My biggest problem is definitely the source maps. It took me forever to get them to "work" and while the stack traces are mostly correct, they're often off by a line number or two. This makes debugging ridiculously hard when the line numbers are just "close".

I know this might not sound like a big deal in the grand scheme of things, but I also don't think CoffeeScript really improves on js all that much, so the annoyances of source maps are just not worth it to me personally.

Composition in this sense is talking specifically about composition of objects. By definition, that's only going to be possible in languages with objects. No other paradigm achieves that (for better or worse).

npm already does this from any git repo. I have no idea why anyone would want to tie themselves to github only.

"Strong-typing vs weak-typing" is actually irrelevant. It's still an error at run-time, and unless your quality control tools and practices actually run the code (like unit tests do), you're not going to know about them.

As you move beyond native types, duck-typing (like in python) completely subverts the strong type-checks anyway.

I honestly have no idea what's so confusing. I've been working with javascript for over a decade and have NONE of this memorized, and I never look it up or check it in the repl. It's simply not an issue if you're using jshint and unit testing your code.

If you come from a static language background and you keep expecting a type-checker will save you from doing silly things like adding arrays to strings, you're always going to hate Javascript. It's a dynamically typed language, and so you have to learn the quality-control tools and practices for dynamically typed languages.

There are javascript implementations that don't go asynchronous though. Take rhino for example: http://stackoverflow.com/questions/7249252/read-file-with-rh... . Or check out the commonjs spec: http://wiki.commonjs.org/wiki/Filesystem/A#Files .

I love how few people mention Sir-mix-a-lot -- You know, the guy that actually wrote the song and popularized it. The Acoustic-version-of-hip-hop song genre is not terribly original, and even predates youtube considerably. I have a hard time feeling sympathy for either one of these cover artists.