Reading Notes of Hello, Startup-A Programmer’s guide to building products,technologies, and teams

从关于产品,技术和团队,到作为一名程序员在日常修行当中的注意事项,Yevgeniy Brikman把他知道的一切都告诉我们了.这可能是我今年读过最好的书了,就是这样。

Outline

Hello, Startup is a practical, actionable, how-to guide to startups. The book consists of three parts: Products, Technologies, and Teams. Although at its core, this is a book for programmers, by programmers, only Part II, Technologies, is significantly technical. Parts I and III should be accessible to technical and non-technical audiences alike. Below is the list of chapters in each part, and under each chapter, a sampling of the concrete techniques, tools, and skills you will learn from reading it.

Part I: Products

Chapter 1.Why Startups

  • What is a tech startup?
  • A tech startup is an organization with the following characteristics:

    • Product: technology

    • Environment: extremely uncertain

    • Goal: massive growth

    • Mode of operation: search

  • Why you should work at a startup
    • More opportunity
      • More ownership
      • More fun

  • Why you shouldn’t work at a startup
    • It’s not glamorous
    • It’s a sacrifice
    • You probably won’t get rich
    • Joining versus founding a startup

Chapter 2. Startup Ideas

  • Where ideas come from
  • creativity boils down to three stages that are all various forms of remixing :

    • Copy
    • Transform
    • Combine
  • Knowledge

    what should you invest your time in learning? One of the most effective strategies is to try to become a T-shaped person:People who are both generalists (highly skilled at a broad set of valuable things—the top of the T) and also experts (among the best in their field within a narrow discipline—the vertical leg of the T).

    • EXPERTS: you’ll need to spend some time on side projects, 20% projects, and hackathons
    • GENERALISTS: you have to regularly seek out new ideas.One way to do this is to come up with top five lists
  • Environment for creativity

    • Give yourself plenty of time.

    • Keep an idea journal.

    • Work on the problem.

    • Get away from work.:Make a habit every day of spending at least 20 minutes doing something that relaxes you and lets you listen to your own thoughts.

    • Add constraints.

    • Look for pain points.The important thing is to write down the problem even if you don’t know how to solve it yet.Learning to identify and fix particularly nasty problems is a valuable skill.

    • Talk to others.

  • Idea versus execution eg.

    • Problem: I don’t know any investors.
    • Idea: let’s find someone who can introduce us.

    • Execution: search for contacts on LinkedIn who know investors.

  • Validation

    • Speed Wins
    • Validate the problem
    • MARKET SIZING
      • Advertising
      • Competition
      • Community
      • Market research and reports
      • product data
    • TALKING TO REAL CUSTOMERS
  • feasibility

Chapter 3. Product Design

Design

Chapter 4. Data and Distribution

Part II. Technologies

Chapter 5. Choosing a Tech Stack

Evolving the tech stack

  • Technologies you should never build yourself

    • Security: cryptography, password storage, credit card storage

    • Web technologies: HTTP servers, server-side and client-side frameworks

    • Data systems: databases, NoSQL stores, caches, message queues

    • Software delivery: version control, build systems, deployment automation

    • CS 101: basic data structures (map, list, set), sorting algorithms

    • Libraries for common data formats: XML, HTML, CSV, JSON, URLs

    • Utility libraries: date/time manipulation, string manipulation, logging

    • Operating systems

    • Programming languages

Build in-house, buy commercial, or use open source summary?

Choosing a programming language

