How crazy can Kubernetes get?

I was flipping through Reddit and found this hilarious post referencing a Scott Adams Dilbert strip on Kubernetes.

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

What I found even funnier were the comments on the Reddit thread. Read on for fun!

1. Watch your memory

One engineer said he had a dockerized app running with 3GB of memory serving just 7 customers.

Not to be outdone another ops guy pipes in that he has one using 180Gb of memory serving just a few hundred customers.

Of course this is the internet, and along comes a guy who has an app using 1TB of memory, with only one user!

Optimization be damned!

Read: Infrastructure provisioning – what is it and why is it important?

2. Beware growing application complexity

As you dockerize your application, you can support multiple versions of software and packages. This can keep you flexible but also enable engineers to kick the can down the road. Technical debt is real!

What’s more each microservice *can* be on a different stack, using a different language and framework. But just because you *can* do something doesn’t mean you should.

Though docker & kubernetes will enable the above, keep in mind your team has to support it. Using some cool new language that hasn’t really achieved critical mass? Remember the engineer who championed that, and built your business crown jewels on top of that, will eventually leave. And when he or she does, you will be faced with the challenge of finding someone who knows the stuff!

Related: 6 Devops interview questions

3. What is a microserved monolith?

Well it’s not really a thing, except it sounds fun. And a bit absurd. If all those docker containers never get optimized, they probably have layer upon layer of useless stuff. Start with a smaller base image, dont include debug stuff, and extra layers. And cleanup after installing packages.

Here’s a more detailed howto optimizing Docker image sizes.

Read: Is zero downtime even possible on RDS?

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

How to think like a senior engineer

via GIPHY

I just read this story
the Art of interrupting engineers. While much of what I read was pretty obvious from the engineer’s perspective, the product & project manager perspective was illustrative.

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

There are definitely things that senior or more experienced engineers do differently. And those things can be learned.

Here are my thoughts…

1. Document all the things

By documenting all the little pieces you are working on you gain in a few ways. You communicate to management complexity they may not see. You buy yourself more time.

Finally you may even help yourself see implicit tasks more clearly. Whenever I hear myself or someone else utter the phrase “that should be easy”, I know I’m onto one of those mysterious tasks that seems simple but never is.

Be relentless. Break big tasks into smaller ones, and ticket each and every darn one!

Also: How can 1% of something equal nothing?

2. Communicate more and better

If you’re doing agile, chances are you’re probably joining a standup everyday.

Those are opportunities to share what is blocking.

o What tradeoffs are you struggling with?
o What technical debt is slowing you down?
o What new discoveries may require a rework of the timeline?

There is surely an art buried in communication. You want to be descriptive. You don’t want to come off complaining. You want to educate stakeholders. Beware of coming off as dismissive.

Related: Is maintenance sometimes a forgotten art?

3. Anticipate. Under promise & over deliver.

If you’ve gotten in the weeds with a particular API before, you’re likely to have a gut feeling about how new features and changes may go well or poorly. Or you may have dug through the comments. Maybe you didn’t find any!?

Or maybe the particular codebase sits on top of an interface or library you haven’t worked with before. So there will be a bit more of a learning curve. Whatever the case, try to promise less than you think you can really deliver on.

You can always finish extra tickets and over deliver later!

Read: What tools and technologies are devops engineers using today

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

How can 1% of something equal nothing?

via GIPHY

I just read this painful story
My company sold for $100 million and I got zilch. How can that be?.

I felt apalled. I was a little sick to my stomach actually.

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

Is it possible to work for years, putting blood sweat & tears into a firm, and end up with nothing?

I’ve been working with startups since 1996. While I wish this was an aberration, I’ve seen it happen a half dozen times over the years.

Here are my thoughts…

1. Have a lawyer review legalese

If your intuition tells you this additional compensation is worth something, then use logic to prove it.

The first step is to have a lawyer review the fine print. They know things you don’t. Since this isn’t your domain of expertise, you’ll want someone who can see around the corners, to give you fair advice.

Related: Is maintenance sometimes a forgotten art?

2. Have a financial expert review it

Ask a financial expert to review your compensation package. Think of it like buying a house, you’re commiting to something big, with a slow long term return.

