New Entrepreneur Podcast by Reid Hoffman

Masters of Scale is a new entrepreneur podcast series from WaitWhat in association with Stitcher.

Masters of Scale - Entrepreneur Podcast by Reid Hoffman

The Podcast

On this show, they have guests like Mark Zuckerberg & Sheryl Sandberg (Facebook), Reed Hastings (Netflix), Eric Schmidt (Google) and Brian Chesky (Airbnb). They cover several topics like raising enough money when to do things that Scale and things that don’t Scale, good and bad business ideas, innovation, hiring, company culture and founder’s grit.

The show has a really light and humorous tone. This, together with high-quality guests and topics, makes it really easy to listen to the 30-minute episodes.

Continue reading

Command Line Script to Run Multiple Commands in Different Tabs

Multiple Log Tails in Different Command Line Tabs Image

Why Use a Bash Script that Launches Multiple Command Line Tabs?

Imagine you just rebooted your computer now for some reason…

Do you have this feeling of “Ok… Ii just need to open again a bunch command line tabs, run a series of scripts, start the log tails, open the IDE and I will be good to go!”?

If you still find yourself having to run all these commands, launching all the Docker containers and mounting the entire setup when you reboot your Linux machine, then keep reading! The solution may be a few lines of bash script 😉

Continue reading

From Scrum Master to Sprint Retrospectives, #15 SCRUM Concepts for Beginners

If you’re not familiar with SCRUM, it is a very powerful set of principles and methods that empower teams to deliver increments of a product in a more reliable and productive way. This means using short cycles of development while gathering constant feedback and adapting to eventual changes in product vision or customer needs.

This article is a sum of terms and concepts about SCRUM, extracted from Jeff Sutherland‘s book Scrum: The Art of Doing Twice the Work in Half the Time, to help beginner users to solidify the key parts of SCRUM in an summarized way. If you’re already a pro user, skip to the end! There is a nice SCRUM joke there 😉

#1 – Teams

When it comes to speed, most of the time, manpower is not the answer. If you’re not moving fast enough, focus on developing your team and your system instead of adding more people to the project.

One famous term in software development is the Brooks’s Law (book “The Mythical Man-Month”):

Adding manpower to a late software project makes it later

– Small teams get work done faster than big teams (Magic number is seven people with plus or minus two)

– Teams must be cross-functional and independent (They must have all the resources needed in the team and be autonomous to make decisions and move fast)

– Focus on team performance instead of individual performance

– Blaming is stupid. Look for the bad systems instead of looking for the bad people (Sometimes bad systems reward bad behaviors)

Continue reading

The Front-End Web Developer Spectrum

Modern front-end web development is in constant change. The evolution is this area has been so rapid in the past years that sometimes it’s hard to keep up with the new kids on the block while maintaining focus on what needs to be done.

One example is this image, that gives you an overview of all the different tools and technologies that have a part in the front-end and JavaScript ecosystem.

(Since there is a huge chance that, while I am writing this article, there are 100325 new front-end tools being released, it’s possible that this image is already not completely up to date.)

The Front-End Spectrum

Front-End-Spectrum

Continue reading

GitLab.com Backup Failure and Data Loss Incident

gitlab-logo

Last week, a backup incident in a staging server on GitLab resulted in the deletion of the production database and was responsible for 6 hours of data loss and some server downtime.

gitlab-downtime-data-loss

The official blog post about the incident starts like this:

Yesterday we had a serious incident with one of our databases. We lost six hours of database data (issues, merge requests, users, comments, snippets, etc.) for GitLab.com. Git/wiki repositories and self-hosted installations were not affected. Losing production data is unacceptable and in a few days we’ll publish a post on why this happened and a list of measures we will implement to prevent it happening again.

 

As we all know, data loss is a major nightmare for any product out there, but it’s worst if you’re a cloud code repository with a massive amount of daily users like GitLab. Although these things were not supposed to happen in 2017, organizations are made of humans (at least for now…) and making mistakes is part of being a human. But is the way that the organization deal with the problem that makes the difference.

GitLab’s Approach After Data Loss Incident

GitLab’s approach was based on transparency and it’s getting some positive feedback from the community.
They didn’t try to hide the problem and instead, they set up a live stream of the team resolving the problem (8 hours) and released a google docs explaining step by step how the mistake happened and how it got solved.

Continue reading