HN user

lamplovin

94 karma
Posts1
Comments12
View on HN

bit of revisionist history going on here if they think that those products weren't sleek enough or stylish from the start. It was the functionality that people got used to, but those products were always relatively stylish enough to not be branded a "nerd <x>." For example, a quick google search on the first CNET iPhone review shows it was considered stylish from the start -https://www.cnet.com/tech/mobile/original-iphone-review/

The headline makes it feel like you're going to go into the dependency struggles of JavaScript tools, which you do, but not until the end of the article after mentioning struggles with database dependencies and operating system dependencies...

Seems like this is more of a rant against tools upgrading themselves and breaking previous dependencies which causes this kind of domino effect of dependency issues when trying to upgrade the initial tool, not the "JavaScript ecosystem"

I think the author should invest in learning the keyboard shortcuts and search more often. They’re great and allow me to move around slack with ease. Also reminders for things you don’t want to think about at the moment work well too

The noise issue seems tool agnostic to me, if you converse with noisy people who are sporadic with posting and put important messages in threads/channels with less visibility then you’d have issues no matter what tool you use. Does anyone ever read a company wide email longer than 1 paragraph anyway? At least with slack you can search it

The comments so far seem pretty negative, but for a pause of (what the article says) of 15 minutes I'd say that sounds like a pretty good call on the FAA's part for what reads like a moment of uncertainty with the risk of being wrong very great?

Personally I'd think 15 minutes of inconvenience would be pretty petty of me to prioritize over protection from a potential national security threat

I agree with you on language syntax choices, but as far as the articles examples are concerned it seemed like the "clever" solutions to them were more about OO architecture choices via abstraction for example. In which case, if it's not a codebase that you have experience in, then those architecture choices can get very confusing if not properly documented

Why would it be a problem to write code in a way that's easily understood by others reading it? If your code is so complicated that a little bit of documentation can't explain it or at least help get people started then you're probably being too "clever" with your code and need to simplify it a bit. Simple code doesn't mean it has to be under-engineered or non-performant, and creating a culture that doesn't take the time to help others understand what's going on is how teams get to the point of depending entirely on 2 people to do all their enhancements/fixes.