skip to content
Notes && Anecdotes

Likable videos on the internet.

  • Startup execution: Focus on few things

    Focus is critial. There's 100 important things to work on every single day, so you need to say no more often than you'd like.
  • Make everyone do support

    I like to think of a support ticket as a condensed result of a user test. It's a user telling you what they want, what they don't understand, and what they don't like. Treasure it, and spread that knowledge across the company by having everyone do customer support.
  • Scalable frontend velocity

    Make it easy to delete: colocate by feature. Make it easy to build it right: automated checks. Make it easy to be newb: reduce knowledge-requirements, embrace dumb questions. Migrate incrementally: large diffs fail. Use a monorepo: reduced error rate. Make code quality derivative positive: make things better over time.
  • Review your own PRs

    I wrote in a (student) newspaper once. I bet I wrote ~10 typos per page. 9 of which I caught on my own review. Similarily, most bugs I write are apparent to myself when I review the code. It's like its two different brain modes: producer and reviewr.
  • Build for today. Only today

    I often add a field, model or endpoint that I need 'tomorrow'. When 'tomorrow' finally shows up, it's usually not quite what I need. Note to self: Stop building for tomorrow. Stop build it 100% complete. Stop over-generalizing to fit future scenarios.
  • Don't abbreviate variable names

    Variable name: don't make them short and cryptic – let them be as long as they really are. Sidenote: Subscribe to that channel, it's great.
  • Don't write comments

    There is a consistent way of describing how a program should work, it is called writing code. Writing comments that describe how code work is usually an excuse for writing bad code. Exceptions: documentation/issue links, and sometimes bad code is required.
  • Test "commit driven development"

    Writing smaller commits is a constant practice that I feel often pays off. The Primeagens reflections on the topic is worth seeing (from 11:16, earlier parts are so so). Challenge: for your next feature, write commits messages first!
  • DRY does more harm than good

    «Please DRY up your code» is usually bad advice – abstraction creates coupling and complex code. I'd advocate ALRY – ALways Repeat Yourself (once). When that code has matured, you are in a better position to see if it's a matching concept that can be combined to common code – or if it's just accidentally similar.
  • Speed: Performance vs Velocity vs Adaptability

    The speed of your app can be seen as a combination of performance (how fast the user experiences it), velocity (how fast you add features) and adaptability (how well suited code are for future changes). TLDR of the talk: Don't care about performance until it's a problem. Then measure, test and measure.
  • React.js: The Documentary

    React.js: The Documentary is a 2015 documentary film about the React.js JavaScript library. Bring popcorn?
  • Typescript: don't use interfaces

    Use types instead of interfaces in Typescript. Except when you have to use interface.
  • Typescript: do not use enums

    Typescript enums are bad. Never use them, use a record as const instead. Note: This still applies after the 5.0 release with enum improvements (they are not bad instead of terrible).
  • The job of my boss: make me feel trusted

    Extend the circle of safety to the outer parts of the organisation. When employees feels safe and trusted, they can spend they energy being creative and productive.
  • Take initiative beyond what is expected of you

    «Guest leadership» is about taking responsibility to try to solve a problem or task that is not your own (alone), without needing an invitation to do so. Increase trust and ownership by giving your team the freedom to own the outcome and trust to solve things their way.
  • React Conf 2017: A Prettier Printer

    While ESLint eliminated the need for people to talk about code conventions, Prettier can eliminate the need for people to think about code formatting. 10 000 thumbs up! I will never work for a company without autoformatting again.
  • GraphQL: Designing a Data Language

    GraphQL will replace REST, and the world with be a better place with end-to-end typing safety.
  • Chromes Awesome Developer Tools

    A tour of the Developer tools: emulate network speed. emulate devices. JS debugger. console log timing. profiler.
  • Building a better Bootstrap

    Many mini nuggets on CSS systems. cssstats.com, atozcss.com, sassmeister.com, thesassway.com
  • 7 ineffective coding habits

    Don't write comments, don't write off the line, don't make complex methods with many parameters, don't make complex methods with many parameters, don't do lousy encapsulation, testing should be a reflection of your functions.
  • Clean Code III: Functions

    Functions should do 1 thing. And be short. With few args. Without comments.