kamstrup

joined 2 years ago
[–] kamstrup@programming.dev 1 points 6 months ago

Can't divulge too many details, but one example was when we had 2 options for solving a problem: 1. The "easy" way, storing a bunch small blobs to s3 as a job was running on an embedded device, or 2. The slightly tricky, implement streaming of said data on the device (not as easy as it sounds).

We went with option 1, the easy one, because it was deemed faster bang for the buck. I did some basic math showing that the bandwidth required upload the high number of blobs to s3 within our time budget was not possible on our uplink.

After we spend a month failing on 1., it was clear that we hit the predicted problem. Eventuelly we implement option 2.

[–] kamstrup@programming.dev 5 points 6 months ago (2 children)

Being comfortable with basic back-of-the-envelope math can be a huge benefit. (Full disclosure: i am a math major who is now a programmer)

Over my career I have several examples of projects that have saved weeks worth of dev time because someone could predict the result with some basic calculations. I also have several examples where I have shown people some basic math showing that their idea is never gonna work, they don't listen and do it anyway, and I see them 1 month later and the project failed in the way i predicted.

A popular (and wise) saying is that "Weeks of work can save you hours of meetings". I think the same is true for basic math. "Weeks of coding can save you minutes of calculation".

You can definitely be a successful programmer career without great math skills. Math is a tool that can help you be more effective.

[–] kamstrup@programming.dev 5 points 7 months ago

Must include CHANGELOG...

The changelog:

  • misc fixes
  • pls work
  • fixe a typo
[–] kamstrup@programming.dev 1 points 10 months ago
[–] kamstrup@programming.dev 1 points 10 months ago

There is a dangerously large population of devs and managers that look at themselves, unironically, as the gigachads pumping out ui "upgrades"

Many of these fail to realize how disruptive it is. UI change is like API breakage for the brain.

I have lost track of how many times I've tried to help an elderly family member with an app after some pointless, trivial, ui change. Only ending with them entirely giving up on using the app after the "upgrade" because the cognitive overhead of the change is beyond the skill that can fairly be expected for them 💔

[–] kamstrup@programming.dev 1 points 11 months ago* (last edited 11 months ago)

Depending on your needs you can also break it into a columnar format with some standard compression on top. This allows you to search individual fields without looking at the rest.

It also compress exceptionally well, and "rare" fields will be null in most records, so run length encoding will compress them to near zero

See fx parquet

[–] kamstrup@programming.dev 2 points 1 year ago* (last edited 1 year ago)

Postgres and MySQL/mariadb are all primarily written in C.

Contrary to what other posters here claim, most programming languages are not written in C, but are self hosted. Ie. written using themselves. This usually involves a small bootstrapping component written in C or something similar, but that is a minor part of a whole

[–] kamstrup@programming.dev 26 points 2 years ago

That we stop fawning over tech CEOs

[–] kamstrup@programming.dev 5 points 2 years ago

Thank you for saying this. Sometimes I feel like I sm the only one thinking like this 🙇♥️

[–] kamstrup@programming.dev 2 points 2 years ago (1 children)

You should probably change page content entirely, server sizey, based on the user agent og request IP.

Using CSS to change layout based on the request has long since been "fixed" by smart crawlers. Even hacks that use JS to show/hide content is mostly handled by crawlers.

view more: next ›