Honestly, based off what you said, in my opinion you clearly lack credibility.
The very least you could do is properly quote what I actually said instead of poorly paraphrasing, and then holding that paraphrase up as an example (with a different context). That's no better than putting words in other peoples mouths, its just flawed reasoning, and the tactic comes off as plainly manipulative and biased.
If you read and comprehended what I said, and knew what good documentation practices are, you'd agree if you had the experience.
Every single time I've seen a developer say differently and get their way, its resulted in project cost overruns by integer scaling factors greater than 1, many times in the double digits, assuming the project even completed (some don't).
Availability of good documentation on existing systems makes and breaks project budgets.
I really don't see how you can reasonably think this is a good example, let alone a great example. You of course are free to think what you want.
Fundamentals are covered in Chapter 31 of the Limoncelli books (TPOSA) covers the broad strokes, and Redhat Documentation pre-IBM takeover are examples of good end-product from proper documentation practices.
Em, this isn't meant as a snipe but has to be said because you clearly didn't read and comprehend.
Read what was said, and make sure you look up the definition of words like over-generalization beforehand (its a logical fallacy). If you can't pass reading comprehension at a grade school level, there seriously is almost no skilled job your suitable at. This is basic fundamental stuff. You need to do this for almost everything in a professional environment.
> And these people, there are the ones telling the average rest what they should do
Following that reasoning, you can literally claim anyone who communicates anything is telling someone what they should do, and the author tends to fall into this bias to group people doing just that. So anyone they want or perceive as negative then falls into this group which in fact encompasses all humanity (because communication is inherent in almost everything we do). This is literally in the definition of over-generalization, which is what I said (if you go back and read). Its also very common and manipulative tactic in identity politics often used for malign infuence against those that don't critically think to dupe them.
Unfortunately, this lacks any kind of rational thought, is biased and follows flawed reasoning, and as a result lacks any kind of credibility, and rightfully so.
Nassim Taleb has a great bit on it: characteristics of "natural" systems tend to settle on gaussian distribution on a long enough time frame. Weight, life span, force, height, skills... On the other end, systems that we have created have metrics that tend to not follow the normal law: money, electricity consumption, size of houses, etc.
It's not a perfect match and I'm not trying to write a white paper on anything. It's just a way to warm up the reader to the essay point.
Demo meetings that matter, now that's an anti-pattern if I've ever heard one. Only UI work makes for a snazzy demo, anything else will bore stakeholders to tears (and you of course need stakeholders if the meeting matters). The backend can be completely mocked out and stakeholders wouldn't even realize. All demos do is bely progress and make milestones seem closer or farther away than reality. The only "demo" that matters is the actual product launch.
I have always had great success when systems are designed from the UI first. It really helps you break a new business case down to the point where the backend code just starts writing itself.
I suspect you are coming from a design background because people who have never built a UI before are always very suspicious of this suggestion.
I don't come from a design background but my father drilled into my skull that nobody cared about my beautiful skills at work. They cared about their problems and if I could solve them.
Coding just happen to be a mean to solve their problems, but they don't understand code, and I don't understand their problem.
After a lot of frustrating client/dev interactions, I came to read "don't make me think" from Steve Krug. I realized the UI was the only language I shared with my customers to start a meaningful discussion.
This turned out to work well, and got me paid, so I sticked to it.
This is how I start with libraries. How do I want to use it, and start with some code that will eventually compile. It acts as an integration test too. But this starts to expose issues earlier with my understanding. Then if the interface doesn't work, it's easier to fix earlier.
I know it's passe, but I generally like to start with a set of requirements first. In the old days, when we were doing XP instead of agile, we didn't feel the pressure to "code something, anything." Now, unless I check in a couple thousand lines of code per day people think I'm slacking.
But... not trying to say "build the UI first" is a bad choice if it works for you. I do mostly backend work on "high trust" transactions, so I tend to look at the API first and see if it matches the requirements i have at the time.
A good many times the customer doesn't spot important issues until they see it in a UI, preferably interactive. The design process is done best with a combination of formal written requirements and mockups/demos.
For some applications, like an API-driven backend made to serve other applications, you can consider that the API itself really is your UI. It's how your users interface to your code. Your users just happen to be other developers whose code had it's own UI too, maybe a text or graphical one or maybe another API.
XP as I remember it was about implementing one customer-relevant feature at a time. This isn’t too-down or bottom-up, it’s doing a thin vertical slice. There shouldn’t be code that isn’t used or buttons that don’t work.
The UI [GUI, API, CLI, etc] is a statement in the "solution domain." By "requirements," I mean a problem statement.
"A form with three text inputs labeled street, state and zip" is solution while "the system should allow the user to specify an address" is a problem statement. (And ideally it should be more detailed with respect to its context: "The system should allow a user to specify an address associated with a delivery record, associated with the user's id.")
Most of my readers come from HN, reddit or substack itself. Now it's mostly Python so it makes sense a tech oriented medias will be reading more about it.
Still, the ban on substack by twitter means that, while a #python tweet gets some view, the same with an article to substack tanks bit time.
I'm curious how you're dealing with Reddit: some of the mods don't even respond to a direct message; they just say "read the guidelines." And then their auto-mod deletes your post.
I follow mostly techies, very few went to mastodon, and among them were none of the ones I cared about.
Seems like the people doing the most things in my field have no time for drama and are busy doing stuff, while the ones that actually accomplish little have the time and energy for this.
Counterpoint: most of the Cloud Native crowd I follow moved to Hachyderm.
> Seems like the people doing the most things in my field have no time for drama and are busy doing stuff,
Standing up for ethics isn't performative drama. I made my exit very quietly because I didn't have time for the drama of a petulant tyrant. I care that the tech I consume is open source or at the very least is guided by some principal of any good kind.
People spent months and a tremendous amount of energy discussing the state of a site that is a glorified animated wall of text, but it's not drama.
Sometimes I wish I could teleport this community to were I lived in Mali and force you to stay there for 6 months to re-calibrate your sense of what's important.
Most of the Python developers I followed are on Mastodon. "Techies" has lots of sub-cultures, so it could be C# or React developers are stuck on Twitter, for example, so if you are in those groups it might seem nobody has left.
IANAL but I would expect you can only be held reponsible for a product if you say it fits a particular purpose.
But the python licence explicitly says:
PSF is making Python 3.11.3 available to Licensee on an "AS IS" basis.
PSF MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF
EXAMPLE, BUT NOT LIMITATION, PSF MAKES NO AND DISCLAIMS ANY REPRESENTATION OR
WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE
USE OF PYTHON 3.11.3 WILL NOT INFRINGE ANY THIRD PARTY RIGHTS.
So it's not sold to you, and not distributed with any implied level of quality or guaranted service.
> I would expect you can only be held reponsible for a product if you say it fits a particular purpose.
That is an incorrect expectation. Even in the American legal system "I said don't do that" is not a shield against liability. In the EU framework a new law can pretty much create any new liability they want, so a disclaimer absolutely could be rendered meaningless.
