Next week I'm headed down to sunny Atlanta to speak at the second CoderFaire. It's a two day event giving people the opportunity to connect across technology communities to learn new stuff and create fun things.

That's the cool thing about CoderFaire. Unlike the PHP events or the .Net events or all the other language/technology-specific events that happen out there, this one is truly and completely across technologies.

When I attended the first one last fall in Nashville, it was 200+ attendees from across the technology and industry spectrum. You had Ruby hackers hanging out with a few corporate .Net types talking with Perl summoners.

Note: The following is not legal advice.. it is an explanation of legal advice. If you need legal advice, hire an attorney.

Earlier this week, a student I'm mentoring asked about my "IP Agreements at Hackathons" post. He plans to attend the event in question and asked me specifically about the IP agreement and what it could mean for his startup.

This blog post heavily quotes my occasional collaborator Cal Evans. The quotes are used with permission. The link to the original is at the bottom.

Despite the problems with sexism in the tech community in general, the PHP community has had it pretty easy. While there are potentially a number of reasons, the founder of phpWomen Ligaya Turmell shared it this way (paraphrased from Cal):

The PHP community has not had the problem with sexism that other communities seem to have but that is because from the early days, we have had strong women role models. Women like Lara Thomson, Sara Goleman, Liz Smith, and the like have played such a prominent role in the community that no, we’ve not had as big of a problem.

So I am honestly surprised to see this promoted at a conference:

When we start projects, we often follow the naming conventions of our frameworks without even thinking about the "Why?" It almost seems silly to ask until you run into a - hopefully, legacy - codebase that has an incomplete or inconsistent scheme.

Unfortunately, web2project is one of those codebases.

For those just joining us, we forked web2project in late 2007 from dotproject which itself was started in mid 2000. Therefore some of the code goes back nearly 13 years all the way back into the PHP 3 days. Therefore, there's a little.. cruft. And naming conventions are just one piece.

First, we've had a simple Object Relational Mapper (ORM) since the earliest days. It handles our object to database (and back) conversion with no configuration. While there are many arguments for and against ORMs, it works and makes things simple.

Over the past decade, I've started, been employed by, and advised a flock of startups. More recently, I've been an advisor at events like Startup Weekend, Lean Startup Machine, and the new Longhorn Startup Program at UT.

One of the big pushes in recent years - I suspect primarily due to Lean Startup - is customer interviews. At some point during these interviews, the "would" question comes up. Generally it's structured something like this:

"Would you like a product that makes X better?"

And every group celebrates that "95% of our customers said yes!"

That's great, right?  Well.. let's break this down a bit.

First of all, until they give you money, they're not a customer. That's it plain and simple.. so therefore, these are potential customers or potential users but not customers.

Almost six years ago now (whoa!), I was a regular agitator in the Washington, DC PHP Developer's Community (DCPHP). The community was probably a hundred people with skills ranging from total newbs who couldn't spell PHP to contributors to major open source projects. At that point, we consisted solely of a monthly presentation-style meeting and a mailing list.

And without fail, traffic on the mailing list started getting.. aggressive.

To be clear, there was nothing wrong with the group, that's just how email goes.

Email is a lossy way to communicate. You don't see the smiles or frowns, hear the tone of voice, or see the frustration that elicited that response. And misinterpretations are going to happen. Now take software developers - a culture known for being direct (aka blunt) and sometimes inappropriately so - and trouble is guaranteed.