The longest I worked for a company is around 6-7 years.

As long as you get the opportunities to develop your skills in the areas you want (so that they are still relevant in the job market) and there is a good team around you, it doesn’t make sense to change jobs just to change jobs. It’s generally difficult to get a meaningful salary increase without a job change and that’s the main reason most people are looking for new jobs, I think.

The first time I saw that prompt, I thought the same. “I don’t want to cancel the install, I want to install it.” You get used to it, but I don’t think this is a very good UX.

Watching Brandolini is fun. He always have fun slides to look at and a humorous way to express his ideas. This talk is no exception. There are two things I would like to highlight:

1. Brandolini thinks using Lo-Fi tools (like sticky notes, pen and paper) is superior to digital alternatives because when using them you focus is modelling instead of tidying the diagram. He says: “Digital tools are changing your brain priorities. I enter a session to model, and I find myself aligning rectangles and making arrows clear.”
2. Following the domain expert wherever they go is not necessarily a good idea. In many cases, the domain expert will push for a quick fix in the system instead of aligning the code base with the business and that will not be beneficial in the long run.

The book was published in 2010. And for a 13 year old book it certainly feels old. This is a compilation of short articles written by several people. And they generally do a good job of articulating their thoughts, but I cannot say it’s full of gems, or anything. There is obviously some good advice. After all they are all experienced people with a good understanding of the field. But there are also sentences like “Do not only measure test coverage, but automatically check the results, too. Again, break the build if test coverage is too low.” or “Have a regular code review day each week. Spend a couple of hours in a review meeting.” So… I think it makes good light reading. You can read a single of these 97 “things” in a couple of minutes. But I wouldn’t keep my hopes very high.

BTW: The book is available in GitHub: https://github.com/97-things/97-things-every-programmer-should-know

Beginning in Git 2.43, Git will realize when it’s about to perform a double-revert, and instead produce the much more pleasing message

Doesn’t happen very often, but I’m glad we have a better solution to this now.

Please consider posting language specific questions to language specific communities in the future. For example, !c_lang@programming.dev

This sounds more like a Github question.

Apart from the historical value, the most important part of this article now is the “Note of reflection” added 10 years after it’s inception:

If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.

I don’t think this work flow is relevant any more even for teams that don’t do CD, to be honest. It was a messy work flow to begin with and I haven’t seen it applied successfully in practice.

Thanks for the response. It sucks to not have language being set in some implementations of ActivityPub. I think separating the write language settings from the read language settings would help a bit to set the corrent language when writing, at least. But I suspect that needs to be fixed in the core Lemmy (not instance specific).