国民收入模型和分配理论

国民收入模型是新古典宏观经济学中较为著名的一个模型。国民收入模型旨在讨论在一个经济体当中,经济的收入是如何从 企业向家庭分配的,以及商品和服务的需求与产品和服务的供给之间是如何达到均衡水平的。

首先我们需要了解这个模型中的三大主体:企业,家庭,和政府。其中,家庭得到收入,向政府纳税,并向企业购买产品和服务。企业主要提供产品和服务。政府从税收中得到收入,用其支付政府购买。

在平衡的供给一方是产品的生产和服务。为了对其进行量化,我们引入了生产要素和生产函数的概念。首先假设在这个模型中只存在两个生产要素:

  • 资本:K
  • 劳动力:L

企业将生产要素转化为产品和服务:

  • Y=F(K, L)

同时我们假设生产函数具有规模不变效应,也就是说,生产要素增加Z%会带来产出增加Z%。企业在生产的产品和服务的过程中需要进行支付购买生产要素,这部分资金就进入了家庭当中–生产要素的提供者。那么什么决定了向家庭的收入分配呢?为了解释这个现象,我们引入了要素价格,也就是支付给生产要素的报酬数量,如果假设只存在资本和劳动力两种要素,那么报酬就仅仅包括工人的工资和资本所有者的租金。

那么什么决定了这些要素的价格呢?国民收入模型在这里引入了另一个重要的假设:竞争性企业。在这种假设之下,市场是完全竞争的,企业对于生产要素的价格的影响可以忽略不计。如果我们假定企业用P价格出售产品,用W工资雇佣工人,用R价格租用资本,那么企业的利润就可以用下面的共识表示:

  • Profit = PY – WL – RK = PF(K, L) – WL – RK

我们假设企业的经营目标是是利润最大化。那么利润在何时会达到最大呢?在之前的文章中,我们谈到过边际产量数,也就是企业每多一个单位的投入所带来的单位产出,边际产量是递减的,因此产出也会递减,于是:当边际产量所带来的收入恰好等于边际的生产要素成本的时候,企业便达到了最大利润,继续增加生产则会降低利润。这个定理可以适用于劳动力和资本两种生产要素,用公式表示:

  • PxMPL = W 当劳动力的边际产量至等于工资的时候,企业的产出达到了最大化。
  • PxMPK = R 当资本的边际产量等于资本的租赁价格的时候,企业的产出达到了最大化。

那么生产要素如何决定市场中经济收入的分配呢?当企业在充分竞争的市场运营的时候回答道上述的边际状态,也就是工人的实际工资等于劳动力的边际产量值,资本的回报的等于资本的边际产量值。假设企业在支付了劳动报酬和资本租赁价格之后的盈利是经济利润,那么经济利润等于:

  • Y – MPLxK – MPKxK

而根据规模不变的效应,经营利润等于0,因此Y=MPLxK + MPKxK

现在我们已经知道什么决定了市场中收入的分配,那么什么决定市场中对产品和需求的供应呢?首先我们可以认为GDP分为下面四个部分:

  • 消费(C):假设消费水平直接取决于可支配收入,C=C(Y-T)
  • 投资(I):假设投资量的需求去决定于利率:I=I(r)
  • 政府购买(G):

那么是什么使得消费,投资和政府购买之和等于所生产的产出量呢?这里我们引入可贷资金市场,我们认为可贷资金市场来源于居民储蓄S,那么

  • S= Y – C – G = I

经过变换可以得到:

  • S = (Y – C – T)-(T-G)

其中(Y-C-T)等于收入减去消费,减去税收,等于私人储蓄,T-G等于税收减去政府支出,为公共储蓄。带入前面所得到的投资函数和消费函数可以得到

  • Y – C(Y-T) – G = I(r)