Programming paradigms

  • OBJECT-ORIENTED PROGRAMMINg
  • FUNCTIONAL PROGRAMMING
  • STATIC TYPING
  • AUTOMATIC MEMORY MANAGEMENT
  • Problem fit
  • Performance
  • Productivity
  • Final thoughts on choosing a programming language
    C family (C, C++, C#)

Go

Groovy

Haskell

Java

JavaScript

Lisp family (e.g., Clojure or Scheme)

Perl

PHP

Python

Ruby

Scala

You can quickly shorten this list by applying three filters: problem fit, programming paradigm, and performance requirements.

Choosing a server-side framework

it’s usually not a question of libraries versus framework but minimal framework versus full-stack framework

  • Problem fit
  • Data Layer
  • View Layer/BUILT-IN VIEW HELPERS
  • SERVER-SIDE VERSUS CLIENT-SIDE
  • LOGIC VERSUS LOGIC-LESS TEMPLATES
  • Testing
  • Scalability
  • I/O BOUND - use a web server built around non-blocking I/O, such as Node.js or Netty
  • CPU/MEMORY BOUND
  • Deployment
  • Security
  • AUTHENTICATION- You do not store passwords as plain text
  • CSRF ATTACKS
  • CODE INJECTION ATTACKS
  • Final thoughts on choosing a server-side framework
  • Hot Frameworks
  • C#: .NET

Clojure: Ring, Compojure, Hoplon

Go: Revel, Gorilla

Groovy: Grails

Haskell: Snap, Happstack, Scotty

Java: Spring, Play Framework, DropWizard, JSF, Struts

JavaScript: express.js, sails.js, derby.js, geddy.js, koa, kraken.js, meteor

Perl: Mojolicious, Catalyst, Dancer

PHP: Laravel, Phalcon, Symfony, CakePHP, Yii, Zend

Python: Django, Flask

Ruby: Ruby on Rails, Sinatra

Scala: Play Framework, Spray

Choosing a database - the most important consideration is maturity

  • Relational Databases
  • NoSQL databases
    • KEY-VALUE STORES
    • DOCUMENT STORES
    • COLUMN-ORIENTED DATABASES
    • GRAPH DATABASES

Optimize the data storage format and queries on your existing database.

Set up a cache in front of the database (e.g., memcached).

Set up master/slave replication.

Vertically partition unrelated tables.

Horizontally partition a single table.

Set up multi-master replication.

Recap

Here are the key trade-offs to consider when evaluating a programming language:

  • Programming paradigms
    Is it an object-oriented or functional programming language? Does it support static typing or automatic memory management?

  • Problem fit
    For example, C is particularly good for embedded systems, Erlang for fault-tolerant distributed systems, and R for statistics.

  • Performance
    How does the language handle concurrency? Does the language use garbage collection and how tunable is the collector?

  • Productivity
    How popular is the language? How many frameworks and libraries are available for it? How concise is it?

Here are the key trade-offs to consider when evaluating a server-side framework:

  • Problem fit
    For example, Rails is particularly good for CRUD applications, DropWizard for RESTful API servers, and Node.js for real-time webapps.

  • Data layer
    Does the framework help you manipulate URLs, JSON, and XML?

  • View layer
    Are there many built-in templating helpers? Does it use server-side or client-side rendering? Does it allow logic or is it logic-less?

  • Testing
    Is it easy to write unit tests for apps built on top of the framework? Is the framework itself well-tested?

  • Scalability
    Does the framework use blocking or non-blocking I/O? Have you benchmarked the framework with your use cases?

  • Deployment
    Do you know how to integrate the framework into your build? Do you know how to configure, deploy, and monitor it in production?

  • Security
    Is there an built-in, well-tested way within the framework to handle authentication, CSRF, code injection, and security advisories?

Here are the key trade-offs to consider when evaluating a database:

  • Database type
    Is it a relational database or a NoSQL store (key-value store, document store, column-oriented database, or graph database)?

  • Reading data
    Do you need to look up data by primary key or secondary key? Do you need JOINs? How do you map the data into an in-memory representation?

  • Writing data
    Do your writes update just a single aggregate or many? Do you need atomic updates or transactions?

  • Schemas
    Is the schema stored explicitly in the database or implicitly in your application code? Is your data uniform or unstructured?

  • Scalability
    Can you get by with just vertically scaling your database? If not, does the database support replication, partitioning, or both?

  • Failure modes
    How many different ways can the system fail? How easy are the failures to debug?

  • Maturity
    For how long has this database been in development? How many companies are using it? How rich is the ecosystem of supporting tools?

    Towards a model of polyglot programming, where you use different technologies for different use cases. That is, you build a tech stack on top of a number of different services, where each service is written using different languages and frameworks, is deployed to different servers, talks to different data stores, and communicates with other services via remote messages .

Chapter 6. Clean Code

Code is for people

  • introduce the basic principles of clean code, including code layout, naming, don’t repeat yourself (DRY), the single responsibility principle (SRP), functional programming, loose coupling, high cohesion, comments, and refactoring.

Chapter 7. Scalability

  • Scaling coding practices

    • Automated tests

      • Unit tests
      • Integration tests
      • Acceptance tests
      • Performance tests
      • EST-DRIVEN DEVELOPMENT (TDD)
    • Split up the code

In programming, there are many different kinds of abstractions. We’ll just look at the three most common ones:

  • Interfaces and modules
  • Versioned artifacts
  • Services

    • Code reviews

      • design reiews
      • pair programming
      • pre-commit reviews
      • static analysis
    • Documentation

    • WRITTEN DOCUMENTATION

Written documentation consists of the readme, tutorials, reference manuals, and project websites.

  • CODE DOCUMENTATION
  • COMMUNITY DOCUMENTATION

Scaling performance

Improving performance is an iterative two-step process:

  • Measure

  • Optimize

    • Divide and conquer
    • Caching
    • Laziness
    • Approximate correctness
    • Asynchrony
    • Redundancy
    • Faster algorithms

Chapter 8. Software Delivery

  • Build

    • Version Control
      • WRITE GOOD COMMIT MESSAGES
      • COMMIT EARLY AND OFTEN
    • build tool
    • CI
      • TRUNK-BASED DEVELOPMENT
      • BRANCH BY ABSTRACTION
      • FEATURE TOGGLES
  • Deployment

    • Hosting (Where)
    • Configuration Management(What)
      • APPLICATION CONFIGURATION
        • VIRTUAL MACHINES
        • CONTAINERS
        • ORCHESTRATION TOOLS
    • DEPLOYMENT AUTOMATION
    • Continuous Delivery
      • ROLLBACK
      • BACKWARD COMPATIBILITY
  • Monitoring

    • Logging
    • Metrics
    • Alerting

RECAP

  • move fast and don’t break things.

  • what happens to the code after you write it is just as important for productivity. This includes integrating your code with other developers through version control and a build process, getting your code to production by setting up hosting, configuration management, and automated deployment, and ensuring your code keeps running in production through logging, metrics, and alerting.

  • DevOps

Teams

Chapter 9. Startup Culture

Actions, not words

Core Ideology

  • Mission
  • concise
  • clear
  • timeless
  • inspiring
  • Core Values

Organizational design

  • Management-driven hierarchy

    • set objrctives
    • organize
    • motivate and communicate
    • measure
    • develop people
  • distributed organization

Hiring and promotions

  • The Peter Principle:every post tends to be occupied by an employee who is incompetent to carry out its duties

  • Management as a promotion(wrong)

Motivation

  • Autonomy
  • Mastery
  • Purpose

The office

The ideal office for developers needs to have four things:

  • A place where you can work with others.

  • A place where you can do focused work alone.

  • A place where you can get away from work.

  • A way to customize the office for your personal needs.

What kind of tools do developers typically want? Here’s a list to get you started:

  • Desk built for programming (flat, large, with an adjustable height)

  • Comfortable chair

  • Fast laptop or desktop (max out the RAM, CPU, and hard drive)

  • One or two large monitors

  • Good mouse and keyboard

  • Fast Internet connection everywhere in the office

  • Plenty of power outlets

  • Whiteboard

  • Basic office supplies (notebooks, Post-its, pens, markers, printers)

  • Storage space (a place for a jacket, bag, and private items)

Remote work

  • Benefits

    • ideal for focused work
    • save money
  • Drawbacks

    • Meetings are harder
    • interactions are much less frequent
    • security

Best practices

our team should work like an open source project [Tomayko 2012]. Open source projects are inherently distributed, so they have developed practices over the last 20 years to make this model work.

  • Electronic
  • Available
  • Asynchronous
  • Lock free

Communication

  • internal
  • external

Process

  • A company’s core ideology is the why. The process is the how.
  • The stronger the culture, the less corporate process a company needs.

Software methodologies

Recap

Take a company and subtract the profit. What do you get? A <startup. Take a company and subtract the people. What do <you get? Nothing. It can’t exist.
-[Preston-Werner 2012], Tom Preston-Werner, GitHub Co-founder

Companies should be about making people happy, not about profits. In other words, startups are about people.

Chapter 10. Getting a Job at a Startup

Finding a startup job

  • What industries and types of products are you interested in?
  • What technologies are you passionate about?
  • What type of business model are you interested in?
  • What role are you looking for?
  • What other factors are you looking for?
  • What role are you looking for?
  • What other factors are you looking for?

Use your network

Grow your network

  • MEETUP GROUPS AND CONFERENCES Start your own!
  • HACKATHONS AND COMPETITIONS :go out, do two or three hackathons, and spend a couple weeks building projects.
  • TALKS, BLOG POSTS, OPEN SOURCE
  • Build an online identity
  • Online job search

Nailing the interview

  • Coding on a whiteboard
  • Thinking out loud
  • Know yourself
    Tell me about yourself.

What projects have you worked on before?

Why are you looking for a new job?

Why do you want to work here?

What is your ideal job?

What do you want to be doing in five years? Ten years?

What are your greatest strengths? Weaknesses?

What is your greatest accomplishment?

What was the toughest bug you ever fixed?

What else should I have asked you?

  • Know the company
    What are the expectations for the role?

What does success look like in this job?

Who will be my manager?

What projects will I work on?

What is the tech stack?

What are the hours like? How many of them are spent coding? In meetings?

How do you build and release code?

What are the company’s mission and values?

What is the office like?

What’s your favorite and least favorite part of working here?

  • Short, repetitive CS 101 problems

How to evaluate and negotiate a job offer

  • salary
  • equity
  • benefits

Recap

Put yourself in the shoes of a startup founder and write down the traits of someone you would want to hire.

Smart.

Gets things done.

Good culture fit.

Chapter 11. Hiring for Your Startup

Who to hire

  • Co-founders
  • Early hires
  • Later hires
  • 10x developers

What to look for

  • SMART/GETS THINGS DONE
  • CULTURE FIT
  • GOOD COMMUNICATION SKILLS
  • I WOULD BE OK REPORTING TO THEM

Finding great candidates

  • Referrals:everyone is a recruiter
  • Employer branding
  • Searching online

The interview

STEP 1: CONNECT
STEP 2: PHONE SCREENS
STEP 3: ON-SITE INTERVIEW

Interview questions

  • ASK THE CANDIDATE TO TEACH YOU SOMETHING

  • GIVE THE CANDIDATE A CHANCE TO LEARN SOMETHING

  • HAVE THE CANDIDATE DEMONSTRATE THEIR TECHNICAL SKILLS

Making an offer

  • the oppotunity
  • compensation
  • benefits
  • Follow-up and negotiation

Chapter 12. Learning

Principles of learning

  • Choose your skills wisely.

  • Dedicate time to learning.

  • Make learning a part of your job.

Learning techniques

  • Study.
    • Read articles, blog posts, and books
    • Read academic papers
    • Take a class.
    • Attend a talk, meetup group, or conference
    • Read code, especially from open source projects.

three things that make my study time more effective

  • set concrete, measurable goals
  • take notes.
  • involve your friends and coworkers in the learning process

  • Build.

A maker.

Until you start making things, most of your learning, whether from books or from school, will feel largely useless.

I started to try to make something of myself and I realized that I needed help.

the best thing you can do is to find a project where you have to build something you don’t know how to build.

  • Share.

Who are the best software engineers in the world?

What are the best software companies in the world?

Why these names and not others? It’s because these engineers and companies not only do great work but also spend time telling you that they do great work.

WHY YOU SHOULD SHARE

  • Mastery: The best way to learn is to teach.
  • Quality
  • Labor :they are doing QA, for free.
  • Marketing
  • Ownership

推荐阅读

http://www.hello-startup.net/resources/recommended-reading/

思维导图下载

MindNode