Category Archives: All

Why startups need techops

devops divide

I was at a talk recently on node.js. Even if I’m not working with a technology directly, it’s exciting to see what’s out there, and node.js is bringing some hyper fast performance to a certain category of web applications.

During the keynote, the speaker mentioned a service to deploy applications on. I can’t name names unfortunately but it was a cloud solution on top of which you could deploy your application. Go this route
and you can do without an operations team. Avoid overhead of hiring ops, he claimed. And hey, then you can hire more developers!

To be fair I’ve heard much of the same thing at DBA or linux conferences. I can’t count the number of stories that start with “what some idiot developer did that took down our production systems…”.

Yes, it seems dev & ops are still just a tad bit adverserial.

Join 13,000 others and follow Sean Hull on twitter @hullsean.

1. My little known origins as a developer

Many colleagues and clients I’ve met in the New York City startup industry know me primarily as an operations & scalability guy. I tune databases, infrastructure and components to make things lightening fast.

I spent my earliest years at university on the computer lab operations staff. We watched and managed, made sure level zero backups were taken care of, and moved the tapes. Directly after college, I started at a software firm. I did C++ GUI development on the Mac, using the toolbox libraries with Metrowerks Codewarrior. I built split windows, and scroll bars, and displayed rows of data with nice resizable columns. All this wasn’t built into the class library, so for a lot of it we needed to roll our own solution.

We always had a long list of features coming from the business units. I also fielded many support calls, often from the windows platform as the code there hadn’t been managed and built as carefully. But that too was instructive as you could feel the pain of customers day-to-day challenges. It also illustrated the tradeoffs between new code and features, and existing bug fixes and support.

Also: Why generalists are better at scaling the web

2. A trip through the dot-com bubble as Oracle DBA

Through a circuitous path, I moved to New York in the mid-nineties and joined a startup. I had the opportunity to wear a lot of hats there, and apply my computer lab and Linux operating systems experience to the challenge of managed Oracle. I got a lot more involved with operations quick.

As the dot-com bubble grew, I saw a hot and growing demand for Oracle DBAs as most startups used Oracle, but the talent was in short supply. In one startup 80 million dollars was on the line as performance hobbled the website, and investors feared the worst.

Read: Why the Twitter IPO made a shocking admission about scalability

3. Different priorities & mandates

I remember working at Starmedia a media darling at the time. I was analyzing the database & server systems, and finding some code & jobs running during peak daytime hours. Management claimed that could not be the case. Yet for the next days and weeks I saw the same jobs running. I held strong and spoke truth to power as they say. That’s not always easy when you have a lot of investors, screaming CTOs and 100+ hour weeks. But eventually the source of the job was located, and disabled. And the website returned to it’s speedy self.

These experiences though do underline in my mind the different priorities and focus that developers and operations staff have.

Techops, system administrators & DBAs are typically averse to change. They fight it tooth and nail. That isn’t because they like to be curmudgeons though. They are typically very concerned about the business, but from a dramatically different perspective of stability, and reliability, even at 2am in the morning. They are concerned about the longevity of data, consistency, and durability of it.

Developers on the other hand have a different mandate. They are responsible for new business features, solutions to business requirements. Rapid prototyping & reactive or agile is embraced because it means you can deliver quicker to the business.

Crucially, both of these folks care very much for the business. Just with very different priorities.

Check this: Why AirBNB didn’t have to fail

4. Can developers do operations for you?

In a lot of small startups, the initial phase is obviously on building a product. That’s the build phase, and not surprisingly you hire a lot of developers. As you should. But as you grow you may find the operational tasks that are defaulting to one or more developers are taking more and more of their time. As your customer base grows and you’ve seen your first few spikes, it’s time to start thinking about hiring for a real ops role.

In summary, yes they can, but perhaps not well.

Related: How to hire a developer that you can work with

5. Volume discount, made to order or instant coffee

