leghifla

This make me think about a scandal pre dotcom burst in Belgium: https://en.wikipedia.org/wiki/Lernout_%26_Hauspie

The creators "invested" in foreign companies that would buy their product. They had realized that $1 of product sold was making them much more than that in the stock exchange...

Be cautious about calling their customer support if you have "bought" DRM stuff: you can be banned for any reason at any time.

I complained about a failed delivery (broken box, one item missing). They refunded me but then immediately put me on a watch-list, threatening to ban me if I ever complain again. I will never buy anymore on amazon.

See https://news.ycombinator.com/item?id=41555898

How do you know they are good? Did you use one for an extended period of time?

A set of wheels and a cushion do not make a good wheelchair, if you want to live an active life. Please see https://news.ycombinator.com/item?id=41721976

I am from Europe and chairs are a bit less expensive here, but an "active" wheelchair is usually more than 2k$ anyway, often closer to 3k$. And some are much more than that (for instance if you want a soldered chassis)

see my earlier post: https://news.ycombinator.com/item?id=41721976

Let me use a car analogy.

I have no idea why a car should be more than 10k. On Amazon you can get a go-kart for less than 100: https://www.amazon.com/s?k=go-kart

It is really the same comparison. A true every-day wheelchair or a "hospital" wheelchair that will make you sweat after 10 yards

You are missing the experience of being tied to a wheelchair for a complete day.

None of the chairs you have shown are suitable for daily use. Even the "Magnesium" one.

One of the most important point (beside being the right size) is to be able to move the center of the rear wheels just behind the center of gravity. Too far rear and you have very good stability (hospital chairs), but you need to use most of your strength just to be able to turn (and you take a lot of space for turning). Too far ahead and it becomes dangerous. So it must be adjustable. In theory this should be possible on a cheap wheelchair, but I have never seen it. Probably the weight ditribution is too different (most is on the rear wheel) that the chassis must be thought differently?

I am on a watch-list too because of a recent problem with a broken package with only one item out of two inside. It was clearly a too light packaging for a heavy item with sharp corners. The only other problem I had was a warranty claim 5 years ago.

My account is not closed (but they "reserve the right to close it" anytime). I am glad I have no kindle or DRM stuff...

I tried to get an explanation, but just got a robot email.

I will never buy there anymore. Even if some stuff are hard to find elsewhere

When I was about 10, I was able to swim but I was not great at it.

For some reason (I think someone dived just in front of me), I needed to stop swimming and ended "vertical" in the water. It was quite unusual for me at the time. For a moment, I tried to go back to swim horizontally on the belly, without success. Then tried on the back, no success either. After a few tries, I began panicking like it is said the the video: I was just climbing an invisible ladder... A guard finally helped me reach the border of the pool and that was over.

After that, I tried to put me under the same circumstances: vertical in the water, 2 m from the border. And then convert to horizontal swimming. Every time it was easy. To this day, I still have no clue why I was not able to do that

+1 And usually, the one person in the meeting not using headphones does not feel the problem: he can speak all the time and be heard correctly, while the others cannot interrupt him while he is speaking

Just a fun anecdote on end-to-end testing I did 20 years ago while working on the compression of images.

Some parts of the algorithm were easy to test, others very hard. On the easy part was loading and saving the file. I tried to test as best as I could, but the lossy part was not really tested.

Then time to benchmark the algo on some images. The results were kind of OK, but some images compressed much better than others at low bit-rate, while the content did not look much different.

On square images, everything was fine. On rectangular ones, at high-bit rates it was somewhat fine, but strange patterns like ghosts of another part on the image started to appear for lower and lower bit rates.

Of course, I searched on the mostly algorithmic parts what was going on, and failed. Only after a holiday break and fresh eyes did I found the root cause: inversion of height and width in some part of the loading AND saving.

I had "end to end" test of the loading and saving, but the error was symmetric, so undetected. Young engineer error...

"Refactor your codebase to put the related code together"

Of course it is a goal, but not always possible. You sometimes have two (or more) conflicting "relations" in the codebase. E.g.: you are dealing with taxes in various countries. Do you group by country or by kind of taxes (on sales, profits, earnings, energy, real estate...) ?

The right answer really depends on how your team is organized and how you are making changes.

On a slow ssh connections, I prefer to close my eyes while typing, to avoid distraction by the delay on screen. I have better accuracy this way

In EU (and probably elsewhere), there are strict rules for the stability of power wheelchair. One such rule is "On a incline of x% (x chosen by the manufacturer), pushing for max speed from stop should not lift the front wheels"

To achieve that, the max acceleration must be quite low (software controlled), and the whole experience is sluggish, like trying to steer a car by pulling on rubber bands attached to the wheel.

From the moment I found a way to overcome this, I never went back. I know that I can hurt myself if I do something stupid, but I prefer this hypothetical risk instead of cursing 100 times a day because I cannot move how I want. It has been 10 years and I never got hurt.

I understand that such "high" risk device cannot be sold, but forbidding someone to change this is like inflicting a second handicap on him.

And first, lead by example. If the parents cannot help looking at their phone every 5 minutes, how are the children supposed to act?

These shenanigans before displaying the final result can have quite a lot of psychologic effects.