What are the chances statistically that the company will succeed? What are the chances it may fail? If it does get bought, what are the chances the fine print will eat up your portion? When in doubt be conservative with your guesses.

Also: Is Kubernetes going bye bye?

3. Use your math skills

Compare these numbers to other financial investments, such as real estate, or the S&P 500. Use your math skills to choose the best place for your money.

Be relentlessly logical. It’s very easy to get emotional or be irrational when you are dealing with money. But remember it is just math in the end. Evaluate. Test. And execute rationally.

Read: What tools and technologies are devops engineers using today

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

What Matt Ranney learned scaling Uber to 1000 services

via GIPHY

I was recently watching Matt Ranney’s 2016 talk from GOTO conference. He’s an excellent speaker, not least because of his formidable experience at the helm of Uber.

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

Jump to 11:45 to start out…

1. What’s the cost of many languages

As they embraced microservices, they discovered surprising problems around having so many languages.

For example it became hard to share code and furthermore it became hard to move between teems.

The upshot is that the fragmentation of languages siloed teams, and built up tribes around those languages, and expertise or interest in them.

Related: How can we keep cloud architectures simple

2. What’s the cost of using RPC for everything

In the microservices world, everything becomes a remote procedure call. For starters there are problems with HTTP and related semantics.

Also there are challenges with JSON. Since there aren’t any types, you don’t have a schema to lock you into formats. So you get weird behaviors down the line.

The upshot: Servers are not browsers. Indeed. Function calls are wayyyy better *within* a datacenter. That’s because you control both servers, so you can tune accordingingly.

Also: What hidden things does a deposit reveal?

3. Tuning across languages can be very challenging

Different languages have different tools available. Can your favorite tool work across all the languages you’ve decided to support in your microservices?

Even though you’re going to go with microservices, think about standardizing across those services. Use tools that work on all of them. And when building your services, make sure it outputs the same dashboard metrics.

Read: Can communication mixups sour an engagement?

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

Are you as good as the public cloud?

via GIPHY

According to Lyft’s recent public filing, they plan to spend 300 million buckaroos in the next 2.5 years on AWS.

Did I hear that right?

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

Perhaps that is their estimate, or the maximum amount they want to budget for. Regardless that’s a lot of money any way you slice it. A lot of folks are commenting about how crazy that is, and how much datacenter you could build yourself with that much money.

What do you think? Is it foolhardy? Or is there a hidden wisdom here?

Here’s my take.

1. Do you have one million customers testing your datacenter?

If you’re comparing the cost of the cloud to the raw numbers of running your own datacenter, the hardware costs are not enough. You’ll need to include the ops teams & other engineers. Right, you probably guessed that.

But did you factor in the costs of a legion of testers. This is the hidden cost that commercial software carries, even while open source software gets this benefit for free.

With a public cloud like AWS you have millions of customers testing the product everyday, and running into edge cases long before you do. So you get a better service, that’s more reliable, all invisibly for free.

Related: How can we keep cloud architectures simple

2. Do you have 66 datacenters spread across 21 regions and a free network between them?

Anybody who was building web applications in the year 2000 will remember how websites didn’t load the same for different customers. Depending on where in the world they were located, they could experience a very different user experience.

These days we assume that we can be global from day one. But how exactly do we achieve this? Remember with a public cloud, you’re getting tons of things for free, without knowing it. Moving data between AZs or regions? That’s all going across a private interconnect.

And that’s not even including the 180 nodes inside cloudfront that give you a global CDN footprint too!

Also: What hidden things does a deposit reveal?

3. Do you have an engineering team automating away job roles?

I remember the days of DBA job role, do you? Probably not. I specialized in this for years, and there were tons of companies hiring me to help them with it. First Oracle, then MySQL, then Postgres.

Then along came Amazon RDS. Guess what, companies don’t really hire for that role anymore. They do need help with it from time to time, but not as a primary specialization.

What do I mean? Well by hosting your application on AWS, you’re benefiting from the work of teams of engineers in different departments, all expanding on APIs and automating things that those one million customers are asking for.

You’re not going to be able to innovate that well and that quickly in your own datacenter. So you’ll pay more!

Read: Can communication mixups sour an engagement?

4. Do you have APIs that tons of engineers have already written code for?