You may choose to go with instant coffee, by bringing someone in-house. You may find the right talent is hard to find. I wrote about this: Why techops and DBAs are in short supply.

Alternatively you may prefer a volume discount from one of the larger remote DBA or managed support solutions such as Oracle’s, Pythian or Percona. These guys all provide great service, but keep in mind how big of a fish you are. You’ll likely work through a ticketing system, and in some cases different engineers will look at your systems at different times. You will likely need either a very hands-on technical CTO or other in-house person to take ownership, and manage things closely.

The third option is a made-to-order coffee. Yes you pay more for Toby’s, Blue Bottle, or Ninth Street Espresso but you get what you pay for as they say. A boutique shop or independent consultant will provide a lot more hand holding, help your internal staff get up to speed, and communicate intimately about the process. If you’re a more non-technical CTO, or you’re very busy running the business, this solution may make a lot of sense for you.

Also: Why cloud detractors need a history lesson

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Round up of recent scalability, startup & social media posts

strawberries

If you’re checking back in, we’ve written a lot of new content recently. Here are some highlights for digging a little deeper.

Join 13,000 others and follow Sean Hull on twitter @hullsean.

1. Why you should evaluate carefully before hiring a consultant

You’re a startup, and you’re grappling with some particularly thorny problems. You’ve gotten pocked and scratched, and are still struggling with big issues. So you’ve decided to hire a consultant, now what?

Evaluating consultants is a key step to ensure you find someone you can work with. But how is the process different from interviewing a candidate for a fulltime role? Here’s our thoughts on it.

2. Why a killer title can make or break your content efforts

For devops & techops bloggers out there, I’ve put together this quick howto guide. Titles really make the difference as to whether your content gets noticed, or ends up dying on the vine.

Don’t let it happen. Practice some creative title writing and other tips and you’ll be zooming your way to the top!

3. Why real world high availability is so hard to deliver

Five nines, goes the saying, is the gold standard for availability. But if it is really a standard, then why the heck isn’t anybody really achieving it?

4. Why a four letter word divides dev and ops

The on-going battle between developers and operations teams rages, devops be damned. Here’s our take on the age-old turf war!

5. Why Amazon RDS doesn’t support Percona or MariaDB

Should I use Amazon RDS or build my own MySQL box on EC2? It’s a question I hear constantly from clients and prospects. The answer of course is it depends!

In this short article, I hit on some of the typical use cases, and discuss which solution is best. If you’re interested in Percona & MariaDB, you’ll want to take a look.

6. Why techops talent is in short supply

Database administrators? Systems administrators? Ops teams? They don’t carry the sexy allure that rock star developers do, but once code is deployed, and out in the wild, these are the swat teams, and national guardsmen that you’ll rely on everyday. They’ll monitor your systems, and when necessary wake at 3am to repair things that have fallen over.

Despite their crucial role in web application deployments in the cloud, they remain in short supply.

7. 5 more things deadly to scalability

Scalability is the goal every fast growth startup struggles with. Here are some key best practices to keep reliability and capacity in the crosshairs.

8. Why the Twitter IPO makes a shocking admission about scalability

Flip through a tech company IPO filing, and you’ll find some rather vulnerable admissions about data centers and fragile architectures. How can this even be possible, for a major internet firm that’s dealt with the fail whale many times before?

9. Why reaching journalists with email fails where social media & twitter succeed

After reading Adrienne Erin’s 7 deadly sins of pitching I felt discouraged. Everything she said in there I had done. Pitching is a game neither writers or journalists enjoy. I’d long since given up on it.

Then I thought about it some more. Actually I’d had some good success reaching journalists on social media. I just didn’t really think of it as pitching per se. That’s because it was more like getting into the conversation. It was almost like the networking and hob nobbing we do naturally at conferences and meetups. So I wrote about what worked for me. Read more

10. 25 Rumsfelds Rules for startups & managers with tweetible links

