canpolat

Not having any personal projects is perfectly fine. Don’t worry about it. Not everyone has to have their job as their hobby. Try other things (music, hiking, cooking, etc.). Try to find a hobby that makes you happy (if you don’t already have one). That’s way more important than having a public GitHub profile. And if a company decided not to hire you because of that, you basically dodged a bullet.

Here is the link to the original website (an NGO that monitors blocked websites in Turkey): https://ifade.org.tr/engelliweb/distrowatch-erisime-engelledi/

And here is the Google translation of the text on that page:

The IP address of the DistroWatch platform, which provides news, reviews, rankings and general information about Linux distributions, was blocked by the National Cyber ​​Incident Response Center (USOM) on the grounds of “IP hosting/spreading malware”.

git branches are just homeomorphic endofunctors mapping submanifolds of a Hilbert space

Yeah, once you realize that everything falls into place.

Good point. However, approaching this problem from “YAGNI” point of view is a bit misleading, I think. If you are not going to need the timestamp, you shouldn’t add it to your code base.

In my opinion, hastiness is the culprit. When a property appears to be a binary one, we jump to the conclusion to use a boolean way too quickly. We should instead stop and ask ourselves if we are really dealing with a situation that can be reduced to a single bit. The point raised by the article is a good example: you may want to record the state change as timestamp. Moreover, in a lot of the cases, the answer is not even binary. The values for is_published may be, “Yes”, “No” or “I don’t know” (and then we will be too quick to assign null to “I don’t know”). Underlying problem is that we don’t spend enough time when modeling our problems. And this is a sure way of accumulating technical debt.

This can only be solved at organization level. First, I don’t think there is a reliable way to measure business impact of an engineer’s work. But I don’t think that’s necessary anyway. The organization should focus on the team, not the individual. Only real measurement you get is the customer feedback. And the best way to make it matter is to shorten the feedback loop. If in your organization some people write stories and then send them to engineers, your engineers are essentially not in the loop. Engineers need to be present (and asking critical questions) when you are defining the features. Only then can you expect the team to deliver what the customer wants. And that generally requires organizational changes (cutting the middle man, giving the team more autonomy in their work and developing a trust culture).

https://observablehq.com/@ayhanfuat/the-fall-of-stack-overflow

https://www.overheid.nl/english

Overheid.nl is the central access point to all information about government organisations of the Netherlands.

OK, I may have hit a wall with this one.

I wouldn’t expect it to impact Fedora, but this will probably be significant for Rocky/Alma.