Skip to content

therobinkim/reading-list

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

33 Commits
 
 

Repository files navigation

In Progress

  • Effective Engineer

  • Mostly Adequate Guide to Functional Programming

  • Awareness by Anthony de Mello

Done

  • user > ops > dev
  • biz > ops > dev
  • biz ≹ user
  • Many people like to think that UI can be derived deterministically from state, when this is simply not true.
  • React's attempts to become more pure (eg, classes -> hooks) makes it become further out of touch from reality.
  • Svelte!

prefer duplication over the wrong abstraction

Q: Aren’t you just a member of the PC police trying to take away my First Amendment rights? A: No. The First Amendment protects you from government interference in free speech. It does not protect you from criticism about the words you use.

What it takes to get the job isn't what it takes to do the job well

  • Use side projects as a way to stick out
  • Twitter: a technical notebook to express thoughts about things learned and built
  • Record conference-like talks and post them online

Do tell us a story; don't bury the lede; don't say what YOU'LL get out of the position; aim at the right target; get somebody to proofread

Try product vs infrastructure instead!

  1. Favor embedding unless there's a compelling reason not to.
  2. If you need to access an object on its own, don't embed it.
  3. Consider one-to-few vs one-to-many vs one-to-squillions. Don't embed if you have high-cardinality arrays.
  4. Don't be afraid of application-level joins; if you index correctly and use the projection specifier, it'll be fine.
  5. Only denormalize when the read-to-write ratio is high. Don't denormalize infrequently read, but often updated data.
  6. Structure your data to match the ways your application queries and updates it.

May I be filled with lovingkindness.

May I be safe from inner and outer dangers.

May I be well in body and mind.

May I be at ease and happy.

Learn how to design beautiful user interfaces by yourself using specific tactics explained from a developer's point-of-view.

"I know how I would solve the problem" => "I know how others would solve the problem" => "I can anticipate how the API choices that I'm making, or the abstractions that I'm introducing into a project, how they impact how other people would solve a problem."

You want to get to a state where whatever the engineers on your team do, the most straightforward way is also the right way-so that they don't get off the path, so that they naturally do the right thing.

Otherwise add a test that ensure the right way,

Don't talk about any topic that you could discuss in the open

Maybe in the Future

This book is a guide to how we do product development at Basecamp. It’s also a toolbox full of techniques that you can apply in your own way to your own process.

Whether you’re a founder, CTO, product manager, designer, or developer, you’re probably here because of some common challenges that all software companies have to face.

As software teams start to grow, some common struggles appear:

  • Team members feel like their projects are never-ending.
  • Product managers can’t find time to think strategically about the product.
  • Founders ask themselves: “Why can’t we get features out the door like we used to in the early days?”

We saw these challenges first-hand at Basecamp as we grew from four people to over fifty. Through years of trial and error — and some contrarian thinking — we solved these problems. For over fifteen years we’ve consistently shipped new software at a high-level of quality while maintaining a sense of calm and order.

Recently more and more friends and peers have asked us how we do it. This book is a comprehensive answer.

Atomic Design details all that goes into creating and maintaining robust design systems, allowing you to roll out higher quality, more consistent UIs faster than ever before. This book introduces a methodology for thinking of our UIs as thoughtful hierarchies, discusses the qualities of effective pattern libraries, and showcases techniques to transform your team's design and development workflow.

This book describes the process of refactoring and spends most of its time explaining how to do the various refactorings - the behavior preserving transformations. The book opens with a simple example that describes the whole process. There are then some introductory chapters that discuss broader issues around refactoring, the “code smells” that suggest refactoring, and the role of testing. The bulk of the book is around seventy refactorings described in detail: the motivation for doing them, mechanics of how to do them safely and a simple example.

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published