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.
Last night, due to the graces of On Demand video, Jenn and I watched The Master of Disguise.
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.
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?
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.
I’m what you could consider an “entry level” user when it comes to financial services. I don’t know all the terminology. I don’t know what everything means. I’m not intuitive when it comes to figuring financial things out. What I know is simple stuff - what accounts I have, what I want to do, what I want to see. Very simple.
I used to have an account with a stock brokerage in Portland called “Bidwell & Co.” I liked them. The customer service representatives were friendly, my monthly statement from them was easy to understand (big print, small words, lots of pictures), and when I wanted to do something on their web site, it was easy to figure out. If I wanted to see my portfolio, I clicked the “Portfolio” button. If I wanted to sell stock, I clicked the “Sell” button. Even more key, when I got to my destination (“Portfolio” or “Sell” or what have you), the interface was very simple
- I wasn’t overwhelmed with buttons and text boxes and options and words I didn’t understand. For things I didn’t get, there was help all over the page that I could click on and read about the tough stuff.
Bidwell was bought out by Ameritrade recently. My account was transferred over, and now I have to manage my stock via the Ameritrade site.
I don’t get it. Seriously, I don’t. There are far too many options to know which one I need to click to get to where I want to go. Want to see your portfolio? Click a link (hidden in a list of like 50 other links) along the side of the page marked “Positions.” Positions? What the hell is that supposed to mean? Click on that, though, and you see an abbreviated version of your portfolio. Want to see a more detailed view? I did. I wanted to see my portfolio broken out by individual lots of stock. That’s under “Gain/Loss Tracker” - a whole new link along the left of the screen - then you have to select the “Detail” view from a dropdown box, then click the “Update” button. Isn’t that a portfolio thing? Maybe not. It is from the uninitiated perspective. (I actually had to call them to figure this out.)
Got a Capital One credit card? Their site rocks. There are four tabs at the top of the page you can choose from. One gets you a view of your current activity, one gets you your statement, one lets you pay your bill online, and one gets you a list of everything else you can do. Click on one and you know what? You get exactly what you’re expecting. Very simple.
Got a BankOne credit card? Ever try their site? The print is tiny tiny tiny, and they try to cram way too many options onto the page. Do I really need to be able to get from any page to any other page in one click? No. I need the interface to make sense. More mouse clicks is not the problem; being able to find what I want to do and understand what I’m looking at is the problem.
I think financial institutions might want to think about that. My grandparents, for example, who do own stocks and bonds and all that, will never ever be able to manage any of that online because there’s too much going on. Stop listening to these so-called interface rating services. I’ve seen the sites they rate highly; it’s scary what they think is easy to use. Stop ranking things on how many mouse clicks it takes to get somewhere. Instead, think about how things are logically. Sure, you may have the technical ability to enable the most flexible web site ever - offer 2000 ways to transfer money from one account to the next or whatever - but in all honesty, how many do customers really want?
Here’s an idea: Take a page from the search engines and offer two versions of the user interface. One version is the “basic” version - for the 95% of people who want to just get the job done. The other version is the “advanced” version - for the 5% of people who need that ultra flexibility.
Or, better, here’s another idea: Get a beginning banking user (not unlike myself) to help design the interface. Listen to him (or her) when he tells you that the interface is too complicated. Consider the fact that what you’re hearing is probably more important than what you heard from the interface rating institution because if you can’t get a beginning banking user to understand how your product works, they aren’t going to use it. Get grandparents in there to try it out. Get eighth graders in there, fresh out of personal finance class, to try it out. If they can all figure it out, that’s where you need to be.
[Important Note: This is all definitely my personal opinion and absolutely not [necessarily] my employer’s. (Seeing as how I work for a company that makes financial web sites and all…)]