cdavid

Japan suicide rate has decreased a lot, and is now almost the world average, it is actually lower than in the US and several European countries.

I agree however that this smells of orientialism. I don't speak anywhere fluently Japanese, but having lived there for 15 years, the only time I've seen or heard of the ikigai concept is in the "Book for foreigners" section.

For large companies, a big reason is to transform capex into opex, and the predictability. Moreover, large organizations tend to favor predictivity over levels, i.e. are ok to increase average if variance is decreased.

It is true both countries were already industrious, but it was far from a given they could go back to their former self. They were both utterly destroyed, and things could have gone really badly, especially in Japan.

I can't find the reference right but I remember reading average adult calorie intake to drop to ~1200 kcals in 1947/1948 in "embracing defeat" by John Dower. That period has a huge influence on Japan to this day, including architecture of Tokyo through black market.

Both Japan and Germany had strong military govt culture, and became reliably democratic at the end of the allies occupation.

It is programmable but the HW is sold assembled and ready to use. Wouldn't qualify it as DIY.

Not sure whether the word come from there, but sleepers from W. Allen has it in 1973, one of his most fun slapstick movie of that period.

In ML, it generally is ordered from most contributor to least contributor, w/ heads of the lab last.

It is hard to find modern references on this. When I led a search group, coming from an ML but non search background, I found the following most useful

1. Query understanding series: https://queryunderstanding.com/query-understanding-8a2b16024... 2. Deep learning for search in manning. It covers some non DL techniques

Then it is mostly papers and talking to people. Berlin buzzword has videos of all talks and is very non academic but technical.

If you have access to the query log, aka "who makes which query in what context"), you can use see which queries are "close" to others in context.

For example, with session, you can detect manual query rewriting, and use this as a signal to see which queries are close to others in the time context. You can do various fancy things from just that.

Nowadays, a simple way to start would be to use SOTA LLMs to generate synonyms offline, and use this for query expansion at query time. At least in a context where queries are small, that should give decent results. This has however diminishing returns because of cost (the more synonyms the more expensive querying the index), and also you lose precision with diminishing returns on increased recall.

Ofc, for complex search like google, I am sure it is much more complicated

What is your goal ? 1) Know more about how they work on the academic side ? 2) Be able to work in a company that work on LLM ? 3) Be able to work with LLMs 4) agents ? Each of those goal may require different learning "streams"

The book "NLP with transformers", or fast.ai is good for 3). For 1), assuming you do know how they work, I recommend you start reading papers.

I find the discussions around "prompt engineering" to be rather pointless and they are quickly obsolete anyway (newer, more powerful LLMs makes it more and more obvious)

Abortion was sensitive in France when it was voted in the early 70ies.

Few people in France oppose abortion laws as they are today, but the abortion restrictions are quite different compared to the US. E.g. abortion time limit in France are much shorter in "usual" cases, ~3.5 months. It was 3 month until quite recently, and that extension was controversial.

[edit] controversial, but nowhere near as controversial as abortion is in the US. I wonder how controversial extension to 2nd or 3rd trimester would be in France. Those later-terms are legal only under exceptions in France (rape, danger to the mother, etc.).

silos is one of this keyword that is org health dependent.

When things go well, people highlight team autonomy. For the exact same setup, when things go bad, people talk about silos.

Both Karpathy and fast.ai are good resources. Karpathy is "bottom up" (start from first principles and build on it) while fast.ai is "top down" (you start w/ working examples and gradually "peel off" to understand it).

Both approaches have merit, and it may come down to personal preferences.

  - karpathy: https://karpathy.ai/zero-to-hero.html
  - fast.ai: https://course.fast.ai/Lessons/lesson1.html

Yes, that's a fundamental reason python packaging is a mess. Python success is largely due to the availability of key mixed language packages. No other mainstream language package manager has to deal with this.

For example, cargo for rust, which is great, can assume to package mostly rust-only code. And while it is compiled, the language "owns" the compiler, which means building from sources as distribution strategy works. I don't know how/if cargo can deal with e.g. fortran out of the box, but I doubt cargo on windows would work well if top cargo packages required fortran code.

