Before you place a line or add a parameter, think through every way this family might be used. Define the goal. Plan for edge cases. Solve problems before they happen. The goal is to hand off something that just works—like it read their mind. That’s white glove thinking from start to finish.
Do it the same way every time. Naming, parameters, behavior—consistency is what makes the system work.
If it’s not in the plan, don’t build it. Stay focused on the defined goals. Every added feature, fix, or idea should serve the original intent. Keep it clean. Minimize distractions. Deliver exactly what’s needed—nothing more, nothing less.
Start with code—understand the rules, the reach ranges, the limits. Then look at how Forum handles it. Our standard may go beyond code, and in most cases, it takes precedence. The goal is to make both work together. But when there’s a conflict, Andrew’s word is final.
A family is never alone. It should work smoothly with others—think about how it connects, snaps, and schedules.
Start with the parts that will show up in schedules and sheets. These matter most to the team and the client.
Before modeling, check the parameters and formulas. Make sure the brain works before building the body.
Once it works and meets code, then polish the nice details.
Document how and why it was built. Add notes, name things clearly, and explain the logic. This isn’t just for today—it’s for the next person who has to fix, adjust, or learn from it. Good documentation saves time, avoids confusion, and keeps the standard alive.
Most users won’t notice when you do it right—but they’ll definitely notice when you miss something. That’s the job. Quiet success is normal. Missed details make noise. Build with that in mind.
“User didn’t notice your work?
Good.
That means it worked flawlessly.” - Quote Inspired By Jocko Willink