Donald Rumsfeld, what can be said? What can’t be said? Well for all controversy and bad press you have to give him credit for some great one liners.

I picked up his new book, and couldn’t put it down. There’s inspiration on every page!

So I selected out my twenty five favorite quotes, and included them here for your twitter enjoyment!

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Why email pitching fails when social media succeeds

Editor & writer in friendly dialog

I was reading Adrienne Erin’s muck rack list 7 deadly sins of pitching. It struck me that I had committed many of the sins she mentioned. Maybe I was writing too much, or emailing at the wrong time, or being boring. It’s possible. Unfortunately I don’t know which of the sins to work on. Because there was no dialog.

But thinking about it more, maybe it’s just the nature of email? I’ve definitely tried pitching before, and didn’t seem to get anywhere. Not even a response. It seemed all that formality was falling flat. Ultimately email pitching is a waste of time. There I said it. I’ve sent them, never seemed to get me very far, try, try as I might.

Join 13,000 others and follow Sean Hull on twitter @hullsean.

Reading her sins though, I did feel inspired a bit to write about what has worked for me. And what has worked from time to time is having real conversations on twitter.

What I’ve learned is, drum roll please… don’t make pitching like cold calling or online dating. Because those lack context. Without that, you’re just a stranger…

So what do I do? Here’s what’s worked for me.

1. Twitter has tools, make a list

Search google for a Gigaom, Forbes, Pando or ReadWrite and you can find a list of twitter handles. But they’re all not created equally.

Some folks use twitter as a one-way ticker, but don’t converse much. Or they focus on topics not related to industry & business. Others actively use twitter professionally. Look for the latter folks.

Related: Why the Twitter IPO makes a shocking admission on scalability

2. Check that list, get interested

I could use the word “engage” but I feel it’s lost it’s meaning. The point here is that twitter is one giant conversation, among folks some known personally, and some only in the social sphere..

Comment on articles, add your opinion, or mention a quote or bit of the piece you thought really struck a nerve.

Also: Why a killer title can make or break your content efforts

3. Be helpful, share something you know

Don’t just charge in like a bull, asking for something. No one likes this in business. It’s why I’m frustrated sometimes with recruiters.

See a typo in a title or article, or something that might be awry? Spot a fact that needs clarification? Why not help a reporter out. LOL Think if you were hiring, what type of people would you most likely hire? Those who are helpful.

Read: Why high availability is so very hard to deliver

4. Strike while the iron is hot!

Making a connection is great. And not easy. So don’t go screwing it up asking for too much. Ask if they’re looking for guest bloggers, and who to talk to on your selected topic. Hopefully if you’re already working this hard for a publication, you’ve checked that!

When you have someone’s ear it’s important to avail yourself of it. Email offline, and share some topic ideas, and sexy titles. To me the title is the name of the game these days. Have some in mind. Show that you’re already playing with titles. If you get a good, vibe, write some new material

Read this: Why you should evaluate before hiring a consultant

5. Be open to criticism

Listen more than you speak and heed the guest posting guidelines.

Hear what the editor is suggesting, and be willing to move in a direction that might appeal to the largest audience.

Get something back in a few days. Extending the hot iron metaphor, no time like the present!

Good luck!

Read: Why generalists are better at scaling the web

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

25 Rumsfelds Rules for Startups

RumsfeldsRules

Join 12,100 others and follow Sean Hull on twitter @hullsean.

While we are still deep in the woods of a government shutdown, I thought it would be interesting to sum up some of our former Defense Secretary’s words of wisdom.

Rumsfeld may not have done everything right, but some of his quotes are priceless. What’s more they appeal to Startups quite nicely…

1 If you are working from your inbox, you are working on other people’s priorities.

Click To Tweet

2 Men count up the faults of those who keep them waiting.

Click To Tweet

3 In unanimity, there may well be either cowardice or uncritical thinking.

Click To Tweet

4 Test ideas in the marketplace. You learn from hearing a range of perspectives.

