I switched to Apple Music after Google Play, and Groove (Microsoft Music), and it's most frictionless library I used so far :-) I just don't give a damn about polishing my playlists into oblivion, I just want some selection of music, put it on my phone, shuffle. Curated playlists from Apple are the best I've seen lately.
For me this star was very confusing before I googled, but now I treat it as a cool "shortcut" to see the strongest song of the album/artist to quickly get my opinion :-)
Well, time to shred my "Samsung Chromebook", and maybe get something newer or just give up with this "gazillion of models and revisions" bullshit I hated about Windows years back :/
For me these two platforms are more-or-less the same from a user perspective. There're some cosmetic changes, like notifications are handled better on Android by bundling them, instead of pinging for every single one of them. Apps are usually on both platforms, same with games. iOS users at my work seem interested and impressed by the Nexus 6P, some consider the possibility to switch someday. But it really doesn't matter as long as the device get the stuff done, does it? :P
I have ING DiBa and it is the cheapest account ever here in Germany — they even give you a free VISA card, and free withdrawals in Germany and rest of the world. The only difference is that there's no physical office, so you have to use their website, which is good, and never had problems with it.
Same with me, I basically do 3 things on my computer: develop code, edit pictures and write stuffs. Almost all my files are in the cloud available through the browser, and the fullfledged terminal with lots of convenience tools just feels great.
I'm like 8 years into my career, and CTO-level now, and I'm happy most of the time, depending on the non-technical situation at a moment ;-) (dealing with requests from non-technicals can be exhausting sometimes :D)
From my personal experience, I can say that such teams are toxic and you have 2 options: 1) don't say anything publicly, just focus on the work, and 2) leave. If the company has a huge turnover (like the one I worked at), nobody will say anything about leaving quickly. Just be confident, you cannot lower your value as a developer and human being just to fit some bad, toxic place.
Amazon delivers lots of value to customers, and there're only two ways to do that: 1) spend shitload of money on processes and people, or 2) squeeze employees as much as possible. Sadly the 2nd option is much cheaper and "people are expendable anyway" these days.
I find the whole idea of using "writing speed" as the factor describing how good is a programmer, plainly: stupid. Honestly, you can be a mindless person making weird, overblown constructs all day, and then you can be a smart developer that thinks before writing few characters and solving the same problem. I would rather consider efficiency as the factor: process and output efficiency.
Process efficiency is how organised is the process of the development — a.k.a. getting things done. If somebody keeps shipping stuff, they are process efficient. Even if it's the smallest thing ever, just keeping the flow going.
Then there's the output efficiency — how efficient is the thing that was shipped. Is the code high quality? Is the algorithm performing well in the problem's domain? Is the code running "fast"?
I personally think that the best developers optimise their work on these two fields: they keep delivering great output code most of the time. Because what is better: lots of bad code in short time, or good code taking more time?
The "10x programmer" myth is a fallacy that boosts the rat-race mentality in programmers, believing you need to be able to solve problems with quick hacks in order to be considered "a good progreammer". But the problem is: productivity is not a constant. It's more like a tide, when it comes, it comes strong, but then it fades and you can't do anything about that. Unless you're a robot. Also, engineering is that fancy field, that often gets overly excited about short-term wins, loosing the track of the bigger picture — one programmer can do something in 15 minutes, using lots of poorly designed hacks, without any optimisation or deeper thought, which will come back to bite very soon; and another programmer might take few hours, making a solution that will be rock-solid even after some time. The short-term "productivity" is in favour of the 1st one, but in reality the 2nd one is more productive in the long run.