I don’t have multi-user library maintenance experience in particular, but

I think a library with multiple users has to have a particular consideration for them.

1. Make changes in a well-documented and obvious way
   1. Each release has a list of categorized changes (and if the lib has multiple concerns or sections, preferably sectioned by them too)
   2. Each release follows semantic versioning - break existing APIs (specifically obsoletion) only on major
   3. Preferably mark obsoletion one feature or major release before a removal release
   4. Consider timing of feature / major version releases so there’s plannable time frames for users
2. For internal company use, I would consider users close and small-number enough to think about direct feedback channels of needs and concerns and upgrade support (and maybe even pushing for them [at times])

I think “keeping all users in sync” is a hard ask that will likely cause conflict and frustration (on both sides). I don’t know your company or project landscape though. Just as a general, most common expectation.

So between your two alternatives, I guess it’s more of point 1? I don’t think it should be “rapidly develop” though. I’m more thinking doing mindful “isolated” lib development with feedback channels, somewhat predictable planning, and documented release/upgrade changes.

If you’re not doing mindful thorough release management, the “saved” effort will likely land elsewhere, and may very well be much higher.

Depends on what I want or need to “understand”.

I’ve worked for many years on a project (it’s a whole project ecosystem tbh with multiple projects; desktop winforms app, server app, SQL server, asp.net MVC app, asp.net blazor app, mobile wpf app, sync service app). On the main project (client + server) I haven’t visited one major area, and another I confidently know that it’s not understandable to me without specific deep effort.

I recently had to work on the latter. I take a localized approach. Explore what I have to do, without opening the full scoped understanding that’d lead me to architecture refacs. I write out the method call stacks to get an overview of who calls what when. To then know what I have to inspect and analyze further.

I take notes where necessary, or improve and comment code where appropriate for better understanding and obviousness.

I create documentation - about concepts and architecture as appropriate and necessary.

Code should be obvious and intuitive. Concept docs should document the broader concepts.

When those concept docs exist, those are what you look at to understand app intention and behavior. And it should give you an introduction to architecture. From there, exploring the code should be self-explanatory (but may require specific, repeated, and iterative analysis). And I take notes about what’s relevant and I need for understanding or task.

Afterwards, those notes should have, or should then integrate into the code base or docs, or be determined irrelevant for that. If I had to write them out and down, it’s more likely they should be part of something than not.

The article tells me more what features are new in Java 21 than it tells me anything about “keeping up with modern programming languages”. I don’t think the title fits.

In this article, we’ll debunk the notion that Java is a relic of the past

Did you not agree with them?

At work I use Jenkins, and I am very frustrated with it. I’ve worked with GitHub Actions, GitLab CI, and Azure Pipelines, and none were truly enjoyable to work with. They’re acceptable.

The last change I made on our project was to send a build failure and build fix notification email on branches to the last committer. (After having disabled branch build failure notification emails because Jenkins (or its plugins) were not able to send to only the branch developer/new change pusher/author a while ago.)

The best thing we did was introducing commit message conventions and convco to verify them, and to generate changelogs automatically.

It is warranted, and your colleagues seem to agree.

and other people on the team will almost always agree that it’s a good idea and will happily accept my PRs

I think you may be misinterpreting what is happening.

Them not taking initiative does not correlate to its importance. It’s just that most people don’t take initiative - or at least here, evidently, for naming consistency.

How much of an issue ambiguous naming is or may become depends on context - on a lot of things. But ambiguity in naming, just like elsewhere, weakens certainty and reasonability. If you can define and keep clear terminology, then always do so.

It certainly fits bad UI if you need Lemmy comments to understand how to spin the wheel.

09:30 on my team. Between multiple project teams I believe our dailies are between 9:00, maybe slightly before too, and 10:00. Can also depend on the customer if we’re part of their development team. I believe not all teams have them every day.

It’s a good time for me because I sometimes begin at around 9:00.

At 9:00 begins our central working hours where we’re expected to be working. And I think that’s late enough for the late starters. So I like where we’re at.

I think it’s good to have it “early” rather than late. If you struggled the previous day it’s a good point of fresh start and possible discussion or follow-up support. It’s also where you have [to make] a plan for the day.