Who has time for this? I've always been on under resourced projects where every hour had to be signed off. Everything is a rush and quality is required but never budgeted for.
It's a bit of an argument for "less haste, more speed".
As an example, I've always found with CI (continuous integration) servers that setting them up on day 1 of a project takes almost no time, but trying to set them up 3 months (or later) into the project seems to require a lot of time. Once a CI server is set up, it invariably improves both quality and productivity significantly, they start yielding dividends on their time investment very quickly.
If management claims they can't afford the relatively small amount of time required to set up a CI server, then I would argue that the lack of time only strengthens the need to have it done sooner to enable the project to move faster.
For onboarding documentation, finding random time may be hard, but it's almost free if it's done by a new member as they join a team. As they get their environment up and running, they just need to document the steps as they went along. Make sure it's committed to the same source control repository, readme.md seems to work well for this. It's fine if it's initially very simple, just an unformatted list of steps in plain text is a great start.
If someone is adding new technology stacks which would would affect the onboarding document, they should quickly add it at that moment, while possibly improving it a little by adding a little formatting. Future new team members should also be encouraged to improve the documentation based on their onboarding experience. Over time the document becomes quite refined and easy to keep upto date.
That doesn't address all their points, but it's a start and I hope it's helpfull.
HN resorts to the "just quit your job lol" far too easily. people are in all sorts of different situations. you don't know if they are struggling to find work and this is the one shot they have been given. you don't know if they are in extreme demand and get paid well to fix bad situations like this. you just don't know. and telling people to blithely change jobs when they can't or don't want to isn't helpful
Indeed, I encounter this anti-pragmatic personality a lot in tech people.
It's an extreme intolerance to imperfect circumstances: a preference for nothing at all over compromise.
The issue is that tech attracts the mathemetically-minded who reasons from universal principles. Rather than the empirically-minded who start with cases, and abduce to provisional principles from those.
To a aximoatic mind: when a universal principle is violated, the situation is declared Bad.
To the case-base mind: when a tolerable situation seems to violate a principle, declare the principle Inapplicable.
Of course both types of thought are helpful in different contexts, I suspect 'the management of one's life, day to day' however, should be a matter of case-base reasoning to rough principle.
Okay, that's a reasonable universal principle, but in this case it's Inapplicable. To quote the OP:
> Everything is a rush and quality is required but never budgeted for.
It doesn't really sound like this is a situation where the principle is wrong, it sounds like this is proving the principle correct: you get what you pay for.
I think the "you get what you pay for" is the kind of heuristic reasoning I'm advocating. It's essentially balance/tradeoffs/etc.
That trading off thought process isn't the same as the ACCEPT|REJECT process of the axiomatic mind.
I think a person who says "quit" is really saying that the very question of trading off heuristics of value isn't applicable.
It's a bit like Poisonous|Edible, or Gold|NotGold. There's nothing to be traded. A Copper apple is Poisonous and NotGold. No two ways about it.
That reasoning only works when the concepts (Gold, Edible, etc.) are natural kinds -- or otherwise disjoint and universal classifiers.
In life, situations fall both into the ACCEPT and REJECT categories, into both GOOD and BAD, into both VALUABLE and WORTHLESS. These concepts are heuristic ones, and not disjoint & universal.
The attempt to apply this "disjoint, axiomatic, ..." reasoning to life is a recipe for catastrophe.
EDIT: my point about principles vs. cases, is that i take: def. heuristic "a resemblance amongst cases"; and def.., principle "a universal rule which disjointly classifies cases"
..ie., a slightly more extreme meaning to "principle" than is in general use
I think it is perfectly fine to remind people that looking for something better might be an option. Even if you have good reasons to stay in that situation, this reminder will do you no harm.
The reason might be they've been looking for a different job for a while without luck, and the harm might be... pretty depressing having someone tell you how easy it is?
I sort of agree and am just playing devil's advocate, but I also think everything of 'there's better things out there you know' has probably already come up thread just before the person complained of their situation not being as good - they know better's out there at that point.
It's a bit of an argument for "less haste, more speed".
As an example, I've always found with CI (continuous integration) servers that setting them up on day 1 of a project takes almost no time, but trying to set them up 3 months (or later) into the project seems to require a lot of time. Once a CI server is set up, it invariably improves both quality and productivity significantly, they start yielding dividends on their time investment very quickly.
If management claims they can't afford the relatively small amount of time required to set up a CI server, then I would argue that the lack of time only strengthens the need to have it done sooner to enable the project to move faster.
For onboarding documentation, finding random time may be hard, but it's almost free if it's done by a new member as they join a team. As they get their environment up and running, they just need to document the steps as they went along. Make sure it's committed to the same source control repository, readme.md seems to work well for this. It's fine if it's initially very simple, just an unformatted list of steps in plain text is a great start.
If someone is adding new technology stacks which would would affect the onboarding document, they should quickly add it at that moment, while possibly improving it a little by adding a little formatting. Future new team members should also be encouraged to improve the documentation based on their onboarding experience. Over time the document becomes quite refined and easy to keep upto date.
That doesn't address all their points, but it's a start and I hope it's helpfull.