Welcome back to the list of life lessons coding can teach you!
Previously in this article series: “testing is believing […] Ariane 5 failure […] lifelong learning […] knowledge is power […] UFOs and extraterrestrial intelligence […] you can learn by yourself […] there’s very good news: you are not alone.” (Please note that the “you are not alone” sentence does not necessarily refer to the “UFOs and extraterrestrial intelligence” part of the article.)
How will the hero in you acquire all available knowledge and master the power of infinite wisdom to defeat the zombies and get the girl/boy, car, house, dog and plasma TV?
Short answer: he/she won’t. But they don’t have to.
8. Knowledge is shared: you can draw from collective intelligence to compensate for your limitations
You already know that knowledge is shared, otherwise you wouldn’t be reading an article here, attending a class or hopping from one Wikipedia page to the next — the Internet is not an “electronic cat database” only!
Trust in the knowledge of others makes it possible to thrive as a society, since individual agents can specialize in different interdependent fields to optimize the global output. If you’re skeptical of economics, playing any strategy game should convince you.
You don’t have to know everything if you can rely on people out there who will know for you. (Researching who those people are, their personal interests and the criteria you need to set to measure that they effectively know what they pretend to know is another matter.)
Apart from this “absolute” form of knowledge, which can be written down in books or bits for everyone to share, fellow human beings can also provide you with a more contextual perspective, aka feedback on what you’re actually doing. When programming, for instance, you can always ask another developer to proofread the lines of code you have produced.
A conscientious programmer can point out bugs, help with corrections, suggest improvements (“are you seriously hard-coding all possible cases when a loop could do the trick?”), provide a host of useful comments. Also, sarcasm. A lot. (Asking for proofreading should NOT be considered a blank check for renaming all variables with the most random words, dammit!)
This is the whole philosophy of peer learning at coding school 42 (including sarcasm, yes). You don’t need a teacher when you can learn partly by doing, partly by searching for useful information on the Internet, partly by interacting with the people around you who know better. Testing will then give you an idea of whether your program works or not. And a final round of reckless corrections by your peers will eventually determine whether you thought of everything. If not, expect the occasional -42 (remember?).
9. Knowing when and how to ask questions goes a long way to solving your problems
To receive this kind of support from others, you need to ask for it. If you want to be effective, there is much to earn from putting your ego aside and learning to ask for help. You will soon realize that you’re not that special/exceptional/unique that the questions you’re asking yourself haven’t previously been asked by someone else somewhere sometime (yeah, even THAT one).
However detrimental to your self-image this revelation may sound, it’s actually great news: it implies that you have more chances of finding an answer than any of your ancestors may have had in the past.
This is precisely why Google (or [insert any other search engine name here]) is your friend. As a developer, if you’ve never heard of Stack Overflow, I can promise you that this online platform will soon make it to the top list of your most consulted websites. And we won’t ask you what the other websites in the list are.
Even if you turn to people rather than a machine, asking for help should never be seen as belittling or held against you. Quite the contrary. (In teams and organizations, it is the failure to acknowledge that you are stuck on a problem and unable to solve it by yourself that should be punished.)
Which doesn’t mean everyone will be ready to help you. Or should help you. If only because there exists a very annoying, pushy breed of people who invariably try to get the most from others without making any effort themselves. In some cases, not answering your questions directly is a way to teach you to get information through other means; life will not bring all answers on a silver plate. At 42, ask any member of the education management team for help, and you’re likely to receive either a random answer (“42!”) or a new list of questions that will leave you more puzzled than when before you came…
There’s a balance to be found between learning to find solutions yourself and asking for help. You should develop a healthy habit of asking questions and, in any case, work on your communication skills. Because, on top of learning when to ask a question, you also need to know how to ask a question. And there’s more to it than saying “please.”
Finding out the best way to formulate a question is the first step to actually finding an answer. Being an engineer, as opposed to working as a mere developer, is all about devising creative ways to solve problems. To do so, framing each problem correctly is key. Just compare the two following questions: “what can we do to solve the problem of world hunger?” and “how do we manage to feed a world population of X billion people?” Get it? “How do we fight against unemployment?” vs. “how do we provide Y million people with jobs?” “What can I do to provide for my family after I die?” vs. “How many more drug deals do I have to strike to make the $737,000 required to pay for mortgage, medical bills and school tuition?”
In all the above examples, the second version of the question is more actionable because it moves away from the vague notion of “problem” so as to define objectives built on specific, concrete, measurable elements (see the concept of SMART criteria). This applies to the questions you’ll ask fellow coders (“nothing works, help me!” is a less motivating request than “subfunction Z seems to return null instead of a string, can you see why?”) as well as the technical problems you’ll need to solve (before you attempt to build a sorting algorithm, can you define in simple terms what “sorting” an item list exactly means?).
Web search engines however tend to be so clever that you can type your questions in plain (baby talk) English, and still get a relevant list of answers.
Bad, bad Google. Allowing us to be as dumb as can be (can you believe that the world’s IQ is actually declining?).
10. Being organized is not (only) meant to make your life easier — you’re doing it for others (too)
If you want to increase your chances of getting an answer, you need to do your part of the job. By being clean and orderly, you’re doing yourself and others a favor. In programming, this means breaking up your code into classes and functions, following a specific syntax, adding comments, etc. (your first -42s at the 42 school will most probably come from a failure to comply with “the Norm,” the set of coding rules defined to make your code clean and legible — you’ll learn from pain).
By making your code easy to read through, you’ll have less of a hard time scanning through everything you’ve produced in case you need to make a change or correct a bug. Other coders will be grateful that they can easily grasp the inner logics of your program too, whether they need to proofread, debug, maintain or improve it. Or hide jokes and Easter eggs.
Developers invariably hate it, but documenting a program — i.e. generating written text to explain how it works, either as comments inside the code or as a written document — is extremely valuable to anyone having to deal with the code at some point. And being “agile” can never be an excuse for constant improvisation and escaping the need to produce information on what you have produced!
11. There can be many ways to solve a problem… and defining which is “the best one” is quite arbitrary
Reviewing code produced by other programmers will show you the different approaches one can adopt to solve a problem. The peer corrections at 42 will be opportunities for you to ponder the effectiveness of other strategies than the one you chose. Now, how do we elect the “best” piece of code? How to be a decent judge at My Dev’s Got Talent?
Well it entirely depends on the criterion you decide to optimize — what the “best” in this case stands for. Is the “best” program the one that contains the smallest number of lines? The one that executes the fastest? The one that requires the least amount of memory? The one that’s easiest to read? The one with the most extravagant variable names?
The context in which you’re meant to provide a solution to the considered problem determines what criterion you should consider. Solving a given problem with a program running in a mobile app, on a website or in an in-house superdatacenter is not exactly the same. One size does not always fit all.
Speaking of size…
12. There is elegance in simplicity
Various problem-solving strategies can be used but, sometimes, the elegance of one approach, as compared to all others, is absolutely overwhelming. Some Da Vinci developers manage to write a solution in such a way that you cannot but recognize the magnificent beauty of a masterpiece.
In such a situation, it’s usually the case that the programmer has found a way to pack the code very neatly in a minimal number of lines and functions (possibly involving recursion, the thermonuclear weapon of natural-born IT geniuses). Like in mathematical demonstrations or story plotlines, simplicity pays. Quantity is certainly not synonymous with quality. Some programmers — or their managers — will brag about the number of lines they’ve written. Well it’s not necessarily a good sign… Size (of code) does not matter #deadhorsetrope.
(And if you feel the author of this article himself may not have learned the “keep it simple” lesson yet… We won’t blame you.)
13. You are bound to spend a lot of time and energy on things you alone will ever see
The Tim Ferriss aficionados among you must have heard of the 80/20 rule, or “Pareto law,” stating that, in a given system, 20% of the input yields 80% of the output. For example, 20% of what you study will account for 80% of your effective knowledge, 20% of your clothes are those you wear 80% of the time, 20% of your friends make up for 80% of your happiness, etc. (dating websites, however, seem to follow other-worldly rules). Unfortunately, the negative and pessimists among you can’t have missed the glass-half-empty way of looking at the figures: you’ll need to put in four times your initial effort to get the output from 80 to 100%…
The sheer gap between energy and outcome is definitely a reality of life and time management. Whatever the exact number, a small share of your coding time will be spent working on the core functionalities or standard behavior, while most of your time will concern handling exceptions and non-standard behavior. More generally, the time you’ll spend coding new exciting features is nothing like the time you’ll spend debugging everything. As a rule, just accept the fact that you will always grossly underestimate the time required for bug fixing.
Which is why you should definitely love the job you’ll end up landing. Whatever you’ll eventually achieve in this life will have cost you more than others will ever know. They don’t have to know, and you don’t have to prove them anything, but you owe it to yourself to enjoy “the way” in addition to dreaming of the end result — since you’ll spend much, much more time on the way.
14. The limits are yours to set: at the end of the day, you are the only one in charge of yourself
You’re the only one responsible for yourself, and nobody will (should?) care more about yourself than you (not even your mom). So you’re the one who should be able to say go, pause or stop.
Sometimes, you’ll get lost so deep in a problem that you won’t see how to get out of it… Beware of the sunk cost fallacy, and know that starting all over again can be a valid decision. Sometimes you just have to produce — compulsively refactoring your code is reassuring, but a pure waste of time.
As a passionate developer, in a school like 42 (open 24/7), you could fall into the state of “flow” or be so desperate to solve a capricious problem that you’ll put in hour after hour of work, with no consideration for the time it is or your own physical needs and limitations. Also, if you’re a perfectionist, you’ll always think you could do better, improve some bit of code, or add a new feature… You’ll never be done. You’re the one who should say stop.
For example because it’s already 8am, the sun is high in the sky and you should get some sleep.
And now, because it’s already 8am, the sun is high in the sky and, man, I should definitely get some sleep, it is time to put a final end to this list.
Good luck on the path to awesomeness!