Original: https://livebook.manning.com/book/street-coder/chapter-1/19
Translation: Zhu Kunrong

fb543da4d0da6b785bb5120e98e52bff.jpeg
bt3gl ♡ pictures: https://www.pexels.com/zh-cn/photo/3689659/

1.3.4 Embrace complexity and ambiguity

Complexity is scary, ambiguity is scarier because you don't know how much you're going to be scary.

Dealing with ambiguity is one of Microsoft's core skills when hiring. There are often hypothetical questions such as "How many violin repair shops are there in New York?" "How many gas stations are there in Los Angeles?" or "How many agents does the president have and what are their schedules? List their names and point out in the picture. their possible route from the White House"

The trick to solving these problems ends up being clarifying all the parts you know and reaching the end goal based on those facts. For example, you can get from the population of New York and how many people are likely to play the violin. This can help you sort out the size of the market and how much competition the market can support.

Likewise, when faced with a problem with many unknown parameters, such as estimating how long it will take to develop a feature, you can also narrow the approximation window based on what you know. You can use what you know to your advantage and use it as much as possible to reduce ambiguity.

Interestingly, the same goes for dealing with complexity. Something that seems extremely complex can also be made manageable by dividing and conquering, and then made simpler.

The clearer you are, the better you can deal with the unknown. The techniques learned in this book can help you figure things out and give you more confidence when dealing with ambiguity and complexity.

1.4 Problems with modern software development

In addition to the ever-increasing complexity, countless layers of abstraction and modern stack overflows, there are other problems with software development today:

  • There are too many technologies: too many programming languages, too many frameworks, too many libraries, think npm (the package management tool for the node.js framework) has a library called "left-pad" that handles adding spaces to the end of strings.
  • It is paradigm driven and thus conservative. Many programmers consider programming languages, best practices, design patterns, algorithms and data structures to be the legacy of alien races and have no idea how they work.
  • Technology is starting to become opaque, just like cars. People used to be able to fix their own cars. Now as the engine gets more advanced, all we can see is the metal casing, like the Tomb of the Pharaohs will curse anyone who opens it. Software development techniques are no different. Even though most things are now open source, I guess new technology is still more complex than reverse engineering of binary code from 1990, precisely because of the ever-increasing complexity of software.
  • People don't care about the overhead of their code because we have more resources. Have you written a new simple chat app? You know that tying it with a full-featured browser will save you time and no one will notice that you're using gigabytes of memory, so why not?
  • It makes sense that programmers focus on their own stacks and ignore other jobs: they have to serve food and don't have time to learn. I call this the "serving developer problem". Many things that affect the quality of the product will appear due to their own limitations. A web developer is usually completely ignorant of how network protocols work under the hood. They accept the delay in loading the page and accept the status quo because they don't know a small technical detail, an unnecessarily long certificate chain that slows down page loading.
  • Thanks to the programming paradigms we've learned, there's a chain of contempt for low-level jobs like don't repeat yourself or copy-paste. You expect to find a DRY solution. This culture causes you to question yourself and your abilities and ultimately damage your productivity.

The Story of NPM and Left-pad Over the past decade npm has become a package ecosystem for JavaScript libraries. People can contribute their own packages to the ecosystem, and other packages can use them, making it easier to develop large projects. Azer Koculu is one of the developers. Left-pad is just one of 250 packages he contributed to the npm ecosystem. It has only one function: adding spaces to a string ensures that it is always a suitable size.

One day he got an email from npm telling him they had removed one of his packages called "Kik" due to a complaint from a company of the same name. npm decided to remove Azer's package and give the name to that company. This annoyed Azer and removed all his contributed packages, including left-pad. So the problem is, hundreds of large projects depend directly or indirectly on this package. His actions brought all of these projects to a standstill. This disaster taught us a lesson about newcomers to the platform.

The story tells us that the road of life is full of scary surprises.

In this book, I offer some solutions to these problems, including reviewing some core concepts that you may find boring, prioritizing practicality, simplicity, rejecting some inherently unquestionable beliefs, and more importantly, questioning everything we do. Asking questions first is valuable.


This article is from Zhu Kunrong's WeChat public account "Malt Bread", the public account id "darkjune_think"

Developers / sci-fi enthusiasts / hardcore console players / amateur translators, please indicate.

Weibo: Zhu Kunrong
Station B: https://space.bilibili.com/23185593/

Communication Email: zhukunrong@yeah.net


祝坤荣
1k 声望1.5k 粉丝

科幻影迷,书虫,硬核玩家,译者