The single biggest improvement for python ecosystem was the standardisation of a binary package format, wheel. It is only then that the whole scientific python ecosystem started to thrive on windows. But binary compatibility is a huge PITA, especially across languages and CPUs.

The question of removing fortran from scipy has happened a few times, and never got anywhere for the reasons you gave. A lot of scipy itself contains fortran code that would take man years to rewrite.

Several key parts using fortran have been removed, once it became possible. For example fft stuff.

vespa's blog https://blog.vespa.ai/ will have tons of info about hybrid search

If you want, feel free to send me your resume and I can "review" it for you. I've have hired dozens of engineers and EM across ML, BE, etc roles.

Info to contact me in my user account (handle + gmail.com)

Maybe "risibles amours", but biased as it was my first book from him.

As novel, it is hard for me to split between immortality and the joke. The joke touched me more, immortality is more "serious".

But hey, I am French, so my immune system against this kind of thing is definitely weak. And I did read those as teenagers, and girls were definitely part of the appeal, at least originally

haha, I somehow expected you to participate to this thread.

I still disagree with your reading on Kundera, though I found unbearable lightness of being his least interesting work. The joke, "risibles amours" and immortality are great.

Somebody who like both Kundera and Boulgakov.

Middle management (above first line manager) in large organizations is hard to do well. I think it is difficult to understand if you have never done it, and it is even difficult to articulate why. I find it much much harder than working as an engineer or Eng Mgr.

Fundamentally, I think it is an incentive and systematic issue: what is expected of middle managers, and incentivized, requires almost complete dedication to managing up and laterally. People who spend time w/ their reports are the exceptions because there is close to 0 correlation with getting promoted. Caring about your report either require crazy number of hours, or ignoring what people above you will expect. The latter will ultimately affect their report.

Many people in that line of work do the minimum ? Yes, I can believe this. But the odds are stacked against you. I used to joke "as a middle manager, doing above average work requires extraordinary dedication".

1. Lack of agency: once you are above first line management (EM), you actually have much less agency. As an EM, you can tweak processes, and improve things. You only are accountable to your manager, and maybe 2-3 other people. Once you are above that, the number of stakeholders explodes, and any perception of failure will get at you. You can't say no to many useless meetings because you have to be there. If you don't go, and something goes wrong, guess whose teams/projects will be slashed next time.

2. Corollary: spooky action at a distance. Once you're middle manager, you will get random people with random level of competence ask you things you don't even understand. I regularly encountered "You have not done X yet, and this is slowing down other teams", and that was the first time I heard of X. Everybody knows you can't do half of what you are asked, but you better not be perceived as not doing all of it.

3. Solitude: As an EM, you can foster your team. Above, you just have a bunch of individuals who very much don't work as a team. Very difficult to keep some cohesion.

4. You need to own shit you are not responsible for: You have to explain often nonsensical decisions you had no authority on, but you also cannot say "sorry guys, this is coming from above".

5. Outside of exceptions, doing a good job is completely unrelated to how you will be evaluated. There are many things you know in your heart will negatively impact your team that you absolutely have to do. The best middle managers are the ones who manage to balance the kafkaiesque and still maintain good environment in their report line. This requires an enormous amount of time that you can only do for so long, most burn out quickly.

It is slightly over cynical, but I think avoiding what spakhm describers on his blog is impossible to escape above a certain size: https://www.spakhm.com/p/how-to-get-promoted

Not sure I understand your use case, but if you have to use nfs, cachefilesd is very effective for read heavy workload: https://access.redhat.com/documentation/en-us/red_hat_enterp...

That somehow surprises me. Can you link such a study ?

It releases the GIL only in very specific sections. Most of the Numpy C code runs under the gil.

A quick check on master shows only 10-20 calls using NPY_BEGIN_ALLOW_THREADS (which is an alias to Py_BEGIN_ALLOW_THREADS).

A lot of the NumPy code manipulates python runtime objects, and doing so without thread safety would likely break everywhere. A lot of efforts would be needed to gradually make large C extension thread safe.

