First official “How Not To…”
Arbiter here. As our beta launch begins to loom ever closer, this seems to be a good time to start revealing more of the inner workings and personalities that comprise the Net Minds DevTeam (codename: Stache 5, as in mustaches. For everyone. Even the ladies). Over the past few months, we’ve learned a lot - what to do, what not to do, best practices, not so best practices, how to properly bag your groceries, etc. Mainly, though, we’ve learned what not to do. So as our first official blog-type post, I’m kicking it off with a How Not To Do Pair Programming.
Pair programming is when two (or more) people get together to well, program. It’s a great format for not only introducing people to new technology but helping them to learn it. Or making them hate it depending on how you go about it. Use-case:
- Do NOT demand that organizers or other group members spend two hours trying to convince you to use their programming language or technology. If you are attending a Ruby on Crackz Meetup group, then you should already be interested in Crackz (or at least pretend to be interested in hopes of gaining the attention of that really cute programmer that’s in the group). Otherwise, why did you show up to the meeting? It’s a meetup. It’s not like you have to attend it. This isn’t grammar school where you are being forced to take recorder lessons by your parents because they know having music talent is supposed to help make you smarter, but you can’t seem to be coordinated enough to play any real instrument. You’re an adult. If you don’t think Crackz has any street cred, and prefer Ruby on Smackz, then by all means go get your Smackz on!
- Do NOT show up with a Packard Bell laptop that’s rubber-banded to a Sony Vaio battery pack and then offer to do the programming on your machine. I’m not hatin’ on your old school technology but by the time Windows 3.0 boots up, the meeting will be over. That’s assuming it does boot up.
- Do NOT use technical terms simply because you think they make you sound smarter. You are welcome to pontificate on the ductility of refactoring, or should I say refuctoring, of framework parameters in order to better lubricate the system. Just don’t do it out loud…in public.
- Do NOT show up and insist that a pre-established group that you have never attended before drop everything they are doing and work exclusively on YOUR problem. It’s okay to bring up a problem that you may be having with the code and tying it into the current project on hand, but don’t expect that what you are doing should take precedence over what everyone else has been working on.
There are a few more use-cases but these should cover the basics. Until next time… Arbiter out.