3 ms·

In all fairness, to me this reads as more of a rant man-splation for why thing's aren't productive, and largely misses the point. Its also fairly niche and spe

by than3 4y ago

In all fairness, to me this reads as more of a rant man-splation for why thing's aren't productive, and largely misses the point. Its also fairly niche and specific to developers that have a very developer-only mindset. Anyone who has spent time and designed systems with the bare-minimum feature sets needed to make operations supportable understands that most of the examples provided are very brittle, and purely opinion with little backing them. Its an overbroad generalization with a poorly thought through hypothesis that doesn't really match observations I've seen. I've worked as a System Admin and System's Engineer over the years, most of the issues are solved when you follow good documentation practices. If you aren't generating documentation in a way that others can read and understand, you simply aren't doing your job. A proper IT Operations team understands this, the developers in general that I've met seem to think these rules don't apply to them, this includes the supervisors managing the business unit, and then they raise holy hell when SHTF like it wasn't a completely predictable outcome. There are exceptions but they are just that, 'exceptions'. Average people should be able to read, and comprehend documentation needed for their position. If you can't do that, you aren't doing your job and deserve to be fired for misleading business about your skill set. If you don't have good documentation for an existing system, you need to generate that first before you can really do anything new, its deferred maintenance that needs to be paid. Its impossible to put any reasonably accurate scope of work together if you have no documentation on a system, and only generalized requirements. Documentation is often a critical part of the initial requirement scope/process (before any work gets done). You skip this phase, and you are tacitly approving a project that either will never complete, or will complete egregiously over budget.

BiteCode_dev 4y ago
You are a great example of the too good to be helpful crowd. "Things should have a good doc and you should read it". I could not have come up with a better example in the article. This is just perfect :)
- than3 4y ago
  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-bee 4y ago
    to quote the original article: And these people, there are the ones telling the average rest what they should do
    - than3 4y ago
      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.

by than3 4y ago

BiteCode_dev 4y ago

You are a great example of the too good to be helpful crowd. "Things should have a good doc and you should read it". I could not have come up with a better example in the article. This is just perfect :)

than3 4y ago
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-bee 4y ago
  to quote the original article: And these people, there are the ones telling the average rest what they should do
  - than3 4y ago
    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.