Click To Tweet

5. You can’t recover a fumble unless you’re on the field. Get out there.

Click To Tweet

Read this: Why the Twitter IPO mentioned scalability

6. First law of holes. If you get in one, stop digging.

Click To Tweet

7. Talent hits a target no one else can hit. Genius hits a target no one else can see.

Click To Tweet

8. You pay the same price for doing something halfway as for doing it completely so you might as well do it completely.

Click To Tweet

9. It is difficulties that show what men are.

Click To Tweet

10. What you measure, improves.

Click To Tweet

Also: Why I don’t work with recruiters

11. If you are lost, “climb, conserve and confess”

Click To Tweet

12. It is not the strongest species that survives, nor the most intelligent, but the one most responsive to change.

Click To Tweet

13. Luck is what happens when preparation meets opportunity.

Click To Tweet

14. People don’t spend money earned by others with the same care that they spend their own.

Click To Tweet

15. Disagreement is not disloyalty.

Click To Tweet

Related: Why a CTO must never do this

16. A lie travels halfway around the world before the truth gets its shoes on.

Click To Tweet

17. It is easier to convince someone they’re right, than to convince them they’re wrong.

Click To Tweet

18. Your best question is often why.

Click To Tweet

19. Simply because a problem is shown to exist, it doesn’t necessarily follow that there is a solution.

Click To Tweet

20. The world is run by those who show up.

Click To Tweet

Read: Who is Sean Hull?

21. Don’t panic. Things may be going better than they seem from the inside.

Click To Tweet

22. Know that the amount of criticism you receive may correlate closely to the amount of publicity you get.

Click To Tweet

23. Sunshine is a weather report, a flood is news.

Click To Tweet

24. If you expect people to be in on the landing, include them in the takeoff.

Click To Tweet

25. If a problem cannot be solved, enlarge it.

Click To Tweet

Read this: Why a killer title can make or break your content efforts

Get more in your inbox: Exclusive monthly Scalable Startups. We share tips and special content. Here’s a sample

http://www.flickr.com/photos/estabrook/5729555412/

Why weekly billing amps up time pressure

http://www.flickr.com/photos/estabrook/5729555412/

Join 11,500 others and follow Sean Hull on twitter @hullsean.

This past year I worked on an 8 week contract. I was tasked with helping improve scalability, measuring current throughput, then troubleshooting systems & infrastructure to find the big problem areas.

Slow process of on-boarding

In only six months, the firm had grown from a small startup, to a larger mid-sized company. That kind of growth is great for margins & investors, but it’s tough on teams & management.

We had outlined a nice todo list up front. Tasks would fit well within our eight week budget, with some additional time for things that came up along the way.

As it turned out, on-boarding for the project got drawn out. I got tangled in email problems, configuring, forwarding, and so forth. The default on-boarding process placed me on various general lists about office parties, and treasure hunts. Having all this email forwarded to me became a problem to untangle.

Meanwhile getting credentials and logins to the correct servers was a challenge. Tickets were created, emails flew back and forth and time rolled on.

Read this: Why operations & MySQL DBA talent is hard to find

Time pressure at the end of engagement

As the engagement barreled on, we reached the final two weeks mark. It was then that I scheduled another meeting with the director of operations, and to go over status.

At that point the team was fighting some new fires with database change management. I was intrigued by the problem, and wanted to dig in and see if I could assist. But at that point we both agreed there wasn’t sufficient time left to devote to it.

Having spent a large portion of the engagement up front on administrative tasks, we now had time pressure at the end to finish the tasks agreed to.

Related: 8 Questions to ask an AWS expert

The hourly billing experience

I’d worked on many hourly clients over the past decade. With hourly projects the VPN configuration, logins & admin tasks sometimes fell through the cracks. Firms of all sizes, even small startups, often have a lot of balls in the air at once.

On hourly billing, when things get drawn out, there’s no real pressure. The cost to the firm is the same whether they drag their feet or push to get things done rapidly.

