As a Dutch person, I was never taught this, I can see it is good practice but we just don't do it. All we do is check over our shoulders before we open the door because we know there can be a cyclist. Why? Because we are all cyclists so we know it can happen...
>In NL, you pay ~€110/month annually, with a max out-of-pocket cost of €385 per year. So, maximum €1600 cost annually.
My provider, CZ, charges ~€150/month with max-out-of-pocket ~€385. If you get the full ~€850 out of pocket then your monthly payment drops to ~€110/month.
I would guess that you are also including "anvullende verzekeringen", additional cover for e.g. dental/glasses/physiotherapy etc in your premium, because if you check a price-comparison site [1], then the majority of insurance policies are in the €110 - €120 range.
The extra insurance (dental/glasses etc) is also a bit of a scam, because the amount covered is often less than or just equal to the premiums that you pay in a given year, and you'd need to also be buying a new pair of glasses every year, always visiting the dentist, and so on. It's probably more economical to simply pay these costs out of pocket.
That's even worse. You don't need to throw in a massive library like pandas, especially not when OP is build a basic API. Sure, if you're in a data science-y project where pandas is already a dependency, go nuts.
It really depends on the size of the list you want to process. If it's 10 items, pandas is overkill (and probably slower). If it's a million items, pandas is a great solution.
I have a nagging feeling there is an easier way to do this, but my quick and dirty solution was
def merge_list1(l):
other_dict = defaultdict(lambda: 0)
for t, c in ((i['thing'], i['count']) for i in l):
other_dict[t] += c
return ({'thing': k, 'count': other_dict[k]} for k in other_dict)
which is still readable, but probably far from optimal.
> If it's a million items, pandas is a great solution.
Possibly not even then, it depends on how much you're doing and I feel like the topic at hand might be around that tipping point. We have some rather slow code that, profiling it, turned out to spend something like 60-70% of its time just converting between python types and native types when moving data in and out of the dataframe.
True. If there are millions of different “things” conversion times will end up dominating. If they are just a handful, then the libraries will be able to do a lot more work with parallel operations and converting the output will be very quick
Yesterday, I wrote a short blog post titled "Don't mistake the internet's intelligence for your own" [0] which is very closely related to this blog post here. I wrote it it to shine some light on the fact that knowledge on the internet (Google, SO) is not ~your~ knowledge. This fact often gets painfully exposed during interviews. Funny timing.
I consider the internet an external brain I reference (mainly through Google search). I've done this for decades. At some point systems like linux got so complicted and changed so rapidly it didn't make any sense to store information in my head if it was already stored and easily fetched externally.
Much of my ability in using internet information comes from being able to rapidly prune what I can tell are incorrect answers ("do this to systemd to fix that problem" when systemd isn't related to the problem because on OS whatever, they disabled that feature) while discovering the one random answer that has the deep, non-obvious fix.
Now, in terms of interviews. I'm not looking for people to spit out information from memory in an interview, beyond some fairly basic reference information. I'm looking to see if they can apply the skills they have to solve useful problems better than other candidates.
I failed my first interviews at Google because I didn't know quicksort (the details of the implementation) off the top of my head; anybody who had memorized the code could have answered the question instantly. After later joining and spending 12 years as a software engineer, I can assure you: knowing how quicksort is implemented isn;'t helpful for the vast majority of SWE roles at Google. Knowing that quicksort can be faster than heapsort or bubblesort, but sometimes slower, is useful, and how to select the right library implementation and benchmark it with a good set of data is far more important.
It makes me think of how much complexity we agree to live/work with, being actually unable to manage it without searching the internet. It’s really funny that interviewers try to expose that, cause regular developers (think fullstack configuration vs software algorithms) do just that: convert the internet to a source code of mediocre value but high complexity, and then implement a crucial business logic on top of that. Which cannot be learned beforehand, unless you’re reimplementing something for legal reasons.
I think most of this complexity is a failure in scope limitation. No exaggeration I wouldn't be surprised if the average piece of software today is 1000 times bigger and slower than it needs to be.
You need to spell check a text? In the 1980s, you could do that relatively quickly on a computer with no network access. The dictionary data was pretty big back then but today it will fit in an L3 cache.
Today, each checked word likely gets converted to JSON and is then sent around the world through load balancers and proxies to some cloud instance where it is deserialized and checked and a new JSON message is encoded saying "{\"message\:\"yup, it's a word\"}", which gets passed back through a bunch of servers until it ends up in a mobile app that is really a souped up HTML widget. Spell checking isn't by any means trivial programming, but it doesn't require planet scale computing either. There is no benefit to that. It's just a waste of resources.
So why do we build things that way? Because of Parkinson's law. If we had put a constraint on resources, we would have found a faster and better way of doing it. This is in part why I advocate targeting low power hardware when designing a new system. If it's fast on a Raspberry PI, then it will be fast on any hardware. You will identify scaling problems early while the code is still malleable and easy to redesign.
This is the so-called "Illusion of competence/learning" [1] and I have become fascinated with this topic (and learning in general). The only way out of this trap is to self-test.
Is there any version of Dan Luu's website with just a hint of css? Plain HTML is unreadable imho, content is usually great but I struggle to get through it because it's so damn hard on the eyes.
