dranka

My comparison to waterfall was a reductionistic take on the specifications up-front before coding starts aspect. If comparing it to the full waterfall process then it is definitely a fresh take!

It sounds a bit like the Waterfall model. It became highly unfashionable in the 90s, maybe even earlier.

I miss the passive nature of the web. A page got loaded and then it was idle. Now I can stare at a page of text with my cpu spinning at 100% in the background, it adds nothing extra to my experience except for a quiet hum from the CPU fans

The TDD advocates I have been exposed to are mostly cargo culting consultants and this alone makes me very sceptical. It has some good core ideas but I find that in practice it leads to unit tests that are highly coupled to implementation details. Quick to execute but almost worthless from a test perspective. Its best to throw them out after the inital implementation is done since the usually just become a burden to maintain. Black box at system boundaries are the only tests that bring value long term in my experience. I would really like to hear more details about projects that use TDD and how they use it a few years down the line. All I can find are toy examples..

This "article" is just an ad.

I would definetly pick the store with the hacker newsish website!

I don't like people saying just hello and expecting me to answer before they get to the point. If I see the message and immediately respond hello back then I have to sit and wait and watch the 'person is writing' indication until I get the the real reason they contact me. This time is just active waiting and can't be used for anything. In the situation where I see the hello at some later time and reply back the other person might not even be there. Should I actively wait or start something else and keep an eye on the chat, prepared to be interrupted? A lose-lose situation for me..

..in my experience it can also lead to antagonistic thoughts about people who I have never met and only know through the code they wrote :)

Yes definitely. But only reading the code and looking at the history can sometimes be enough to build the picture when the same names repeatedly show up in troublesome code

If you are working on an old code base for a reasonable time I recommend to get to know the old developers. Check out the commit history, who wrote what, talk with them a bit if they are still around to get a feel for them. After a while you will probably see patterns, guy A usually wrote solid code, guy B a bit more sloppy. If you are investigating a bug in a specific area of the code use git blame and start investigating any additions by guy B first

A variant of no 3 is used for some large scale telecom equipment supporting multi millions of attached users with serious uptime requirements. State is distributed and handled locally and replicated to a sibling node for fallback protection in case a node goes down. The replication is dynamic so new sibling relationships are established when nodes come and go. There is also some more persistent state (like billing information) that is used to recover in case of total node failure but a lot of the transient state can be rebuilt when users are forced to reattach

Agree with this. I obviously comment on bugs and also convoluted code that I know will be hard to understand later. If it is just small details it is easier to just change them myself when I inevitably have to revisit the code later on rather than nitpicking and arguing during the review. If I don't have to revisit the code for any change then just let it be. Out of sight, out of mind

Seems like a common theme with the explosion of new programming related projects. Everyone wants to be innovative, why check first when it's more fun to reinvent the wheel (now done in Rust :P)

One Chinese I talked to said there are two reasons that can play into this pressure. First reason is that the grandparents probably had the same situation themselves, they were raised by their grandparents, so now they have a urge to take the parent role themselves since they never were that close when their own children grew up. Second is the age aspect, they want to do this before they get to old and tired.