为了使得等式,也就是可贷资金市场达到均衡,利率r将起到调节作用。在给定的T和G之下,储蓄量是不变的,而投资函数是一个向右下倾斜的曲线,因此:

  • 当投资需求大于供给也就是储蓄量的时候,利率将上升,从而降低供给。
  • 当投资需求你小于供给也就是储蓄量的时候,利率将下降,更多资金将进入投资。

我们需要注意,在这个均衡模型中我们进行了诸多假设,比如:我们没有加入货币市场,我们假设这是一个封闭的经济体,我们还假设这个经济体中的就业是充分的,而且资本存量,劳动力和生产技术是固定的。在后续的解释中,我们将通过扩展这些模型来更加准确的了解宏观经济运行。

过于国民收入的一个非常著名的理论来源于马克思主义的劳动价值理论。马克思主义经济学引入了两个主要的理论:劳动价值理论和剩余价值理论。马克思主义认为劳动是创造价值的唯一方式,机器在劳动中将一部分价值转移到了商品当中,但是资本方并没有参与劳动因此也就没有生产价值。马克思主义认为,商品生产中在出去不变成本和可变成本之后的为剩余价值,而这一部分剩余价值应归属劳动者所有。在传统的经济学当中,我们认为这部分的剩余价值是包含企业投资资本的租值的,也就是企业的投资回报。

书评:弗里德曼《自由选择》

政府在经济活动中应该扮演多大的作用一直都是颇具争议性的话题。弗里德曼在《自由选择》一书中充分阐释了他的理念:政府应该致力于充分支持经济自由,让市场发挥完全的作用。弗里德曼是自由主义的坚定支持者。在他看来,美国的经济奇迹建立在两个自由之上:政治自由和经济自由。前者由人权宣言和美国的宪政体系所保证,后者则由亚当斯密以来深入人心的经济学思想来维系。但是从大萧条开始,经济自由开始受到越来越多的威胁。

美国1930年代的经济大萧条是经济思想的一次大转折。普通民众和学界都开始认为大萧条是市场失灵的结果,于是凯恩斯主义开始逐渐兴起。以大萧条的政治氛围为契机,从经济领域开始,政府在普通民众的生活中开始发挥越来越大的作用。从经济安全到社会平等,从促进教育到保护消费者,从保护劳工到避免通货膨胀、促进就业,政府的影响越来越多的进入到人们的日常生活当中。

弗里德曼认为市场尤其是价格有三个主要作用。第一个作用是传递信息,当信息构成相互比较的时候人们得以据此作出选择,第二个作用是促使人们采取最高效的生产办法;第三个作用是收入分配。弗里德曼认为,这三个功能是相互联系的,人们有动力改进他们的生产方式,是因为这些造成的价格改变最终会影响他们的收入。共产主义政府所犯的错误在于试图将收入的分配和价格体系隔离开来,直接决定人们的收入分配,价格机制所传递出的信息被扭曲了,人们也就失去了改进工作和生产的动力。

国际贸易是一直一个广受政府干预的领域。几乎所有的经济学理论和经济学家都支持自由贸易,因为自由贸易使消费者获得更加廉价的产品,使生产者可以专注于更具有比较优势的行业。但是自由贸易也是都到政治影响最多的经济领域。人们以各种理由反对自由贸易,比如保护等行业但不具备产品竞争优势的劳工,对其他国家政府补贴行为的反击,出于国家安全的需要,出于保护新兴产业的需要等等。在弗里德曼看来,这些顾虑大都是特殊的利益群体自我保护的结构,自由贸易最终都还是有利于各方的。

1930年代的大萧条是人类历史上最令人瞩目的事件之一,它使得公众相信资本主义是不稳定的,为了避免危机再次发生,政府有必要介入经济活动。这场危机也同时在经济学专业领域上产生了深远影响:凯恩斯主义的兴起。弗里德曼认为,公众和学术界对自由市场观点的转移是源自对大萧条发生原因的误解:大萧条是政府的行动错位而不是市场的失灵造成的,而美联储系统等政府经济控制机构的崛起实际上是受益于当时的这种政治氛围。

