Category Archives: All

10 ways I avoid trouble in database operations

1. Avoid destructive commands

From time to time I’m working with new recruits and bringing them up to speed in operations. The first thing I emphasize is care with destructive commands.

What do I mean here? Well there are all sorts of them. SQL commands such as DROP table & DROP database. But also TRUNCATE and DELETE are all destructive. They’re easy to execute but harder to undo. Think of all the steps it would take to restore from your backup.

If you are logged in as root there are many many ways to shoot your own foot. I hope you know this right? rm has lots of options that can be very difficult to step back from like -r (recursive) and -f (force). Better to not use the command at all and just move the file or directory you’re working on by renaming it. You can always delete later.

2. Set your command prompts

When working on the command line, your prompt is crucial. You check it over and over to make sure you’re working on the right box. At the OS, your prompt can tell you if you’re root or not, what directory you’re sitting in, and what’s the hostname of the box. With a few different terminals open, it’s very easy to execute a heavy loading command or destructive command on the wrong box. Check thrice, cut once!

You can also set your mysql prompt too. This can provide similar insurance. It can tell you the database schema you’re set at default, and the user you’re logged in as. Hostname or localhost too. It is one more piece in the risk aversion puzzle.

3. Perform backups & test them

I know I know, we’re all doing backups already. Well I sure hope so. But if you’re getting on a system for the first time, it should be your very initial impulse to check and find out what types of backups are being done. If they’re not, you should set them up. I don’t care how big the database is. If it’s an obstacle, you need to sell or educate management on what might happen if. Paint some ugly scenarios. It’s not always easy to see urgency in these things without a good war story or two.

We wrote a guide to using xtrabackup for hotbackups. These can be done online even while your production database is serving customers without table locking or other downtime.

4. Stay off production machines

This may sound funny to some of you, but I live by it. If it ain’t broke, don’t go and try to fix it! You don’t need to be on all these boxes all the time. That goes for other folks too. Don’t give devs access to every production box. Too many hands in the pie so to speak. Also limit root users. But again if those systems are running well, you don’t have to login to them and poke around every five minutes. This just brings more chances for operator error.

5. Avoid change as much as possible

This one might sound controversial but it’s saved me more than once.

I worked at one firm a few years back managing the MySQL servers. The Oracle DBA was going on vacation for a few weeks so I was picking up the reigns for a bit. I met with the DBA for some brain dump sessions, and he outlined the main things that can and do go wrong. He also asked that I avoid any table alterations.

Sure enough ten days into his vacation, a problem arose in the application. One page on the site was failing silently. There was a missing field which needed to be added. I resisted. A fight ensued. Suddenly a lot of money was at stake if this change wasn’t pushed through. I continued to resist. I explained that if such a change were not done correctly, it very likely would break replication, pushing a domino of other things to break and causing an unpredictable mess.

I also knew I only had to hold on for a few more days. The resident dba would be returning and he could juggle the change. You see Oracle was setup to use multi-master replication those changes needed to go through a rather complex process to be applied. Done incorrectly the damage would have taken days to cleanup and caused much more financial damage.

The DBA was very thankful at my resistance and management somewhat magically found a solution to the application & edit problem.

Push back is very important sometimes.

[quote]
Many of these ten tips are great characteristics to select for in the DBA hiring process. If you’re a candidate, emphasize your caution and track record with uptime. If you’re a manager, ask candidates about how they handle these situations. We wrote a MySQL DBA hiring guide too.

[/quote]

6. Monitor important things

You should monitor your OS syslog and MySQL error log for starters. But also your slow query log for new activity, analyze them and send the reports along to devs. Provide analysis. Monitor your partitions. You don’t ever want disks to fill up. Monitor load average, and have a check that the database login or some other simple transaction can succeed. You can even monitor your backups to make sure they complete without error. Use your judgement to decide what checks satisfy these requirements.

7. Use one or more slaves & checksum

MySQL slave databases are a great way to provide insurance. You can use a lagging slave to provide insurance against operator error, or one of those destructive commands we mentioned above. Have it lag a few hours behind so you’ll have that much insurance. At night this slave may be fresh enough to use for backups.