Back when I started programming, I did simulate a jackpot machine in software (no money involved). The final probabilities were fair, but I added a twist while rolling the images: before stopping, the probability of having 2 or 3 of the same image was quite significant... My younger brother was instantly hooked to it. The trick made him overestimate the probability of having 3 images the same, as he was seeing this pattern quite often just before stopping. This made me realize of fucked-up casino can be, while still abiding by the rules

On the other hand, rebasing can create its own problems re: regression finding

If you rebase more than one commit, you can also have an intermediate commit which does not run fine, or even compile. This can happen silently, without conflict resolution while you rebase. Think a function call in trunk needs one additional parameter.

So you have a commit message saying "Protocol X tested successfully with Y", which was true when the code done and tested. After the rebase, it might not run anymore because of changes done in the trunk. You will probably notice it and correct it in a later commit, but good luck in 3 month when someone points a bug at protocol X and you want to re-run the test in this commit...

About "truly fragile software", it seems to be the norm now, thanks to the ease docker provides to hide this

About touch buttons, I have seen once a lift with touch buttons for controls. For accessibility, the floor were also written in Braille. I thought to myself: "nice, they thought about vision impaired people".

Then, a friend of mine, which has completely lost vision and can read Braille, jokingly said to me when he arrived: "Trying to find the right button, I probably send the lift to all floors!"

It won't succeed because of physics/math.

They claim a save of 400kW per sail, with a boat cruising at 22kts. Let's do some math:

- 400kW is 400e6 J/s, or 400e6 N.m/s

- 22kts is 11.31m/s

So the forward force must be 400e6/11.31 = 3.5e7N, so around 3500 metric tons of force for a single sail. And with a relative wind coming from the front usually, this means the side force will be much bigger than that.

I am calling this BS

Good writing is clearly useful and quite often mentioned. But good reading is very rarely talked about. I think it is even more important.

Too many people cannot maintain attention for more than a few seconds while reading. Or they read "what they want to read" instead of the actual text. Like I write a "list of things" and they read it like "a set of things", loosing the meaningful ordering of a list.

I tend to write concise documentation, but people always loose some important details that way. So I am now purposefully adding more text than strictly required to be sure important points are really understood.

Like a good teacher repeats at least 3 times the same matter, with a slightly different angle

About mental effort in meetings being lower than solving a technical issue, it is definitively true (most of the time), even though non-technical people cannot even grasp how much a difference there is.

In a previous software job, I was participating in a trade show. It was meeting after meeting, with both sales and technical aspects (I was paired with a sales guy). After several days like this, I remember vividly the sales guy saying how this trade show was good, but at the same time complaining how tired he was because all of these meetings. I kept it to myself, but for me, this was nearly like vacations compared to the day to day usual work

If management does not pay close attention, doing sloppy work with many small bugs is the key to very high (measured) productivity:

  - You close a feature ticket by cutting all corners possible
  - Every corner cut will later become a bug ticket, that you can solve quickly as you are more familiar with the feature

Total: you have closed more tickets than a dev that did the feature right the first time... sad

The initial script was fine, but not ideal. The CI is better in this regards.

The CI is not the problem, sure. But it is not the solution either. That was my point.

Regarding a dedicated person to handle the CI, here is my experience.

In the small company I am working now, I had setup a adhoc deployment script that was working fine, took less than 5min (with no user interaction) on my dev PC. Since it is not a SaaS, our release cycle was a bit slower than wanted, 1 or 2 times per month, depending on circumstances.

A guy was hired and he wanted to speed this up. I explained clearly that the build/deploy script was not the cullprit of the "slow" release cycle. It takes time to decide was is ready for production, write a nice changelog for users (not just collecting git messages), testing on the custom hardware...

That is why it took me an hour to half a day when the boss said: we need a release today. The above guy was justifying its work by: "After I am done, you will just need to put a tag and the rest will be automatic". I could not convince my boss this was fantasy land.

Result 3 years later: we have a "nice" CI which rebuild the world several times per day. But we are doing maximum 2 official releases per year, with much more stress. We had a few "releases" which needed very urgent hot-fixes because of last-minute changes and not enough testing on hardware.

And the CI person is constantly tweaking bits of the CI (it has become part of his job), breaking thing here and there.

I long for the old days...

You receive an email for your flight: tomorrow at 10am. When you arrive at the airport, you are told the flight has already departed.

"How is that possible, it is 9am and my flight is at 10am?"

"No sir, your flight was at 8am"

Checking your email, you see 8am and you have questions about your sanity

I somewhat agree, but every feature is not equal. And you usually start with the easy ones... So, even without any technical debt, it will probably go up, just less fast.

In a previous job (Belgium), I had a non-compete clause, correctly written except that the "compensation" part was missing. To my understanding, when leaving, I could either:

- claim the clause null and work wherever I wanted

- follow the clause obligations and ask for half of my salary for the 3 years of non-compete

Moreover, when quitting, if they did not explicitly waive the clause, I could also ask for those 3 years of compensation... but they did not forget that when I left ;(

If you are 3 competitors on your market and you might lose x orders while your are down, but gain 2*x orders when the other 2 are down, you are ahead (with the same probability of going down as the others).

Real world is not so easy though...

> some testing is worlds better than no testing

While it is probably true most of the time, like many things in live, "it depends".

When you are developing some not so well defined functions and everything is on quicksand, tests may just slow your progress, while not really providing useful feedback (i.e.: when you always modify a function and its test in tandem). Ideally you should clarify your requirements, but sometimes the process of producing the code is the refining step