A quick peek at Terraform’s community modules on Github and you’ll probably blush. From VPCs to bastion boxes, key management to load balancers, lots of code has been written and open sourced.

By deploying on a platform that a lot of other devs are using, you’ll benefit from all this open source code. That means you won’t have to write that stuff yourself.

Sure you’ll have integration work to do, but the hidden benefit of being on a popular platform saves you money.

Check out: How I use 5 daily habits to stay on track

5. Can you do disaster recovery for free?

If you build your own datacenter, you have to buy all your capacity. So there are no spare servers sitting around waiting for your use. In the public cloud there is always spare capacity.

What that means is you can write automation code to spinup copies of your application stack in alternate regions, at the push of a button. Thus you effectively get disaster recovery for free!

Also: Can daily notes help you work better with clients?

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

I have a new appreciation for Agile and not because it worked

via GIPHY

A couple of years ago I worked at a startup in the online publishing space. But this story isn’t about online publishing. This story is about deadlines, and not meeting them.

For those who don’t know me, I’m a professional services consultant. I’ve worked on a project basis for 90% of two plus decades of my professional career. I mentioned this to give my opinions and perspectives some context. Although I’m not a manager, I’ve worked under more managers than most. Because I work on 5-10 projects per year, that comes to close to two hundred in my career.

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

My career path has given me a unique perspective, on teams, leadership and motivation. Of course like anyone who’s worked in tech, I’ve see a lot of agile.

Daily standups are de rigueur of course. As are breaking up your work into two week sprints, and assigning story points to those tasks.

I have to admit there are times when Agile seemed the most fashionable way I saw teams working. And I guess I believe it was more trendy than functional.

Doesn’t everybody already work off tight todo lists, break tasks down into manageable pieces, and always deliver what they promised? It may be because I’ve spent a lot of time managing myself, and surviving as a freelancer that I’ve picked up some of these habits. But I digress…

1. Crunch time

While we as a team had been working on two week sprints, something happened to derail us. Suddenly a major customer was in jeopardy, because we had not delivered on sales promises.

Although what was being promised, we *could* build, we were stumbling over the details.

As an emergency plan, we dropped our current sprint tasks, and marshaled our forces towards this new goal. Everyone on the team knew the customer was hanging by a thread.

Related: When you have to take the fall

2. We need to deliver production by Friday

While this edict looks great on paper, it didn’t work out so well. Developers and ops weren’t clear which systems were included in “production”, and how they needed to be connected together.

Each engineer ended up interpreting the goal in their own way, often assuming that others were shouldering ultimate responsibility of delivery.

“Well I did my part, this other part of the team is responsible for those other pieces…” was the refrain I heard. Sadly the deadline was missed, and everything was a mess. Only after management later dug in and sifted through the rubble, did they actually break up the tasks, assign story points, and give each engineer actionable items to work on.

Related: When clients don’t pay

3. Please work together to make that happen

This doesn’t work because “production” is not an actionable item.

Actionable is much more specific
o deploy this container
o setup these five servers
o fix these three bugs and push code
o setup these new environment variables

Why is “production” not specific?

Which application? Which layer or API must work? Are there intervening steps before production will work? Are their individual tasks for each engineer?

To me you need to “break things down” further if you have tasks that span multiple people, and multiple sessions. I think of a session as a 2-3 hour bucket of productive work. For me it is also the length of time my laptop battery takes to drain from 100% to 0%. When that happens I know I need a break.

And I know that’s how I get chunks of work done.

So to take this to a more specific level, if Friday is 5 work days away, I figure I have 12 increments of work I can do in that time, and if I have 3 engineers, then I need 36 chunks of work.

If you assign 36 chunks of work I believe you are much more likely to get 25-30 of those chunks done.

If you stick to the one macro goal of “get production to work”, engineers may secretly drop the ball figuring, well there are dependent tasks that are not done, so we’re not gonna get there. And also since the goal points at everyone, nobody saddles the failure.

Whereas if you have 36 chunks of work, individual engineers are less likely to drag their feet because it’ll be clear that the hold up was three of john’s tasks…

Related: Why i ask for a deposit

