How much value is locked up in our social data? The information that we enter into our social networks already has explicit value. LinkedIn can tell a recruiter who you work for, and what you do there, along with what skills you have. But what implicit information is embedded in that network, which it isn't obviously communicating?

Tacit information in social network sites may include how often you post, who else you know on that network, and perhaps most importantly, what kind of person you are. A resume says one thing, but the way that you interact online says far more - and recruiters may soon be able to mine and quantify this information.

Sentiment mining is a good example. Companies such as Attensity and Lexalytics already produce systems that analyse text to produce structured data. They use these techniques to help customers with tasks such as customer relationship management, advertising optimisation, and social media monitoring. But when it comes to social media mining, these techniques are still relatively rudimentary. Searching Twitter streams for "British Airways" and "sucks", or "terrible" to see which customers are irritated so that you can reach out to them is a basic operation.

But your language says far more about you than whether you've had a bad experience on British Airways. In their book, Tribal Leadership, Dave Logan and John King identify five stages of maturity in leadership. As individuals become more mature and better able to lead, their maturity is evident in the language that they use. The language that you use at stage one is markedly different than the language you use stage five. It's more negative, self-centred, and generally victim-like. At stage five, you are using language that is more positive, and community-focused. You revel in other people's success, and identify goals that are bigger than yourself.

Heidegger once said that language is the house of being. Your language defines how you are in the world. So the way that you conduct yourself on social media sites is about more than simply avoiding unprofessional behaviour. Not posting drunken pictures of yourself on work-related social media sites is basic common sense. The smart candidate, however, will use such sites to show how mature and helpful you can be. What kinds of things are you saying on sites such as Facebook, LinkedIn, and Twitter, and how are you bringing people together and helping others? How often do you post intelligent answers on Quora and Stack Overflow?

Right now, recruiters may scan such sites manually to see what kind of leadership potential you have. In the future, natural entity recognition algorithms might score you based on parameters such as these. In an algorithmic world, such things become increasingly likely. Are you ready?

At Agile 2011 last week, we were treated to three wonderful keynotes, aside from over 260 sessions.

The first, on Tuesday morning was about positive emotions by Barbara Frederickson. I was afraid it was going to be one of those "be happy" nonsense things, but it wasn't. She discussed how to stay happy, and it was about challenging yourself, and learning how to have emotional resilience, something I'm quite interested in, and will be discussing in more detail on my createadaptablelife blog sometime in the next few weeks. I bought her book and will be reading it because I really liked her presentation. Her presentation is mostly pictures.

The second was entitled "Code" and delivered by Kevlin Henney. I hadn't heard of him, because I'm a management geek. Well, if you have not heard of him, go seek him out, find his presentation. He showed pictures of code. Yes, pictures! Aside from cute things you can do with code, one of the best analysis tools I saw was using wordle as a static analysis tool, to see what kinds of domain knowledge you have built into your code. Is that cool or what? Way cool.

But the best and last, was Linda Rising's keynote called, "The Power of an Agile Mindset." I should tell you, Linda and I are friends, as well as colleagues. I've known Linda for years, and volunteered as a shepherd on the Insights stage that she co-chaired for the conference.

 Linda discussed the fixed mindset where we go for perfection and get stuck if we don't achieve it versus the agile mindset where we adapt if discover a challenge and we try harder.

And, then came the zinger. As a society, we encourage smart little girls towards perfection in elementary school. We encourage little boys towards challenge. So, by the time we all get towards middle school/junior high, little girls do not want to fail. They don't want the challenge. They want perfection. All their lives they have been praised for perfection. How can they stop now? And boys? Why should they want perfection? All their lives they have been praised for rising to the challenge. Why should get all As? Why should they want the grades when they can find a bigger challenge?

This explains so much about why girls gravitate towards classes they can do well in, and why boys take classes they find a challenge--as a generalization. There will always be girls like me who rebel (rebelled) against society and boys who had such family pressure for perfection that they avoided the challenge.

