Test Before Yes

My first ("real" / "grown-up") job was with a web company back in 2006. Those were the days when streaming was becoming a novel concept, and we were known as "new media."

Probably the biggest lesson I learned was the mantra: "Test before Yes."

We flew pretty fast and loose with best practices - a "deployment" was just uploading files to the prod web server, with no version control other than local backups. It was risky, but it also allowed us to move at a breakneck pace.

We were constantly trying new things, experimenting, building - and we were regularly asked: "Can you guys build ___[fill in the blank]____...?"

Being the young whipper-snapper dev, I said yes to everything. Yes! I'll build a site poll in PHP. Yes, I'll build a Question of the Day feature!

Saying "Yes" allowed me to work on a lot of cool projects. But it also got me into tough spots when I realized my "Yes" probably should have been a "No." But we hated no - the internet was a world of possibility, and to shoot an idea down was such a buzzkill.

Eventually, I learned to respond with enthusiasm without committing: "That sounds really cool, let me try some things out to see whether we can make it work! I'll get back to you on whether we can do it before the end of the day."


Let's Clear Up The Ambiguity!

FAQs for a Software Engineering Hiring Manager

7 Steps to Writing an Amazing Resume

7 Steps to Building your Portfolio MVP

On Systems Debt