The script used by @KentBeck automated the commit-push-PR steps: `while(true); do git pull --rebase; git push; done;`.

And trunk based development explains how to work in small steps and keep the build working:https://t.co/q8kRBZBwub

I'm working toward this future, and you?

— Yiming Chen (@dsdshcym) September 27, 2019

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?

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

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.

The real 10x is in the environment, not the individual contributor. The world is full of capable, creative people who’d make that 10x jump if only they weren’t being trapped and demotivated by the stupidity of the modern workplace.

— DHH (@dhh) July 13, 2019

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.

• 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.

如果有一个程序员他开始意识到，我每天的工作是什么，我的基本功（如何），对我开发效率有影响的事情是什么。我们讲：理解需求、拆分任务、编写测试、高质量的代码实现——所有这些动作能够很快的做出来。这五个要素很少有企业去考他。

但是如果程序员自己意识到了这些东西很重要，去练习这方面的能力，他就会在这个团队中鹤立鸡群。他做的工作会更快、更好。

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

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