Ernesto Tagwerker: Founder & CTO at OmbuLabs.ai

Improving My Jekyll Site with Claude Code

Thu, 15 Jan 2026 00:00:00 -0500

Today I spent some time improving this website with the help of Claude Code, Anthropic’s CLI tool for software development. All the changes described in this article were authored by Claude Code with my direction.

The Starting Point

My Jekyll site had been running for years with several technical debt items I never got around to fixing. I decided to see how Claude Code could help me tackle these issues in a single session.

SEO Improvements

Claude Code started by analyzing my site for common SEO issues and identified three critical problems:

1. Missing Meta Descriptions

My posts had description fields in their frontmatter, but the template wasn’t rendering them as <meta name="description"> tags. Claude Code added the necessary Liquid template code to _includes/head.html:

{% if page.description %}
  <meta name="description" content="{{ page.description | strip_html | truncate: 160 }}">
{% elsif site.meta_description %}
  <meta name="description" content="{{ site.meta_description }}">
{% endif %}

2. Missing Canonical URLs

Without canonical URLs, search engines might index multiple versions of the same content. Claude Code added:

<link rel="canonical" href="{{ site.url }}{{ page.url }}">

3. Missing Open Graph and Twitter Card Tags

When sharing posts on social media, they weren’t displaying rich preview cards. Claude Code added complete Open Graph and Twitter Card meta tags, so now when you share a post on Twitter or LinkedIn, it displays a proper preview with the title and description.

Git-Based Last Modified Dates

I wanted to show when pages were last updated on my Now page. Claude Code created a Jekyll plugin that reads the git history to get the actual last modified date:

Jekyll::Hooks.register :site, :post_read do |site|
  site.pages.each do |page|
    relative_path = page.relative_path
    next unless relative_path

    Dir.chdir(site.source) do
      git_date = `git log -1 --format="%ci" -- "#{relative_path}"`.strip
      if git_date && !git_date.empty?
        page.data['last_modified_at'] = Time.parse(git_date)
      end
    end
  end
end

GitHub Actions Workflow

My site uses Jekyll 4.0 and custom plugins, which aren’t supported by GitHub Pages’ built-in Jekyll. Claude Code created a GitHub Actions workflow that:

Builds the site with all custom plugins
Fetches full git history (needed for the last modified dates plugin)
Deploys the generated site to GitHub Pages

This was necessary because GitHub Pages’ default Jekyll build doesn’t support custom plugins like sitemap_generator or my new last_modified plugin.

Google Analytics 4 Migration

The site was still using the deprecated Universal Analytics (ga.js). Claude Code replaced it with the modern GA4 gtag.js implementation.

Site Branding Updates

I updated the site title from “Pivot or Persevere” to “Ernesto Tagwerker: Founder & CTO at OmbuLabs.ai” with proper descriptions. Claude Code helped identify that the title wasn’t updating because:

The index.html had the old title hardcoded in its frontmatter
The _config.yml used name but the templates expected site.title

Both issues were fixed, and now the site has consistent branding throughout.

The Experience

Working with Claude Code felt like pair programming with a knowledgeable colleague. I could describe what I wanted at a high level, and Claude Code would:

Explore the codebase to understand the existing structure
Identify the right files to modify
Make the changes with proper context
Commit with descriptive messages
Push to GitHub

The entire session took about an hour, and we made 7 commits addressing issues that had been on my backlog for months.

Conclusion

AI-assisted development tools like Claude Code are changing how we approach routine maintenance and improvements. Tasks that might have taken a full afternoon of context-switching between documentation, Stack Overflow, and code editors can now be completed in a focused conversation.

If you’re curious about Claude Code, check it out at claude.com/claude-code.

If you’re curious about AI and how it can help your engineering organization, contact OmbuLabs.ai!

Bye bye, Medium! Hello, Jekyll 4.0! 👋🏼

Mon, 02 Dec 2019 21:25:00 -0500

This year Medium decided to implement a paywall with all their content (meaning my content, and your content, and anyone’s content published in their platform)

When that happened I thought it was a good idea to leave their platform and use Jekyll instead. It took me almost 10 months to finally move away from Medium! This Thanksgiving break was a good time to spend a few hours migrating my content to Jekyll + GitHub Pages.

Here is how I did it:

