1. Summary

  1. An exercise: the architecture of this note

I confess that the architecture of this note is not of mine own conception. It is merely a reflection of the talking points that were mapped out in the video (1). I am sure the speaker, John, had thought carefully about the structure of his talk, and the assembly of which is beyond my brief analysis.

Although, we can observe its structure. The premise of the talk is the development of great programmers. Programming is an art, and great artwork is made by artists who possess a great drive and generative capacity. By analogy, great programs are created by programmers who possess a great drive and generative capacity.

At this point, it is clear what great programmers and artists produce. However, what makes their programs or artworks great? In other words, what is important in code? Herein, we introduce the balance of two elements (not of the same space): abstraction and concreteness. Abstraction is loosely defined as the ideal form of the program – what it is expected to do. Concreteness is the implementation of the program. Abstraction is a product of design, and great code is associated with greater levels of it. Therefore, design is an integral part of great code.

Lastly, the most practical discussion is of the types of programmers and the type of code they generate. The tactical programmer is known to create working but poorly designed code. The strategic programmer, on the other hand, creates well-designed and working code.

One way you can view the order of these concepts is how readily you can pinpoint the particular subject in reality. When it comes to the tactical vs. strategic programmers, software engineers can think of someone that fits either of these profiles. When it comes to the essentials of good code and programming, the answer is not so clear cut which John opens to discussion in the beginning of the video.

  1. Abstraction vs. concreteness

At 3:40, John mentions abstraction to be an integral part of coding. Above, we loosely defined abstraction as the expectations of a program. What a program is supposed to do is only partly correct. What John believes to be the most important aspect of coding is problem decomposition, and in terms of first principles, he makes a good point.

While abstraction is the expectation of a program, concreteness is the implementation of the program to actualize that. Abstraction and concreteness are not mutually exclusive, but they are unidirectionally complementary from concreteness to abstraction. There is no minimum amount of each either.

If concreteness automatically generates some amount of abstraction, then there must be varying amounts generated by concreteness. It is a ratio of some sort between the amount of code of a program and the utility it provides. Besides the sheer amount of code of the program, there must be some other factors that leverage the ratio between concreteness and abstraction. John argues that good design is the answer to leveraging this ratio.

  1. The tactical programmer

A buzzword commonly mentioned in the video is that of the 10x programmer. John describes it as an individual who can produce large amounts of code. It seems to strive for, but John cautions otherwise. While the code may work in the present, it may become detrimental in the future. On the other hand, strategic programmers prioritize design over pure implementation. What comprises design? READMEs, onboarding, and code reviews all comprise design. Strategic programmers more readily see their value and invest current resources. While they seem to accomplish less than tactical programmers, they gain momentum over time while the latter lose momentum.

  1. Source(s):

1 A Philosophy of Software Design | John Ousterhout | Talks at Google