LinkedIn Just Shot Itself in the Foot
Okay, maybe not just, because it seems may have started a few months ago, but it’s the first time it happened to me.
“Partner Message” in my Inbox? Well, at least they didn’t send me an e-mail saying I had a new message. Is nothing sacred? Spam from LinkedIn on behalf of “partners” (which, by the way, is misleading. You have to pay something to become a partner. Which means you’re really just an advertiser). They didn’t even give it any kind of design treatment to make it look different than a standard message. Either LinkedIn is desperate to find a business model that works, or the sales organization has too much power. DON’T ALIENATE YOUR USERS by mixing advertising in with the functionality!
’nuff said.
The NoSQL Movement: The Object – RDMBS Incompatability
I could prove that I’m a dinosaur and say “are you out of your mind — No SQL?” But then, I would be the one out of my mind.
I’ve always used relational databases and SQL. In fact, SQL could probably be called my second language. And while I don’t have the gripes that others may have with the language itself [http://www.kellblog.com/2010/02/24/the-database-tea-party-the-nosql-movement/], relational databases do come with a bag full of limitations and challenges. I’ll tell you my gripe.
My biggest gripe is that I believe in object oriented programming, and RDBMS doesn’t play nicely in the OO sandbox. Now of course, you could write your own data tier that calls stored procedures, or that has prepared statements. But this is asking developers to write in a second language for your application. This leads to ORMs, and for anybody who hasn’t worked with me, know now that I hate them for anything beyond simple CRUD operations.
But the biggest problem is effective modeling. You cannot effectively model some object or hierarchical relationships with RDBMS. For example, try to model n-deep dynamic menus in a relational database. Each menu node has a parent, and each menu node falls within some order relative to the other items under the same parent.
Example Menu Hierarchy
This is actually fairly easy to model in an RDBMS, but it is not very effective. Each node has a parent node (except for the root node, which I left out for the sake of this example), and each node has a numeric ordering.
Data Model for a Menu in a RDBMS
So here comes the problem. What’s the SQL for selecting out your menu structure? Since you do not know how deep the structure is (n-deep), you could do this with a crazy loop and some recursion.
- Get the root node [SELECT * from MenuNode where nodeParentNode is null]
- Get all of the first level nodes [SELECT * from MenuNode where nodeParentNode=0 ORDER BY nodeOrder ASC]
- For each node returned, get it’s children, recursively
For the example menu hierarchy above, this would result in 1 SQL call to get the root, 1 call to get its children, 1 call for each of those 4 children to look for their children, two calls to get the children of D3a and D3b, two calls to get the children of D3bA and D3bB, and one call to find the children of D3bBi. SQL round trips are expensive, and this is a lot of calls for a small menu. This does not scale at all. And this doesn’t even address the problem of maintaining order within each level of the hierarchy. Of course, there are other ways to skin this cat. nodeOrder could be replaced with nodeAbove, using more of a linked list type of structure, but that doesn’t work well either. It would probably be more efficient to grab all the nodes in one sql call, and put them back together as you load them into a proper data structure, which in and of itself will take processing and time.
The bottom line is that it’s not a natural fit.
So, NoSQL people, tell me how you would do this using other tools? CouchDB? MongoDB? Cassandra? MarkLogic? I presume this problem has been largely solved. I still don’t believe that RDBMS is a bad tool. You need to use the right tool for the problem you’re trying to solve, and be careful to minimize the total number of data persistence tools in your organization.
It’s One Thing to Hire People Smarter Than You…
…but it’s another thing to learn from them. It’s important to trust your team, but why not get the most out of the experience? Especially if you’re a technologist, you can’t ever stop learning (and probably wouldn’t want to).
“No Surprises”
This is a great follow-up to my previous post about great managers. What Great Bosses Know About ‘No Surprises’ by Jill Geisler at the Poynter Institute really hits the nail on the head regarding managers’ relationships with their employees. Are you approachable? Do you handle issues that are raised, and/or are you clear about what you can and will do about information that is raised to you?
While I’ve never had an explicit “no surprise” rule with my employees, it’s very true that I don’t want to be surprised, and would love for my team to be as open with me as possible. If you want your team to be open with you, though, you have to act on their feedback. It is important to note, though, that as managers we have to choose our battles. But at the same time, your team needs to see that they’re not wasting their time by going to you. I’m sure I’ve been guilty of not making it clear to my teams how I’ve addressed problems with the sacred cows, perhaps in an effort to protect my relationship with them. But that may not be best.
A lot to think about.
Being a Great Manager
From time to time I like to read books or articles on how to be a great manager, so that I can find ways to continuously improve. Tonight, I instead decided to reflect on the qualities I’ve tried to emulate in my [best] managers past [and hope that I've succeeded]. It’s a good way to make sure I’m not slipping, and to continue to find ways to improve. Here’s the short list of advice I’ve given myself:
- The best leaders consider themselves support for their team, rather than “bosses”
Rather than give orders, ask for suggestions and try to gain consensus. Look for the signs people give off when they need help to make progress. Help them solve their own problems, or give them access to the resources and support they need to succeed. Being an expert in what your team does is a huge bonus, but recognizing that members of your team may know some aspects better than you do is even more important. And when the team screws up; focus on how to fix it, followed by how to prevent it from happening again, rather than getting angry. In fact, let the team come up with solutions on how to prevent it from happening again. Course-correct with evidence-based suggestions; not by using a stick. - Lead by example
Show excitement. Be the first in the office, and the last out. Work collaboratively, and work hard. Show the team you’re not afraid to get your hands dirty and do some real work.
- Be organized and proactive
Plan ahead as much as possible. The more lead time you can give your team on a project, the less you’ll have to give your team frustrating last minute urgent tasks.
- Be patient, and not reactive
Don’t respond to frustrating situations immediately unless absolutely necessary (kind of like the rule of not sending e-mail when you’re angry). Don’t freak out when people screw up. The last thing anybody needs after screwing up is a lecture. Offer support, suggestions and alternatives; not criticism. - Always support your team with outsiders; but make sure you fix problems from the inside
If you want everyone to see your team as great; tell them how great they are. Focus on the positives when talking with outsiders. When the team does fail, take responsibility, and talk about what you’ve all learned from the situation, and the actionable changes that you’ve put in place to prevent a repeat. However, don’t let problems fester unaddressed within the team. If you focus with outsiders on the negatives of the team, that’s all they’ll see. Be your team’s cheerleader!
There’s certainly more, but I think a short list is most effective. What did I leave out that should have made the top 5? What would you add for the remainder of the top ten?