I started with FastRuby.io’s blog’s source code (which is open source). Then I followed the instructions in this article: https://hackernoon.com/medium-2-md-convert-medium-posts-to-markdown-with-front-matter-c044e02c3cbb
I tweaked some of the content and file names. I had to massively edit file names so that Jekyll could figure out that it had to generate HTML pages for them.
I migrated from Jekyll 3.0 to 4.0. Fortunately the migration was quite easy! You can see all the changes over here: https://github.com/etagwerker/etagwerker.com/pull/1/files
I implemented Hyde and tweaked a few details to find a look & feel that I liked.
I configured Route 53 and GitHub to serve the domain without www. The nice thing about GitHub Pages is that it is simple, easy, and free for open source projects.

Here is the end result!

If you are thinking about migrating away from Medium, Jekyll is a great alternative to have full control of your platform and content! ❤️

2019 Best Tech Startups in Philadelphia?

Wed, 30 Jan 2019 23:28:02 -0500

The Tech Tribune lists CloudMine as the third best start up in Philadelphia in 2019: http://thetechtribune.com/10-best-tech-startups-in-philadelphia/

Maybe someone should tell them that they filed for bankruptcy more than 3 months ago? (Source: https://technical.ly/philly/2018/11/06/cloudmine-saas-cloud-shutdown-2018-backruptcy/)

What’s the point of these rankings anyway? To me it’s just a great example of vanity metrics.

The Death of a Successful Product

Thu, 04 Oct 2018 16:53:52 -0400

I have been using Highrise since June 2011, and I have been very happy with the product for a long time. It has been very helpful for both our consulting business and our own software-as-a-service solution.

I’m a big fan of all things Basecamp, especially the simplicity behind all of their products. That’s why it is so hard to write this open letter criticizing one of their last decisions.

I keep coming back to this issue: If Highrise is such a successful product, why are you killing it? Is it just me or is there something definitely dissonant about this decision?

This is part of their farewell message:

What started out as a simple tool to keep track of who you talked to, what was said, and when to follow up next, eventually matured into a full-fledged CRM trusted by more than 10,000 companies around the world. It’s been a big success.

If more than 10,000 companies are happy with your service, doesn’t that mean that you are raking in a decent amount of money per month?

It seems that 4 years ago Highrise was making several million dollars in annual profit:

On its own, Highrise generates several million dollars in annual profits, so we figured it would be attractive to someone. (Source)

So, seriously, what went wrong? Something must have gone so wrong that several million dollars in annual profits weren’t enough to keep development going.

The explanation behind this decision is not good enough. It has been a huge disappointment. Would it have been better if they had shared all the things they tried? Maybe.

In many ways, that’s a baffling business decision. We know how many Highrise customers love and depend on the product, and had hopes for future development. It sucks to disappoint good customers like that. It stings to turn down the future prospects of a successful business. But it’s decisions like this that allows us to be the kind of company that we are.

Yes, indeed it is. It is so baffling that it doesn’t really make sense. If the past handoff didn’t work, why not try with another team?

Just because it didn’t work once it doesn’t mean that it will never work with another home.

I know, I know: Focus is saying ‘no’, but sometimes that ‘no’ feels like a big middle finger to your clients.

This open letter feels like criticizing a ‘sacred cow’ and it has taken me days to actually publish it. But I would love to know more about what happened between 2014 and today.

Maybe it is just me, but I am used to transparent post-mortem reports. This farewell message falls short of what I would expect of Basecamp.

Experimentos en vez de startups

Fri, 10 Jun 2016 23:43:41 -0400

Juan es un emprendedor. Tiene una idea brillante. Se la cuenta a algunos amigos. A los amigos les gusta. Juan empieza a construirla.

Después de 3 meses de esfuerzo finalmente se decide a lanzar una versión beta.

Cuando Juan le muestra el producto a sus amigos, ninguno lo usa. A ninguno le gusta. Cuando se lo muestra a gente de su mercado objetivo, nadie lo entiende. Prefieren seguir usando lo que venían usando.

3 meses tirados a la basura.

Hay muchas ideas que son geniales, pero no todas son buenos negocios.

Un negocio es un conjunto de hipótesis sin validación. ¿Cuál es la mejor forma de validarlas?

Haciendo experimentos

En vez de dedicar 3 meses (o más!) de tu vida a construir algo basado en 27 hipótesis, ¿por qué no armas un experimento que valide la hipótesis más riesgosa?

Por ejemplo: Si quieres hacer una mermelada de sabores exóticos, empieza con una degustación gratuita con un grupo de amigos, amigos de amigos y desconocidos.

¿Qué sabores tuvieron más éxito? ¿Cuánto pagarían por cada gusto?

Un buen experimento debe tener:

Una hipótesis fácilmente validable (o invalidable) con un criterio medible de salida.
Restricción de tiempo. Debe ejecutarse unos días. No más de 2 semanas.

De no tener un límite de tiempo, vamos a esperar que dure lo suficiente como para justificar la hipótesis que queremos que sea válida.

Para el caso de la mermelada, mi hipótesis es la siguiente: De las 20 personas que vinieron a la degustación, a 10 les va a gustar el sabor de Naranja-Frutilla-Jengibre.

Si no se cumple, se invalida la hipótesis.

Por eso, la próxima vez que tengas una idea genial, tienes que considerar tres cosas:

¿Cuál es la hipótesis más riesgosa?

Arma el canvas del modelo de negocios (o Lean Canvas) e identifica las hipótesis más importantes para que tu idea se convierta en un negocio exitoso.

¿Cómo puedo validar esta hipótesis objetivamente?

¿Qué experimento puedo armar que tome la menor cantidad de tiempo y esfuerzo posible? ¿Cómo puedo validar la hipótesis con mi mercado objetivo?

¿Qué criterio de salida validaría la hipótesis? ¿Cuánto tiempo es suficiente para correr este experimento?

Luego de ejecutar el experimento, ¿queda validada o no?

Si es una hipótesis válida, puedes continuar con la segunda hipótesis más riesgosa.

Para seguir este proceso de aprendizaje, está muy bueno el Validation Board de Lean Startup Machine. Puedes imprimirlo y empezar a pegar tus hipótesis sobre el tablero.

Conclusión

Para evitar pérdidas de tiempo y esfuerzo y para evitar perder el contacto con la realidad, crea experimentos que validen cada una de tus hipótesis más riesgosas.

Es la única forma de construir un producto o servicio que se ajuste al mercado.

Cuatro Consejos para Emprendedores de Startup Chile

Tue, 07 Jun 2016 10:40:40 -0400

En 2012, con OmbuShop, Tu Tienda Online, participamos de la ronda 4 del programa y nos sirvió mucho para crecer en América Latina, especialmente en Chile y México.

Estos son algunos consejos fundamentales para todos los emprendedores de las nuevas rondas de Startup Chile.

Esta es tu guía para los seis meses en Chile.

El objetivo es encontrar un modelo de negocios que funcione, que esté validado, que sea escalable y que termine generando ingresos al final del programa.

1. Empieza creando tu Lean Canvas

Este debe ser tu primer paso. A nadie le importa tu plan de negocios. Por eso Startup Chile no te lo pide para entrar al programa. Lleva mucho tiempo confeccionarlo y nadie lo lee.

El primer día crea tu Lean Canvas.

Es un canvas que tiene información sobre todas las áreas importantes de tu negocio. Te hace pensar en el problema, la solución, el mercado, los ingresos, los costos y al final del día te sirve para resumir tus hipótesis.

Es un documento dinámico, que irá evolucionando en el ciclo de aprendizaje (build, measure, learn)

Puedes crearlo en leanstack.com o en docs.google.com.

2. Encuentra tu hipótesis más riesgosa y empieza a validar

El Lean Canvas te sirve para identificar los riesgos más grandes de tu startup.

Por ejemplo:

Tu has definido el problema, ¿pero tu mercado también lo percibe como un problema?
Tu has definido un precio, ¿pero pagarían tus clientes $100 por mes por tu servicio?
La solución que tienes en mente, ¿soluciona el problema?

Antes de empezar a construir una solución en base a hipótesis incorrectas, puedes empezar a construir experimentos que verifiquen las hipótesis de tu canvas.

¿Qué es un experimento?

Puede ser un video, una imagen, un cartel, una reunión, una página de bienvenida, un smoke test, una serie de mockups.

Es lo mínimo indispensable para validar o invalidar una hipótesis.

3. No te obsesiones con el Demo Day

El evento más importante dentro de Startup Chile y para la organización del programa es el Demo Day. Pero no es el evento más importante para tu startup en estos seis meses.

No dejes que este evento guíe tus acciones durante el programa.

Sí debes practicar los pitches de tu emprendimiento porque te servirá para explicar tu startup a diferentes stakeholders. Tienes que saber pitchear a:

Socios
Clientes
Empleados
Partners
Inversores

(Esta lista está ordenada según el orden de importancia.)

Si no puedes convencer a alguna de estas personas de que tu startup soluciona un problema que vale la pena, tienes que cambiar algo.

Startup Chile tiene una reunión semanal muy buena para practicar tu pitch y ser más claro al momento de vender tu idea.

4. Experimenta todas las semanas

Los recursos del programa nos permitieron realizar muchos experimentos en busca de:

Nicho de Mercado
Motor de Crecimiento
Canales de Adquisición de Clientes

Uno de los experimentos que realizamos en OmbuShop fue la visita puerta a puerta de nuestros potenciales clientes.

Descubrimos que no era el mejor canal para conseguir nuevos clientes.

De 20 locales que visitamos, ninguno se convirtió en cliente de nuestro servicio. Llegamos a la conclusión que este canal no era el mejor para llegar a los tomadores de decisiones.

Y continuamos con nuestra siguiente hipótesis.

¡Bienvenido a Startup Chile!

Aprovecha esta oportunidad para cambiar el mundo. No tengas miedo de pivotar.

Aplica Lean Startup para encontrar un modelo de negocios que funcione para tu emprendimiento.

What I learned after my writing experiment

Tue, 31 May 2016 00:10:16 -0400

I’ve been writing every weekday for more than a month. This was a small and intense experiment.

To be honest, I feel like I’ve been producing a large quantity of content with little quality.

I’m not a big fan of this. I’ve always preferred to release a few quality products vs. a large quantity of mediocre products.

From now on I’ll bring it down to two posts per week. Hopefully this will give me more time to work on my drafts and create better content.

I now have a better idea of what people want to read. If you’re a data junkie like me, here you can see the stats around my most popular article since I started writing here:

I love the simplicity of the Medium stats interface.

A new perspective

Sat, 28 May 2016 00:32:33 -0400

Becoming a father for the first time sure puts things in a different perspective.

You are now responsible for another human being. This is now your most important priority. You need to make sure that they are healthy, well fed and constantly growing.

There are a few metrics that become the most important metrics in their life: Weight and Size.

Everything else is on a different level. Within that lower level, things are important, but not as much as your newborn daughter.

“I don’t know (yet)”

Thu, 26 May 2016 21:23:58 -0400

Some people will say “I don’t know” and expect you to tell them the answer. If you tell them the answer right away, they will probably keep asking you similar questions.

Next time you are in this situation try to guide the person to the best solution. Explore the different alternatives and mention the pros and cons of the different solutions. Let them make decisions, let them make mistakes.

If you are stuck with a problem and you don’t know how to move on, remember:

It’s easier to ask for forgiveness than it is to get permission.

Before asking for help, do some research. Find a solution, even if you think you will get in trouble, even if you know it’s not the best solution.

Make mistakes. Break things. It is the only way to learn and gain experience.

Don’t expect someone else to provide a solution on a silver platter. You will learn so much more on your own.

A few notes on hiring

Wed, 25 May 2016 22:45:42 -0400

Lately I’ve been evaluating and interviewing quite a lot of candidates for the Junior and Senior Developer positions at OmbuLabs.ai.

Here is what I’ve learned in the process.

Process

In a software consulting business like mine, you must have a clear process to evaluate candidates. The people in your company have to be well aware of what you are looking for in each candidate.

If you have a pool of questions to ask each candidate, you should explain why you are asking them. You should explain what you are looking for with each question.

Having a well defined process will allow you to delegate it to someone else when you can’t participate in the interviews. This is our current process at OmbuLabs.ai.

Rigorous filtering

There has to be an early stage of rigorous filtering. You must have some criteria that clearly defines deal breakers.

For example, if a candidate has been job hopping for the past 5 years and they haven’t stayed in a job for more than a year, then that’s a deal breaker.

Another example in our case: if a candidate doesn’t speak English fluently, then that’s a deal breaker. We program, do research and talk to clients in English. So this is very important to us.

Do a real live test

If you are looking for a UX Designer, have them work on a real project with you. Make sure that they are not just great at interviewing, but also great at delivering value right away.

When we look for a Developer, after the candidate passes the interview filter, we make sure to have at least 8 hours of paid pair programming time with them.

Don’t be afraid to have candidates complete sample projects. If the sample project is too long, pay for their time. It’s better to spend time and money before hiring, than to regret it later when you realize they are not the right fit.

After they’ve passed all the filters in your process, you should also have a culture fit interview. Here is a great article about culture fit interviews.

You must spend as much time as you need making a hiring decision. In the software business, bad hires cost a lot of time and money.

5 Rules to build a software MVP

Tue, 24 May 2016 23:21:46 -0400

I’m tired of saying that your MVP is not small enough. Here are five simple rules to build a software MVP.

Rule #1

Quality is non-negotiable. Quality must remain high. You cannot build something that has poor quality.

You are not building a cheap product fast. You are building a quality product with reduced scope.

Rule #2

The release date is non-negotiable. Once you define the scope and set the date, you cannot postpone the release date.

There is a fixed amount of time that you have to work on the design and development of the software MVP. Once you have defined the release date, you cannot change it.

Rule #3

The end result has to be a usable product which tests a core hypothesis of your business model.

When you define the minimum feature set, you need to always keep this in mind:

This is a great illustration by Henrik Kniberg. You can read more about this in his article about an Earliest/Testable/Lovable Product

Rule #4

You can remove features from the scope. You must not add features to the scope. The goal is to avoid scope creep as much as possible.

Before you begin, you will have a list of prioritized features. You will start working on the most important features and leave the least important ones for last.

You might need to cut some of the features out of the project. So it’s best if the least important features get cut.

Rule #5

Before you release the MVP you must setup a goal tracking mechanism. The goal is to track the interactions with the MVP and start learning from day 1.

Fortunately there are great free tools that you can use like Google Analytics or Mixpanel. If you have a small budget, you could also use Intercom to talk to the people using your product.

If you follow these rules, you will be able to release early and start iterating using real feedback.

Taxis, disrupted

Mon, 23 May 2016 22:21:07 -0400

Taxis have been doing the same thing for years. Pick up a passenger, hear the destination, take the passenger there, get paid. It’s pretty simple and it hasn’t evolved much in decades.

Taxis in Buenos Aires are transit’s public enemy number 1

Last month Uber launched in Argentina and disrupted the whole business. Taxis were obviously against the whole thing.

In the long run, Uber and other services like Lyft will become your preferred alternative. You will only hail a cab on the street when you can’t get an Uber or a Lyft.

Why?

Because the whole experience is more enjoyable and usually more secure. You can pay with your credit card. You have a clear idea of the fare. And if a driver misbehaves, you can easily report him.

Taxis never had to provide a better experience because there was no real competition. Until Uber launched in Buenos Aires, you could only get a taxi or a remise (private car service) to quickly drive you to places.

Just because you don’t need to innovate, it doesn’t mean you shouldn’t.

That’s the beauty of competition. It forces the players in the game to become better players, which is great for customers.

Hopefully the city government and Uber will find a way to legalize this business model and we will have better alternatives to get from point A to point B.

Taxis will have to adapt or die. It’s called survival of the fittest. When this finally happens, passengers will only benefit from this disruption.

Postponing a decision

Fri, 20 May 2016 19:54:56 -0400

Postponing a decision is a decision in itself.

Every time you need to make a decision, there is always a default.

For example: When you’re interviewing someone for a position, the default is a “No”.

If you postpone your decision, the candidate will understand that you are not going to hire her.

In that example you should tell the candidate whether you hire her or not. But if you don’t, she will understand that you won’t hire her.

If you can’t make up your mind, then your decision will be the default implicit decision.

Streaks, Part 2

Thu, 19 May 2016 23:51:41 -0400

Today I broke one of my latest streaks. Today I didn’t contribute to any open source projects and I broke a 35 days straight streak.

It was a bit disappointing but it was also a great run. I made at least one (sometimes very small) contribution every day for the past 35 days!

To be honest, this happened because I decided to stop bringing my MacBook home. And I have no regrets. I’m much happier having less distractions at home.

Every time I break a streak, I like to think about this:

How far will I go next time? I’m quite a competitive person and I can’t help to think about the next streak. Now the mark is quite high: 35 days! It’s a new goal for the next time. Get to 36 days, beat the last streak!
I can’t believe I made it so far. I was sure I was going to quit after 10 days (when I beat my last streak) but I kept going. I kept thinking: How far will I go this time?
The end of a streak brings the beginning of a new streak.

The Impostor Syndrome

Wed, 18 May 2016 22:10:03 -0400

I believe that high achieving individuals have suffered this syndrome at least once in their life.

I first heard of this concept in the last Rubyconf Argentina. It was one of the most interesting talks for programmers that had nothing to do with code.

People who suffer this are high-achieving individuals marked by an inability to internalize their accomplishments and a persistent fear of being exposed as a fraud.

You can read more about this here.

What has been really helpful to me is to always ask myself this question: What’s the worst thing that can happen?

If I send a proposal to a conference, what’s the worst thing that can happen? It might get rejected.

If I present a talk at a meetup, what’s the worst thing that can happen? People might hate it and might make fun of me.

Don’t let the fear stop you.

Instead of thinking, why me? Think, why not me?

On perfectionism

Tue, 17 May 2016 22:18:39 -0400

I’ll admit it. I’m pretty bad at product management. I’m a programmer, but I’m also a product manager at OmbuShop. I’ve been taught and I’ve learned that for something to reach production it needs to be perfect.

And by perfect I mean that it needs to work as expected. And it should also consume the least amount of resources to achieve its goal. And the build needs to pass. And there should be more test coverage.

Usually the programmer in me will be against deploying to production right away, because the feature is not perfect enough. While the product manager in me will be freaking out that we haven’t deployed in more than 2 weeks!

I know, deploying should be as boring as hell. That is something that I need to improve in our process.

Sometimes I wish I were more pragmatic when it comes to delivering a feature. Just because it is not perfect, it doesn’t mean that it’s not good enough.

As a programmer, you need to understand the concept of good enough software. There is a paper by Edward Yourdon that explains very clearly the relationship between cost, schedule, staffing, functionality, and quality.

When you are taking forever to deliver a feature, I suggest that you timebox it. Timeboxing will help you deliver software that is good enough. Because most times, you don’t need perfection, you just need something that is good enough.

Perfect is the enemy of good enough.

Focus

Mon, 16 May 2016 21:43:23 -0400

Close your Facebook, Twitter, Slack, Skype, Mail, and anything else that might produce an interruption.

Put your phone on do not disturb mode. Put your computer on do not disturb mode.

If you can work without Internet, shut down your connection. If you don’t need it, it will just produce interruptions.

Put on your headphones. Even if you don’t want to listen to music, you can use them to show other people that you can’t hear them.

Only then can really focus.

Only then you can achieve flow.

Mihaly Csikszentmihalyi’s famous TED talk: Flow, the secret to happiness

The work breakdown structure

Fri, 13 May 2016 22:48:50 -0400

Next time you need to tackle a big project, break it down into smaller projects. If the sub-projects are still too big, break them down into sub-sections. Then break those down into action items. You get the idea.

This technique has been around for ages, though in college it was reintroduced to me as the Work Breakdown Structure.

Before you start working on a huge project, you should have a list of prioritized items in your TODO list. Priorities will be defined by your requirements and limitations.

If you have a hard delivery date, you need to think about the duration of each part. If you only have 3 months and one of the parts will take 2 months due to bureaucracy (in life this will always happen) you should start with that on day 1.

Sometimes we face projects that seem impossible to be accomplished on time. This is what you need to know: They are not impossible. You just need to apply the WBS before you start.

Evaluating Advice

Thu, 12 May 2016 20:13:52 -0400

As an entrepreneur, I’ve heard a lot of advice from potential investors, investors, partners, clients, friends, family, acquaintances, random people at a party. You name it. I have received advice from everyone.

Only a few times I have actually acted based on their advice. Most times I will hear it, nod and later ignore the advice.

The hardest part is ignoring the advice from someone you really care about.

At some point in time, a good friend of yours is going to give you business advice. Someone who has been your friend for years, someone who you respect, someone who you love and who loves you.

They will mean well. They are giving you advice with good intentions. But…

The road to hell is paved with good intentions.

You need to take a step back and think about what you are hearing and who is saying it. You need to forget about your relationship. You need to evaluate their experience and if their advice is based on theory instead of practice.

That friend might have no experience starting nor running a business. Yet he is giving you advice as if he had been running a successful business for the past 10 years.

Take advice from people you respect and have enough experience to be giving advice. Otherwise, ignore at will.

The 10,000 hours rule

Wed, 11 May 2016 22:41:31 -0400

If you read Malcolm Gladwell’s Outliers you know about the 10,000 hours rule, which is based on a study by Anders Ericsson.

I’ve been listening to the series of episodes for self-improvement month in the Freakonomics radio podcast, which goes deep into this topic. It’s very interesting to hear the conflicting points of view of both Malcolm Gladwell and Anders Ericsson.

I believe that they both reach some common ground when they say it’s not just about deliberate practice.

If you don’t know how to play the piano, you won’t be a great piano player if you practice for more than 10,000 hours with the best teacher. You will definitely get better at it, but you won’t be a star piano player.

They say that “Practice makes perfect” but that’s just not so. If you don’t have some talent, you will never be the best in the world (even if you do deliberate practice for more than 10,000 hours)

Talent plus deliberate practice makes perfect.