deleted by creator

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.

*removed externally hosted image*

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).

I believe there is an API to convert such a link, but detecting that a link is going to a Lemmy instance might be difficult (or non-elegant).

This is great. I think "instance post/comment links" would be a great addition to Lemmy core in general, but don't know how easy it would be to implement. What I have in mind is: when someone provides a link to a post/comment in another instance, it would be converted to a link the person is logged in from. I think it would be OK to leave the link as is but add an icon next to it that goes to the correct URL for that instance.

I have had Pluralsight for many years now and I agree with you. In some cases they have excellent courses, but I sometimes find the content outdated. I plan to explore O'Reily's platform next year. They seem to have a different set of resources and are comparable in price.

The way I commit on my private branch is different than how I merge those commits to the main branch. When working on the private branch, things can get messy and if they do, I just try to keep certain things separate from each other (refactorings and bug fixes should not go into the same commit). Once the work is done, I do a interactive rebase to tidy things up and then merge them afterwards. Sometimes the changes are not that much and it becomes a squash commit. I would definitely refrain from creating 100 (insignificant and possibly back-and-forth) commits on the main branch.

Git is definitely dominating the landscape. The fact that it is free software plays a big role. There are alternatives, but they are unlikely to gain much adoption. They may provide slightly better UX or marginally more comfortable flows, but it's not enough to replace Git. Not to mention, most developers don't even really care about which SCM they use.

@AutoTLDR again?

@AutoTLDR please :)

I think I will quit at this point.

*removed externally hosted image*