If you are a parent now, you can help your children chart their way by encouraging them to challenge themselves by praising their effort, not their results. "Wow, look at those colors!" or "Wow, you must have worked really hard on that." or "I saw how hard you concentrated on that. Good for you!" Kids need to have their effort acknowledged, not rewarded. There's a big difference.

If you are a manager, same thing. Acknowledge the work, even if the result is not always what you expected. Some of you might be asking, "But why can't we take partial credit for partially complete stories at the end of the iteration, if we want to acknowledge effort?" Because we while we want to acknowledge effort, we do not want to reward it. That's the challenge.

I was one of the people who gave Linda a standing ovation. I will be urging her to share this presentation.

I have been looking at Microsoft's forthcoming SQL Server 2011, code-named Denali, for which the third preview has recently been released. There is plenty to say about Denali, which has many new business intelligence features as well as the intriguing ability to publish a table as a network share accessible from the file system, but I am particularly interested in the new developer tools, known as Project Juneau.

What is Project Juneau? Well, the old SQL Server Management Studio is being redone using the Visual Studio shell, but what is more interesting is the new SQL Server Database Project in the full Visual Studio, along with some new tools for working with databases.

Now at this point I have a confession to make. I have never given Visual Studio Database Projects the attention they deserve. Visual Studio 2008 instroduced a specific database edition, with a specific database project type. In Visual Studio 2010 this became a feature of the Premium and Ultimate editions. Juneau includes the next version of the database project type, now called a SQL Server Database Project.

Just in case others have also paid little attention to Visual Studio database projects, the core feature is the ability to treat databases as code.

How is a database code? It helps to break down what we typically mean by a "database":

1. The data itself.

2. The structure of the database: tables, column types, indexes.

3. Code embedded with the database structure and executed by the database manager, included stored procedures, triggers, user-defined functions.

Of these, it is only the third category that I had previously considered to be code. I was wrong though. The database schema is also code. Further, since the schema can be instantiated by running SQL create statements, you can conveniently represent a schema with that code. Execute the code, and you instantiate the database schema.

Once you start treating the database schema as code, new things become possible. You can do all the things that you usually do with code: put it under version control, refactor it, compare it with other versions, and so on.

This is what Juneau does. When you import a database into Junueau, it becomes a set of SQL create scripts.

This is also what the old Database Project does, so the concept is not new. Microsoft describes the Juneau tools as:

an evolution of the existing Visual Studio Database project type

which can be interpreted to mean that this is a new product which will eventually encompass everything the old product did and more, but that initially there are compromises: while there are new features, there are some other features mssing. Since Juneau is currently in preview it is impossible to be definitive about this yet.

Still, there is plenty of good stuff in Juneau. They follow through on another implication of treating the database as code, which is that you can debug it, by building a local version of the database. The Juneau tools do this, using a new local instance of SQL Server. When you publish the database to production, you have a bunch of options concerning how you want to handle the operation, given that there may be an existing database already present. There is always an option to generate script, rather than executing the operation immediately. The same is true if you change the schema of a connected database in Visual Studio's server explorer. The Juneau tools show all the implications of any change, including warning about data loss when necessary, and offer to generate a script rather than immediately applying the change.

Schema Compare is another useful feature. Imagine that you import am existing database into Visual Studio for application development. This takes three months; but in the meantime the admins have made some changes to the production database, maybe for security or performance reasons. If you have also added some tables and rows for the new application in your development version of the database, this can be awkward to reconcile. Schema Compare lets you see the differences easily.

A goal of the Juneau tools is to make it easy to migrate a database from one platform to another. Microsoft has in mind that some developers will be moving databases from on-premise servers to SQL Server Azure; but irrespective of whether you have cloud hosting in mind, this is a useful feature.

One of the reasons the old Database Projects are perhaps not as well known as they should be is that they are reserved for the high-end Visual Studio editions. I hope Microsoft makes the Juneau tools more widely available, because treating the database as code is a powerful idea, with benefits that should please the operations folk as well as developers.