伴随大萧条新政而来的是一系列的社会福利计划,比如社会保障计划、健康保险计划等等。在西欧,国家福利主义开始盛行,比如英国的全民健康保险计划。在美国,最大的福利计划则是社会保障计划。社会保障实际上用现在的征收的税收来给已经退休的老人养老,这种计划的问题在于它无法提供任何保障,因为谁也难以预料未来若干年退休之后社会保障资金的运转情况如何。

在做着看来,社会福利主义的兴起部分的源于对结果平等的追求。比如诸多的收入再分配计划。这种做法实际上会损害到经济和社会本身,因为这样一来大家努力进取的动力就变低了获得回报的很大一部分被拿走交税,而就算不努力工作所获得的支出也不会太差。而在那些努力宣扬其追求结果公平的国家里,最终这些用来保证结果公平的强制力都落入了那些追求自己特殊利益的人的手中。

与结果平等相对的是起点平等,其含义是只有一个人的才能才会决定他的机会,除此之外任何因素都不应该影响他获得的机会。然而起点公平本身就是一个复杂而难以实现的想法:究竟怎样才算起点公平呢?一个穷人的孩子和一个富人的孩子所可以得到的教育资源就是完全不一样的,这样难道不是一种不公平吗?弗里德曼认为,先天所继承和拥有的财富就如同一个人先天的禀赋一样,是自然的事情,不应该被嫉妒。他认为,起点公平是和自由相互关联的,如果对于平等的追求被置于自由之上了,那么它无疑将会损害自由,反之,自由将可以用来促进公平。

政府干预经济自由的另一个领域在教育市场。作者认为政府设立的公立助学计划限制了家长们的选择自由。家长需要通过交税为公立学校出资,但是公立学校并不能满足所有家庭的教育需求。作者的建议是在初级和中级教育阶段设立凭单制,家长可以使用凭单来抵扣教育的费用,这样一来家长可以在公立教育和私立教育之间灵活选择。

第二个受政府干预的领域是消费者保护。近半个世纪以来,政府开始设立越来越多的消费者保护机构,比如州际商务委员会,消费品安全委员会,环境部等等。这些机构提供诸如帮助消费者鉴定产品质量以避免上当受骗的价值。但弗里德曼认为,这些政府结构的设置阻碍了市场的自由发展,如果允许市场自由竞争,那么这些问题都会随之解决。

第三个例子是劳动者保护。政府和劳工委员会通过设立基本工资,进行薪酬谈判等方式来保护劳工的利益。但在作者看来这实际上是难以实现的。市场的供需关系不会改变,人为设立的基本工资只会限制和降低劳动需求量,最终损害劳动者的利益。 比如工会谈判要求提高工资,这样一来势必会压缩企业的利润空间,从而导致企业降低劳工人数以控制人力成本。而一般认为的提供工资提升空间的公司利润部分实际上是资本的利得部分,如果一项投资的回报率降低,势必导致对该行业或企业投资的减少。初次之外,劳工委员会常常和政治影响力合作,通过政治影响来增加自己所在群体的特殊利益,又反过来对政治力量予以支持。在作者看来,这些都是政府不适当干预经济过程的后果。

在本书的最后,作者谈到了通货膨胀的现象和医治。作者认为通货膨胀完全是一种货币现象,其发生的根源在于政府滥发货币。通货膨胀实际上是政府获取资金而又不直接增加税收的一种隐蔽的手段,获取资金只需要开动印钞机即可,既增加支出而又不增加税收简直是一件大快人心的好事。但是实际上通货膨胀的成本最后还是会转嫁到普通民众身上。通货膨胀的另一大原因是政府错误地将控制就业作为基本目标。为了达到不切实际的就业率,政府只能通过增加支出来实现,因此必然导致货币超发发,通货膨胀。为了治疗通货膨胀,在抑制政府开支的同时,还必须忍耐高失业率这一副作用。

