Building something? Working as a team? Use these Kevin-isms to keep each other efficient, tested, and moving forward.
I have this friend “Kevin” who has mastered how to get teams to self organize and think without being lead. He does it with questions which he pulled from the socratic method and bits of wisdom he has collected over his career coaching and writing software.
While you are building out your dream, and you come to a point where a decision is needing to be made. Try these questions and helpful rules of thumb to simplify and get it done.
What’s the simplest thing that could possibly work?
Yes, there are some awesome things you can build and wouldn’t that be great. But you need to get it built first. What is the least you need to do?
Why not both?
Sometimes debates come down to two competing ideas, why can’t you build both of them? This question helps you figure out the argument that separates them.
How do you make this easy to reason about?
At some point you won’t remember why you build this or someone else will have to figure this out. Remove dependencies to make it easier to reason about.
Deleted code is tested code.
This saying makes you feel better when you chop away something you just spent the last week building.
Deploy early and often.
Un-deployed code has no value. If you got it built, get it out there so someone can use it.
Leave ideas in code as comments, not as features
It’s easy to suddenly have a brilliant idea, if you have to put it somewhere in the code, make a comment not a new function. Come back to it later if you still think it's awesome.
All decisions eventually become regrettable.
Don’t get hung up on debates, eventually you will learn something that unravels the original reasoning. Leaving test to document behavior and making your code easy to reason about will make it easier to change later.
Don’t build today what you can put off until tomorrow.
Be disciplined, every line of code you add is a line you have to test. So don't waste all that effort making code that isn't going to add business value. Wait until the "last responsible moment" to add new code because that is when you will the most.
If you care, you will test it.
Tests are your chance to explain the desired behavior, this is the only way to know if you are done. Test that are being run regularly are the only real documentation of your code and project.
Build first if you are prototyping, test first if you are going to use it.
Testing first is super hard right at the beginning when you are still trying to get off the ground. But after you get something to work, start figuring out how you are going to test it.
Don’t code alone.
Buddy up, it keeps you from wasting time in a creative haze. Paired programming and pull requests will help you fight the battle against technical debt.