@johncrickett I've had improved results providing BDD requirements and asking the agent to work with a TDD mindset. This helped while creating an implementation plan and during execution, where it actually implemented using TDD. The result is only as good as the requirements though.
@housecor As long as prior data setup isn't needed, a unique or shared db should be the same. For example, a new anonymous sales transaction starts with creating a unique id for that transaction. Then that same id is used throughout the test. Which for insurance quoting flows is common.
Hot take 🌶️: I’m not a fan of dedicated QA.
I prefer the dev team to be solely responsible for quality.
When dedicated QA exists, 2 problems tend to occur:
1. Devs get lazy. They lean on QA to find bugs.
2. Dev and QA often use different testing tools which duplicates effort.
Many programming practices have a sweet spot.
No types vs 100% perfect types.
No tests vs 100% code coverage.
No pair programming vs 100% pair programming.
No code reviews vs mandatory reviews by every team member.
There’s often wisdom in between. Look for the sweet spot.
@housecor I find that doing TDD regardless of deadlines has always produced higher quality code more efficiently. Most of the arguments I get are from people who don't know how to write tests well. TDD forces you to plan out your implementation ahead of time making implementation quick.
Any organization that imposes a "change initiative" from the top down has no hope of actually changing. You do not change an organization by telling people to change, IMO.
6 signs a dev team is out of control:
1. Few/no automated tests
2. Many lint warnings/errors
3. No Continuous Integration server
4. Frequent misspellings in code and UI
5. PRs are typically merged without any comments
6. "Hot fixes" are frequently necessary after deploys
@starbuxman I wasn't sure whether I would rather have a single composite monitor for my apps that tells if anything is down or multiple individual ones. Then I looked at the comments 🤦
👨💻Unexperienced developer: I need advice from the seniors.
👨💻👨💻Experienced developer: I don't need advice.
👨��👨💻👨💻Really experienced: Let's see what the new guy in the team thinks about that topic. Maybe it can shift my perspective. Maybe we both can learn.
Habit: When I open a PR, I review the diff myself first.
I ask:
Is this change well tested?
Are docs necessary?
Any hacks I need to resolve?
Any follow-up tickets I should open?
Do I need to add comments or improve my naming?
Should I split this PR to make it more focused?
@NotMyAgile If the requirements are well enough, does the product owner need to meet with developers for the demo? Can't the devs complete the work and the PO can sign off themselves without pulling devs away from development to demo?
We moved our projects from #Java 11 to #Java 17 almost right after the LTS release. Here is a list of the Top 5 features that I have used and enjoyed for more than a year that may convince you to upgrade your projects. 🧵👇