At work, I had to defend my use of Perl and swear not to check any into the build tree, no matter how useful. This is a decided shame since I am effective with it.
I understand my peer's take on this; we've all been bitten by having to maintain something that is a pain-in-the-ass to read. Perl syntax is a little weird to those not steeped in it. And it did take a few years to get the hang of non-module, shell script-style development with it. Finding a Perl GUI debugger really flipped the switch for me.
Anyways, it reminded me of a few good things we used to do at my last job;
I understand my peer's take on this; we've all been bitten by having to maintain something that is a pain-in-the-ass to read. Perl syntax is a little weird to those not steeped in it. And it did take a few years to get the hang of non-module, shell script-style development with it. Finding a Perl GUI debugger really flipped the switch for me.
Anyways, it reminded me of a few good things we used to do at my last job;
- Always check in and use the checked in headers, libs, and tools in the build (including the Perl interpreter)
- This kept us from having everyone have to install the right versions of things, and guaranteed that a user sync'd to head could build
- This is in opposition to relying on the user's local environment and installed SDKs to be up-to-date.
- Check your calendar and show up to meetings you were called to.
- Setting development policy minus attendees never works. Good reason to have a wiki or versioned word doc.
- Have and stick to core hours for the developers so they can be relied on to be there when you need them.
Leave a comment