The more I work in tech, and the more I write in this blog, I’m finding that I write more about work/tech stuff and less about what I’ve been up to. The thing is, what I’m usually up to is tech stuff.

I’m not sure how my readers feel about this (or even if I have any readers other than the Google search bots) because you gang out there don’t comment. Not that I’m soliciting comments for comments’ sake, mind you, I’m just sort of going by intuition here.

I’m pondering the idea of splitting out my tech-related stuff into a fully separate blog. That would allow the folks coming for the tech to see what they want and the folks trying to keep up with me personally to see what they want, ne’er the twain shall meet.

Again, though, the problem is that what I’m usually up to is tech, which means the people who want to know what I’m doing should probably just assume, should I split the two, that I’m simply busy with work things that you really wouldn’t care about.

Any opinions on that?

I’m also thinking of creating a more static “downloads” section for the little programs I’m throwing up here. Not that I think I’m going to have some massive load of software to download, but I figure it might make it easier for the folks coming for the downloads to have a nice, central spot that has the latest info in a less bloggy format.

Questions? Comments?

I was talking to Greg yesterday about a discussion he was having with Chris about job skills every employee should have.

Okay, so I don’t remember exactly which ones they came up with, but I know what my thoughts are, so here’s a list of skills I think everyone should have when it comes to the workplace:

Disagree and Commit (or, “You don’t have to like it, you just have to do it”): You will very rarely be on a project involving more than one person and come to consensus on how the project will go. There will be times when the project leaders ask for your opinion, you provide it, and you’re overruled. Once the decision is made on a direction to go, once all parties have been heard and it’s been decided, you don’t have to like the decision, you just have to follow it. Fighting it every step of the way and continuing to bring decisions back to the table when they’ve already been made is entirely counterproductive. (My personal corollary to this one is that I retain the right to complain about it all I want, but I’ll still go with the flow. Maybe that’s still a tiny bit counterproductive, but it’s the only way I’ll be okay with doing something I disagree with.)

Commitment Follow-through: If you say you’re going to do something, do it. Don’t tell people in the meeting that you’re on top of something when you’re not. If you aren’t going to be able to meet the commitment you made, at least notify people early on so a contingency plan can be arrived at. If people are counting on you to get stuff done and you’ve committed to it, do your best to get it done.

Ownership and Personal Pride: When you’re working on a project, give it your all. Take ownership of the thing (yeah, “ownership” is one of those buzzwords) and have a little pride about it. The way your end of the project turns out reflects on how people see your quality of work. Have a little pride and do a good job. “Good enough” is not always good enough.

Writing 101: Everyone should know how to write with, at a minimum, reasonable grammar and correct punctuation. I’ll give a little on the spelling, but you should know at least how to spell simple words. Learn the difference between “its” and “it’s.” Know when to use “their,” “there,” and “they’re.” Figure out how to use apostrophes and commas. Knowing how to write (say, at an eighth grade level?) will help you to better convey your ideas and to be better understood.

Phone Etiquette: Not the “greetings and salutations” portion of phone etiquette, but other stuff, like “when it’s okay to use the speakerphone” or “how to leave a voicemail message.” For example, just because you have a speakerphone doesn’t mean you should call everyone on it. It’s still okay to use the handset (or headset). (Oh, and it is never okay to get your voicemail over the speakerphone, particularly if you’re in a cubicle environment.)

Under-promise and Over-deliver: You’ll come to find that when you’re working on a project, if you say it’ll take 5 days and it takes 10, that’s not so good. That’s what makes a project go over schedule and over budget. Plan for contingencies and worst-case scenarios. Provide time and budget estimates for both, but expect to take the longer amount of time. If you come in ahead of schedule and under budget, that’s a pleasant surprise; if you come in late and over budget, you’ll be disappointing folks at the least. I’m not recommending you sandbag and double every time estimate, but the concept of under-promise and over-deliver is a good one to maintain.

media, movies comments edit

Last night, due to the graces of On Demand video, Jenn and I watched The Master of Disguise.

Hoooo boy.

How do movies like this get made? I mean, who reads a script like that and says, “Hey, this will be great on film! Let’s do it!” I understand that there’s a market for children’s films, but even kids are going to wonder what the makers of this pile of shit were smoking.

I think I laughed like four times. Mostly it was at the quips the grandfather character used to tell Dana Carvey to shut up. Stuff like “curb your yammering skullcave,” which I will now attempt to work into daily conversation somehow. It cracked me up because it was so out of nowhere… but those were about the only things that were any good. (Do you remember when Dana Carvey was actually funny? I do. I miss those days.)

That’s an hour and a half of my life I will never reclaim. (And I’m not the only one who thinks so.) I am actually dumber for having watched that. I award myself no points, and may God have mercy on my soul.

net comments edit

When it comes to programming, I will admit I am a spoiled, whiny baby. I hate low-level crap. I am not a C++ programmer. Sure, it may be powerful and flexible and yadda yadda yadda, but having to deal with all of the little things in there is such a pain. I like higher level languages that abstract that away. I’m a big fan of C#, Perl, Smalltalk, and whatnot. (You may or may not like any or all of those. Too bad. They’re my personal preferences… even if I haven’t written in Smalltalk for years.)

I’m working on this project where I want to put the Windows “Send To” menu inside the Solution Explorer of Visual Studio .NET. I’m finding that in order to do that, you have to do some pretty low-level shit. As such, I started browsing around in the Shell Programming section of MSDN.

Combining the knowledge I was gleaning from that and some code snippets and things I found online, I started compiling a library of imported shell programming related objects into a big library - shell programming gone C#, right?

The problem I’m having is that I can’t get it to quite work right. The marshaling of parameters is befuddling me because there doesn’t seem to be a consistent translation from C# managed types to C++ unmanaged types (of course, this is probably my lack of education speaking). Where I can get some methods to work correctly, others don’t seem to want to cooperate.

I decided to set about converting the various sample code snippets found on the MSDN shell programming site to my C# library, figuring that’d be a good way to test - code that supposedly works, just translated to the new language. No problem, right?

Huge problem.

I’ve been fighting this thing for quite some time now and I just can’t seem to get it to work. Now, here’s where you’re going to smack me: It’s making me think I should just learn the C++ way and do it in C++.

And you say, “You don’t already know how to do it in C++?” To which I respond, “Well… no.” Okay, I admit, that’s probably pretty fundamental, but if I can read how it’s done in C++, and I can see how that works in the documentation, I don’t see how copying and pasting example code into a sample project is going to make it any easier to convert the stuff.

Which leaves me thinking I should just leave the conversion of shell stuff to the folks who do shell programming. I’ll DllImport my way to freedom and leisure where necessary, and/or maybe just write the thing in managed C++ that I’ll call from my VS add-in. I’ve seen the managed Send To example out there; maybe I’ll start with that. Regardless, I can only beat my head against something for so long before I decide it’s not worth the effort and leave it to the professionals. My bag is web apps, not COM interop and low-level shell programming.