hendershot

6 ms·

1.
by hendershot 5y ago
what the author is talking about in a short rant is classical vs mockist TDD. for better content on the subject: https://martinfowler.com/articles/mocksArentStubs.html https://martinfowler.com/articles&
2.
by hendershot 6y ago
Why would you want to? when the same unit test coverage will run under 1 minute, and be smaller easier to understand/change tests and can all be done on your laptop. it all depends on your definition of unit/integration, what I am
3.
by hendershot 6y ago
Integration, E2E, and smoke tests are generally slow, flakey, hard to write. They should not cover/duplicate all the cases your unit tests cover. They are good at letting you know all your units are wired up and functioning together. I
4.
by hendershot 7y ago
I've seen the following from pairing Junior and Senior engineers: * Really talented junior engineers blossom extremely quickly. They will easily be a multiple better after a year vs not pairing. * Middle of the road junior engineers ca
5.
by hendershot 7y ago
Paring with Ping Pong TDD works really well. Improves paring with frequent driver/navigator switches and improves TDD by having the navigator thinking ahead. Been doing it almost exclusively for 14 years. Hiring for pairing is importan
6.
by hendershot 7y ago
The problem often is that scrum (or any iterative process) fails when it's not paired with good XP engineering practices. There's constant learning and change on the product side, which drives constant learning and change on the i
7.
by hendershot 14y ago
Yup. Play is built on top of Netty and adds value so my point is why not build it as a re-usable library (or set of libs) vs a Framework, it's really not any more difficult.
8.
by hendershot 14y ago
I like Play, currently using for a personal project. But ultimately looking forward to the day where frameworks are replaced by mixing and matching libraries where you get just what you need and wire it up exactly how you want to without an
9.
by hendershot 14y ago
+1 on keeping things simple and not using a "F"ramework for every concern from the very beginning. >in Java you have to make those architecture choices day 1. That's just not true. Very easy and advantageous to start out with say a simp
10.
by hendershot 14y ago
Sometimes solving the hard problem means jumping into a teamroom in front of a whiteboard and doing some serious brainstorming / design. That is the one thing that is very hard to do effectively over say skype. Often with remote developers