To answer the question right away, the best way to start is not by choosing a programming book and reading over all syntactical features of the programming language. Surprisingly, these coding books sell well—even I am a seller of such books. However, interacting with thousands of programming students personally I realized that many ambitious students buy programming books as a commitment device to put the learning task on their ToDo lists—if they’ve spent money on the book, they better read it or the investment will be lost. But as so many other tasks on their ToDo lists, reading a programming book is seldomly one to be completed. (View Highlight)
So, what is the best way to start to learn to program? In my opinion, the best way to start is to choose a practical code project—a simple one if you’re a beginner—and push it to completion.
Don’t read coding books before you do this.
Don’t read random tutorials on the web.
Don’t scroll through endless feeds on StackOverflow.
Just set up the project and start coding with the limited skills you have and your common sense.
It’s okay if you don’t understand what you’re doing, you will gradually increase your understanding. You read books and articles only to make progress on the project in front of you. By diving into the process of finishing your first project, you need to solve a number of highly relevant problems:
Which code editor should you use?
How to install Python?
How to read input from a file?
How to store the input in your program for later use?
How to manipulate the input to obtain the desired output?
By answering these questions, you gradually build a well-rounded skill set of a practitioner. Over time, you’ll answer these questions better and better. Your speed and skill to solve these problems will grow. You’ll be able to solve similar problems much bigger and you’ll create your internal database of programming patterns and conceptual insights. Even advanced coders learn and improve with the exact same process—only the coding projects have become much larger and more complicated. (View Highlight)
You’ll struggle with complexity in:
finding bugs in ever-growing codebases,
understanding code components and how they interact,
choosing the right feature to be implemented next,
understanding the mathematical and conceptual basics of the code. (View Highlight)
Complexity is everywhere, at every stage of a project that comes to life. And the hidden costs of this complexity are very tangible: coders who are just starting out throw in the towel and the projects never see the light of day. The beginner argues: “coding is too difficult for me” and he truly believes it—even though nothing can be further from the truth. (View Highlight)
The answer is straightforward, and I’ve already stressed it a few times in this book: minimalism. Seek simplicity and focus – in every stage of the coding cycle. I want you to take this one concept out of the book: Take a radically minimalistic position in every area you’ll encounter in the programming space. If this book can convince you to take more extreme measures to increase your focus, it has accomplished its mission! (View Highlight)
Complexity: “a whole, made up of parts, that is difficult to analyze, understand, or explain”. (View Highlight)
Tags: favorite
If you are a coder, you are especially prone to overwhelming complexity. Let’s dive into different sources of complexity in the field of programming:
Complexity in a Project Lifecycle
Complexity in Software and Algorithmic Theory
Complexity in Learning
Complexity in Processes
Complexity in Social Networks
Complexity in Your Daily Life
Complexity in a Project Lifecycle (View Highlight)
The first stage of the software development life cycle is the planning phase. From software engineering literature, you may know this as requirement analysis. The purpose of this phase is to determine how the end product will look like. A successful planning phase leads to a strictly defined set of required features to deliver to the customer or the end user. (View Highlight)
This phase is crucial because it can save you from massive wastages of downstream energy in the following phases. Business owners know that capital allocation (or generally-speaking: resource allocation) is the single most important function of a CEO. The planning phase is where leverage plays out to its fullest extent: Planning mistakes can lead to millions of dollars’ worth of wasted resources. On the other hand, careful planning has the power of setting the business up for great success in the years to follow. The planning phase is a great leverage point where you can apply your newly acquired skill of 80/20 thinking. (View Highlight)
However, the planning phase is also very difficult to do right. (View Highlight)
Why? Because of our major enemy that is lurking everywhere: complexity. It is complicated to assess risk in advance properly. It’s equally complicated to figure out the strategic direction of a company or an organization. It’s complicated to guess the customers’ responses to a software project. It’s complicated to weigh the positive impact of different feature candidates—the features that are considered for inclusion. And it’s complicated to determine the legal implications of a given software feature. Taken together, the sheer complexity of solving this multi-dimensional problem is killing us. (View Highlight)
Compared to the previous phase, this phase is relatively simple. The defining phase consists of translating the results of the previous phase (requirements) into properly specified software requirements. In other words, it formalizes the output of the previous phase to gain approval or feedback from clients and end users who will later use the product. (View Highlight)
The goal of the designing phase is to draft the architecture of the system, decide on the modules and components that deliver the defined functionality, and design the user interface – keeping the requirements in mind that were developed in the previous two phases. The gold standard of the designing phase is to create a crystal-clear picture on how the final software product will look like and how it is built. (View Highlight)
Roughly speaking, you want maximum bang for your buck. (View Highlight)
This is where many coders want to spend all their time in. The building phase is where the transformation from the architectural draft to the software product happens. Here, your ideas transform into tangible results—it feels satisfying to see your brainchild come to life. (View Highlight)
Yet, the building phase is always full of new and emerging problems. Unexpected things happen that slow down the progress such as bugs in external libraries, performance issues, corrupted data, human mistakes, and many more. Building a software product is a highly complicated endeavor. To write great software, you must use an artificial language and properly explain to dumb machines what to do in every possible circumstance. A small spelling mistake (=bug) can decide over the correctness and viability of the whole software product. (View Highlight)
You still must test the behavior of your software product for different user inputs and usage patterns. It seems like a minor detail, but this phase is often the most important of all! (View Highlight)
In fact, it’s so important that many practitioners now advocate the use of test-driven development where you don’t even start to implement (in the previous phase) without having written all tests. While you can argue against that point of view – I haven’t seen a way to rigorously deploy test-driven development in practice – it’s generally a good idea to spend lots of time to think of different ways to test your product by creating test cases and checking if the software delivers the correct result for these test cases. (View Highlight)
Your software has passed the rigorous testing phase. Now, it’s time to release it and throw it into the marketplace. (View Highlight)
Complexity in Software and Algorithmic Theory (View Highlight)
That’s why algorithmic complexity is a thoroughly researched field with decades of progress and myriads of computer scientists who continuously reduce the algorithmic complexity of algorithms to solve the same problems quicker and quicker. In my opinion, the algorithms produced in decades of computer science research are among the most valuable technological assets of humanity. Those algorithms allow us to solve the same problems with fewer resources, not once, but over and over. We truly stand on the shoulders of giants. (View Highlight)
The world’s information can be modeled as a huge network of interrelated chunks of information—and no chunk of information is independent of other chunks. (View Highlight)
In the year 2012, Google announced to populate a data structure called the “Knowledge Graph” with information. The knowledge graph represents information in a network-like structure—which, instead of storing dumb and independent facts, maintained an interrelationship between different facts and pieces of information. (View Highlight)
The Google search engine then used this interdependency of facts to enrich the search results with higher-level knowledge and to create many answers autonomously. (View Highlight)
Example: small part of the knowledge graph may be about the famous computer scientist Alan Turing. In the knowledge graph, the concept of Alan Turing is connected to different pieces of information such as his birth year (2012), his field of study (computer science, philosophy, language theory), and his doctoral advisor (Alonzo Church). Each of those pieces of information is also connected to other facts (e.g., Alonzo Church’s field of study was computer science as well), forming a massive network of interrelated facts. You can use this network to acquire new information and answer user queries programmatically. For example, a query about the “field of study of Turing’s doctor father” would result in the deducted answer “computer science”. While this may sound trivial to you, generating new factoids like these lead to a breakthrough in information retrieval and search engine relevancy. You’d probably agree that it’s far more effective to learn by association than by remembering unrelated facts. You can easily remember a story, but you struggle remembering the phone number of your mother! (View Highlight)
If you study any field, you must accumulate knowledge about a great number of interrelated facts. Over time, you’ll understand more than you understood before—but you’ll never understand everything. Knowledge is far too complex. There are too many dependencies and facts in the graph. You can learn more but the more you learn, the more you become aware of the limitations of your knowledge. It is obvious that complexity poses the most fundamental boundaries to your ambitions to learn. Learning and complexity are two sides of the same coin: complexity is at the boundary of the knowledge you’ve already acquired. To learn more, you must first know how to control complexity. (View Highlight)
We’re getting kind of abstract here, so let’s have a practical example! Say you want to program a trading bot that buys and sells assets according to a set of sophisticated rules. There’s lots of useful knowledge that you could learn before starting your project. You could learn about concepts such as the basics of programming, distributed systems, databases, application programming interfaces (APIs), web services, machine learning, data science, maths and many more. (View Highlight)
Fortunately, because you’ve read this book, you’ve attained the only effective weapon against complexity. This weapon has many names: focus, simplification, scaling down, reducing, minimalism. It’s how you obtain success: you focus on mastering one area—and forgetting about anything else. You reduce complexity with minimalism. You think first-principles and forget about the noise. You create one program, not many. Philosophically, you go for one full life and don’t try to live one hundred partial ones. (View Highlight)
A process is a series of actions that you, a group of people, or even a machine takes with the goal of realizing a defined result. (View Highlight)
If people are the lifeblood of a business, processes are the veins and arteries. If your arteries are clocked, you need to get rid of the bottlenecks quickly or your body will suffer. It’s the same for a business: if the business suffers, you must remove bottlenecks in your business processes to stay alive. (View Highlight)
Complexity in Your Daily Life or the Death of a Thousand Cuts (View Highlight)
Now, the caveat: it has become almost impossible to engage in deep work if you don’t brutally enforce it. The external world demands your attention. Your boss and your colleagues will regularly pop into your office. Your smartphone will demand your attention in, say, 20 minute intervals. Your email provider will present you with email after email—each asking for a slice of your time. To make matters worse, not only the external world plays against your plan to engage in deep work—your internal work does, too. Deep work results in delayed gratification. It’s a satisfying feeling to have spent weeks of your time to complete a computer program that works. (View Highlight)
You should now see how complexity is the enemy of the lean and efficient organization and individual. You simply cannot become productive without mastering tactics and strategies to handle complexity. A simple but efficient tactic to overcome complexity in social networks is to uninstall them from your smartphone (I won’t water down this recommendation only because some people assume it’s not possible—read Deep Work from Cal Newport if you want to learn how it can be done). A simple strategy to overcome complexity in business is to schedule a monthly session where you discuss with your teams tasks you can get rid of—even knowing that these tasks may provide some value to some people (think: opportunity costs, not absolute value). (View Highlight)
Let’s recap some of the most important consequences of the preceding arguments:
Complexity harms productivity due to the loss of focus it incurs.
If you don’t take control and full responsibility for this problem, it will quickly consume your most precious resource: time.
At the end of your life, you won’t judge whether you’ve led a meaningful life based on how many emails you’ve replied to, how many hours of computer games you’ve played, or how many Sudokus you’ve solved. (View Highlight)
As the 80/20 principle, complexity is everywhere, and you constantly need to think about how to reduce complexity and simplify things. Keep it simple, stupid! (View Highlight)
This article is based on a draft of a new chapter of my upcoming book “From One to Zero: A Minimalistic Approach to Programming” (View Highlight)