HN user

bandika

64 karma
Posts0
Comments16
View on HN
No posts found.
The ROI of Exercise 11 months ago

I think you are really wrong here. I’m 47 and after on and off running for decades, a few months ago I started to run every day. 2K in the first month - to start gently, then 2M (3.22k) for a month, then the next month 5k, and then 8k. I am doing 10k every day after 5 months, and I've never felt before so fit and healthy. I think it’s never too late to start exercising regularly, even if it means daily.

21st Century C++ 1 year ago

Honestly, I am a happier and more productive developer since left C++ behind for other languages. And it's not just the language, but the lack of ecosystem too. Things like the build system, managing dependencies, etc, all such a pain compared to modern languages with good ecosystem (Rust, Flutter, Kotlin, etc)

What works for me for a long time is total separation of work vs private online life. On my work laptop, no social media, private email etc is set up, whereas on my private laptop there is no access to any work related stuff. Also, no work email/chat on my phone.

So no private notifications during working hours and if I really have to focus, I just turn off email/chat temporarily.

On the other hand, after I finish work, zero work related notifications can reach me.

It’s a hard problem, and I don’t think there is a single solution for a DAW UI. On the one hand there are a lot of UI elements that can be built with traditional widget kits, like the toolbars, panels, even knobs and sliders just custom widgets, you can even build a channel strip that way.

On the other hand there are the “contents” or “views” like track view, clips, automation, piano roll, eq etc. I believe those are best to be handled as 2D scene graphs with direct GPU rendering. Even then, each of those DAW specific views presents their own set of challenges which are very involved to address.

So I would definitely choose a toolkit that allows both traditional widget trees as well as scene graph style rendering (for eg Egui + wgpu in rust, or Qml in C++).

There are other challenges too, I’ve always found synchronizing the ui, the rendering and the audio thread so that everything feels responsive is very hard.

It's not just that. I had only two articles published in well known journals, but in both cases the reviewers main criticism was that I didn't cite the reviewer's own article. It's an utterly corrupt system, something you learn to live with it when you decide to choose academic life.

Not sure if the code is the best place to track technical debt. Whenever a compromise made that results in tech debt, a ticket should be created in the issue tracker. That way it's easier to get an overview about the project's health.

In my experience as the carrier of a developer progresses, it is getting less about coding, and more about other tasks. The difference is probably the strongest between a senior vs principal/staff software engineer. In the places I worked principal/staff engineers are looking after the overall design and architecture, negotiating with teams developing other components, helping management with planning, looking after the progress of other devs especially new joiners, etc, etc. I'd say it's about 15% coding at that level and 85% everything else.

I find it amusing that many corporate dev teams picks C++ for its performance / low levelness, but then reject any code that Casey's advocate for. It is extremely hard to convince them to consider these things (ie in this case cache misses and branch mispredictions).

Now, if we consider only a conservative 2x speed-up, I might not care if my app starts up in 2s or 4s, but I do care if my device's battery last for 20h v 10h.