Who is this particular developer
As far as I understand from the discussions about the topic, Maxim Dounin was one of the few core developers of nginx. Looks like Wikipedia has already been updated.
Who is this particular developer
As far as I understand from the discussions about the topic, Maxim Dounin was one of the few core developers of nginx. Looks like Wikipedia has already been updated.
I don't follow it very closely, but as far as I know, they are the only one implementing the open protocol they designed (which doesn't interoperate with ActivityPub). However, there seems to be some efforts for creating a bridge: https://www.docs.bsky.app/blog/feature-bridgyfed
As you said, there are some recognizable faces and that may impact the adoption. But not being compatible with ActivityPub is a real bummer.
I no longer look forward to updates.
[...]
It seems to me that some software is actually getting worse, and that this is a more recent trend.
[...]
Why does this happen? I don't know, but my own bias suggests that it's because there's less focus on regression testing. Many of the problems I see look like regression bugs to me. A good engineering team could have caught them with automated regression tests, but these days, it seems as though many teams rely on releasing often and then letting users do the testing.The problem with that approach, however, is that if you don't have good automated tests, fixing one regression may resurrect another.
Every time I see a new update, I think: "I wonder what will break after this update" and postpone them as much as I can. Software updates shouldn't cause anxiety. But they do these days...
When I saw the title, I thought "just another blog on 10x developer". I don't really know why I decided to read on, but I'm happy I did. Searls touches on many more while investigating the topic. The writer approaches the topic from a inter-generational point of view and also goes in to things like "passion" and "craftsmanship". I would even say, this is not about the 10x developer at all. This is about how as a young engineering discipline we are still trying to find better ways of doing things.
It’s an open secret that the industry has no idea how to teach people to program. Computer Science degrees famously don’t prepare programmers for the job of programming, which has always been left as an exercise to the student to figure out on their own time. If the industry is going to outlive us enthusiast programmers, will it adopt a sustainable approach to educating the next generation that doesn’t require people to teach themselves everything?
https://www.overheid.nl/english
Overheid.nl is the central access point to all information about government organisations of the Netherlands.
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).
OK, I may have hit a wall with this one.
I think I will quit at this point.
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: