arendjr

joined 8 months ago
[–] [email protected] 0 points 3 months ago (1 children)

I have a Framework laptop (Intel GPU) with Arch and KDE, and while I’ve never seen all windows crash when connecting an external monitor, I wouldn’t call it out of the ordinary for one or two to crash after I connect one, especially if I try to drag one to a new position right after.

[–] [email protected] 11 points 3 months ago

This is the real reason we have linters.

[–] [email protected] 2 points 3 months ago

I absolutely agree with you. If I can avoid NPM I will indeed do so. Sometimes that means using Deno, but sometimes it can be a valid reason to avoid using the language altogether. And sometimes we have to suck it up 🤷‍♂️

[–] [email protected] 8 points 3 months ago (5 children)

As much as people like to make fun of JS/TS, I think you’re right, especially compared to the languages you mentioned. It’s my second-favorite language after Rust.

I think I would put Swift above it as well, except I don’t really use it since it’s too domain-specific in practice.

[–] [email protected] 2 points 3 months ago* (last edited 3 months ago) (1 children)

If you just have one or two required fields, with the rest being optional, it can also be a good middle ground to just pass the required fields to new() and use methods like in your example for the optionals.

PS.: A common convention for these methods is to prefix them with with_, like with_max_depth(max_depth: usize) -> Self.

[–] [email protected] 5 points 3 months ago

Nah, more senior devs often also advocate for the quick fix, for the simple reason that the economics of a “proper” fix simply don’t add up, especially when you don’t know how much value such a fix would bring anyway. If you’re always looking to create “proper” solutions in hopes of someone in the future thanking you for it, it most likely means your priorities aren’t where they should be and it’s very unlikely someone will thank you for it.

I even wrote a blog on this topic: https://arendjr.nl/blog/2023/04/mvp-the-most-valuable-programmer/

[–] [email protected] 7 points 3 months ago (2 children)

Sorry, I don’t understand. Do you mean there have to be 6 digits of Pi in there, or the sixth character must be π? I’m down either way.

[–] [email protected] 2 points 4 months ago (1 children)

Sure! The other day someone called it emergent architecture. I guess it goes by multiple names :)

[–] [email protected] 6 points 4 months ago

Can’t it be both? :)

[–] [email protected] 1 points 4 months ago

Ah, fair :) then yeah, I’d say it’s pretty aligned with emerging architecture, just that I’m trying to define the values (and in the next post, technical guidelines based on those values) to (hopefully!) help you make the right decisions as you’re working on an emerging architecture.

[–] [email protected] 2 points 4 months ago (2 children)

I assume you're referring to this blog series: https://medium.com/prospa-technology/emerging-vs-intentional-architecture-385071ae5d75 ? I wasn't aware of it, and it seems to have some insightful observations! There's definitely some overlap, but by the looks of it, I think I will diverge quite a bit with my next post. I think I'm pretty aligned on the "One-Way Decisions" vs "Two-Way Decisions" part. A One-Way decision in my mind would be, which programming language or framework do we use? Do we use REST or GraphQL?

But it doesn't really go into how to deal with Two-Way decisions, apart from saying to trust your developers. And I think it kinda glosses over the part that things that may appear to be Two-Way decisions initially may actually be closer to One-Way decisions if you continue to build on them. So where that blog still focuses quite a bit on the process, I think I want to shift the focus a bit more to the technical side (so far I've mostly laid down the values that inform the technical direction), especially when it comes to Two-Way decisions. I wasn't thinking about covering One-Way decisions much, but rather on how to shape everyday coding to be more in alignment with Post/Emerging architecture so that you can avoid the Two-Way decisions that in retrospect aren't as much of a Two-Way decision as you'd hope.

Hope that makes sense :D

[–] [email protected] 5 points 4 months ago

Thanks! This mirrors quite some experiences I’ve had over the years indeed. And for what it’s worth, I think the way you’re handling that is not bad at all.

As someone else mentioned in the comments on Mastodon, one of the hardest things about mentoring is articulating the lessons you may not even realize you’ve learned. I don’t think anyone can be blamed for failing to teach or convince someone else, since people are simply too different to be able to teach and convince them all. As you say, you have to pick your battles, and as long as you let your teammates do their work respectfully in their own way, that alone is a great achievement!

view more: ‹ prev next ›