This is a repository of awesome articles, videos, tweets, and thoughts on building software startups.
In this intriguing business novel, which illustrates state-of-the-art economic theory, Alex Rogo is a UniCo plant manager whose factory and marriage are failing. To revitalize the plant, he follows piecemeal advice from an elusive former college professor who teaches, for example, that reduction in the efficiency of some plant operations may make the entire operation more productive. Alex's attempts to find the path to profitability and to engage his employees in the struggle involve the listener; and thankfully the authors' economic models, including a game with matchsticks and bowls, are easy to understand. Although some characters are as anonymous as the goods manufactured in the factory, others ring true. In addition, the tender story of Alex and his wife's separation and reconciliation makes a touching contrast to the rest of the book. Recommended for anyone with an interest in the state of the American economy.
The Lean Startup approach fosters companies that are both more capital efficient and that leverage human creativity more effectively. Inspired by lessons from lean manufacturing, it relies on “validated learning”, rapid scientific experimentation, as well as a number of counter-intuitive practices that shorten product-development cycles, measure actual progress without resorting to vanity metrics, and learn what customers really want. It enables a company to shift directions with agility, altering plans inch by inch, minute by minute.
A series of lectures unpacking a single idea:
Technology can bring benefits if, and only if, it diminishes a limitation.
Why are you struggling to grow your business when everyone else seems to be crushing their goals? If you needed to triple revenue within the next three years, would you know exactly how to do it? Doubling the size of your business, tripling it, even growing ten times larger isn’t about magic. It’s not about privileges, luck, or working harder. There’s a template that the world’s fastest growing companies follow to achieve and sustain much, much faster growth.
Straight from the programming trenches, The Pragmatic Programmer cuts through the increasing specialization and technicalities of modern software development to examine the core process--taking a requirement and producing working, maintainable code that delights its users. It covers topics ranging from personal responsibility and career development to architectural techniques for keeping your code flexible and easy to adapt and reuse.
Embrace failure. Chaos and failure are your friends. The issue is not if you will fail, it is when you will fail, and whether you will notice. It's between whether it will annoy all of your users because the entire site is down, or if it will annoy only a few users until you fix it at your leisure the next morning.
Instrumentation and monitoring often get lumped under the "ops" umbrella, but it's just as critical for every decent software engineer. You can't hope to understand what's going on in even a moderately complex system, unless you've been building for observability all along. Easy to say, harder to do.
Let's talk about how this plays out in the real world -- how to focus your limited engineering time on high-impact instrumentation, where to start, how your needs may change as the project matures or the contributor list grows; how and where to use traces, events and metrics. We'll talk about some of the differences between monolith vs microservices, databases, and mobile/web instrumentation ... and how to avoid the kind of solution fragmentation that creates silos between teams.
For us as team leaders, the goal and the way we measure our work is the overall growth in skills of self-organization and self-maintenance in each member of our team and the team as a whole. To that end:
- We accept that the team's needs from us change continuously based on their skills for handling the current reality of work, so we embrace a continuously changing leadership style over a one-style-fits-all leadership approach.
- We believe in challenging ourselves and our teams to always get better, so:
- We create slack time for the team to learn and be challenged.
- We embrace taking risks for our team over staying safe.
- We embrace fear and discomfort while learning new skills over keeping people within their comfort zone.
- We embrace experimentation as a constant practice over maintaining the status quo:
- With people
- With tools
- With processes
- With the environment
- We believe our core practice is leading people, not wielding machines, so:
- We embrace spending more time with our team than in meetings.
- We embrace treating software problems as people problems.
- We learn people skills and communication techniques.
On build a README for yourself for the purpose of communicating your working style to the rest of your team.
What is “slack”? Slack is the degree of freedom in a company that allows it to change. It could be something as simple as adding an assistant to a department, letting high-priced talent spend less time at the photo copier and more time making key decisions. Slack could also appear in the way a company treats employees: instead of loading them up with overwork, a company designed with slack allows its people room to breathe, increase effectiveness, and reinvent themselves.
With a blend of software engineering facts and thought-provoking opinions, Fred Brooks offers insight for anyone managing complex projects. These essays draw from his experience as project manager for the IBM System/360 computer family and then for OS/360, its massive software system.
“Peopleware is the one book that everyone who runs a software team needs to read and reread once a year. In the quarter century since the first edition appeared, it has become more important, not less, to think about the social and human issues in software develop¿ment. This is the only way we’re going to make more humane, productive workplaces. Buy it, read it, and keep a stock on hand in the office supply closet.”
—Joel Spolsky, Co-founder, Stack Overflow
How to manage products with Theory of Constraints.
Michael Seibel of Y Combinator moderates a discussion on building product with Steve Huffman of Reddit and Emmett Shear of Twitch.
Steve Huffman, on re-writes:
I think you need to be clear whether you're talking about tech or the product. I'll repeat what I said before, which was, "your users don't care about your tech." So, if you can move forward, leave that for another day. If you're talking about redesigning your product, you're probably in trouble because whatever habits led you to build a product your customers don't like, if you haven't addressed those habits, you're probably going to build another product your customers don't like.
I've been through a bunch of re-writes. At Hipmonk we re-wrote our flight and hotels, probably about half a dozen times each. At Reddit, we re-wrote the tech a whole bunch of times, and we're re-doing the UI and UX now. With better habits and better data. You want to make sure you know something new, but honestly, if you're in that situation, I would also go through another exercise of: Okay, what's the new MVP?
It comes up in tech a lot, the second system syndrome. The same thing happens in the product, where you're like, alright I've got this vision. I'm going to fix all of the mistakes at once and its going to be perfect. That product never ships. It never ships. So, can you iterate your way there? Can you just start from scratch with an MVP and build it back up? Those are much more likely to actually get somewhere. Their also harder to do and require more discipline.
Emmett Shear, on product disagreements:
You talk to your users first and then you have the ideas about the product. Almost everyone does it in the opposite order. It's called product validation. If you find yourself thinking I'm going to go talk to my users to validate my product idea. You've gone horribly off the rails. You do it in the other order. You don't talk to user to validate your product ideas. You talk to users to have your product ideas.
I just have a rule in general, for people who want to have a voice in product design. They better talk to the users and look at the data too. If you haven't talked to users, and you haven't looked at data, you don't get to have an opinion about the product. I'm sorry. The person who has actually done the work gets to have the opinion. You can have ideas, but they get to make the call.
In the case where you wind up where, both people really have talked to users, and both really have looked at the data. And people still disagree with what we should build, which by the way is actually much more rare, once both people have actually talked to users and actually looked at data, its usually relatively easy to get to consensus. It will still come up that people will disagree. I have found its better when you just have someone whose in charge. At the end of the day, you have someone whose the CEO, and everyone agrees this person's judgement will be trusted and you let them make the call. Don't avoid conflict. Talk about it. Argue about it. But then, you have someone who just gets to make the call. Cause anything else leads too... just, decision making is far to slow for a startup.
Learn how to building an internal component library & style guide can help your company ship and iterate faster. This talk will cover how we created a scalable & maintainable UI library (http://ux.mulesoft.com) with ES6, React, and PostCSS for consumption across multiple product teams.
The role of the product organization is to consistently deliver significant new value to the business through continuous product innovation. At a startup, the product team either innovates and provides real value or the startup dies. However, in larger, more established companies, product teams very often lose their ability to deliver that ongoing value. They just make minor optimizations to existing products. Or they continue to turn out more features that don’t make a difference.
I’m always badgering teams about moving faster. Yet I continue to meet people and teams that not only move very slow, they don’t understand the relationship between speed and innovation, or speed and quality. In fact, many people still think those goals are at odds. I attribute this mainly to a deeply rooted Waterfall mindset.
Software only becomes valuable when you ship it to customers. Before then it’s just a costly accumulation of hard work and assumptions.
Make your team’s deploys as boring as hell and stop stressing about it.
A talk about code, teams & process by @holman
Feature Flags decouple deployments from releasing software.
The downside of Feature Flags, they must be managed with discipline or they will cost you in the long run.
The Goal, but for delivering software instead of manufacturing.
A blog post I wrote on everything I've learned about implementing timezones the many times I've had to do it.
Probably the best post on timezones.
The trade-offs of micro-services in the real world.