Results tagged “work” from Pumanchu

Ah, hell. How do I love thee? Let me enumerate (python range?) the ways:

• Rebuilding the 3dsmax OLE interface functions I depended on at my last job. From hell's heart, I stab at thee, Maxscript.
• Using python unittest to verify my library of poorly written utility functions and classes.
• Using eclipse and PyDev with an actual seat of PyDevExtensions to remove errors and warnings and debug classes.
• Author a scons data build.

The real trick is that this is pretty much solo, although slightly steered. Besides the python module writing, it's all stuff I've done already, so it can drag at times. But today was full of the promise of having almost all the pieces together; python interpreter importing the win32com.client calling the 3dsmax ole object's exposed functions, the scons scanner for the animation file enumerating the deps. Just short a couple of builders and scripts. Almost there ...

• Forced the issue of moving internal tools bugs out of project databases and into an internal tools bug database.

• Migrated bugs into bugzilla, patching importxml.pl in the process.

• Written perforce trigger in python.
  

• Update: convincing engineering to (re)implement it on precious servers much harder.

• Enable a spec depot so engineers can recover their borked build clientspecs and I can rest easy.
• Debugged some crazy low priority game bugs.
• Wikified lots of wisdom.
• Wrap Xenon SDK dll functions with ctypes.
• Read the GUITAR white papers and a similar interpretation in a how-to-auto-test book.
• Try to recruit people at GDC
• Sucker people into playing warfish.
• Used python to start a framework for automated testing.

But more than all this, is the cutting through red tape and internal resistance to good ideas. That is a very tiring battle indeed.

But days went by, Friday loomed, and I hadn't had my review yet. I became worried - was my TV a kickback in lieu of a review and raise? Was I going to get the royal shaft supreme? Even the UI Guy hadn't gotten a new display, and it is his job to ensure that every video mode is correctly supported and designed for. WTF was going on?

Well, it turns out the TV mercifully isn't my raise. I had a pretty good review, by which I mean there was praise and good criticisms. I feel good moving forward, and happy to be working there. And I still get to keep the TV where it is. Yay.

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;

1. 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.
2. 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.
3. Have and stick to core hours for the developers so they can be relied on to be there when you need them.

The good news? I had to learn some C# and windows .NET widgets. I got my own seat of vc7 so I don't have to nag engineers for things I can figure out myself. I got to break my old habits, really. And I got to break some of theirs by checking in a Perl script that proves useful. Yay.