Read this: Why Amazon RDS doesn’t support Maria DB or Percona

Contrast with weekly billing – mutual accountabilities

The contrast with weekly billing engagements is palpable. You feel it right out of the gates. We both want to make good use of time. And clients feel they don’t want to waste resources, and budgets.

That’s a good thing. There’s an incentive on everybody’s part to keep things moving.

Also: Why generalists are better at scaling the web

We act when we feel it in our wallet

My conclusion from these experiences, we act when we feel pressure on our wallet. With weekly billing the client will pressure their own teams on mutual accountabilities. They’ll also pressure you the consultant or service provider. So be prepared to pull your own weight.

When things are not moving along smoothly, expect discussion to quickly bubble to the surface. Embrace these moments, for everyone will have incentive to solve those problems.

Time pressure & budgets – keys to successful consulting engagement.

Related: Why I don’t work with recruiters

Get more in your inbox: Exclusive monthly Scalable Startups. We share tips and special content. Here’s a sample

5 startup & scalability blogs I never miss – week 2

5 blogs week 2

Join 11,500 others and follow Sean Hull on twitter @hullsean.

Hunter Walk – Startups

If you want to have your finger on the pulse of startup land, there aren’t many better places to start than Hunter Walk’s 99% humble writings. Google finds his top posts on topics like AngelList, Advisors, and reinventing the movie theatre. Good writing, insiders view.

Read: NYC technology startups are hiring

Arnold Waldstein – Marketing

I first found Arnold’s blog using my trusty disqus discovery hack. He had written an interesting piece about new mobile shopping at popup stores like Kate Spade.

Follow him on Disqus, follow the blog, get the newsletter. All good stuff.

Read This: Why hiring is a numbers game

Claire Diaz Ortiz – Social Media

Claire writes a lot about social media, twitter & blogging. She wrote an excellent guide to increasing your pagerank, another on 30 important people to follow on twitter and more. She can even help you find a job.

Check out: Top MySQL DBA Interview questions for candidates, managers & recruiters

Bruce Schneier – Security

Bruce Schneier is one of the original bad boys of computer security. He writes about broad topics, that affect us all everyday from common sense about airport security, to the impacts of cryptography for you and me. Very worth looking at regularly, just to see what he’s paying attention to.

Also: Why operations & MySQL DBA talent is hard to find

Eric Hammond – Amazon Cloud

Eric Hammond has been writing about Amazon Web Services, EC2 & Ubuntu for years now. He maintains and releases some excellent AMIs, those are the machine images for spinning up new servers in Amazon’s cloud.

Even if you’re not big on the command line, you can get a lot of critical insight about the Amazon cloud by keeping up with his blog. Jeff Barr’s AWS blog is also good, but not nearly as critical and boots on the ground as Eric’s.

Also: 8 Questions to ask an AWS expert

Get some in your inbox: Exclusive monthly Scalable Startups. We share tips and special content. Here’s a sample

Why I don't work with recruiters, but I learn from them

Join 11,000 others and follow Sean Hull on twitter @hullsean.

Bring me clients, please… pretty please!

When you first start out as a freelancer, your network is small. Without a steady stream of projects, the tendency is to reach for whatever you can find. Head shops & agencies build a brand, and ongoing relationships with firms. However a project with a middleman is a relationship with him or her, not the client directly. You lose control of a few very key things, such as fees, testimonials and payment terms.

Read: NYC technology startups are hiring

It’s all about the relationship, Luke

With independent consulting, your relationship with clients is key. Fostering that relationship, builds trust, communication, and confidence in you as a service provider. Doing operations and database management, a CTO, VP or Director of engineering needs to be confident entrusting enterprise systems to you. Security of assets, reliability that things won’t break, and consistency are all crucial.

Working with a recruiter, agent or head shop the client then may feel a stronger relationship with that firm. Testimonials and due credit for successful completion of a project may go to them rather than to you directly.

