This spring, Sandra and I decided to take a vacation to St. Louis, Missouri with Charlotte and my mother.
I did find some humor that almost universally, the response was "St. Louis? Why would you want to go there? Do you have family there?" from friends and coworkers of both Sandra and my mother.
Of course, you may be asking yourself the same. But I decided a while ago that I hate vacations, but I love exploring and visiting new places and because Charlotte is still very young, for practical reasons, it's easier to visit destinations that are a relatively short flight away and has some kid friendly attractions.
We left on a Saturday afternoon and arrived at STL (to rain and cold weather). We decided to have dinner at a Steak and Shake near the hotel as both of us have seen them in our previous stops through the midwest but never stopped at one. It was pretty good -- right up there with Five Guys and In-&-Out.
From there, we made our way to City Museum.
I will say this: I think this alone is worth visiting STL for if you have children (or if you're a big kid at heart). City Museum cannot really be described in words. It is a fantasy world in the truest sense of that word -- it is the world of Labyrinth, NeverEnding Story, Goonies, and a dash of Willy Wonka's chocolate factory realized in our world. You can get lost in there for days exploring every nook of the Enchanted Caves or crawling through the various tunnels and passage ways.
Forget Disney; City Museum is the one place that every child should have a chance to visit once in their lifetime (before they become too big to fit into some of the passages!).
Be sure to stop here on a weekend when it's open until midnight and there are tons of kids around -- you can really feel the magic and energy of this place come to life.
I definitely plan on bringing my daughter back here at least one more time in her lifetime.
St. Louis Zoo
Fortunately, our second day there was a gorgeous day as we had planned to visit St. Louis Zoo. Having visited San Diego Zoo twice now, St. Louis Zoo had big benchmark to live up to.
One important thing to note is that there is no entrance fee to this zoo. You might think that it would impact the quality of the zoo, but I am pretty amazed at the quality, quantity, and variety of exhibits at this zoo. And because entrance to the zoo is free, we spread out our visits and returned two times (three visits total over three days).
I have to say, in terms of the overall design, it certainly doesn't come close to San Diego, but in terms of the exhibits? I think it blows San Diego away! The herpatarium, bird house and garden, and the insectarium in particular were top notch; some of the best exhibits of their kind that I've seen at any zoo. Sandra and I also noted that the animals at this zoo were particularly active compared to animals at many other zoos that we've been to.
We really enjoyed the zoo and Charlotte had a great time seeing many of the animals that she's learned about in person. The only disappointment is that her favorite animal seemed to be "Mr. Rhino" who decided he would hide on the second and third trips (the third trip was specifically to see him).
Missouri Botanical Garden
Also on our agenda was the Missouri Botanical Garden or "mobot". Because the zoo was free to reenter and because the weather on the second day was amazing, we decided to leave the zoo early and visit mobot. At this time of year, there's not much in the outdoor exhibits so it's hard to compare it to say Longwood Gardens (which we frequent) or Cheekwood. And certainly, it felt smaller than either of those (Longwood for sure), but I still found it to be beautiful and interesting, especially the Climatron and Temperate House.
It is unfortunate that we did a poor job of timing our visit. Had we scheduled our trip 3-4 weeks later, mobot would have surely been amazing as it would be in full spring bloom by then.
Of course, we also stopped downtown to see The Arch on our third day (after another stop at the zoo to visit the exhibits we skipped the day before). I didn't expect much out of it, but I do have to say that driving up to it through the city, the structure is massive and seemingly alien in nature; it doesn't seem of this world -- I couldn't take my eyes off of it!
While there was not much to see while we were there, we thought it would be cool to show pictures of it to Charlotte when she gets older so we stopped and took pictures and visited the Gateway Museum in the lower level.
We showed up at Pappy's somewhat late for lunch as Charlotte decided to take a nap. I was hoping that by getting in around 2, we would avoid most of the crowd and it sure seemed promising walking up to the entrance. However, upon opening the door, we were greeted with a line that was at least 50 patrons long. We debated on staying given that Charlotte was surely hungry and it looked like it would be at least 45 minutes before we got to eat. But we stuck it out and it was worth it (so worth it).
I would say that this was one of the highlights of the trip. The ribs were fantastic -- smokey, crisp on the outside, tender and moist on the inside, and so flavorful. The pulled pork and turkey were amazing as well. We ate a good sized portion, but none of it left us feeling heavy. While I normally hate waiting in line for anything, this was definitely one time where I'm glad that we stuck around.
City Coffeehouse and Creperie
For breakfast on our final day, we decided to get a special treat and headed into the business district to hit up City Coffeehouse and Creperie.
This is definitely a must-visit destination if you plan on stopping here as the crepes were all delicious and fantastic (we each ordered a different one and shared them).
What We Missed
There are a few places that we didn't make it to either because they weren't open yet or the timing didn't work out; I think we will definitely be back to STL once more.
STL also seemed to have some great nightlife scenes and many, many awesome breweries and pubs. It's a shame that Sandra and I weren't able to get do visit these on this trip!
Contrary to popular sentiment, St. Louis is a fantastic place to take a vacation, especially if you have kids. City Museum, the zoo, and mobot are enough to keep you occupied for quite a while and because the zoo doesn't have an entrance fee, you can really plan multiple trips to the zoo and break up your trip. This is great because it gives you an opportunity to get out there and try some of the amazing food in the area.
I also found that getting around STL was pretty easy. We never really hit any traffic nor did we have to drive very far for anything that we wanted to do; everything was within a 15-20 minute drive, tops!
Prices were great as well. Of course, the zoo is free. Mobot is $8 for adults (compared to $26 at Longwood Gardens). City Museum is $12 for adults so I think it's a very wallet friendly destination for families.
If you plan on visiting STL, I would definitely recommend no earlier than the middle of April but optimally for the beginning of May as I'm sure the scenery at the zoo, mobot, the Arch, and Grant's Farm would be beautiful by then.
A curious thing.
We were working on a custom view for one of our lists and found that we were not able to retrieve a list item using a CAML query that should have worked.
After spending quite a bit of time studying the query itself, I decided to look at the actual SQL that was being generated.
This list has a large number of columns and SharePoint was wrapping the rows according to the boundary conditions. For example, when you have 16 integer or user fields, the 17th field of this type will force the row to wrap into a second row.
When this occurs, in the AllUserData table, you will see multiple rows for the same item, each with a different tp_RowOrdinal. Looking in the table, it was clear that the value was in the table, but it was not on the first row (tp_RowOrdinal="0").
The problem with this is that for some odd reason, the SQL query that gets generated when you query on the field that has wrapped onto the second row inexplicably only queries the first row.
In the generated SQL, I found the following:
...AND (UserData.tp_RowOrdinal=0) AND ((UserData.[int10] = N''34'') ...
In this case, "34" represents the ID of a user and "int10" represents the column that the data is in. But the key is that even though this data occurred in the row with ordinal 2, the SQL will filter only on the row with ordinal 0.
This is kind of inexplicably bad but not all is lost.
The dirty workaround is that you can do one of two things:
- If you are adding the columns manually or in a single content type, you need to ensure that the field(s) that you want to query against appear earlier in your content type definition or they get added earlier.
- If you are adding the columns via content types in a Schema.xml file, you need to ensure (1) above and that you add that content type to the list earlier in the XML.
There is an MSDN discussion on this, but Microsoft seems to claim that this is not a "bug" (it most certainly is).
I was listening to a piece on NPR on 6 Steps To Find A Job For Soon-To-Be College Grads and it got me thinking about my resume (Word version), what I'm doing right, what I could be doing better, and how to make it stand out.
One of things that I think that has worked for me (really well, I'm guessing based on the response rate to my resume, feedback I've gotten when I've copied this format for others in my family, and comments made to me by interviewers) is that my resume uses a two column format.
I have interviewed quite a number of people over the last several years for various projects and I'd say only 1-2 resumes have popped up in my inbox in two column format.
But there is a very good reason why I think it's a successful format -- especially for techies: you can present all of the key information in the first page and it ensures that you can put your most recent experience up front and center without losing the ability to call out additional information in a side column. Almost every resume I've gotten from any resource with actual experience has been longer than one page. But the problem with the traditional one column format is that:
- It is not an optimal use of space because in many cases, you don't have enough text to go the full width of the page (for example, a bullet list of skills) or going the full width of the page makes reading the text more laborious (for example, using a comma separate list instead of a bullet list).
- It becomes more difficult to get a concise view of a candidate without having to flip pages or scroll. With a properly configured two column resume, I can easily get a very concise understanding of a candidate by simply reading the first page without having to jump around.
I think one additional benefit is that it allows you to more clearly isolate your experience from the other sections of your resume. What this means is that you have your experience all in one vertical list without breaks or sections. Even though it's a minor nuance, I think it makes the information easier to digest as it makes a clear spatial delineation of content.
The format is flexible. I like to put my personal statement and education on the side column on my first page, but you can easily switch it with whatever information you deem to be more pertinent to how you want to express your qualifications.
One closing bit of analysis is that the format works in this age because many web sites and blogs are designed in the same manner in terms of visual layout with a primary column of content and a secondary, smaller side bar of navigation or smaller chunks of content. I think that this is very effective because it creates an easy analog to how a reviewer of your resume would visually navigate a web site.
In some discussions regarding Windows 8 and Surface, it has occurred to me how miserably Microsoft has failed in advertising the Surface.
Check this ad:
There is no substance to their message. You can watch this ad 100 times and not understand what is being sold here.
Look at Apple's ads for the iPad or i-Anything.
"Hey, look at how simple this is!"
"Look at how you can do all the things you want to do easily!"
Their recent ads for the iPad mini are brilliant in its simplicity: just two tablets side by side with people video chatting, playing games, playing apps, etc. They've effectively communicated "Hey, it's the same thing, only smaller" (whether this is true or not) and "It's so easy, even your grandmother can use it" and "Look, you can stay in touch and communicate so easily with your loved ones!".
This is what consumers want. Whether iOS is actually easier or not is another debate, but great advertising creates the perception that iOS is indeed the easiest to use. Consumers can connect with this advertising because it is simple, straightforward, and effective in communicating a brand image and embodied that brand image: "It's so simple, we don't need gimmicks to sell it."
What has the Microsoft campaign given us? What is the message? What is the key selling point of the Surface according to these ads? How is Microsoft capturing the market? A bunch of folks dancing around clicking a tablet into a keyboard dock. Is this ad selling me the dock? Is this an accessory? Why do I want to buy this hardware? Does it come with great software? A consumer can't tell based on that ad. Microsoft has literally given consumers the song and dance -- a gimmick, if you will.
This would not be the first time that Microsoft has failed miserably in designing a marketing campaign lest we forget the abomination of those Seinfeld commercials. They had a pretty good stint with Windows Phone, the "I'm a PC" campaign, and the a few clever bing commercials as well. Their tablet marketing campaign has been lackluster and has failed to differentiate themselves from the competitors. They have not demonstrated a reason to choose a Microsoft tablet over an iPad or Android tablet when they could have easily done so with an effective campaign around the software.
There have been many defenders of Microsoft online in various forums, but I'm not sure why there are so many fervent Microsoft defenders when clearly, the Win8 release has been a mess on nearly every possible level from the software architecture to the hardware to the marketing. "Yeah, but it's perfectly fine if you do this and that" is not a good defense because the operating system should be usable right out of the box.
It occurred to me that enterprise social is kind of like holiday parties -- AKA: enterprise socials.
When you go to a holiday party, you probably primarily interact with and socialize with the group of people that you work with on a day to day basis anyways.
But more importantly, according to recent studies, while 9 in 10 companies plan to have a holiday party, only 1 in 20 employees actually want to have a holiday party.
In my opinion, this more or less mirrors top down enterprise social initiatives. Employees would probably rather have better communication and collaboration tools and don't actually care about social tools (I make the distinction because you can have communication and collaboration without social).
It is the leadership that crumbles to the sexy sales pitch of enterprise social, failing to make the distinction between communication, collaboration, and social. Give your employees more communication and collaboration and skip the social.
Every once in a while, I'll talk to a colleague and the topic of SharePoint and "social" will come up. I mean literally, every iteration of SharePoint adds some other "social" feature or another. It always leads me shaking my head.
You see, Microsoft really talks a great game when it comes to social and SharePoint. It's the next big thing! It's all new! Look at all this cool stuff that you can do!
But all you have to ask yourself is whether Microsoft has proven themselves in any aspect of social. The answer is simple: no. And social for SharePoint is no different.
There is a very fundamental reason why it's a non-starter: social for the enterprise is stupid.
"But doesn't NewsGator make millions of dollars?"
Sure, but social for the enterprise is still stupid.
"But didn't you hear? They purchase Yammer!"
Yes, but social for the enterprise is still fundamentally broken. Never forget: Google once offered Groupon $6 billion -- doesn't mean that it was ever a good idea.
At the core of why social and the enterprise is fail, it's actually pretty simple as it comes down to one main issue: Portability.
Of course, for most people, their social networks often include a nexus around co-workers and professional acquaintances. The perfect case for social for the enterprise, right? Wrong! Because LinkedIn already has that covered and, more importantly, a professional social network on LinkedIn is portable. If I leave the company, I can still stay in touch with all of my contacts and connections at my previous companies via LinkedIn whereas my investment in a closed network is entirely thrown out the window the moment I leave a company.
A closed-system, non-portable social network is a useless one; it's a non-starter.
Aside from the major flaw of lack of portability, there are a few other shortcomings that come to mind.
The first is that, in a large company, I simply don't care about 99.5% of the people in the company; I'm only connected to these people because we happen to be employed by the same company, but that could change at any moment. In a small company, I will already have everyone added in LinkedIn or Facebook. What good is a closed-system social network when the people in that network would largely be people I already work with on a daily basis?
The second is that, in my opinion, what is of more value to teams are not social capabilities, but collaboration capabilities. Social is like the antithesis of task-oriented collaboration capabilities. Teams would get more value out of an investment collaboration capabilities than an investment in social capabilities. What I need from my enterprise platform is not social, but tools to help me and my team get things done. You want to know what other people are working on, but usually in the common context of a project or such so tools that are focused on communication and collaboration in the context of project workgroups seems much more useful and practical an investment to me.
The third is that many companies include a forum or discussion type system in their social initiatives. I saw this at CSC where Jive was deployed. But this kind of circles back to the closed-system problem: if I have a question or if I'm working on a hard technical problem, am I more likely to find an expert within my company? Or am I more likely to find an expert within the global community? This approach makes sense maybe within Microsoft or Google, where the concentration of highly specialized subject area experts is high. But in a consulting company, for example, it is less likely to be of any value as the global community will include a greater breadth of subject matter experts with a more extensive depth of knowledge.
Microsoft and social -- especially in the enterprise -- is pretty much a pointless endeavor, in my opinion.
Reflecting on the past year and a half, I've come to some conclusions on how development teams can be successful in delivering software. I don't think any of them are major or relevatory, but I think each team and each project has a different take on the same ideas. Here are mine:
During our active build phase, we release a new build every week and each build is functional software that incrementally incorporates requirements and defect fixes from previous builds. This has given us the benefit of allowing our customer to preview the software and help us identify flaws or areas requiring additional clarity in the requirements continuously and early in the process.
It might sound insane, but it is possible to release weekly builds because our solution incorporates a heavy dose of automation where it counts on many levels.
- We've removed raw SQL from the equation, relying purely on FluentNHibernate and NHibernate to automatically generate our schema
- We've invested in building tools to automate the export and re-import of configuration and data, allowing us to easily and quickly reset our development environments entirely with standard test data (bonus: the same tool allows us to move configuration and data from environment to environment)
- We've invested in idiot-proofing our installs so that they are boiled down to a few scripts
- We've built automated build scripts that package everything up neatly and even FTPs a build to our integration and test environments
- Our domain data model is 90% generated automatically from content schemas (SharePoint content types) which we have to create anyways.
Because of the automation, tasks which would otherwise be expensive are cheap to execute.
It also cuts down on mistakes and missed steps.
Our team is 100% geographically dispersed with developers and team members in Vietnam, Mexico, Virginia, New Jersey and California.
But relatively speaking, we meet very infrequently. Two development team meetings a week: one at the start of the week -- our "A" meeting -- and one towards the end of the week -- our "B" meeting. We use the "A" meeting to discuss our deliverables for the week and the "B" meeting to discuss the outcome of our weekly sprint walkthroughs, any adjustments that need to be made, and so on.
We also use these sessions as show-and-tell to let everyone see the progress and changes being made by different team members as well as to inform of upcoming breaking changes and mitigating actions required downstream.
Otherwise, developers are encouraged to have long spans of uninterrupted work time instead of constantly being pulled into meetings. One-on-one sessions and communications occur as necessary, but this recipe has been very successful in minimizing the amount of time the team spends huddled up in conference calls and gives everyone more time to solve problems.
Meet with a Purpose
Every meeting should have an agenda and an outcome (an action, decision, or an issue for followup). Demand a bullet-listed agenda when someone sends you a meeting request and provide one if you need to schedule a meeting. Ensure that the goal and outcome of the meeting is clear for all parties and schedule new meetings to resolve items not on the agenda or do not contribute to the outcome.
Additionally, create a record of every meeting. Who attended? What was covered? What was not covered? What was left open? What are the action items? Ensure that this record is easily accessible (wiki or forum system is perfect for recording these details) and email a copy to all participants and other relevant parties to ensure that everyone has the same understanding of what was just discussed. This basic task can often clear up misunderstandings before they become systemic issues. I take the burden on myself to record and followup with major bullet points from the meetings and it's saved my butt many times when following up with customers.
This is the simple art of not running a terrible meeting.
Lead by Example
A bit of career advice for those with a passion for software development: never remove yourself from the process of creation.
I have witnessed it as the career ladder moves individuals up and up, further from the pure act of creation that is software development. For those of us who feel invigorated when we solve a difficult programming task, for those of us who feel a great rush of exhilaration when a machinery of thousands of lines of code executes in harmony, it is our burden to tinker, to learn, and to create.
When you "ascend" from developer to architect or team lead or such, never leave your passion for creation behind; authority flows naturally from understanding, knowledge, and mastery -- not just a title.
I was inspired to reflect on this by an interview with James Dyson in Wired:
Wired: Now that Dyson is a sprawling, multinational corporation, how do you keep the spirit of innovation alive?
Dyson: We try to make the corporation like the garage. We don’t have technicians; our engineers and scientists actually go and build their own prototypes and test the rigs themselves. And the reason we do that—and I don’t force people to do that, by the way, they want to do it—is that when you’re building the prototype, you start to really understand how it’s made and what it might do and where its weaknesses might be. If you merely hand a drawing to somebody and say, “Would you make this, please?” and in two weeks he comes back with it and you hand it to someone else who does the test, you’re not experiencing it. You’re not understanding it. You’re not feeling it. Our engineers and scientists love doing that.
As a team lead, never just be a middle man with the developers and requirements; be an active participant in the process. Work on the hard problems. Understand the creation process and understand the challenges of the team from the bottom up and build your authority from your ability to innovate and solve problems.
If you watch shows like Iron Chef or Chopped, every one of the judges and every one of the Iron Chefs can be considered the vanguard of their craft and it is from there that their authority flows. You would not watch Iron Chef if all the Iron Chefs did was design the menu and then watch their team cook. You would not trust the judges on Chopped if they weren't great chefs in their own right that understood the ingredients, the techniques, and the skill required to pull off a dish.
The better you understand the system, the better you understand your team, the more effective you will be in understanding the root cause of an issue and how to route defects within the team.
Push Your Team Incrementally
As a young developer, I always found great satisfaction in solving new problems and new challenges. I think it's important that throughout the process, you push your team members and give them tasks that challenge their knowledge and abilities to push them just a little bit.
Of course, there will be plenty of mundane code and defect fixing, but don't box in your team members intellectually. Understand their capabilities individually and push them to try things that are just beyond their current level of capability, understanding, and comfort zone. This will keep them engaged and improve their skills to boot.
Invest in Code Quailty, Especially Early On
It's a lot easier to write good code earlier on in the process than it is to come in and try to refactor later on. Additionally, code written early on tends to be reused more often and patterns and solutions are copied by other developers later on. So early in the process, it is important to keep code quality in mind and correct bad behaviors since the most influential code will be written earlier in the process rather than later.
What this means is that detailed code reviews are far more important at the beginning than at any other time in the project. If you can correct bad programming practices or show a developer a better, more modular way of writing a piece of functionality early on, she will carry that knowledge throughout the project.
We rarely do code reviews now (1 year in) as I focused heavily on working one-on-one with developers as they joined the team to ensure that the code was up to standards. I frequently rejected code and asked developers to rewrite whole pieces of functionality to help them understand why one design was better than another.
Put Your Best Developers on Your Least "Visible" Code
What this boils down to is the framework level components. Your best developers should be working on the deepest innards of the system that power what the rest of the developers do at the presentation and business logic layers. This code will be the most invoked and the most reused so it is important that it is:
- Easy to use and as intuitive as the platform you are working on
- Well structured and object oriented to reduce repetition of code and code complexity
- Well documented with abundant examples -- your best developers must embody and practice whatever best practices have been designated
Do not waste your best developer's time with defect fixes (unless there is sufficient bandwidth), even if they can do it better than anyone else on the team because it will throw off the balance of the team (your more junior developers might not be able to fix a low level defect as quickly, but there are many design issues and higher priority defects that they cannot solve effectively yet).
Document, Document, Document
Early on in our process, I had to decide between a wiki system or a Word document for our documentation. Because of the fast, iterative nature of the project, I decided to use a wiki/forum system as it was more flexible and -- in a sense -- more "visible".
While our formal documentation is trailing, it is easy to assemble it from our weekly sprint guides which document every new feature with screenshots, details, and examples.
But at any given time, our customer and our delivery partner can load up the wiki and see exactly when we delivered a feature, how to install and configure the feature, how to use the feature, and so on. By putting it all out there in lock-step with the weekly delivery, it is easy to ensure that the entire team is aware of the status of the project and progress being made and allows test teams to progress iteratively so that by the end of the project, most features have been tested for weeks.
Mid ways through the project, we moved from "status" focused meetings to "demo" focused meetings where we would do a weekly writeup and walkthrough of what changed, what was added, and what was fixed. It also allowed for open forums for test and business teams to ask questions and get clarifications.
This approach has allows the customer to see progress and the customer will never be surprised at the end of the project as they will have seen the progress and documentation update on a weekly basis.
So far, we have done well with these basic guiding principles.
I'm sure I will revise and add to my own lessons learned as the project continues, but I think that this is a good starting point!
While there has been a lot of chirping about the shifting racial makeup of Americans, Republicans already have a very big problem that crushes any discussion of the Latino or minority vote.
The Latino-American vote issue is going to start to pop up, but states like Texas are in no danger of turning Democratic for at least 4-5 more cycles. On the other hand, Republicans are losing the battle for women today by a big margin.
The real wakeup call should be Republican messaging and policies when it comes to the female vote -- it's the single largest block of voters by population and participation and it broke for Democrats by 11 points.
It's hard to imagine how some e-tailers are still functioning like it's 1999 in the age of Overstock and Amazon.
I ordered an item from West Elm online on October 18th assuming that I'd have it in my possession within a week.
Nope! A week later, and nary an email on the status of the order, which is still listed as "shipping soon" on their website.
Turns out on 11/09, I'll get a call to set up a delivery date....
I don't even get the privilege of setting up a delivery date until almost a full month later? Are master craftsmen hand-crafting my headboard, right at this very moment? Given the reviews of their quality (or lack thereof), I think not.
I'm not sure if their stock management system sucks or what but this seems pretty crazy (OK, I'm spoiled by Prime as well). I think it's a bit silly that I had to contact a live person to get a status on my delivery.