5 Matching Annotations
  1. Aug 2021
    1. This is problematic because a project without a corresponding goal is known as a “hobby.” If you’re not committed to or haven’t fully articulated the outcome you want, you must be doing it just for fun. And if you have a goal without a corresponding project, that’s called a “dream.” You may desire it with all your heart and soul, but without an active project, you are not in fact currently making any progress.

      Project without goal = hobby Goal without a project = dream

    2. You can easily see how failing to make this distinction leads to common frustrations: if you have a project that you think is an area (for example, the book I’ve been “writing” for a couple years now, that feels like a never-ending part of my life), it will tend to continue indefinitely. If you have an area that you think is a project (for example, a health outcome like “losing X pounds”), you’ll revert right back after it’s been achieved, because you didn’t put in place any mechanism for maintaining the standard.

      This distinction is important, as it gives you clear and structured way to get things done.

  2. Jul 2021
    1. I used to be very interested in Software Architecture, in fact I've read many of the papers cited here.When I did a startup many years ago, I committed the mistake of paying too much attention to the architecture of the software [1] I was writing, and not enough attention to the product/customer side of it.The last couple of years I've been de-emphasizing software architecture as an interest, and have been paying much more attention to how product teams build successful products, what the patterns are, etc. I was lucky enough to work at Facebook for a while and got to see (and learn) a very successful working model of product development.So, while I'm not saying that software architecture is not important (it is), also pay attention to the product/customer side: what choices (software, organizational, hiring, business) allow you to move fast and iterate, to release early and often, to run A/B tests, etc.I think good software engineers are just as much product guys (and data guys) as they are software guys.
    1. Growth hacking and lowest common denominator experiences are their problems, so we should avoid making them our problems, too. We already have various tools for enabling growth: the freedom to use the software for any purpose being one of the most powerful. We can go the other way and provide deeply-specific experiences that solve a small collection of problems incredibly well for a small number of people. Then those people become super-committed fans because no other thing works as well for them as our thing, and they tell their small number of friends, who can not only use this great thing but have the freedom to study how the program works, and change it so it does their computing as they wish—or to get someone to change it for them. Thus the snowball turns into an avalanche.

      This is exactly how I feel about Joplin - the open-source note taking application, developed as an alternative to Evernote.

    1. I've had this discussion with peer engineers working at other tech companies, FANG (Facebook, Amazon, Netflix, Google), as well as at smaller startups. Most teams and projects - however large or small - all shared a similar approach to design and implementation:Start with the business problem. What are we trying to solve? What product are we trying to build and why? How can we measure success?Brainstorm the approach. Get together with the team and through multiple sessions, figure out what solution will work. Keep these brainstormings small. Start at a high level, going down to lower levels.Whiteboard your approach. Get the team together and have a person draw up the approach the team is converging to. You should be able to explain the architecture of your system/app on a whiteboard clearly, starting at the high-level, diving deeper as needed. If you have trouble with this explanation or it's not clear enough, there's more work required on the details.Write it up via simple documentation with simple diagrams based on what you explained on the whiteboard. Keep jargon to the minimum: you want even junior engineers to understand what it's about. Write it using clear and easy to follow language. At Uber, we use an RFC-like process with various templates.Talk about tradeoffs and alternatives. Good software design and good architecture are all about making the right tradeoffs. No design choice is good or bad by itself: it all depends on the context and the goals. Is your architecture split into different services? Mention why you decided against going with one large service, that might have some other benefits, like more straightforward and quicker deployment. Did you choose to extend a service or module with new functionality? Weigh the option of building a separate service or module instead, and what the pros and cons of that approach would be.Circulate the design document within the team/organization and get feedback. At Uber, we used to send out all our software design documents to all engineers, until there were around 2,000 of us. Now that we're larger, we still distribute them very widely, but we've started balancing the signal/noise ratio more. Encourage people asking questions and offering alternatives. Be pragmatic in setting sensible time limits to discuss the feedback and incorporate it, where it's needed. Straightforward feedback can be quickly addressed on the spot, while more detailed feedback might be quicker to settle in-person.

      A good, high level overview on how to get started with architecture