All of this gave me a new appreciation for Agile. It truly does keep teams on track, and focuses everyone on actionable work. This allows management more transparency on whats working, and engineers the feedback they need to get to the finish line.

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

I’m speaking at Techhub on Wednesday – stop by!

This wednesday I’ll be giving a talk at the newly launched New York outpost of TechHub. The talk is entitled Intro to building a web/mobile app on AWS

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

Although I focus on Amazon Web Services as the default cloud, the concepts could apply equally to GCP or Azure.

Want to get a head start? Download the slide deck here.

1. A short history of application hosting

Just to give some context, I’ll start by a quick walk through compute history. From the server cabinet in the back office, to the early managed hosting providers and then on to today’s modern cloud offerings, I’ll explain how we got here.

Related: 30 questions to ask a serverless fanboy

2. What the heck is serverless?

With that new context in mind, I’ll talk about that evolution one step further, to managed functions. What’s that you ask? Just hand over your code to the cloud, and let them handle running the servers, provisioning load balancers, and reacting to your customers when they hit the endpoint.

Related: What’s the luckiest thing that’s happened in your career?

3. Introducing a reference architecture

No presentation is complete without a proper diagram. My reference architecture makes use of Amazon’s many cloud services, including API endpoint, cognito for user authentication, lambda for serverless functions, dynamodb to store state information, S3 for storing objects, CloudFront for the edge caching network, and Route53 for the domain name.

Related: Ben Horowitz’s choice wisdom for startup entrepreneurs

4. Architecture walkthrough

Each of the components I mention above, requires some explanation. I’ll talk about how to setup a serverless project, how to define and manage your API endpoint. This is where users first touch your application. I’ll introduce user authentication with Amazon’s own service or a third party like OneLogin or Auth0. From there you’ll see how Amazon’s nosql database Dynamodb works, and how you can store your original & edited images in S3. And no site would be complete without an edge cache, and we’ll have that setup too. Then store your domain name in Route53 and point it to your API.

Voila site complete!

Related: How I use progress reports to achieve consulting success

5. About Sean Hull

Of course I’ll also talk a bit about myself. Mostly what I’m doing these days, and the types of boutique consulting services I offer.

I’ll also encourage everyone to Signup for my monthly newsletter. I discuss cloud, startup & innovation topics once a month.

It’s a great way to keep in touch!

Related: Which tech do startups use most?

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

Surprising wisdom – thoughts on Ben Horowitz’s new startup tale

I took a recent flight to San Francisco to have meetings with a few startups. Naturally I needed some good reading to immerse myself in for the flight over and back.

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

I have to admit, though I’m not a management consultant, I do pickup the big ones from time to time. Good to Great, How to Make Friends & Influence People, The Lean Startup, Innovators Dillemma & Who Moved My Cheese among my favorites.

I’d seen Ben Horowitz’s book “The Hard Thing about Hard Things” in the news. But I also really love the a16z podcast, and although I don’t know a ton about the VC business, I thought it would be a good read.

Boy is that an understatement! The book is so readable & so accessible, there are nuggets of value in there for anyone in the startup world, or building their career, CEO or not!

On the efficient market hypothesis

I had always assumed Adam Smith’s invisible hand was a good theory, almost as scripture. So to see a different perspective on this, and one backed up by real experience. That’s cool.


“No, markets weren’t “efficient” at finding the truth; they were just very efficient at converging on a conclusion — often the wrong conclusion”. p52

What’s more for investors out there, it means good old fashioned investigative work can still turn up gems, that are worth investing in. Word to the wise.

Related: What I learned from David Maister’s book on trust & advising clients.

Questions for interviews

Add this one to your list of great interview questions. And if you’re being interviewed, why not volunteer this as an action plan. Great advice!


“What will you do in your first month on the job?” p122

Related: A review of Eli Pariser’s insightful book The Filter Bubble

On the Freaky Friday management technique

Freaky Friday was a movie way back in the 80’s. In it a mother & daughter are at each others throats, frustrated with the each other. They end up switching places, and quickly learn to sympathize with the other’s plight in life.

Horowitz decided to put this method to use between two of his managers. Pretty ingenious.

“After just one week walking in the other’s moccasins, both executives quickly diagnosed the core issues causing the conflict. They then swiftly acted to implement a simple set of processes that cleared up the combat and got the teams working harmoniously. p253