Also since mysql uses statement based replication, data can get out of sync over time. Those problems may or may not flag errors. So use a tool to compare your master and slave for data consistency. We wrote a howto on using checksums to do just that.

8. Be very careful of automatic failover

Automation is wonderful when it works. We dream of a data center that works like clockwork, with robots that never sleep. We can work towards this ideal, and in some cases get close. But it’s important to also understand that failure is by nature *not* what we predicted. The myriad ways that complex systems can fail boggles the mind, and surprises even seasoned veterans of operations. So maintain a heathy suspicion of this type of automation. Understand that if you automate things to happen in this crucial time, you can potentially put yourself in an even *more* compromised position than simply failing.

Sometimes monitoring, alerting, and manual intervention are the more prudent path. Your mileage may vary of course.

9. Be paranoid

It takes many years of doing ops to realize you can never be paranoid enough. Already checked that you’re on the right host, and about to execute some command? Quit the shell prompt and check again. Go back and ask the team if that table really needs to be dropped. Try to rephrase what you’re about to do in different words. Email out again to the team and wait some time before you pull the trigger. Check one more time that you have a fresh backup.

Delay that destructive command as long as you possibly can.

10. Keep it simple

I know I know, we all want to use that new command or tool, or jump on the latest hardware and take it for a spin. We want to build beautiful architectures that perform great feats of magic. But the fewer moving parts, the less things that can go wrong. And in ops, your job is stability and availability. Can you avoid using multi-master replication and go with just basic master-slave replication in MySQL? That’s simpler. Can you have fewer schemas or fewer filter rules? Can you skip the complicated HA layer, and use monitoring and manual failover?

Made it this far? Grab our newsletter.

Hiring is a numbers game


