If you want to level up your game, find a new job, or grow into a new role, by all means take a course or training on your own time. All of the concerns that you listed are probably worth spending dedicated time to upskill on.

If you stay in this field for much longer, you’re going to run into a lot of cases where the thing you’ve been doing is replaced with the New Thing. The New Thing will have a couple new ideas, but will also fundamentally handle the same concerns as your Old Thing, often in similar ways. Don’t spend your free time chasing the New Thing without getting something out of it - getting paid, making a project that you wanted to make anyways, contributing to New Thing open source projects.

If you sink work into the New Thing without anyone willing to pay for it, that’s fine, but it means that you might never get someone to pay for it. Most companies are more than willing to hire experienced Old Thing devs on New Thing jobs, and will give you some time to skill up.

It’s not a fully controlled environment, that is the point of smokes.

Polling is certainly useful, but at some point introducing reliability degrades effectiveness. I certainly want to know if the app is unreachable over the open internet, and I absolutely need to know if a partner’s API is down.

My experience with E2E testing is that the tools and methods necessary to test a complex app are flaky. Waits, checks for text or selectors and custom form field navigation all need careful balancing to make the test effective. On top of this, there is frequently a sequentiality to E2E tests that causes these failures to multiply in frequency, as you’re at the mercy of not just the worst test, but the product of every test in sequence.

I agree that the tests cause less flakiness in the app itself, but I have found smokes inherently flaky in a way that unit and integration tests are not.

My team has just decided to make working smokes a mandatory part of merging a PR. If the smokes don’t work on your branch, it doesn’t merge to main. I’m somewhat conflicted - on one hand, we had frequent breaks in the smokes that developers didn’t fix, including ones that represented real production issues. On the other, smokes can fail for no reason and are time consuming to run.

We use playwright, running on github actions. The default free tier runner has been awful, and we’re moving to larger runners on the platform. We have a retry policy on any smokes that need to run in a step by step order, and we aggressively prune and remove smokes that frequently fail or don’t test for real issues.

Get good at the three point turn.

• Add the new code path/behavior. Release - this can be a minor version in semver.
• Mark the old code path or behavior as deprecated. Release - this can be another minor version.
  • In between here, clean up any dependencies or give your users time to clean up.
• Remove the old code path or behavior. Release. If you’re using semver, this is the major version change.

This is a stable way to make changes on any system that has a dependency on another platform, repository, or system. It’s good practice for anything on the web, as users may have logged in or long running sessions, and it works for systems that call each other and get released on different cadences.

I think the best thing to do with TDD is pair with or convince devs to try it for a feature. Coming at things test first can be novel and interesting, and it does train you to test and use tests better. Once people have tried it, I think it broadens your use of tests pretty well.

However, TDD can be a bit of a cult, and most smart and independent people (like people willing to work at a <20 person company) will notice that TDD isn’t the silver bullet it’s proponents make it out to be.

YAML works better with git than JSON, but so much config work is copy and pasting and YAML is horrible at that.

Having something where changing one line doesn’t turn into changing three lines, but you could also copy it off a website would be great.

JSON5 is a superset of JSON that supports comments.

XML to transform XML to import into more XML? Can’t we just have a config file that isn’t setting up some big tie in?

I don’t know if it’s actual json5, but eslint and some other libraries use extended, commentable json in their config files.

XML would be great if it wasn’t for the extended XML universe of namespaces and imports.

“It takes years” seems like the most reasonable alternative to forcing my coworkers to TDD or not merge code.

I think that getting people into the benefits of testing is something that’s really worthwhile. Building out some of these test suites - especially the end to end tests- were some really eye opening experiences that gave me a lot of insight into the product. “Submit a test with your bugfix” is another good practice - getting the error the first time prevents a regression from creeping in.

I’ve had some luck at using AI to get over the hump of the first “does this component work” test - it’s easy to detect stuff that needs to be mocked and put in stub mocks using GPT. GPT is horrible at writing good tests, but often it’s harder to write that first one than the meaningful tests.

His manager at least had the decency to warn him ahead of time about the PIP. Still - it seems mostly about forcing him out of his remote position.

deleted by creator

Github actions is good for us, but honestly just because that’s where our code is.

Cloud, and really any vendor specific stuff, is tough to keep up with both in terms of learning and creating training materials. You’re better off getting it straight from amazon, google or other practitioners. See if you can find some smaller conferences in your area, and if you can spend training budget on that.

Obviously $200 isn’t much, but coursera might be a better bang for your buck than some other systems. Learning core skills will help you level up, while a lot of Udemy and similar content will just keep you on the same track you would have been on.

All of these things are less serious problems if things move faster. QA review of the master branch is the only thing you’re doing that has to be long running and synchronous.

For your acknowledged problems:

1. This is huge, and should be a focus for you.
2. This isn’t actually a big deal. Outside of fixing bad prod deploys, reversion causes more problems than it solves. If you get the devs out of QA, the need for this will decrease.
3. If you freeze the code on tuesday and release on thursday, that sounds like a schedule!

It sounds like the QA department is overwhelmed. You need more test automation in order get the turnaround for regression testing down. Many end to end test tools have recording functions - a senior QA or engineer in test could quickly get simple but brittle automation in place.

Devs need to understand that QA stopping the line is a last resort, not a personal safety net. More unit and integration testing will keep more of the work on the devs until it actually is ready.

What does your source control and CICD situation look like?

The overview is good, and the outline is good, but ultimately the problem is that the returns on big investments in DX are only really seen for companies at absolutely massive scale. There are far more companies that just burned through money getting a “nice” dev environment than there are companies that put a FTE or more into DX and saw worthwhile results.

It’s worth some time for teams to think critically about their own tooling, but the trend towards DX as an end in and of itself has been a drag on many teams.