Related: A review of the Power of Habit by Charles Duhigg

On ancient wisdom & hard choices

“In life, everybody faces choices between doing what’s popular, easy, and wrong versus doing what’s lonely, difficult, and right.” p212

Every time you make the hard, correct decision you become a bit more courageous and every time you make the easy, wrong decision you become a bit more cowardly. p213

Boy, can I relate to these bits of wisdom. Running my own business all these years, it hasn’t been easy. There have been ups and downs, and times when people told me to take a different road. But that courage. When you find it, it can be real fuel for you moving forward.

Related: Can a growth mindset help you recover from setbacks – Carol Dweck

On instincts


I realized that embracing the unusual parts of my background would be the key to making it through. It would be those things that would give me unique perspectives and approaches to the business. p276

When I work with entrepreneurs today, this is the main thing that I try to convey. Embrace your weirdness, your background, your instinct. p276

I hadn’t really thought of this, and it’s an interesting point. It may be one of the reasons why customers hire me, that I hadn’t realized. Certainly I can give an original viewpoint. But I think I will try to put this to work in the future.

Related: Startup of You – Reid Hoffman’s great book on career growth

On publicity in ventura capital

This is a curious & fascinating point about the history of venture capital. Ripe for disruption indeed!

Marc discovered that the original venture capital firms in the late 1940s and early ’50s were modeled after the original investment banks such as J.P. Morgan and Rothschild. Those banks also did not do PR for a very specific reason: The banks funded wars—and sometimes both sides of the same war—so publicity was not a good idea. p271

Related: A review of Nicholas Carr’s book The Big Switch – Rewiring the world from Edison to Google

On the Andreesen Horowitz business model

This is pretty cool. Apparently the A16Z business model built a VC firm by helping startup founders in disruptive ways.

We decided to systematize and professionalize the network. p269

They modeled the firm after Michael Ovitz’s Creative Artists Agency. They had managed to “shift the economics of the industry from the corporations to the talent” p270

Related: Deborah Tannen offers us insights on conversation & interruption across the sexes

On forecasting

I guess I instinctively understood this one, but it’s interesting to see it in black and white like that.


You should expect experienced people to be able to forecast their results more accurately than junior people. p250

Related: 5 things I learned from Frans Johansson about innovation from his book Medici Effect

On checking yourself

Keep yourself honest, ask this question.

“It’s a good idea to ask, “What am I not doing?” p52

Related: 5 things I learned from Gif Constable in his book Talking to Humans

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

Can misfits teach us a thing or two about innovation?

I just finished reading Alexa Clay & Kyra Maya Phillips tour de force, The Misfit Economy.

(Yes that’s an affiliate link. The first one I’ve ever posted on this blog. If you like the book, please 🙂 buy through my link. )
I have to admit I was surprised & delighted by the book.

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

Alexa & Kyra offer us a tantalizing question. Could it be that we could learn a lot from oddball innovators at the edge of the economy? When I say edge, I really mean it. She interviews Sam Hostetler who is building a business around milking camels, and then there’s Abdi Hasan a pirate from Galkayo northern Somalia. Yeah really! Or what about the German copycats Wimdu who built a complete replica of Airbnb by reverse engineering it.

1. Hack the cold call

Take the example of Lance Weiler. Early on the industry was very against digital. They didn’t see it as really making films.

“Part of [Lance] Weiler’s success was due to his ability to work the system. He wrote letters to major production companies telling them he wanted to make the first digital motion picture. After he didn’t hear back, he took a page from the con man’s handbook and wrote the same letters but intentionally misaddressed them so they were sent to the wrong companies. Sony for example would get a letter intended for Barco.”

He was later able to bring digital projection to Cannes & Sundance!

“For Weiler his big epiphany was when he realized he could be creative across all of it [the business]. Not just in the art product, but in financing, distribution, and business aspects of artistic production.”

Related: The art of resistence or when you have to be the bad guy

2. Copy the product

The german brothers Oliver, Marc & Alexander Samwer make a superb example of how copying can bring building prowess to compete against innovators that were first to market.