On a recent twitter chat (#hfchat) I posted some comments about hiring. Some folks were complaining that they had applied to various jobs, and not heard back.

I commented…

[quote]Apply for a job and don’t hear back, it’s nothing personal[/quote]

In today’s market, there are hundreds of job applicants for every position. Sad to say, but that means things become a blur after a while. There’s less chance to sift each candidate and find out who they really are or what they really know. It’s more about keywords, and buzzwords if you must, to get your foot in the door.

But there is a flip side to this coin, which I think many job seekers forget sometimes.

[quote]job seekers: apply to enough positions so that you forget to followup sometimes.[/quote]

Imagine that, you’ve applied to so many positions and heard back from a bunch that you take it for granted it a bit that you’ll surely here back from others.

We might also argue that to some degree, especially early on when you are building your reputation, this numbers game is at play in consulting too. The more people you get in front of the more you’ll practice honing your message. At the same time more people will find out about you, and talk about you. We have a consulting 101 guide we know you’ll enjoy.

If I were to offer a few other nuggets of advice I’d suggest:

o Hone your resume for keywords and search
o Test your linkedin profile – search those keywords
o Edit your cover letter to be short & punchy!
o Throw in some buzzwords – a little rockstar this and agile that!

Looking for specific advice for tech jobs? We wrote a hiring guide for a MySQL DBA. These are equally helpful to job candidates, and those who are interviewing them. Anyone know why are operations & MySQL DBAs so hard to find these days?.

Read this far? Grab our newsletter scalable startups.

Why you should attend Percona Live 2012

What I loved about Percona Live 2011

Last year I was excited to go to Percona Live for the first time in NYC. I arrived just in time to hear Harrison Fisk from Facebook speak about some of the awesome tweaks they’re running with MySQL there. It’s not everyday that you get to hear from top MySQL engineers how they’re using the technology and what their biggest challenges are. If they can make MySQL hum, so can the rest of us!

Afterward, outside in the foyer, I ran into all sorts of luminaries in the MySQL space. Percona folks like Peter Zaitsev & Vadim Tkachenko, plus other big names like Baron Schwartz, Harrison, and Ronald Bradford. I ran into people from firms like Yahoo, Google, Daniweb, Pythian, SkySQL & Palomino.

You might also like our Setup MySQL Replication with Hotbackups as well as How to deploy MySQL on Amazon EC2 servers articles.

What to expect at Percona Live NYC 2012

This years event next month features rockstar engineers from an incredible lineup of firms including Etsy, New Relic, Youtube, Paypal, Tumblr, SugarCRM, Square, and of course a few from Percona themselves. I promise you this, these talks won’t be salesy or in any way a waste of your time and money. They will be thoroughly technical talks, with cutting edge insights and advice from those in the trenches using the technology everyday.

If I wasn’t heading to Oracle Open World for the publishers seminar & MySQL Connect, I would most certainly be there. In fact I had originally been slated to talk about point-in-time recovery in MySQL. Oh well, I’m sure I’ll catch you at the Percona Live in April 2013.

If you do decide to attend please enjoy a 15% discount with code “SeanHull” !

Looking to hire top MySQL talent? Check out our MySQL DBA Hiring Guide with advice for managers, recruiters, and candidates too! We also have an enduringly popular article about the mythical MySQL DBA and why they’re hard to find.

Also if you’ve read this far, please grab my newsletter scalable startups.

Upcoming for Scalable Startups

Just back from the Labor Day holiday, and ready to dive back in.

I thought this would be a great time to outline some of our upcoming topics so here goes…

1. Why Oracle usability sucks

– a rant about Oracle’s weak points

In the meantime take a peek at our piece on why we wrote the book on Oracle & Open Source. We ruminate on trends in the datacenter and take a stab at Oracle’s future.

2. Why relational databases don’t scale

– Is there any such thing as automatic scalability?
– What blocks scalability?
– Are NoSQL databases magic?

Also one of our articles that went viral – 5 things toxic to scalability

3. Eternal tension between dev & operations

– origin in different job roles & priorities
– balance found in each appreciating the others point of view
– hiring the best or building the right culture

You might enjoy a wildly popular piece we wrote a few months back How to hire a developer that doesn’t suck.

4. MySQL Query Tuning Cheatsheet

– SQL queries are hellish to tune, that we know.
– An outline of some of the common patterns that don’t work will help you identify and avoid them.

5. Differentiation in professional services

– A commodity does not stand out in the services business
– Differentiation is about personality, relationships & how you solve problems for the business

Also in the meantime take a look at our professional services 101 guide.

Read this far? Grab our monthly scalable startups newsletter.

31 Essential Blogs for Startups & Scalability

So many blogs, so little time! Here’s our list of the best we’ve found. Currently our favorite reader is Pulse pictured left. Starting to play around with flipboard too.

Nuts & Bolts Technical

Slashdot
One of the original tech blogs, that still covers lots of breaking news, and difficult topics. Very technical, with probing commentary. Beware the actual comments though, as they’re often full of immature and childish rants.

Planet Mysql
An aggregator of many MySQL blogs, it hits on topics from benchmarking, and advanced tuning, to new technologies on the horizon. Drupal and LAMP topics are often also covered.

mysql performance blog
Percona’s technical blog never disappoints. There are endless posts about a myriad of topics related to deploying, tuning and optimizing MySQL and all it’s variants.

Hacker News
You may not like Paul Graham, he’s easy not to. But his YCombinator News site is an awesome collection of always surprising technical topics that are sure to keep you busy.

Netflix Tech Blog
You might have read about Chaos Monkey before, that

Our very own Scalable Startups
You’re already reading us regularly of course! Why not grab our newsletter?

Programmable Web
Mashups & APIs. What more do you want? Very cool stuff here.

Also take a look at our best of compilation.

Business & Economics

HBR Blog
If you’ve ever read Harvard Business Review, you know how in depth and on point the material is. More thorough discussions than many other blogs, and excellent discussions in the comments.

Marginal Revolution
Tyler Cowen’s endlessly interesting and provocative take on the world through the eyes of economics. Like using science to analyze and solve the worlds ails, this blog always has a reasoned take on things.

NPR Planet Money
I’ve been listening to this podcast religiously since the financial crisis of 2008. It continues to intrigue and educate me in ways that college finance never did. You’ll learn a lot.

Bloomberg Businessweek
BBW despite it’s name is like Wired back in the 90’s before it got taken over by Conde, and the cutting edge writers and risk takers left. That’s right this magazine is full of analysis, creativity, and color. It’s what you’re looking for in a print magazine. One of my favorites.

Inc. Magazine
Real articles for your small business needs today. Thoughtful and topical.

Forbes Magazine
Banking, finance, politics, news.

You might also check out our Scalable Startups newsletter archives.

Venture

A VC
Fred Wilson’s iconic blog is always on the cusp, with a thoughtful and participating audience of readers.

Infochachkie
John Greathouse is a VC with a very readable blog on startups and investing.

Chris Dixon
This guy invested in tons of great startups that are household names now. With a very readable blog to match, he’s a man with ideas that we all benefit from.

Springwise
As they call it, your “Essential Fix of Entrepreneurial Ideas”.

Feld Thoughts
Brad Feld is another big VC with an excellent blog on topics relevant to Venture Capital & Startups.

Social

Andrew Chen
Consumer internet, metrics, and user growth. Brilliant idea guy. I learn from this guy’s blog everytime I check it.

Problogger
The smarties behind the book of the same name, this is essential reading for bloggers who wanna make a dent in the world.

Blog Tyrant
How to build successful blogs that make real money. Learn from Ramsay Taplin who’s done it already. Whether your blog sells products, widgets or services, there’s stuff for you here.

Kissmetrics Marketing Blog
Very good stuff on marketing, twitter, facebook and all the other good social topics.

Mixergy Blog
Business tips & startup advice with a bent towards marketing and social.

Mark Schaefer Marketing
Mark’s the brains behind the great book Return on Influence which we reviewed. His Businesses Grow blog is full of helpful ideas and insights.

Figaro Speech
You may have read my review of Word Hero and seen the earlier review of Thank You For Arguing. His blog is a real gem, extending on the wonders and lessons of word hero, you’ll be writing witty and memorable one-liners and titles that will go viral tomorrow!

Industry

Gigaom
Om Malik started out writing about the bandwidth boom and bust of the 2000’s. His blog has grown wildly to cover the industry as a whole, and contrary to the stuff you get on business insider, this is quality journalism.

AllThingsD
Another industry site with a great selection of journalists writing on the internet & startup industries.

ReadWriteWeb
Another excellent industry blog with slightly overlapping coverage to gigaom and allthingsd, but worth scanning each of them for different perspectives.

Venturebeat
Possibly a bit more venture and investment oriented than the others, but still mainly an industry coverage blog site.

Entrepreneur
Slightly more focus on business, and entrepreneurs, but also internet & startup industry topics.

Adweek
Trying to broaden my horizons by adding this one into the mix. Some very interesting topics, and plenty of overlap with internet industry and startups.

If you read this far, grab our newsletter!

5 Things You Overlooked with MySQL Dumps

1. Point In Time Recovery

If you’ve never done point in time recovery, it’s time to take a second look. With a standard mysqldump you restore your database to the time when the backup happened. Only do them once a day, then you can lose as much as 24 hours of data.

Enter point-in-time recovery, and you have the option to restore all those transactions that occured since your backup last night. Those changes, INSERTs, UPDATEs, DELETEs & even ALTER TABLEs are all stored in the binary logs. That’s right, all those statements are preserved for you!

The tool to fetch those statements with is called mysqlbinlog. When you use it, you’ll need to specify the binlog file & offset to start at. Uh oh, you don’t have those?

That’s where the mysqldump option –master-data comes in. We recommend using –master-data=2 option. That includes this important nuggets of information in the dump file as a comment.

Now you’ll know where to start applying transactions. Simply dig this information out of the dump file.

What I like to do is dump the statements into a text file first, then apply them.

Here’s how you fetch all the transactions since your dump:

$ mysqlbinlog --offset=12345 /var/lib/mysql/binlog.000005 > my_point_in_time_data.mysql

Here’s how you would then apply them:

$ mysql < my_point_in_time_data.mysql

Also checkout: Replication setup with no downtime - using hotbackups!

2. Locking & Consistency

MySQL can be confusing when it comes to concurrency and locking. Do we need to lock tables during a backup, yes, no? Sometimes? The confusion is because MyISAM tables are non-transactional. So sometimes locking all tables is required to get a consistent dump.

--lock-all-tables

This option is only required if your application works on tables across schemas. So if any one application hits multiple schemas and there are MyISAM tables in both, you'll need to use this option. It's equivalent to FLUSH TABLES WITH REACH LOCK.

--lock-tables

This option locks all tables in one schema, performs backup, then moves on to the next schema. You only need it if you have MyISAM tables. It's on by default and with --opt flag.

--single-transaction

This is the least invasive way to do a dump of your data. However it only works if all your tables are InnoDB. Keep in mind it won't error out if you have MyISAM tables, but your backup will be inconsistent. The plus side is that from your applications perspective there is really no blocking locks happening. Very cool indeed!

For a more general guide see Accidental DBAs Guide to MySQL.

3. Backups of stored code

If you have stored procedures, triggers or functions, you're not capturing them in your dumps by default. Really! Use the --routines option to include them. Better yet do a dump with just your stored code. This line will do so, and add a date timestamp for you. Be sure to have the [client] or [mysql] section in your .my.cnf file with user & password specified. Then you don't need them on command line.

$ mysqldump --no-data --no-create-info --all-databases --routines > db_code_`/bin/date +%m%d%Y`.mysql

Are you verifying replication slaves? You should know they regularly drift out of sync without throwing errors. Read more to verify MySQL replication..

4. Separate schema & data dumps

Sometimes it's useful to have a schema only backup. That is a dump of the objects in your database (CREATE statements) without any of the data. Why you ask? For starters you could use the unix "diff" command between a schema dump today, and one you did last month. That's a cool use case, but there are others. Suppose you want to build a test server, without all the production data or some subset of it? Again, a schema only dump is your friend.

o Use unix diff to compare objects in two different databases
o Audit schema changes over time
o Build test servers without all the production data
o Parallel loading of data
- use multiple mysql processes to import data
- break up the data only portion of your backup

Here's the syntax to get the schema only dump:

$ mysqldump --no-data --all-databases > db_schema_`/bin/date +%m%d%Y`.mysql

Here's how you get the data only dump:

$ mysqldump --no-create-info --all-databases --complete-insert --skip-quote-names > db_data__`/bin/date +%m%d%Y`.mysql

Looking for a MySQL DBA position? Check our our interview questions guide.

5. A few more options

--complete-insert

By default mysqldump includes INSERT statements built to *follow* create statements. So the assume all the columns match. If you break up your schema & data you could potentially have a mismatch. This option makes sure the INSERT statemens included in the dump specify column names. So if they don't match, you'll get a proper error message.

--skip-quote-names

MySQL's default dump settings will quote everything under the sun. That's to protect if you use certain reserved words or worse if you have objects with spaces in the names. But of course best practices advice against *both* of those in your database, so be advised. This option will make your dump much more readable and easier to edit.

--hex-blob

We had a customer who was using the cross-platform media publishing system K4. When we moved data from one server to another, we had a terrible time at first. That's because this enterprise application stores data in MySQL blobs. Unfortunately the default mysqldump options didn't account for certain special characters which were getting munged. The way around that is to use this option. If you have blobs, you really need this.

Read this far? Grab our scalable startups newsletter.

Beware the sales wolf in sheep suits

Recently a colleague called me up to get my opinion.

[quote]We’re in the process of standardizing our systems on Red Hat Linux, but management and higher ups are convinced we should deploy Oracle on Oracle’s own Linux distribution. Which is better?[/quote]

Therein lies the eternal drama in organizations, the push & pull between dollars and technology best practices.

We had a similar experience with a MySQL deployment, and solution framed by Oracle sales.

Battle lines are drawn

Clearly the battle lines are drawn now. Between director of operations & team versus management & business stakeholders, between high level and the trenches, or between the systems that support your business and day-to-day running of them.

Business units & management are tasked with budgets, cost management, and long term thinking about trajectory and what’s best for the business. Operations teams are tasked with the day-to-day stability, the command line perspective.

What is the sales team’s position?

Sales guys at Oracle have a job to sell licenses. This isn’t good or bad, it’s their driver. Understanding all the drivers will help us align them.

Sales guys sell to management, so they will likely frame all their stories to management concerns. Also Oracle’s history here is fairly clear. Get customers locked into Oracle up and down the stack, and they become more and more beholden to you as their primary provider. As customers become more dependent, they will begin to squeeze more and more out of them.

Nothing personal, this is how money is made. But understand the goal.

How do OS choices affect the business bottom line?

Standardizing across the enterprise reduces costs & reduces operational complexity. This can reduce risks to operator error & other downtime that increase with more heterogeneous environment.

On the Oracle distribution side, you likely have tweaks to make Oracle run better. However don’t forget the profit motive. Some tweaks may be conveniently “overlooked” in favor of profit. For example for many years the Oracle installer would not complete without error on many Linux systems. Imagine all the professional services that are sold around running through a complex install. Streamlining such an install would *reduce* profits. Don’t laugh.

What happens on the front lines?

On the front lines of course are the ops teams & DBAs, actually installing and supporting enterprise software. Let’s not forget these guys are at the command line. They know inordinately more about what’s really happening down in the trenches. You may find them repeatedly rolling their eyes at salesmen claims.

However they are not the colorful storytellers or communicators that salesmen are, so they may

Want to hire a DBA? Here’s our MySQL interview hiring guide. We also wrote a similar one for Oracle DBA Interview questions.

Align each division’s interests

Despite cultural differences, business management & operations teams should work hard to connect, and align with one another.

Operations should make an effort to better understand the business bottom line. Money doesn’t grow on trees as they say, and choices have to be based on budget, and real-world needs. We’d all like to sit in a university and program or build things just to create something new, but in a business there are market pressures. All teams should reflect on those.

Management should also make an effort to understand ops teams needs. Why are my ops teams telling me a different story than they Oracle sales guys? Fight the urge to bond with the sales folks, despite their smooth delivery, great suits and peer positioning.

Weigh short and long term tradeoffs

List out advantages & tradeoffs on all sides. These should be technical and business bullet points. Brainstorming a full list like this, and having the whole team discuss the list openly will help the team together come up with a more realistic outcome. Some questions to ask…

1. What are the advantages & disadvantages of having multiple providers for your technology stack?
2. Which solutions are open and which are proprietary? What are the tradeoffs there?
3. What does your team have subject matter expertise in?
4. Are there real technical advantages to one solution or the other?
5. Are there real cost advantages to one solution or the other?
6. Are there expertise advantages & training savings to go one direction?
7. Is the technology widely used in your industry? Will additional or replacement operations experts be easy or hard to find?

Read this far? Grab our scalable startups newsletter.

Juggling apples & oranges in the datacenter


In which a few choice words become one serious accident…

The Backstory

More than five years ago now, I worked for a shop in the business of news & information around the legal and real estate sectors. It was a fairly large organization with a number of Oracle and MySQL backed applications. The whole place ran on Sun servers, with a team of systems administrators, developers, and of course editors & content folks.

I was the primary database administrator for almost an entire year back then. I reported directly to the CTO. She was bright, competent and great to work for.

Although she had a technical background, she often spoke about products and gave very high level directives when making requests. This was made more confusing as the environment lacked naming conventions. So often product names didn’t match server or database names.

I tended to take the very paranoid approach. I’d ask over and over for clarification, and let some time pass before actually executing on a request.

A Changing of the Guard

After many months as a contractor DBA, the firm finally located a fulltime guy to replace me. It’s no easy task finding a DBA these days, especially for MySQL.

He was a very bright guy with a lot of technical knowledge. A bit green behind the ears, but fully capable to manage an enterprise database shop.

Looking for a top-notch DBA? Here’s our MySQL interview questions & hiring guide. We also have one for hiring an Oracle DBA.

Nuking the database

After two weeks on the job, something unpleasant happened.

Imagine a chef working with cooks & confusing dishes with vegetables.

[quote]
Chef says, “Toss the avocado”
Cook throws the avocado salad in the trash thinking it’s rotten.
Chef comes back later asking quizzically, “I wanted you to mix it up!”.
[/quote]

In the datacenter the conversation went something like this…

[quote]
CTO: Drop the journal database & rebuild.
DBA: Ok. Give me a few minutes
CTO: What did you do? The whole application is offline now!
[/quote]

From there scrambling ensued. After nearly six hours of screaming, and firefighting, everything is finally restored from backups and the application brought back online.

Naming – product or components?

Semantics is very important. Those in the trenches tend to take requests word-for-word while those managing the troops tend to make requests in terms of products, divisions & the vantage point of the business.

That’s why naming conventions can be so important. Don’t want to be talking about apples when you really mean oranges.

Living with dysfunction

As environments grow over years and years, they tend to evolve into a spaghetti of confusing names & relationships. It’s the nature of enterprise environments.

– big confusion can mean big mistakes
– check & recheck – be risk averse and a bit paranoid
– check yourself, your shell, your hostname, your login
– ask questions & clarify repeatedly
– let some time pass before executing a destructive command

Made it this far? Grab our newsletter.

Powerful punchy prose, big hit blog

Word Hero sounds familiar doesn’t it? I had bumped into the title here and there. I finally picked up a copy when I realized it was by the same author as my recent favorite Thank You For Arguing – Jay Heinrichs. Turns out his title inspiration was Guitar Hero, and therein lies the secret to success.

Get Viral

Timing is critical as we learned writing the book on Oracle and Open Source. But just as important is pithy, punchy prose.

Word Hero takes you through chapter by chapter introducing you lightly to the wisdom of the ancient Greeks, but more importantly explains exactly how to get to these phrases that have a life of their own.


o take great phrases & dissect them to see how they work
o illustrate great rhyming & verbing
o focus on the sound to make things lyrical
o puns, mad libs & the square root of rainbows

He quotes from great pop cultural stuff, and even a bit of Warren Buffet & Yogi Berra. By far my favorites though are his quotes from the popular TV show Glee:

[quote]You think that is hard? I’m passing a gallstone as we speak. That is hard![/quote]

If you’re a freelance blogger or sometime free agent, you should also take a look at Startup of You by Hoffman & Casnocha.

Practice your techniques

I definitely like the way Heinrichs breaks down techniques & offers illustrates exactly how to give it all a try yourself. I tried it myself a bit with this blog post. What do you think?

I also tried to put it to use in this review of Startup of You. I titled it Opportunity a day – career risk at bay. Kinda catchy I thought.

Definitely grab a copy of Word Hero, it’ll help you with your blogging, sending a memorable email, or putting together presentations that resonate.

Don’t forget to work on your Klout score!

Read this far? Grab our newsletter.

Opportunity a day – career risk at bay

Free Agent. Stress Test. Avoid Sameness

As the globalization juggernaut rolls on, it continues to create more Detroits. Skills and perspectives quickly become obsolete.

What to do in the face of such change?

[quote]Small fires prevent the big burn[/quote]

So there’s your quick answer. Get the book if you want more!

Some related material: why is it so hard to find a mysql dba?.
Consulting 101 Guide – Finding Business :: Completing Engagements :: Growing business

Your Mentors

On this tour, a free agent needs mentors. Hoffman & Casnocha provide you with plenty from stories & lessons from some of the startup industry’s finest. Jack Dorsey, Mark Andreesen, Cheryl Sandberg, Rick Warren, Paul Graham, Jeff Bezos, Joi Ito and a few of their own running Paypal & Linkedin.

What you’ll love

Each chapter closes with concrete actionable advice. The authors carefully craft marching orders for you in the next day, next week and next month. Go ahead, give them a try.

[quote]Safe is the new risky – Phil Simon[/quote]

An executive summary of Startup of You

1. develop your strengths
– what do you find easy that others find difficult?
– diversify asset mix aka learn new skills

2. plan to be nimble
– pivot as you learn more
– always prepare a lifeboat contingency plan

3. work & develop your network
– hangout with those already on the road
– domain experts, people who know you & smart people

4. hustle for breakout opportunities

5. Embrace baby steps of risk
– bounds of unemployment – shocks that motivate
– adjust your strategy & pivot if need be

What’s next?

Had a taste and want more? If you’re a MySQL DBA we wrote an interview guide. Also check out our Oracle dba interview questions.

Want more? Check out our best of content compilation.

[quote]Only the paranoid survive. – Andy Grove[/quote]

Read this far? Grab our newsletter. We cover all sorts of great topics for free agents, consultants, and those who want to hire them.