弗里德曼在这本书中所讨论的都是颇具争议性的话题,比如大萧条的成因,消费者保护,国家是否应该设立公共教育,控制通货膨胀和控制失业率之间的权衡等等。在这些争议当中,弗里德曼总是坚定地站在市场这一边,并且从理性的经济学的角度阐释选择自由市场的好处。这本书另一个具有启发性的地方在于,他使人们看到了在实际的经济决策当中不可忽视的政治因素–尽管他的本意是要尽力摒除这些政治因素。比如在国际贸易的争论当中,在利益受到短期损害的民众的选票和长期的不容易立即显现的贸易价值之间,政治家很可能选择前者以讨好民众包住选票。在自由主义和政府主义的光谱中间,我们已经看到了全世界各个不同国家的选择。这本书为我们观察这些国家的社会现状提供了一个好的切入点。

Book Review: Cloud Native Java

Cloud Native Java provides an overview of why people want to build cloud-native applications, and how to build them with Spring Boot and other frameworks.

A cloud-native application focus on the application logic that solves the business and product problems, without worrying about the underlying infrastructures setup and operation. Spring Boot is such a framework that provides a simple service bootstrapping process as it covers most of the complicated configuration process in order to bring up a service. It does not solve every engineering problem you will be facing, but it provides easy integrations with the best framework on the problem domains.

Spring Boot enables you to quickly build a REST application, you can have such an application up and running with half an hour. The easy to use reminds of some good frameworks in the Python web world like Falsk. You can easily equip your framework with different persistence solutions: SQL database like MySQL and PostgreSQL, NoSQL database like MongoDB, cache services like Redis. You can also build a data-driven application with the Spring message channel framework or integrating with messaging brokers like Kafka, RabbitMQ.

Spring makes such integration easy by providing you with the native abstraction frameworks to integrate with such systems, like Spring JPA for database access, Spring Data Cache for cache service access, and Spring Message Channel for streaming frameworks. These abstractions help you focus on the application logic without worrying about the underlying details.

Spring also utilize the well-built framework to solve the problems beyond the application logic. By integrating with OAuth, it provides robust authentication and authorization solution. By integrating with Eureka, it helps you solve the middle tier routing problems.

It is fair to say that this book is very comprehensive. It almost covers every aspect of the system that you need to build for a cloud application. The well-organized examples and annotations make this book a handbook for people who need to solve exactly the same problem.

It is a good guide book for people who try to understand how to build a Java application with Spring Boot on the cloud. It discusses some of the essential problems you need to consider and solve when building cloud native applications, and it demonstrated that these problems can be solved easily with spring boot. 

However, I don’t consider it as a good book for people who are exploring Spring Boot as an alternative solution for the engineering problems within a relatively established world.

The major issue is: the infrastructure components in such an organization mostly have already been built. The challenge for the engineers is to integrate the SpringBoot into the existing system.  For one example, OAthu is a good choice for authentication, but what if your company already have it’s own authentication system, for example, Django’s authentication framework where each client is viewed as a user?

I understand that it is very difficult to write such a book that fit for everyone’s use case. as every company is built differently, a solution works for one company might not work for another. And the most interesting challenge for the engineers is to solve the problem with a given context. 

The other problem of this book is that it lacks the in-depth discussions of the essential problems engineerings will be facing when building cloud-native applications. The discussion in this book is relatively superficial. For books that don’t provide the right solution, I expect them to provide inspiriation.

Overall, I recommend this book to people who are new to the industry and new to the Java web service programming world. For people who are looking for more in-depth solutions or discussions, this book is not a right choice.

Book Review: The Effective Engineer

The effective engineer raise a simple question: how does the engineer leverage his or her effort to make a disproportionate and meaningful impact? Before answering the question, we would want to know how to define and measure the effectiveness of an engineer and engineering activities. The author believes that leverage, the value or impact produced per time invested, is the best measurement for the effectiveness. In order to increase your effectiveness, you should focus on either get the same task done more quickly, or to increase the impact of your activities, or to shift to activities with higher leverage.