It also means you lose control of the conversation about fees. Want to do project or week-based fees, your suggestion may fall on deaf ears. What’s more you will share large margins that could amount to 25% or even 50% of the overall fee.

Read This: Why hiring is a numbers game

Headhunters have the pulse of the market

With all those complaints, you might think I don’t like recruiters much, but you’d be sadly mistaken. It turns out I learn a ton from recruiters, and almost always take their calls.

o those conversations are good practice for talking shop
o they provide good feedback & ask questions about confusing areas in conversation
o buzzwords will pop up prominently, helping you understand what their clients needs are
o gives you a bit of the pulse of the market

I learn to speak in broad terms, in a language managers and folks at all levels of an organization can understand, and I learn patience too.

Check out: Top MySQL DBA Interview questions for candidates, managers & recruiters

Recruiter pings – a key performance indicator

Over a ten year period you start to notice trends. Certain times of the year I get more calls & more pings from talent agencies. Here’s what I monitor:

o recruiter views of my linkedin profile
o recruiters email me on linkedin
o recruiters call me
o recruiters signup for my newsletter

Also: Why operations & MySQL DBA talent is hard to find

Learn from people whose business is communication

Although I don’t have referrals or connections for the HR or search consultant that’s reaching out to me there is still lots I can learn. At the end of the day, recruiters are in the business of relationships, and that’s where I become the humble student.

Also: 8 Questions to ask an AWS expert

Get some in your inbox: Exclusive monthly Scalable Startups. We share tips and special content. Here’s a sample

5 Superb blogs this week

Why wait for the new year to start something new? I come across a lot of great new blogs, while digging through the interwebs. So I thought I’d start a regular column to feature the best ones. We’ll including gems from web 2.0 industry, startups, business & management, and of course some technical devops & cloud computing ones.

Join 11,000 others and follow Sean Hull on twitter @hullsean.

1. Todd Hoff’s High Scalability

Todd Hoff’s High Scalability has been around for years, and offers up a cup of espresso for your infrastructure daily. From important topics like why you should avoid ORMs (Object Relational Modelers see post on technical debt) to regular scalability around the web posts to keep you on track.

He also features great articles under the title “real life architectures” from heavyweights such as facebook, twitter & youtube. These are the gold nuggets that are indispensable to devops and startups.

Read This: 5 Reasons Devops Should Blog

2. Albert Wenger’s Continuations

I was tipped off to Continuations using the Disqus commenting system’s discovery features. Click through to the community tab on say Fred Wilson’s AVC blog and you can find top commenters and where they blog at.

Wenger’s posts include such gems as Anatomy of a URL, giving a lay audience a little insight into the ubiquitous web paths and Computing Building Blocks which dissects the internet stack for everyone. As a partner at Union Square Ventures he’s obviously looped in with the big boys, but his writing style is so great he offers a model for technical bloggers everywhere.

Check out: A CTO Must Never Do This

3. Andrew Chen

Let’s face it Andrew Chen is the rock star I want to be! He’s got tons of organic followers on twitter, and reading his blog & newsletter it’s no surprise. He’s bright, and always provides Nate Silver style insights & new perspectives.

What is a minimal homepage, and how will it help me increase signups? Why can’t I seem to find a technical co-founder? What’s a minimum desirable product? You’ll see why Dave MacClure & Mitch Kapor work with him.

Read: AirBNB Didn’t Have to Fail – AWS Outage Postmortem

4. John Paul Aguiar

John’s website may appear a bit busy at first, but that’s just because it is so chock full of useful content. He offers very hands on, down in the trenches advice for bloggers & entrepreneurs. 150k followers on twitter, and articles that get retweeted hundreds of times, means he’s done the A/B testing, and learned to write clearly, and has great insights to share.

