vast

Nested ternaries are horrible. They add an additional burden to think about operator precedence, which is actually a hard thing especially if you switch between languages regularly. They are harder to extend for those reasons and often it is just stupid to handle condition prerequisites outside of the nesting of an if statement.

Conditional logic is the third hardest thing just after variable naming and cache invalidation. There is no excuse to make it harder to understand.

Just yesterday I thought it is really annoying that mobile browsers put the address bar on top, even worse if it is moving in and out. That way it is impossible come close to a native look and feel. Now FF puts the address bar on bottom. Quite a suprise but I think it is a pretty smart change.

I honestly never believed that digital devices are good to take notes, especially if you have to reflect them. Digital devices distract you on so many levels, it is hard to believe people even started doing it.

I am confused. The major problem is claimed to be un/marshalling. But they take no closer looks. Advise an architecture without it just to introduce another with it.

Seems like protocol overhead will stay.

The main point here is worth a broader discussion. Part of the problem is that we tend to hide behind mental concepts that a ambiguous, incomplete or just bad.

DRY is a awful "thing" (a decree at best). In the worst interpretation it simply says "never write the same code twice". There is no balance or end to it. It doesn't have a competitor or alternative. It somewhat implies that it is always good. It doesn't define a scope where/when it should be applied. There is simply no broad agreement how to use it in practice. DRY touches multiple concepts, each too complex to put behind three tiny letters.

OP fails to make a great point, but the direction is right. We cannot take DRY and "code reuse" laws as granted. Abstractions and indirections have their downsides. It increases systemic complexity and may add dependencies. It certainly limits how easy the full system can be understood by humans.

This article was initially inspiring and interesting, but eventually I think it is a mud of "sound lies".

I like the idea that human cognition has a huge impact on our lives and it certainly has. But trying to pull off a new pradigm shift on the congnition hype train is annoying.

What is true for me is that even average software and systems we build can get insanely complex. To fix it, it is just suggested to reduce the product size, train / hire people. It is absolutely not wrong, but the narrative is. If we talk about congnitive load we should look at formalism. Yes it sounds awful. But having clear rules of yay's and nay's is when designing and evolving systems can clearly reduce cognitive load, because I cannot remember all the stuff people failed at in history.

PS: Please don't mix up fomalisms with principles.

Just accusing consultants it too simple. This mindset is prevalent in whole software culture. Think leftpad.

> He just did not worry about reinventing wheels.

That is what annoys the fuck out of me with the software community. We actually reinvent constantly but everyone praises that we never should do it. It feels like a secret master plan of a hidden lobby that want to claim novelty and creativity for themselves.

Pardon?

You totally missed minecraft?

Not at all. Linux support is developers effort and if you are serious about it you won't use wine.

I think neither extreme is perfect. I very much enjoy working closely with my peers. After a while you build a small family. Social factors are a big plus for office workers and a big risk for remote workers. But in an office I cannot work at full potential. For me it would be good enough to have occasional zero disturbance times. Sadly the occasional mode is usually harder to integrate and realise then the full mode. On top of that I highly despise communicating remotely.

This is very misleading and dodgy. GCP/GCE regions were (reportedly) affected. Gcloud apis were affected even in EU. "others" is a pretty big word here.

EUW doesn't seem to be affected.

The only point here that jumps at me is that the manager came a few weeks to late to explain the development values.

React and friends made themself show up on every party. Even if the model isn't remotely appropriate for the taks at hand, you have to argue about them. I am convinced that half the modern frontend devs don't even know how a "classic" web app could work. SPAs or frameworks usually used for SPAs are the default state and there isnn't any competitive option with a real name except jquery/ajax/html. Even talking about the latter will brand you as dinosaur in many circles.

Fun stuff here is that PHP hipsters currently gravitate towards node like runtime models. It isn't really eating the platform right now, but I see it as a risk.

Automated deployment. Even for smaller projects. Ansible for example is a python product.

Online schema change tools if you use RDBMS in production.