Your second point broadly makes sense. In fact, it's almost a truism: if you don't put time into learning, you won't have the skills necessary to be able to execute.
However, it seems detached from your first point.
If one's role is a front-end developer, is it necessary that they know about back-end development? If it is outside their intended job function, why would they need to know about it, if it doesn't get in the way of performing their job? If you are a backend developer, do you need to know about how to host your own infrastructure? Handle your own networking? Chip design? Your logic could be applied to any job function. Each level of the stack benefits from the levels below it being abstracted. We all stand on the shoulders of giants, and we're all much better for it.
Overall, I do think it's better that one has a good understanding about the various components one interacts with. Having a grasp of the overall system will come in handy. A curiosity into other parts of the system is beneficial, and likely is one of many indicators of success. However, if job functions can be simplified and superfluous context removed, why should we fault those for taking advantage of that?
This issue with "lowering the bar" and being glad that a simplification has "failed" (which, is yet to be determined), reeks to me like gatekeeping. The same logic could be applied to any job role which benefits from simplification. In an extreme example, this logic could be extrapolated to support the notion that anyone who cannot build their own machine from the ground up should never work in a programming position. What height is appropriate for the "bar"?
One thing the company I currently work for has done is to use our "corporate blog" as a directory for technical employee's personal blogs. Many of our tech team members write blog posts on their own time about technical problems they're particularly interested in. Having our corporate blog (https://codeshare.getfreebird.com/) redirect to their personal blog allows our company to highlight our team's ability and provide interesting content, while the authors get a signal boost from having their content referenced from the company's technical blog.
We're a small technical team so I'm not sure how well this scales, but it's worked out well for us so far.
This seems to be the third or so day in the past week I've had issues with GitHub around this time in the morning. They've typically been really good. I'm a bit surprised there hasn't been more talk about it on HN.
Having a password manager on mobile is needed, so I need multi-device support. I was really happy with the password manager support the last iOS included. Password entry and persistence are streamlined.
Content aside, I love the ToC to the left with clickable links. Helps prepare a reader for what information their about to consume, and provides relevant context for each section.
I've thought the same and chalked it up to 1) lack of a better way to easily gauge the ballpark value and 2) better headlines. I believe that's the way public company market caps are calculated as well, though with less of a chance of going to absolute zero.
I'm curious of the manual review process. Is this synchronous, i.e. immediately when publishing a package? Or is it after the fact, where suspicious code code have already been distributed? There are plenty UX trade-offs in either direction, of course.
I googled Dave Thomas, and was not disappointed by the images of Dave Thomas of Wendy's fame with a description of the computer programmer and author underneath.
It's a node tool built a few years ago to download the playlists of users through your command line. Might be helpful for a situation where you'd like to back up your own playlists.
You'll need to get an API key - no sure how feasible that is at this moment.
This is unfortunate. I hope you find a new place quickly - having the rug pulled out from under your feet does not seem to make for a pleasant experience.
It's an interesting look into a management team convincing itself of a better financial situation then what the actual situation was, and makes you wonder how far down the chain any indication of impending layoffs / tight financial situation traveled. I must imagine the CTO would know himself, but perhaps he was given explicit affirmation that financials would be alright for hires like this, until all of a sudden it wasn't?
SoundCloud is my go-to for music while programming. I've spent countless hours curating my likes, playlists, follows, etc. I'd be quite upset if the service shuts down, 1) for the artists that have gained large followings through the service and 2) for all the personal time spent that will in the end mean nothing.
I think I'm reiterating what has been said before, but the reposting is horrendous. It's made the listening experience quite poor from just using the activity stream. I've also been really unimpressed with the lack of track uniqueness - if 2 artists repost the same song, it'll show up in my stream twice. Even more frustrating was the lack of uniqueness between tracks & playlists, where one could conceivably listen to the same song multiple times in a row because artists would post the track and then a single-track playlist with that track inside it.
The UI is also lacking for quickly adding to playlists, etc. The simplicity was a feature, not a bug, and the power of SoundCloud has been their artist community.