One thing he does is a weekly piece on entrepreneurs & users to follow on twitter. That great feature inspired this very post, not least because it offers a steady stream of things to write about, but because I was also featured there recently. I feel like I’ve hit the big time, thanks John!

Related: How to Hire a Developer That Doesn’t Suck

5. Krebs on Security

Brian Krebs is a bad boy. According to Bruce Schneier he apparently pissed someone off so bad, they had illegal substances sent to him through the mail in attempt to frame him.

Clearly his security research and writing is not appreciated by everyone. That said take a look at his website. You’d be shocked to learn what an ATM skimmer is, or what is the value of a hacked PC. Phishing, bots, email spam, gaming & reputation hijacking are just a few of the criminal activities that go on.

Also: The Myth of Five Nines

Get some in your inbox: Exclusive monthly Scalable Startups. We share tips and special content. Here’s a sample

Understand the High Cost of Technical Debt by Ward Cunningham (Video)

A week or two ago, I got into a conversation on Twitter about technical debt, and someone shared this superb video by Ward Cunningham (youtube). Here is Ward’s Interview website.

Join 10,000 others and follow Sean Hull on twitter @hullsean.

Waterfall, agile, developer or operations, devops, managers, CTOs… everyone should watch this video, for it cuts to the heart of the challenges we face doing modern software development, in a fast paced and always changing environment.

Though it’s not mentioned in the video, I would argue using an ORM is an expensive form of debt, one that is improperly calculated by teams, managers & startups, and one that bites hard into future scalability. Stay tuned for a post about that!

Enough said, here’s the video.

Here’s the transcript of much of the dialog. Appologies for any typos…

1. Metaphors & Thinking

I became interested in the way metaphors influence the way we think

after reading George Lakoff & Mark Johnson’s Metaphors We Live By (Amazon).

An important idea is that we reason by analogy through the metaphors that have entered our language.

Related: 5 Things Toxic to Scalability.

2. Coining Debt Metaphor

I coined the debt metaphor to explain the refactoring we were doing on a product.

This was an early product done in smalltalk. It was important to me that we accumulate the learnings we did about the application by modifying the program to look as if we had known what we were doing all along. And to look as if it had been easy to do in smalltalk.

The explanation I gave to my boss, and this was financial software, was a financial analogy I called the debt metaphor and that said that:

[quote]
If we failed to make our program align with what we then understood to be the proper way to think about our fin objects, then we were going to continue to stumble on that disagreement which is like paying interest on a loan. -Ward Cunningham
[/quote]

Also: AirBNB didn’t have to fail when Amazon went down.

3. Need for Speed

With borrowed money you can do something sooner than you might otherwise, but until you pay back that money you will pay interest.

I thought borrowing money was a good idea. I thought that rushing software out the door to get some experience with it was a good idea. But that of course you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.

Read this: Why generalists are better at scaling the web.

4. Understand the Burden

I think that there were plenty of cases where people would rush things soft out the door & learn things, but never put that learning back into the program. That by analogy was borrowing money thinking you never had to pay it back. of course If you do that you know say with your credit card, evemtually all your income goes to interest & your purchasing power goes to zero.

By the same token if you dev a program for a long period of time, by only adding features, and never reorganizing it to reflect your understanding of those features, then eventually that program does not contain any understanding and all efforts to work on it take longer and longer. In other words the interest is total. You’ll make zero progress.

Check out: How to hire a developer that doesn’t suck.

5. Achieving Agility

a lot of bloggers at least have explained the debt metaphor and confused it i think with the idea that you could write code poorly with the intention of doing a good job later. and thinking that that was the pirmary source of deb.t I’m never in favor of writing code poorly. But I am in favor of writing a code to reflect your current understanding of a problem even if your understanding is partial.

If you want to be able to go into debt that way by dev soft you odn’t completely understand, you’re wise to make that software reflect your understanding as best you can. So that when it does come tiem to refactor it’s clear what your thinking was when you wrote it. and making it easier to refactor it to what your thinking is now.

