180 karma · joined October 30, 2016
If you are doing 2 features, and cannot both well enough, then it's better to do one (important) extremely well and one (less important) just to get by, than do two mediocre features. In the former case, you will get at least some happy users who will talk about you and hopefully get you more sales. In the latter case, nobody would vouch for you and mediocrity will drive you into oblivion.
During the recent history of computing, the technology improvement opened new possibilities at each step:
- Punching cards: allowed more people share mainframe,
- Video terminals: allowed faster turnaround of mainframe jobs,
- Mini-computers: gave more people access to computing,
- PCs: got even more people into computing,
- Commodity hardware in datacenters: more people could develop services and more people from general public could get access to applications and data,
- Cloud: more people could afford to build applications,
- Microservices: bigger teams could collaborate on increasingly sophisticated services,
- Serverless: reduced the burden of capacity planning and service distribution and further lowered the barrier of entry into backend application development.
Each statement above comes from personal experience and I am looking forward to what new possibilities the future brings.
https://ourworldindata.org/grapher/excess-mortality-raw-deat...
def get_users(f) -> Tuple[List, List]:
return (logged_in_users(f), logged_out_users(f))
def user_count(f) -> int:
return len(get_users())
Now it's clear this is just wrong code. To fix it: def get_users(f) -> List:
return logged_in_users(f) + logged_out_users(f)
def user_count(f) -> int:
return len(get_users())There must be a reason why the print developed as black-on-white, maybe people preferred it this way.
So pick what you prefer: paper-style or CRT-style.
The problem with what you call the principle of lesser power is that people fail to accurately predict "suitability" of their solution and choose wrong tool for the job. They start with "I just want to set a couple of variables" and end up with full-scale development system with IDE, debugger and profiler, badly designed and partially implemented.
The whole point of configuration is that it's not code.
I use a simple litmus test: can your system work at least to some extent with empty configuration file? If not, you went too far and need to simplify.
However I argue that I haven't seen many cases where configuration DSL were well justified.
By configuration here I mean something that describes differences between different deployed instances of the same code. If you take all deployed instances of the existing system and see what is minimal amount of configuration to describe these, you would usually find that very little information, just a few lines would be enough.
The rest of configuration file complexity comes from the designer's attempts to predict the future extensions. My point is, these should be resisted for the sake of future generations of maintainers.
IMO better strategy would be to reduce config files to absolute minimum and let the code that reads them handle all the complexity. Whatever is your main language, it is better supported than any of this.
Would be interesting to hear the opinion of the people with legal experience: what are the merits of the lawsuit?
My personal unqualified opinion is that they will settle out of court for wrongful termination. Since white males are not protected class, the discrimination case is much weaker.
It is much easier for Google to settle this lawsuit than to deal with hundreds of others they would get should they kept Damore on payroll.
I think regardless of the merits of TFD this lawsuit is a good thing because companies would be less inclined to punish people for objecting groupthink.
Call me squarehead but I refuse to "experience" life in North Korea, not even close to this.
Also, I think if I were ordinary North Korean experiencing all the atrocities of the regime I would be really bothered by this act of "observation"; it feels quite a bit like being an animal in the zoo cage being stared at by the bored public.
Due to his knowledge of the early warning system he was more likely to cast doubt than a regular officer on duty. Several factors looked suspicious: 1) The reported starts (5 in total) happened from a single base in the US which didn't make sense from the military point of view: the US would have put themselves at a grave disadvantage by sending just a few missiles; 2) They had visible light and infra-red visuals on the US territory and none of them checked out and 3) It would have been highly unlikely for the war to start suddenly, without any prior escalation.
Like other officers on duty, he had college education as an electronics engineer and additional 2 years of special training. All this probably helped him make the right decision.
This is not to take away from the importance of Mr.Petrov's heroic personal contribution: he definitely deserves recognition (which he didn't get from the Soviet Army and his own country BTW). Still I would also like to hope that we are all collectively not as stupid as to go caboom just because of the single fluke in the satellite system.
Instead of blaming police I would see this is an opportunity to educate everyone on the autism and how to properly deal with it. Especially given the fact that April is the National Autism Awareness month.
People talk about diversity and inclusion a lot, in the context of gender or race or anything; I have never heard "diversity specialists" talk about neuro-diversity even though this impact major part of the population. This has to change.
However in the context of TFA, the campaign to make Uber employees quit is an _action_, and it still based on accusations (however credible they may sound). This sounds a whole lot like a witch hunt. In enlightened modern-day Silicon Valley, that is.
What is so special about efficiency? Efficiency is just one of the concerns the software development orgs are facing, together with cost, utility, usability, deployability, maintainability and so on. The tradeoff between these (and the ability to choose this tradeoff correctly early in the cycle) often defines the success of a project or an organization. Focusing on one while disregarding others can be lethal.
YMMV. Watch your controls.
Another extreme is "false growth mindset" that also breaks the feedback loop but in a different way: no matter the results, you will still get praise for "effort", so there is no point in trying harder.
"Growth mindset" is helpful but it is not a magic replacement for hard work and learning to deal with frustration.
2. Specifically about giving communism a fair trial despite all past failures because it is "ethical": no thanks. I find its principle of "dictatorship of the proletariat" unethical and proven disastrous.
3. Stalin disappearing his political enemies was rooted at least in part in Lenin's cornerstone principle of "democratic centralism" which was critical ingredient for the success of the communist revolution. Trying to decouple the two doesn't do history justice.