it is a common misconception that how the retirement is funded makes a huge difference in how much you need to save. In most situations, it does not matter nearly as much as people believe. Dependency ratio will determine in large part how much people will need to save to get a given level of retirement income.

For example, your 401k ability to pay for your retirement will depend on productivity gains , growth, saving, investments happen in the future. Those will look very different if you have 4 working age people for one non working person, vs 2 working age people for one non working one. In the extreme case, if nobody is working anymore when you retire, your 401k will likely worth almost nothing.

The problem in France is not how it s funded, but the fact that retirement incomes are way above the funding level. France, with Italy, are the only two OECD countries where retirees have a higher income that working people, which is insane. However, since retirees vote much more than other demographics, their too large income will not be touched.

Relying on the cpython gil and releasing the gil are two different thing:

  1. releasing the gil means multithreading is opt-in for a given code section in NumPy. Only very specific parts of the code need to be threadsafe.
  2.  not relying on a gil in cpython runtime means multithreading becomes opt out. Now all the code by default needs to be threadsafe, including the libs you depend on.

A lot of C/C++/Fortran scientific code is not thread safe, and the whole scientific python ecosystem depends heavily on those codebases.

The obvious one is speed/data size: you can handle much larger data with duckdb compared to pandas. Depending on the data, maybe 10x larger, sometimes even more.

From an ergonomics perspective, I find pandas much harder to use casually than SQL. When I was an IC and was using it a lot, I was proefficient in it. But now that I code maybe 5 hours / month at work, I can't really do anything non trivial besides basic stuff/pivots. OTOH, I never really forget SQL.

Depends on the company. Nintendo pays much better than pretty much every game company in Japan.

In the last 5-10 years, the gap between Japan and west europe for top tier companies salaries has decreased a lot: you can now get 100k $ or more.

We'll see how long the 500k + total comp in the US will continue for top tier. My prediction is that this will decrease a lot in the next 5 to 10 years.

He went into politics: https://www.mtdemocrat.com/news/district-1-senate-race-theod...

I now old and past 40, but would say it depends on the clubs.

There is still quite a lot of new electronic stuff worth listening to. Lots of it is derivative, but that has always been true for most pop music styles.

Whatever one may think about it, stuff like barker, raim, empty set, Laurel Halo, all sound very much post 90ies (the period I was a teenager, and started to listen to tons of electronic music).

It is very context dependent. I am assuming here you mean how to sell your work in your current organization, not in the context of getting a new job. And I am assuming you mean as an individual contributor, and as an engineer (e.g. not as a manager or in non engineering roles).

My advice, in the context of large organization (i.e. more than 50-100 engineers):

1. regularly discuss about expectations for next level/grade with your manager. Number one mistake I see are people talking about this 2 weeks before the evaluation period. Do not wait for evaluation period.

2. make it easy for your manager: ask him the information he needs, ask him who needs to understand your accomplishment, etc. Again, do not wait for evaluation period to start those discussions.

3. In the long term (your whole career), good outcomes and getting better at your job matters. But in the short/mid term (within your current job), self promotion matters.

In a large organization, just doing good work is not enough, for the following reasons

1. your promotion will depend on people who are not intimate with your accomplishment anymore.

2. the definition of "good work" is very context dependent: depends on your org, depends on the time, etc. What does your company value ? E.g. in most companies, the closer you are to what the execs value, the easier it is to explain what you do. Money is the obvious one, but that's not the only one. In some organizations, doing something with no business impact but very technically challenging can be rewarded. In other companies, this is not rewarded at all.

3. bonus and promotion budget: the more senior the role, the more it becomes a 0 sum game: for you to be promoted, somebody will not be. There is always a budget, people will fight for it.

4. as companies grow, there tends to be more standard processes on promotion. In practice, such systems will always reduce the variance. PG explained this well http://www.paulgraham.com/wealth.html

The above is why in practice, you need your manager's help to understand what is valued and when. Good managers will know what is needed for you to be promoted to next level, and will help you building such a case.

my 2 cents, as a director-level manager, managing around 50-60 people and having been a manager for 5-6 years now, after ~ 12 years as IC in quite technical roles

It is not builtin, but ipython will give you that and most features mentioned in the article.