Clippings of 2020 Mar

Top 13

Refactoring UI: The Book

With tons of practical examples, this book helped me better understand principles of design: color, layout, text, depth, etc. Right after reading this book, I applied one of the refactor techniques to my daily work: Add a subtle shadow to various logos to prevent background bleed.

I'd highly recommend this book to every Web developer after they learn some basic concepts of Web UI design.

(BTW, I'd also recommend this video serious from thoughtbot for learning basic Web Design concepts: Design for Developers - Visual Layout Online Tutorial by thoughtbot)

We Don’t Sell Saddles Here - Stewart Butterfield - Medium

  • Sell the innovation, not the product
    • The best (maybe the only?) real, direct measure of "innovation" is change in human behaviour.
    • Innovation is the sum of change across the whole system, not a thing which causes a change in how people behave
    • That's why what we're selling is organizational transformation
    • The best possible way to find product-market fit is to define your own market

Tons of valuable startup knowledge in this memo from early days of Slack. No wonder Slack can become such a popular tool.

The biggest takeaway for me is that "innovation" is change in human behaviour. If we think of some biggest innovations in the past (computer, Internet, iPhone, and so on), they all dramatically changed human behaviour. Start innovation by changing behaviour of yourself, then your team, your users, and finally change this world.

3 Reasons Why Great Engineers Don’t Become Managers

  1. People Problems Are Not Engineering Problems
  2. Managers Work With Relationships, Not Politics
  3. Solving Real Technical Issues Is Less Than 30% Of Your Day

Lessons Learned - 10 Years of Running a Software Consultancy - DockYard

  • Business Development
    • Software consulting above most other things is about trust. (The client wants to trust your ability to spend their money wisely.)
    • for software services a big part of BD job is process and ensuring that things are getting done and moving forward.
    • Promote from within, someone with either engineering or PM experience.
  • Design
    • allow design to collaborate and receive feedback from other departments during design phases of contracts.
  • Delegating
    • people who are hired specifically for a job are better at doing that job 100% of the time than I was trying to do that job 10% of the time.
  • Open Source development has had no real meaningful and direct contribution to DockYard’s revenue. Ever.
    • Marketing is not sales.
    • We primarily capture sales leads because of our expertise.
  • A software consultancy at some point always becomes a people management firm.
    • The headcount is much higher for revenue than it is at most other types of companies because we are directly selling our people’s time.
    • The only way to scale that is to either
      1. find more time to sell, which we try very hard not to do,
      2. increase the cost of that time to our clients, which we have more or less settled in for the past few years,
      3. or add more people, assuming you have the projects to put them on.
  • The reality is that the brand a company projects outward is never what is happening internally.
    • Consulting is a messy game.
      • There are cut throats.
      • There are clients that want to steal.
      • There are jobs that can allow your company to grow one day and nearly put you out of business the next.
      • There are often many and conflicting roads to success and there are even more to ruin.
  • you have to be lucky.
    • your chance at getting lucky is where the skills of running a business come into play.
      • The longer you can stretch out your business strategy then you increase the potential of luck playing out in your favor.
      • if you want to build something that is going to persist and thrive you have to think about the long game.
        • Where do you want your business to be five years from now? Ten years from now?
        • Figure that out and work backwards from there. The mental exercise of going backwards from the potential of success allows you to develop a proper strategy to achieve it.

Devon Estes - Comparing common concurrency patterns in Elixir and Erlang - Lambda Days 2020 - YouTube

  • Share a common vocabulary like Object-Oriented Design Patterns
  • 4 useful patterns from A Pattern Language for Parallel Application Programming
    Embarrassingly Parallel
    Simple examples
    • Eagerly evaluated, linear input
    • No communication with parent
    • No communication between siblings
    • No shared dependencies between siblings
    Reduction (async/await)
    • Eagerly evaluated, linear input
    • Communication with parent allowed
    • No communication between siblings
    • No shared dependencies between siblings
    Asynchronous Decomposition
    • Lazily evaluated input of unknown size
    • Communication with parent allowed
    • No communication between siblings
    • No shared dependencies between siblings
    Pipeline Processing
    • Lazily evaluated input of unknown size
    • Communication with parent allowed (rare)
    • Communication between siblings allowed
    • Shared dependencies allowed (but require management)
  • Summary

      Input evaluation Communication w/ parent Communication w/ siblings Shared dependencies
    Embarrassingly Parallel Eager No No No
    Reduction Eager Yes No No
    Asynchronous Decomposition Lazy Yes No No
    Pipeline Processing Lazy Yes Yes Yes

Four Solutions to a Trivial Problem - Guy Steele Jr. - YouTube

  • the best way to write parallel applications is not to have to think about parallelism (separation of concerns)
  • The issue is not so much parallelism is independence
  • Accumulators are BAD. Divide-and-conquer is GOOD.
  • Certain algebraic properties are very important
    • Programmers need help to ensure these properties

12 Signs You’re Working in a Feature Factory - @johncutlefish's blog

  1. No measurement
  2. Rapid shuffling of teams and projects (aka Team Tetris)
  3. Success theater around “shipping” with little discussion about impact
  4. Infrequent (acknowledged) failures and scrapped work
  5. No connection to core metrics
  6. No PM retrospectives
  7. Obsessing about prioritization
  8. No tweaking
  9. Culture of hand-offs
  10. Large batches
  11. Chasing upfront revenue
  12. Shiny objects

🚀 DevTernity 2019: J.B. Rainsberger – The Well-Balanced Programmer - YouTube

Are the software product companies doomed to collapse under the weight of their creations?

  • Different kinds of companies deal with that in a varying way - it depends mainly on their culture & dynamics.
    • The most ambitious & modern-thinking ones usually try to outgrow the problem: they invest in a massive increase of manpower to accelerate development, so their causative power remains higher than their inertia
    • The more enlightened ones create software in a rewrite-friendly way: once debt (of whatever sort) gets too high within a component or a sub-system, it's getting scrapped & re-written (Productivity in the age of hypergrowth)
  • How can we at least increase our odds in the fight for long-term technical excellence?
    Negative Delta
    more stuff is being SCRAPPED than ADDED
    No Open Fire
    make sure you're out of fire-fighting mode (e.g. daily outages, unstable environments, excessively buggy apps that affect business).
    WIP of 1 / secure (exclusive) capacity
    when certain people are working on goals related to technical debt, they should work ONLY on that
    Talk is cheap, show me the numbers
    Be precise when it comes to what you're struggling with
    Consider thrice before building anything
    maybe some products/tools/services should be scrapped w/o re-writing.
    Unlock capacity first
    Companies suffocate not because of the technical debt, but usually due to how it constraints their development agility
    • These are the topics you should probably look at first:
      • build time (incl. dependencies & redundant compilation)
      • everyday dependencies between teams
      • frequency of change integration between collaborating teams
      • stability of test environments & the repeatability of deployment process

Reminds me of The Unicorn Project

A rewrite that only changes one layer is rarely worth its cost.

From puzzles to products, Jessica Kerr (Atomist) - YouTube

  • code is a detail
  • the point is to design change
    • where to next?
    • whole system route
    • how will we see its effects?

Jonathan Blow - Preventing the Collapse of Civilization (English only) - YouTube

  • Technology automatically degrades (if no one works on it) We have this idea of technology marching forward, but it goes backward all the time
    • Space program
    • The Lycurgus Cup (300 AD)
    • Antikythera Mechanism (200-80 BC) (mechanical calendar)
  • Why technology degrades?
    • It takes a lot of energy to communicate from generation to generation,
    • there are loses (in that communication process).
    • Without generational transfer, civilization dies
  • Thesis: Software is in decline
    • Collapses look slow from the inside
    • Software has been riding on immense hardware improvement, so it looks like it's doing okay
    • We don't expect software to work anymore
  • software startups are about stumbling into a market, not doing software technology well
  • Sequence of Abstraction
    • Converse: Loss of Capability
    • This is "for productivity", but productivity is approaching 0
  • The Argument that software is advancing us obviously false
    • Robustness is declining
    • Productivity is declining
  • Why is it so bad? We are adding so much complication