Given that the system these scenarios test also manage state, it's not surprising that the step definitions used in the scenario also need to manage some form of state.
While it's advisable to avoid unnecessary state between steps in a scenario like this, removing all state limits the ability for a scenario to express the intent the author speaks about.
The pull request sat in limbo until just over a week ago when Matt asked me to sign the Microsoft open source contributor agreement, which I haven't got around to yet.
Unfortunately I don't hold much hope for the library in its current state.
I totally agree, but the value that a junior developer can bring to the table is a pair of unbiased eyes. It's what I look for when new developers join any existing team I am on: what can they see that we can't.
At some point in the growth of a human being, we are discouraged from continually asking "Why?" and from questioning things we see. This is largely a bad idea, so showing junior devs that they are in a position to ask questions and help lead everyone to a better solution is great!
The point I was trying to highlight is that time spent on wading through the current situation is time not spent thinking critically about the inherent problems of said situation.
I'm not saying to down tools and get on the war path with management, but to rather try to balance accepting whatever you are told and never coming up for air, versus sitting back for a time to analyse the situation and identify potential improvements.
Ultimately it comes down to the individual, and whether they want to be a cog in the wheel, or whether they are interested in both improving themselves and thereby improving their employer.
That's a terrible attitude to encourage. Accepting the status-quo as a junior is a great way to encourage them to never improve or question the more debatable practices.
Teaching juniors to care about software quality and software maintainability is hugely important in order to encourage an overall improvement within the software dev industry.
When it comes to startups I'm not sure you can prioritise things like this over actually working on your product.
Also, if you're measuring and refining your estimates, they stop being 'estimates' and become something far less useful. If you have problems with estimates being inaccurate, try not estimating.
There are far more interesting metrics to measure rather than flogging a dead horse.
[0]: https://buildbox.io/#learn-more