Henrik Jernevad / is on Nostr

Software architect and developer with a passion for simple, effective solutions.

Last Notes

2024-10-29 07:52:12

- reply

@npub1u95…0kv7 I agree. Most "zero policies" become increasingly difficult as scale goes up. (Maybe that is a good reason to keep scale down? 🙃) But even in inherited large code bases, a light "zero policy" can be a way to "bite the bullet" and start improving the system. Personally, I don't mind working with legacy code as long as I am allowed to meaningfully improve it.

2024-10-29 06:50:23

New blog post: Zero support policy (the right way)
I like to treat every support issue as bug. As an indication that there is something in my product, documentation, or process that is broken. Otherwise there wouldn’t have been a support issue in the first place.
Is it an impossible goal? Sure. But aiming for it drives real improvement.
https://henko.net/blog/zero-support-policy/
#programming #softwaredevelopment #support

2024-09-25 14:32:22

- reply

@npub1u95…0kv7 @npub18et…m5kt More difficult understanding? (Though I guess that applies to premature abstraction too.)

2024-09-17 05:32:52

The best design does what it needs to, and no more.
https://henko.net/blog/when-nothing-can-be-removed/
#programming #simplicity

2024-09-09 16:05:46

- reply

@npub13w7…mktw It is probably the foundation for most technical flame wars too. 🙃

2024-09-04 09:42:59

This is very relatable:
> It’s the Hydra Project Effect: no matter how much progress I make, new challenges always seem to sprout in their place. But while this pattern may seem unbreakable, I’m determined to find a way to tame this beast.
https://www.bytedrum.com/posts/art-of-finishing/
#programming

2024-08-27 06:17:04

Want to learn how to model complex data in a clean and type safe way? My latest blog post takes a look at Algebraic Data Types from the perspective of a curious object-oriented programmer.
https://henko.net/blog/algebraic-data-types/
#programming #functionalprogramming

2024-06-26 18:57:05

- reply

@npub13w7…mktw I very much like Kotlin, but Gradle is a convoluted beast. Even more so with Kotlin Multiplatform.

2024-02-09 11:08:08

- reply

@npub1n8j…0xek @npub15nw…s0l7 Just to clarify, there is not really any performance difference between correctly written async/await vs then-based code. They are both executed asynchronously. Code written with async/await is syntactic sugar over promises and calls "then" under the hood. It is primarily a difference of syntax/style.

2024-02-06 09:23:24

- reply

@npub14lm…5crk @npub1x3r…6hvn I share your idealism. My comment was mainly from the perspective of "surviving" when forced to work in an environment which does not share that ideal. (If you can find a better environment, then that is even better. 😁)

2024-02-06 08:34:16

- reply

@npub14lm…5crk I agree with you. There are many reasons why code quality gets the back seat. (I think you can add AI generated code to that list as well.)
However, something we can ask of ourselves as developers is "how does craftsmanship look like in a world that is moving ever faster?" How can we design systems in a way so the factors you describe will not ruin quality? (I don't have the answer, but I think it is worth thinking about.)