I would prefer to channel that energy that went into writing this lengthy description into actually fixing the toolchain to at least fail with more actionable error message.
Interesting! Wikipedia says that E6B is "one of the very few analog calculating devices in widespread use in the 21st century". What are those other few?
So it is both available and consistent (but perhaps only in read your own writes way?). What is then with resilence to network partitions, referring to CAP theorm? Did they build super reliable global network, so this is never a real issue?
> If you've got all these resources just offer a full VDI which more typically prices in this ballpark.
Perhaps their solution has something specific to the browser which allows them to do it really fast and cost effective. Eg. Sending just diffs of DOM to the client.
While most of those advices (or rather tricks like go around or hire replacement and ask to train them) would work sometimes, they lack empathy and reproduceability. In fact might even be counter effective.
From my experience it works best to build good relation, give honest feedback and ask for reasons of bad behaviour. It might be because of some factor that we do not know or control (eg someone has problems at home, has different understanding of their role, are not aware of the scale of effect of their actions). Only after, if it won't improve, clear boundaries should be shown, which when overstepped would result in well defined consequences. If behaviour is noxious to the team, it is much better to let offender go early on clear notice, not as results of playing some psychological ticks on them.
> That's a nice feature. But it can put a lot of load on your backend if you paginate over 10 of thousands of items.
To prevent that, usually maximum page size is enforced on the server anyway and the client is informed about the actual page size in the metadata in the reply.
For me 'Getting to yes' was too idealistic. It is a classic and good starter but did find it that usable for me.
I was impressed though by radical approach of Chris Voss on 'Never Split the Difference'. Author is a former hostage negotiator, so there are also a lot intriguing stories included w high makes it a great read.
Not to mention that success is often fair dose of luck. But if you know it and try multiple times while correcting your mistakes, the chance is only increasing.
There is a great book by Carol Dweck - Minset. She distinguishes two types of minset in people. Fixed - who believe their capabilities are static and even when they have some success they are afraid to do more in order to not ruin the impression; and growth mindset - who believe almost everything can be developed and are not afraid to learn and try. There is a lot of research and interesting examples from businesses, social and sport in the book on the topic of thise different understandings of talent.
Majority of Polish people is pro European, however like in few other places in the world, unlucky series of events caused populists to reach to power. They used old divide and conquer techniques, seized media and manage to destroy some democratic circuit-breaker institutions. Since more then a month there are huge protests in the streets, despite covid. Worst case ee have to wait 3 years until next elections, but let's keep fingers crossed.
It is sleep paralysis. It is completely normal when it happens from time to time. Your brain inhibits muscle movements during certain phases of sleep so that you do not hurt your self. Sometimes this can get out of sync though.
Thanks for answers in this thread. I didn't really mean to have YOLO-type random access to production. I was hoping there are ways in between to bridge that gap between dev and ops in those systems, similarly how it has been done eg with SRE in more relaxed security applications.
I was hoping for some solutions on the spectrum are adopted more, like mentioned cetralized logs stripped of private data or granting temporary audited access. But it seems with legacy systems this is much harder to implements.
I believe there is an optimum balance where actually fewer mistakes could be made if both people developing and operating te system had more visibility into each other field.
As for willful fraud attempts, well you can't rule out devs would do it, so of course there should be various barriers preventing that and proper change management, but, my sampling bias aside, when I look at some recent scandals in finance, take eg Wirecard as the last one, there is more often higher management involved than devs.
I'm curious, why can't people that created the system take part in production support. You've mentioned finance, that I presume require high level of security, but at the same time there are also people on the other side, just not knowing the system first hand and perhaps having skills different from knowing how to debug software. They can see all the data and in theory modify system behavior, eg modify/install any binary. Why are thrall developers less trusted, is it some kind of logic or regulation or just "the way it has always been done" in finance?
There has been numerous research showing that money rewards led to worse outcome. That was especially true do it creative tasks. Eg curiosity, fun, purpose, development was much better motivation.
Of course in real life job situation good money has to be on the table. But once they are are there, international motivators make all.the difference. I recommend https://en.m.wikipedia.org/wiki/Drive:_The_Surprising_Truth_...
I think we became immunized and stopped noticing it in this context after product being so many years on shelves. Just like you stop noticing your nose in sight.
Though such a threat from a lightbulb sounds scary :)