The foremost and fundamental part of becoming more effective is to adopt the right mindset. Including focusing on high-leverage activities, optimize for learning, and prioritize regularly in order to keep yourself focused.

The following sections of this book are essentially discussing the two major approaches of increasing your effectiveness. Part II of this book focused on execution: how do you get your work done more efficiently.

The first advise it offers it to improve the iteration speed: the faster you can iterate, the more output you could generate within a given time. Many factors could slow down the iteration speed: maybe your team works on a huge monolithic service without enough support on tooling and debugging, maybe your existing service requires constant operation support that your team gets distracted. To become more effective, you should constantly think about what makes you and your team’s iteration speed slow down.

Another advice is to measure what you want to improve. A common mistake people make during work is using the wrong metric to measure the problem. Selecting the wrong metric could be misleading.

Measuring the area you want to improve also help you better drive the work. Whether you are an individual contributor, a tech lead or an engineering manager, you must be in situations when you would like to bring some technical, product work to people’s attention so that you get their consensus on the priority of the work and support to work on it. In these situations, data and metrics are more compelling than words. So the best strategy is to measure the scope of your work: how many order we lost every day due to this issue, how many customers are being affected. You will be much better off with these measures.

The third advice is to validate your ideas early and often. I’ve got multiple opportunities to start new products from scratch. I find it is very useful to deliver the first version of the product as fast as you can, collect the requirements from your customers then try to improve on it. It is very hard to picture every detail of your product before you bring it to your customer. And I give this advice to every engineer working on some project.

The fourth advice is to improve your project estimation skill. Project estimation is hard, but it is important for the team to communicate the expectation to the stakeholders, and for the business to decide the priority of these works. We made many mistakes on effort estiamation, people either tend to underestimate or overestimate the difficulties of their task, and there is an anchor effect on people’s preference. For large project estimation, this becomes even challenging,  because we oftentimes underestimate the unknown parts, and they only start to materialize once the team starts to work on them. Of course, there are approaches to reduce the risk of inaccurate effort estimation, for example, ask the people that will work on the task to do the estimation, and timebox the investigation on the unknown part.

For tech leads and engineering manager who held the responsibilities of communicating the expectation and progress to the stakeholders, the effort estimation becomes even more critical. First of all, you should define a clear goal for your project. A clearly defined goal not only helps you better manage the expectations of the stakeholders but also provides with you a good approach to correctly scope the works and prioritize the tasks.  Secondly, you should build your project incrementally. Trying to achieve multiple goals in one project can significantly increase the risk your project get slipped, as the complexity of the project grows exponentially.

Part III of this focused on building long-term value: which is the more impactful work for the engineers comparing to other activities like delivery a feature.

The advice from this section includes balancing the quality with pragmatism. An essential topic for most the engineering team is how to improve the quality of the work, except for a few companies like Google, as they introduced such a good code review system to make sure the code is written in good quality. This is not the case for most other engineering teams. Introduce the code review process will be helpful. Another such topic is about tech debt. Tech debt will be accumulated as the team takes shortcuts on the development. It is totally okay to introduce tech debt on the code base, but the team should also have a pan to continuously repay the tech debt.

The next advice is to minimize the operational burden. You must always be aware of the tech decision you make: is it engineering infrastructure you build robust enough that you don’t need to worry about its operation support? Does the tools you provide enough visibilities with the clients to track out the failures easily? Another typical mistake we make is to introduce new technology without enough knowledge about its operational burden.

The last advice is to invest in your team’s growth.  Help the people around you be successful, building a better onboarding process, making hiring a priority of the team. All these works would lead to a better engineering culture.

This book is not only a good choice for engineers who want to become more effective but also a good guide for the engineering managers to materialize their ideas of building a better team: essentially only when your team member becomes effective, you will be effective.