Clippings of 2019 Sep

Testing the boundaries of collaboration – Increment: Testing   Testing

We're probably bad at job titles. And it's OK.   Hiring

If you follow my work in this blog, you know I'm a strong advocate for understanding the problem and its context first, then coming up with a specific solution. This post is how we apply this idea to hiring:

  • Software Engineering varies so heavily & is so contextual that what (IMHO) works best is crafting your own solutions to solve your own specific problems (by MAPPING others’ experiences onto your own environment)
  • Everything starts with the actual needs:
    • what activities would a person do (typically)?
    • what goals would (s)he have?
    • which gaps would (s)he fill (in the org)?
    • how would we say whether (s)he does well or not?

RailsConf 2018: Engineering Engineering: More than the sum of our parts by Vietor Davis - YouTube   Management

This talk is about how to help well intentioned organizations become healthy organizations. And it's another application of understanding the problem and its context first.

  • Create stable solutions which balance investment and output
  • Remember that "what's right" is highly context dependent
    • Context matters
      • Few things are 100% bad
      • They are reactions to certain circumstance
  • All bad things have reasonable reasons: Understand them
    • Find the Positive reason to understand a Problem (like Politics)
    • Waterfall magnifies the cost of mistakes (and mistakes are easier to discover downstream)
  • Expect hard problems, bring your full brain
  • Achieve near team outcomes, they provide the credit to successfully achieve long term outcomes
    • Trust is the only silver bullet
      • What is "trust" in an organization
        • Trust is the expectation that observation doesn't influence trust
        • The ability to do the right thing, without asking for permission
      • Successful Execution results in Operational Latitude (Trust)
        • The more we get done, the more we can get done

How to Build Good Software   SoftwareEngineering

This post is a great summary of why software engineering matters and some key principles of software engineering.

  • Some characteristics particular to software that consistently cause traditional management practices to fail, while allowing small startups to succeed with a shoestring budget:
    1. Reusing good software is easy; it is what allows you to build good things quickly;
    2. Software is limited not by the amount of resources put into building it, but by how complex it can get before it breaks down;
    3. The main value in software is not the code produced, but the knowledge accumulated by the people who produced it.
  • Some core operating principles that can dramatically improve the chances of success:
    1. Start as simple as possible;
    2. Seek out problems and iterate;
    3. Hire the best engineers you can.

I recently summarized Agile as Continuous Learning. And this idea was influenced by this article, especially the statement that the main value in software is the knowledge accumulated by the people who produced it.

The only thing I disagree from this article is to hire the best engineers you can. I started my career aiming to become the best engineers. But after I dig into management, I found it was the environment that decided if an engineer can perform well or not.

How Technology Hijacks People's Minds — from a Magician and Google's Design Ethicist — Medium   Technology

This article reminded me to rethink about the technology I'm using. A few takeaways:

  1. All user interfaces are menus. Always ask "what's not on the menu?" and "what's my original need?"
  2. Avoid slot machines like twitter timelines, games, etc..
  3. We don’t miss what we don’t see. And it's okay to miss them.

Overfitting   SoftwareEngineering Abstraction

  • What is overfitting?
    1. overfit the code to a set of assumptions,
    2. then take it down and overfit the next version to the new set of assumptions
    3. It gets worse as the number of assumptions (or order) grows.

This paper explains the same idea as The Wrong Abstraction by Sandi Metz. Sometimes we abstract things too early based on some assumptions, but more often than not, these assumptions are wrong. So what I learned was to avoid making these assumptions and to always write the code based on the fact we know for sure.

太多企业只做敏捷表面功夫,一线程序员水平太差   Agile Coding



这会带来什么效应呢?别人会看到这个人价值很大。比如我 2013 年培养的毕业生,在我这培养了 1 年,他就可以去某知名大公司做咨询,去教该公司那些号称有多少年经验的程序员怎么做软件,这些老程序员还很服他。在我这工作 3 年,这家大公司出高薪去挖他,结果还没挖动。所以这个对个人价值的提升是非常明显的。

坐和放宽 — 对恋爱关系的思考   Love

  1. 平等
    1. 一般般好
    2. 哪哪都好
  2. 相信
    • 相信对方是爱自己的