“in 1998 Marc Samwer had an instinct that eBay would thrive in the German market… his brothers agreed… they contacted eBay via email numerous times, recommending that the company replicate it’s platformin Germany. Claiming that eBay failed to respond, the brother’s started their own German-language auction site, Alando, which was then purchased by eBay for 38 million euros (over $50 million) only 100 days after it’s debut. Had the Samwers not copied, eBay might have remained complacent, not realizing its potential within the german market.”

Although not mentioned in the book, Inditex the wildly successful firm behind fashion brand Zara did much the same thing to the fashion industry. By mastering the supply chain, they enabled their company to take designs from the runway & replicate them, turning designs into real clothing in stores, in just two weeks! And indeed they really do replicate, borrow & straight copy those designs from what they see at fashion week. Sad & brilliant at the same time.

Related: When you have to take the fall

3. Don’t forget to hustle


“In the lexicon of the Misfit Economy, we define “hustle” as making something out of nothing. To move fast, to trade one thing for another, and to proactively create your own opportunities rather than waiting for opportunity to come your way. To hustle means getting your hands dirty, being lean and facile, working hard, being resourceful and resilient, and showing or having gumption, chutzpah, or mojo.”

And after all, isn’t that everything the startup industry aspires to? Agile teams? Growth hackers? Scrappy startups & innovation?

Related: When clients don’t pay

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

Can i get more done by taking some dream time?

via GIPHY

When I have a long todo list and a million things on my plate, my usual tactic is to just plow through it. Take short break to eat, but then get right back to work. My feeling is, if it’s weighing on the back of my mind, I won’t enjoy downtime anyway.

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

Recently though I had a very different experience. And it surprised me.

1. Too much to do

A colleague of mine asked me to meetup for beers. We planned to talk technology, and to catchup on what we were both working on.

As the night rolled on he had some delays, and I wanted to cancel too. After all I had a ton of work to do, and didn’t think I would enjoy myself. I really felt like I’d be worrying about all this work on my plate. It’s like taking a vacation when you have a deadline. It doesn’t feel quite right.

Related: Can a growth mindset help you recover from setbacks?

2. My surprise

We ended up meeting anyway. At first I wasn’t totally relaxed, but then we started talking.
Our conversation turned to the evolution of datacenters. How they used to be on premise, then there were lots of hosting companies. And then Amazon changed everything!

We talked about evolution of tooling & automation. Although system administrators of old have been writing bash scripts forever to make their jobs easier, the proliferation of tools for deployment has allowed smaller ops teams to control fleets of servers. As my friend & colleague was newly starting a job on Amazon Web Services, a lot of this cloud stuff was new to him. So talking about it from a teaching vantage point, made me realize how strong I was in a lot of this stuff.

We talked about docker & containerization too. Even the origins back in the late 70’s with Unix chroot all the way up to Docker today. I explained to him that he could think of a container almost like a unix user, but with a more self-contained view of the whole system. In many ways a container acts like a vm, with it’s own filesystem and processes.

We talked a lot about aws, how S3 was an evolution of FTP in the old days, but much much better, how VPCs worked and the virtualization of networking, how VMs in the AWS world match with bare metal or not, how they share EBS storage. How Amazon has built a database service RDS around popular platforms like Oracle, MySQL & Postgres.

We shared a lot of ideas & brainstorming. About coding, C versus Java versus Python, package management, dependencies and on and on. He also mentioned he needed to build a test script to talk to an Amazon queue. I explained that it should be quite easy, and which libraries to look for.

Related: How I use terraform & composer to automate wordpress on AWS

3. Breaking through hurdles

It’s funny how dramatically different I felt after we got together. I all of a sudden had tons of new ideas bouncing around in my head.

Instead of waiting for the next day, after our get together, I went straight to the terminal. I quickly finished a coding challenge I was working on and struggling with. Easy peasy!

After that I felt inspired further. I created an Amazon SQS queue with the dashboard, and then wrote some python code to talk to an Amazon sqs

I created a git repo & checked in my code. All within a couple of hours!

I was just sitting there laughing. Because I felt such relief that I’ve made progress.

It was a big surprise that such a circuitous route got me there.

I guess the takeaway is that mental play or dream time is important to making progress. Otherwise you’re just working in a vacuum!

Related: What I’ve learned from 10 years of blogging

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