in other words the whole debt metaphor or lets say the ability to pay back debt, and make the debt metaphor work for your advantage depends upon you writing code that is clean enough to be able to refactor as you come to understand your problem.

i think that’s a good methodology it’s at the heart of extreme programming. the debt metaphor is an explanation, one of many explanations as to why extreme programming works.

Read our popular interview guides for candidates, managers & recruiters: MySQL DBAAWS Expert (Amazon Cloud) and Cloud Deployment & Automation Engineer.

Don’t forget, hiring is a numbers game

Get some in your inbox: Exclusive monthly Scalable Startups. We share tips and special content. Here’s a sample

5 Reasons Devops Should Blog

Join 9500 others and follow Sean Hull on twitter @hullsean.

1. Stand up and be heard

Years ago I was sitting on an online forum chatting with an Oracle buddy of mine. This was circa 1998. We were working on an open source tool to interface with Oracle. There were all these libraries, for PHP & Perl, and a lot of developers starting to build tools. We hatched this hair brained idea to write a book about all of this, and pitched it to O’Reilly. They loved it and thus was born the book Oracle & Open Source in 2001.

Writing a book was, is and always will be a lot of work. It was a great learning experience too. Editors critique your writing, and this teaches you to speak to a broader audience, clarify your statements, and including illustrations and stories.

Along with this came opportunities to speak at conferences, user groups and meetups. It’s exhilerating, and professionally challenging, and I enjoyed all of it.

Blogging allows you to do all of the above in a more measured way. Write regularly, get your ideas out there, get feedback, rinse & repeat. What’s more over time you’ll build up a library of material some of which will draw solid, strong, repeat traffic. It may be what you are most passionate about, what ideas you’ve ironed out smoothly, or what material is most missing from the we already. Whatever the reason your analytics will show you the way.

Read this: Database expert interview questions for candidates, recruiters & managers

2. Share your lessons

In professional services engagements, you learn something new everyday. After a few years you’ll have some battle scars & war stories too. For example I used to have a strong distrust of sales. But through real lessons in the feast or famine world of running your own business, you learn some survival instincts. And knowing how to sell your services & expertise is an art all to itself.

Also: A CTO Must Never Do This

[quote]
Getting up and taking a stand isn’t easy. You’ll receive criticism, and likely feel professionally vulnerable at first. But that only makes us stronger engineers, willing to listen, and better communicators.
[/quote]

3. Get opinionated

Taking a stand on controversial topics, is it something you want to do? Is it something you can do confidently, but also being open to criticism, and seeing all sides.

It’s challenging, but in that process it will either open you to new ideas, or make your resolve stronger. And that process is great for your professional development.

Also check out: AirBNB didn’t have to fail – don’t go down with Amazon

4. Withstand a sh*tstorm

Audiences keep you honest. If I were to go out on a limb I’d say technically brilliant, engineering audiences even more so.

I remember a post I did a year ago, which referenced a feature based on a wrong software version. In other words that feature would not work based on my article. The readers tore me to pieces in the comments.

But listen closely now, I’m saying that’s a good thing. Yes criticism is a very good thing indeed. Get enough of it, and you’ll learn to weed out the folks who are just trolls, from the ones with genuine suggestions. And all that makes you stronger!

Learn to listen a bit, and that makes you an even better sysadmin or devop.

Related: 5 conversational ways to evaluate great consultants

5. Learn by doing

Developers, ops, DBAs and Big Data jockeys alike are doers. We sit and code, build & configure components, troubleshoot & tune. Writing is descriptive and often it’s difficult for us to step back and describe what we’re doing.

By writing we carefully sift through our own thought processes to break it down for novices, or a broader audience. This is a learning process for us too. It’s therapeutic. But also it hones our message and makes us better teachers. We literally learn by doing.

Also: The Myth of Five Nines

Get some in your inbox: Exclusive monthly Scalable Startups. We share tips and special content. Here’s a sample