9 Hard Lessons I Struggled to Learn During My 18 Years as a Software Developer
Here are nine of the best lessons I’ve picked up during my time as a developer
我從 14 歲就開始在父母的卧室裡寫代碼。我通過非常慢的網絡閱讀任何我能夠獲得的東西。20 歲時，作為一名 Web 開發人員，我簽了人生中的第一份勞動合同，我當時學的是 PHP 和 JavaScript。
我在這個領域花了 18 年時間，才發現程式設計隻是職業的一小部分。即使是空閑時間出于興趣，我也不會停止編碼，但工作中還有很多其它事情。有些事情，開發者往往很晚才能領悟到，這也是為什麼我想和大家分享我的經曆，以及我覺得很重要的 9 個經驗教訓。
I started writing code in my bedroom at my parents’ house when I was 14 years old. I remember reading everything I could get my hands on via my very slow internet connection. Then when I was 20, I signed my first contract as a web developer, learning PHP and JavaScript at the time.
And it’s taken me over 18 years in this field to figure out that coding is just a fraction of our profession. I still enjoy it, mind you. I don’t think I’ll ever stop coding — even if it is for fun in my spare time — but there is so much more.
That is why I want to share with you my experience and what I think are nine lessons that developers tend to learn a bit too late in some situations.
1. 放下自負
開發者通常很自負。這是事實。
為什麼呢？我認為，任何認真對待自己職業的人都會認為自己有點兒像藝術家。我們雖然不會在數百萬人面前唱歌或者作畫，但我們有時候在以一種非常優雅高效的方式編寫代碼、解決非常複雜的問題，我們同樣為自己的工作感到自豪。
開發者和數學家一樣，解決問題的方式都有點兒像藝術家。
正因如此，我們很維護自己的代碼——就像熊媽媽照顧她的後代那樣。親手寫下這些代碼的我們，無法忍受别人對他指指點點。
但這對任何人都沒有幫助。我們熱愛自己的工作，但更重要的是我們正在解決問題。通過與其他人讨論我們的想法和方案，可能會出現更好的替代方案。這沒有什麼不對的。事實上，合作通常會産生最佳解決方案。
我見過各種各樣自負的開發者，但沒有見過哪種自負對開發者會有所幫助。
是以我的建議是：當你開始作為一名開發者工作時，請把你的自負抛掉，多聽聽其他人對你工作的看法。學會接受這樣一個事實：更好的想法可能來自你的頭腦之外，它們隻會幫你提高自己的技能。隻有傾聽回報，你才能赢。
1. Leave the Ego at the Door
Developers have huge egos. That’s a fact.
Why, though? I would argue that anyone who takes our profession seriously would consider themselves to be somewhat of an artist. Yes, we might not be singing in front of millions of people or painting the Mona Lisa, but we’re sometimes writing code that solves very complex problems in such an elegant and efficient way that we can’t help but be proud of our work.
I would argue that a developer is just as much of an artist as a mathematician is through the way they solve their problems.
Because of this, we tend to crawl around our code — just like a mama bear looking after her offspring. We made it, we love it, and we can’t stand when people start arguing about how wrong it may or may not be.
Then again, this is not helping anyone. We love our work, but we need to understand that we’re solving problems. By discussing our ideas and our solutions with others, better alternatives might arise. There is nothing wrong with that. In fact, cooperation is normally what yields the best solutions.
I’ve seen all kinds of egos in my time, and I’ve never seen a case where that ego worked in the developer’s favor.
So my advice here? Leave the ego at the door the minute you start working as a dev. Just swallow it and hear what others have to say about your work. Accept that better ideas might come from outside your head and that they will only help you improve your skills. You can only win if you listen to feedback.
2. 語言隻是工具
如果你隻懂 JavaScript，所有的問題都會像釘子一樣。不要再稱自己是一名 Java 開發者或 JavaScript 開發者。
由于某些語言的特性或文法，你可能會偏愛一些語言，這很正常。然而，如果你能學點别的東西，就會受益匪淺。學習新語言，尤其與你日常工作所用的範式不同的語言，會幫助你打開思路，發現解決問題的不同辦法。
這一點我怎麼強調也不過分：學習多種語言并使用一段時間，你會從中受益。
我幾年前讀過一本書《七周七語言》，展示了各種可用的選項，這讓我思路大開。很多選擇是我從來沒有想到過的，因為我太專注于自己的日常任務和日常工具，從來沒有停下來看看其它東西。
我們是開發者，知道如何通過代碼來解決問題，但不要把自己放到一個盒子中，你會被那個盒子的大小所限制。看看那個盒子外面的東西，跳出那個盒子思考，試試其它選項、其它語言、其它解決問題的方法。即使隻是一會兒，你也會帶着新的想法和更大的心态做出更好的抉擇。
2. Languages Are Tools. If You Only Know JavaScript, All Problems Will Look Like Nails
Stop calling yourself a Java developer or JavaScript developer. Yes, there might be languages that you favor because you like their features or syntax. That’s perfectly normal.
However, you’d benefit hugely if you were to learn something else for a while. Learning new languages — especially if they follow a different paradigm than the one you’re used to working with — will help you open up your mind to different ways of solving problems.
I can’t stress this enough: Learning multiple languages and using them for a while is going to benefit your skills. I read this book called Seven Languages in Seven Weeks several years ago and it opened up my mind to so many options just because it showed me the types of options available out there. Options I had never even considered because I was so focused on my daily tasks and daily tools that I never stopped to look anywhere else.
We’re developers. We know how to solve problems through code. Don’t put yourself inside a box. You’ll be limited by the size of that box. Look outside of it, think outside that box, check out other options, other languages, other ways of solving problems. Even if it’s for a little while, you’ll come back to your weapon of choice with fresh ideas and a bigger mindset.
3. 程式設計不需要記下所有的東西
有時候，開發新手認為他們需要把所有事情都記在心裡，是以當他們意識到自己開始忘記如何寫一個簡單的
for
語句時，就會感到很糟糕。
這不僅是正常的，而且我認為這也是健康的。
有太多東西需要記憶了，但我們其實不需要記憶，我們隻需要擁抱這樣一個事實：網際網路是另一個有力的工具。就像我們需要 IDE 一樣，我們需要網際網路來尋找答案。
我們都這樣做，如果你一開始就感覺不好，就不要在這種感覺上浪費時間。隻需要尋找你的答案并解決你的問題。
這樣想一想：每一種語言都有一種類似但又稍有不同的觀察者（Observer）模式的實作方式。你認為什麼更現實？了解觀察者模式有什麼好處以及它能解決什麼問題，還是記住你所使用的每一種語言如何實作它？
如果你知道它能解決你的問題，那麼你就真的解決了你的問題。剩下的隻是搜尋實作它的最佳方法。
其它搜尋也是一樣。隻專注于我們職業中重要的解決問題的方面，讓谷歌幫你慢慢回憶。這才是正确的方式。
3. It’s Not About Memorizing Algorithms, It’s About Knowing How to Google Them Fast Enough
Sometimes new developers think they need to know everything by heart, so they start feeling bad the minute they realize they start forgetting how to write a simple
for
statement.
This is not only normal, but I would argue it’s also healthy.
There is simply too much out there to have it memorized. We don’t need to either. We need to embrace the fact that the internet is just another tool in our arsenal. Just like we need our IDE, we need internet access to look for answers.
We all do it, and if you’re just starting out and feeling bad about it, don’t waste time on that feeling. Just search for your answer and figure out your problem.
Think about it this way: Every language will have a similar yet slightly different way of implementing the Observer pattern. What do you think is more realistic? Understanding what the Observer pattern is good for and what kind of problems it solves or remembering how to implement it in every language you work with?
If you know it’ll solve your problem, then you literally solved your problem. The rest is just a matter of Googling the best way to implement it. That is not taking any credit away from your work or from your experience.
And the same goes for every other search you do. Just focus on the important, problem-solving side of our profession and let Google jog your memory. That’s what it’s there for.
4. 你将終身學習
或者說，“你應該終身學習”，這完全取決于你自己是否要跟上行業的最新發展。如果你想要保持相關性，那麼你就必須一直學習。
技術在發展，語言在變化，這都很正常。誠然，有些生态系統比其它生态系統變化得更快，跟上他們的步伐似乎是一項艱巨的任務。但是，記住你隻是一個人，不可能無所不知，隻需專注于重要的事情。如果你必須學會一件事情，那麼我的建議是學會如何學習。
這聽起來很傻，但這可能是一名開發人員需要的首要技能。我們必須在快速學習新技能方面表現得更好。否則，你将陷入被标記為“過時”的風險。
同時，這也是本文提到的其它經驗發揮作用的地方。變化、改變、新的挑戰、沒有自負——所有這些都會幫助你學習并拓展技能範圍。你做的越多，效果就會越好。最終，你會發現所有的語言都是類似的。你将開始看到它們公共的根本，你将能夠用其中任何一種語言工作。你所要做的就是閱讀一些關鍵的東西。
你的整個職業生涯都要學習：
- 新語言
- 新（老）程式設計範式
- 新工作方法
- 解決問題的新方法
- 與團隊互動的新方法
- 檢查和測試代碼的新方法
如果你還沒有準備好永遠當一名學生，那你需要考慮下這個職業是否适合你。請注意，我不是說“立刻辭職”，而是考慮下是否願意開放思維來持續學習。
4. You’ll Be Learning Your Entire Career
Or rather “You should be learning your entire career.” It’s really up to you to decide whether or not you stay up to date with the latest developments in our industry. But if you want to stay relevant, then you’ll have to do it.
Technology evolves, languages evolve, and that’s completely normal. Granted, some ecosystems change faster than others and keeping up with them might seem like a titanic task. But focus on the important things, remember that you’re just a person and you can’t know everything. So if you have to learn one thing, my suggestion would be to learn how to learn.
I know it sounds silly, but that’s probably the #1 skill a developer needs. We have to get better at learning new skills fast. Otherwise, you run into the risk of being labeled as obsolete.
And here is where some of the other lessons in this article come into play. Variation, change, new challenges, no egos — those are all things that will help you learn and broaden the spectrum of your skillset. The more you do it, the better you’ll get at it. Eventually, you’ll realize all languages are similar. You’ll start seeing their common roots and you’ll be able to work with any of them. All you’ll have to do is read up on a few key things.
You’ll be learning your entire career about:
- New languages
- New (and old) programming paradigms
- New ways of working
- New ways of solving problems
- New ways of interacting with your teammates
- New ways of reviewing and testing your code
If you’re not ready to be the eternal student, consider if this is the career for you. Mind you, I don’t mean “Quit right now,” but rather consider if you’d be willing to open up your mind to be always learning.
5. 代碼要解決問題，而非完美
這個問題我說過很多次，但是作為開發者，我們傾向于認為自己的代碼在釋出之前需要是完美的。雖然這并沒有什麼不對，但也可能是一個潛在的問題。
早期優化是一個問題，因為你可能在某件可能并不需要優化的事上花費大量時間，而且在某些情況下執行優化時，你會做出破壞功能的假設。
是以，把注意力集中在需要做的工作和你正在嘗試解決的問題上，一旦問題修複，立馬測試、疊代結果，看看團隊對你的解決方案有什麼想法——即使你已經看到了改進的方法。如果你需要花費兩天以上的時間來讓它完美，但它現在就可以投入生産，很有可能現在就應該投入生産。
歸根結底，你是在解決問題。解決問題越快，對你的使用者就越好。
5. Working Is Better Than Perfect
As a manager, I’ve heard myself say this too many times. But as developers, we tend to think our code needs to be perfect before release. And that’s not only untrue but potentially a problem.
Early optimization is an issue because you end up spending a lot of time and effort on something that perhaps doesn’t need to be optimized. And in some situations, when performing that optimization, you make assumptions that break the feature.
So focus on the work it needs to do and the problem you’re trying to solve. Once it’s fixed, test it out, iterate over the results, and see what your team thinks about your solution — even if you can already see ways to improve it. If you’re going to take two more days just to have it perfect, but it could go to production right now, chances are it should be in production right now.
At the end of the day, you’re solving a problem. The faster you solve it, the better it’ll be for your users.
6. 先讓代碼起作用，然後再優化
跟上面提到的觀點一樣，不要陷入早期優化的黑洞。
即使你認為你可以快速優化，但一旦你開始做，你就會發現時間膨脹效應是真的。
作為軟體開發人員的首要任務是寫一個功能或修複一個 bug 來讓它起作用——無論代碼看起來多醜或者你的方案可能多麼低效。如果它起作用了，你就證明了它是可行的。這就成功了一半。
第二步是優化它。這是可選的一步。一些人容易忘記的細節，你可以用來優化代碼的時間取決于很多變量，這些變量有時候不受你的控制。是以，集中精力讓它起作用，然後再看看你是否真有時間來優化它。
早期優化意味着要邊寫代碼邊優化，這是一種危險的方式，因為優化時，我們都是在對執行時間、資料要求、記憶體需求以及其它我們尚未看到的因素進行假設，任何這樣的假設都可能是錯誤的，最終會在你的邏輯中引入 bug。
想想 TDD 工作流：
- 編寫測試來了解你的功能需要做的所有事情（它将失敗）。
- 編寫代碼來通過測試。
- 現在考慮優化你的代碼。
步驟 2 是必需的。你首先需要考慮通過測試，也就是說讓功能起作用。測試不關心你使用的算法或者你是否使用了三層嵌套的
if
語句。稍後才會做那些，可能是代碼評審過程中的一部分。
6. Make It Work, Then Optimize
In line with some of the previous points, don’t fall into the early optimization black hole.
Even if you think you’ll do it quickly, once you come out of it — if ever — you’ll realize the time dilation effect is real.
Your first task as a software developer writing a new feature or fixing a bug is to make it work — no matter how ugly the code might look or how inefficient your solution might be. If it works, you’ve just proven it can be done. That’s half the battle right there.
The second step is to optimize it. This is an optional step. A detail that some people tend to forget. The time you have available to optimize your code depends on a lot of variables that sometimes are not under your control. So focus on making it work, then figure out if you actually have the time to optimize it.
Early optimization means optimizing your code while writing it. This is a dangerous practice because when we’re optimizing, we’re making assumptions about execution time, data requirements, memory needs, and other factors that we haven’t yet seen in action. Any such assumption might be wrong and you’ll end up introducing bugs into your logic.
Think about the TDD workflow:
- Write your test to understand everything your feature needs to do (it’ll fail).
- Write your code to have the test pass.
- Worry about optimizing your code now.
Step 2 is a must. You first need to worry about passing the test, which translates to having the feature working. The test doesn’t care about the algorithm you used or if you used three nested
if
statements. That comes later, probably as part of a code review process.
7. 項目最後的 10%往往要花費 90%的時間
如果你一個人獨自工作，這一點尤其重要，但是團隊也會有這種細節計算失誤的問題。
任何一個做完項目的人都會告訴你同樣的事情（這不僅僅适用于我們行業）：你一開始會略過很多細節，最後才不得不考慮它們。
這很正常。我們都傾向于一開始專注于重大的功能，将比較小的細節或已知的 bug 留到最後。但是它們仍然需要解決，這就是額外 90%的工作。精細的工作比較花時間。你需要測試、修複、重新測試、寫文檔、執行使用者教育訓練、展示最終方案等等。
當然，這取決于你的環境、客戶以及很多其它因素，但總會有一些東西。是以記住：當你認為你已經寫完代碼的時候，你很可能忘記了一些東西。
7. The Last 10% of a Project Takes 90% of the Time
This is especially important if you’re working alone, but teams also suffer from not having this little math detail correct.
Anyone who has finished a project will tell you the same thing (and honestly, this doesn’t just apply to our industry): You first rush through a lot of details just to have to take care of them at the end.
And it’s completely normal. We tend to focus on the big features first, leaving out smaller details or even known bugs to the end. But they need to be tackled nonetheless, which is where the extra 90% comes in. The fine work takes time. You need to test, fix, re-test, write documentation, perform user training, present the final solution, and more.
Of course, it’ll depend on your context, who your client is, and on a lot of other factors, but there is always something. So remember: When you think you’re almost done with your code, you’re probably forgetting about something.
8. 寫過一次以上的代碼，需要進行抽象
編碼是關于抽象的行為。通過抽象通用邏輯，我們可以在其它地方複用它，但是一開始的時候，我們有時會注意不到抽象的重要性。
這是我個人的經驗法則：如果我在兩個地方寫了相同的代碼，那麼就将它們放到一個函數中（或者一個方法，一個子產品等等...你懂的）。
即使數字二對你來說很低，但是要考慮到将來你可能在其它地方使用抽象後的代碼。而且通過把它放到一個常用的地方，你現在就可以使用它了。
抽象和規模有關。一段抽象的邏輯可以用很少的精力就被複用很多次，而到處複制粘貼代碼雖然很容易，但用的越多需要的精力就越多。想想，如果你因為一個 bug 不得不改變一段邏輯，而它在你的項目中被重複了 5 次，會發生什麼？你在修複這個 bug 時，會有 5 次機會犯錯。
同樣的邏輯也适用于你的日常任務。如果你發現自己做某件事一次以上，那麼它可能就可以用某種方式自動化。這是效率的關鍵，是以不要僅僅在代碼中尋找重複模式，在你的動作中也可以尋找重複模式。如果你能自動化完成一項每天需要 10 分鐘的任務，你一個月就能節省 5 個小時。
8. If You’re Doing It More Than Once, It Needs to Be Abstracted
Coding is about abstracting behavior. By abstracting common logic, we can reuse it in other places, but in the beginning, we sometimes fail to notice the importance of abstraction.
This is my personal rule of thumb: If I have code repeated in two places, then it’s going into a function (or a method, a module… you get the idea).
Even if the number two seems low for you, consider that in the future you might find other places to use that abstracted code. And by moving it into a commonplace right then, you now have access to it.
Abstraction is about scale. A piece of abstracted logic can be used many times with minimum effort, while copy-pasting code all over the place — although easy to do — will require a lot more effort the more you use it. Consider what would happen if you had to change a piece of logic that was repeated five times across your project due to a bug. You’d literally have five chances to make a mistake while fixing it.
The same logic can be applied to your day-to-day tasks. If you find yourself doing something more than once, then it probably can be automated somehow. This is key to efficiency, so don’t only look for repeating patterns in your code but also in your actions. If you can automate a task that only takes you ten minutes a day, you’re saving five hours a month.
9. 副業項目不是必需的，但它們确實有幫助
有人說，如果你想要成為一名成功的開發人員，你需要建立副業項目。我并不認同這一點。我個人認識很多優秀的開發者，他們隻在朝九晚五工作時寫代碼。
老實說，我很欽佩他們。他們能夠在做好工作的同時，享受他們的空閑時間做其它事情。這絕對沒有什麼問題。
然而，有時候你需要一些額外的練習。有時候你覺得自己落後于其它同僚。而這時，副業項目就會有所幫助。
我不是說建構一個新項目，讓數以百萬計的人使用，或者對産業進行革命性改變，當然如果你喜歡的話，就去做。但是我讨論的是拷貝其他人的項目，以便從中學習。我說的是通過解決 bug 或者增加額外功能來向其他人的項目做貢獻。
你可以用副業項目來體驗你不經常看到的地方。如果你每天寫 8 小時的單元測試，也許可以考慮從頭建立一些東西并且開發一些功能。如果你厭倦了獨自工作，可以考慮為現有的項目做貢獻，體驗一下如何與其他人協調工作。
你可以使用副業項目來強化自己的薄弱環節，進而幫助你提高自己的技能。但同樣，不要為了被認為是一名嚴肅的開發人員，而認為你需要為他們工作或者擁有一個綠色的 GitHub 活動圖。那太傻了。
9. Side Projects Aren’t a Must, but They Do Help
Some people say that if you want to be a successful developer, you need to create side projects. I don’t think that’s true. I personally know a lot of great developers who only code when they’re working on their 9-5.
And honestly, I admire them. They’re able to be great at what they do while also enjoying their free time doing other things. There is absolutely nothing wrong with that.
However, sometimes you need the extra practice. Sometimes you feel like you’re falling behind other colleagues. And that is where side projects can help.
I’m not saying to build a new framework that gets used by millions and revolutionizes the industry. Go for it if you like, but I’m talking about copying others’ projects in order to learn from them. I’m talking about contributing to other people’s projects by solving bugs or adding extra features.
You can use side projects to experience aspects of development that you don’t get to see often. If you’re writing unit tests eight hours a day, maybe consider creating something from scratch and developing some features. If you’re tired of working alone, consider contributing to an existing project and experience what’s like to coordinate your work with others.
You can use side projects to strengthen whatever areas you identify as weak to help you improve your skills. But again, don’t think you need to work on them or have a green GitHub activity chart in order to be considered a serious developer. That’s just silly.
結論
這是我作為一名開發者在過去 18 年中學到的最難的 9 個經驗教訓，希望通過我的分享，能對你的新（或者已經從事的）職業有所啟示。
你有想要分享的其它經驗嗎？請在下方留言。我很樂意向你學習。
Conclusion
Those are nine of the hardest lessons I’ve learned as a developer over the last 18 years. I hope that by sharing my experience, I was able to shed some light on your new (or already existing) career.
Do you have any other lessons you’ve learned that you’d like to share? Leave a comment below. I’d love to learn from you.
作者介紹
Fernando Doglio 在 Globant 擔任技術經理，撰寫關于技術、生活方式和個人事業等方面的文章。熱愛學習，自認為是個永遠的學生。在過去 14 年一直從事軟體行業，是以對于其運作方式和技術變遷有比較好的了解。
學習一門新程式設計語言的6步
6 Stages of Learning a New Programming Language
Learning a new programming language is a process that allows you to learn critical life lessons.
文化 & 方法語言 & 開發程式設計語言方法論
有些人學習程式設計剛開始頭腦發熱，買了很多書，下載下傳很多視訊，收藏上百 G 的資料，沒過幾天，熱情就褪去了，最後完成了從入門到放棄的全過程，究其原因主要是缺乏清晰的目标，沒有方向，或者方向不明确。那麼，我們應該要怎麼學習才能掌握新的程式設計語言呢？讓我們來看看 Jun Wu 是怎麼做的。
學習一門新程式設計語言是一個讓你能學到重要人生經驗的過程。
我們要求程式員學習很多東西。随着大資料、人工智能、機器學習和雲計算的普及，開發人員正努力克服系統開發中的大量挑戰。我們所有的開發人員都不再僅僅是程式員了。藉由新的體系結構，我們可以熟練地學習我們系統的新基礎設施設計。通過新的人工智能機器學習算法，我們在學習數學、統計學和函數式程式設計方面很熟練。有了大資料，我們就能擅長學習所有可用于分析資料的不同 API。
在某種程度上，我們作為開發人員的工作，正日益趨向多學科化。在這個蓬勃發展的多學科世界裡，我們面臨的最大挑戰就是學習。
快速學習程式設計語言和深入了解不同學科是一項挑戰。但這是一個非常有趣的過程。對我來說，正是學習，讓我一次又一次地回到程式設計上來。
通過不斷學習，你可以通過以下幾種方式為你的生活增添光彩：
- 拜見該領域的新專家
- 在思考你的項目時，引入新的創造力
- 拓展你的職業前景
- 當你對目前工作變得自滿時，克服無聊
- 在技術領域中保持領先地位
- 發現生活中的新激情
在我上一篇文章《如何快速學習一門新的程式設計語言》（How To Learn a New Programming Language Fast）中，我曾介紹了一個秘訣，如何能夠以快速和靈活的方式掌握許多程式設計語言。
在本文中，我将對學習過程進行拆分，這樣你就可以對學習新的語言和概念有一個大緻了解。有時候，學習一門新語言需要十年時間，就像徒步攀登高山一樣。當你認為自己是 Python 大師的時候，你就會發現，你可以做更多其他種類的項目，這些項目将提高你對 Python 在特定目的上的使用水準，這些都是你以前從未想過的。
最終，一切都在掌控中。
一旦你成為專家，你就可以像體操運動員那樣靈活地程式設計，你的手指将會引路，而你的大腦是一個富有效率、充滿創造性的司機。
你得到的回報并不是工作保障，而是生活上的安全感。
這是一種安全感，知道自己可以學到任何複雜的東西，可以克服解決問題的任何障礙。
在心理學中，知識的内化也包括行為的内化。通過知識的内化，你就創造了新的思維路徑，這将得到以下結果：
- 将知識從短期記憶轉移到長期記憶。
- 建立能夠吸收新知識的知識路徑。
- 能夠建立新的知識擷取、知識保留和知識建立的行為。
We ask our programmers to learn a lot. With big data, AI-machine learning, and cloud computing, developers are trying to overcome a mountain of challenges in systems development. All of us who are developers are not just programmers anymore. With a new architecture, we are skilled in learning about new infrastructure designs for our systems. With new AI-machine learning algorithms, we are skilled in learning mathematics, statistics, and functional programming. With big data, we are skilled at learning all the different APIs available for analyzing our data.
In a way, our jobs as developers are becoming multidisciplinary. The biggest challenge that we have in thriving in this multidisciplinary world is learning.
It’s a challenge to learn programming languages fast and learn about different subjects deeply. But it’s such a fun process. For me, it is learning that keeps me coming back to programming again and again.
By learning all the time, you add to your life in the following ways:
- meeting new experts in the subject area
- bringing new creativity into thinking about your projects
- expanding your career prospects
- overcoming boredom when you become complacent at your current job
- staying current in the technology arena
- finding new passions in life
In my last article, I let you in on the secret that allowed me to learn many programming languages with speed and agility.
In this article, I want to break down the learning process so that you can have the big picture of learning new languages and concepts. Sometimes, it is a ten-year hike up the mountain of learning new languages. Just when you think you are a Python guru, you find out you can do even more projects in other varieties that will sharpen your usage of Python for specific purposes that you never thought of before.
In the end, it’s all in the fingers.
Once you are an expert, you will program with the agility of a gymnast, and your fingers will lead the way while your brain is an efficient and creative driver.
The reward is not job security, but life security.
It’s the security of knowing that you can learn anything complex. It’s the security of knowing that you can overcome any hurdles in problem-solving.
In psychology, internalizing knowledge also involves internalizing behaviors. By internalizing knowledge, you create new paths of thinking that will lead to the following:
- transferring knowledge from short-term memory to long-term memory.
- creating knowledge paths that will enable the absorption of new knowledge.
- enabling the creation of new knowledge acquisition, knowledge retention, and knowledge creation behaviors.
一、先從關鍵要素和概念開始
最初，當你學習一門新的程式設計語言時，你想将學習重點放在那門程式設計語言的關鍵要素和概念上。列出一份這門程式設計語言的“核心”學習清單，然後一步一步地進行學習，這才是正确的方法。
知所知，知弗知
如果你想學習 Python，可以請 Python 專家或老師為你畫一張“核心”學習的清單。你還可以通過學習一門課程來逐漸了解 Python 程式設計的基礎。搜尋該程式設計語言的面試問題清單。
Starting With Key Elements and Concepts
Initially, when you learn a new programming language, you want to focus your study on the key elements and concepts of that programming language. Making a list of the “core” learnings for a programming language and going through them step by step is the way to go.
You don’t know what you don’t know
If you want to learn Python, ask an expert Python programmer or a teacher of Python to draw you a list of “core” learnings. You can also go through a course that will step you through the foundations of programming in Python. Search for a list of interview questions for that programming language.
二、進行發散，提出足夠多的問題，找出正确答案
當你在學習程式設計語言中的“核心”概念時，你是否經常列出要提問的問題清單？我經常發現自己離題十萬八千裡。也就是說，我傾向于沿着我的思路，打破砂鍋問到底。
是以我從關于 Python 的概念 A 開始，然後在 Google 上搜尋一大堆關于 Python 中面向對象程式設計的内容，這就發現了一個以後可能要做的項目。
通過這一過程，我将文法約定、面向對象的程式設計概念和一系列常用的資料結構加入了書簽。要問的正确問題可能就隐藏在我剛剛加入書簽的其中一個網頁中。通過浏覽這些網站，我就将能夠編制出一份關鍵問題的清單。
你要學會提出正确的問題來掌握核心技能。
Branching Out to Ask Enough Questions to Hit the Right Ones
When you are learning “core” concepts in a programming language, do you frequently make a list of questions to ask? I usually find that I digress a lot. That is, I tend to follow my train of thought down the line until the very end.
So I started with concept A about Python, then ended up googling a whole lot about object-oriented programming in Python, which led me to scope out a potential project to do later. Through this process, I bookmarked syntax conventions, object-oriented programming concepts, and a list of frequently used data structures. The right questions to ask are probably buried in one of these webpages that I just bookmarked. By reading through these websites, I will be able to compile a list of critical questions.
You learn to ask the right questions to learn the core skills.
三、養成每天學習的習慣
在我的職業生涯中，從學習許多程式設計語言中得到的一些最好的收獲就是，我在生活中養成提高效率的習慣。我每天至少要花兩個小時學習，這一習慣貫穿了我的職業生涯中。
每天兩個小時看似不多，但一年下來，并堅持 15 年呢？那将是一個可觀的數字：2x365x15=10950 小時！工作之餘，就像健身訓練一樣，我還有一個長達 10950 小時的健腦訓練，已持續 15 年，讓我能夠 得以學習到新的東西。
大部分時間，我隻是在早上 5 點起床而不是早上 7 點，或者晚上 11 點而不是 9 點睡覺，這樣我就有更多的時間用來學習。
你終将知曉，學習是有趣的，學習是在你自己的時間，學習是一種激情。
Building Habits to Learn Daily
Some of the best takeaways from learning many programming languages in my career are the habits of productivity that I’ve built into my life. Throughout my career, I dedicated at least two hours to learning every day. That is a lot of time: 2*365*15=10950 hours. Outside of work, just like a physical fitness routine, I have a mental fitness routine that spanned 10,950 hours over 15 years to allow me to learn new things. Most of the time, I just woke up at 5 a.m. instead of 7 a.m. or went to sleep at 11 p.m. instead of at 9 p.m. to give myself that added amount of time for learning.
You learn that learning is fun, learning is on your own time, and learning is a passion.
四、雪球效應
當你克服學習複雜概念和項目的複雜障礙後，你的信心就會像滾雪球那樣越滾越大。我在工作中也目睹過。這并不完全是“流”的狀态。它更像是一種激勵你的能量，讓你整個人都充滿活力。這與喝咖啡、果汁或過健康的生活方式一樣。汝欲乘長風，破萬裡浪兮。
這種激勵能量轉化為想要學習所有關于基礎設施、設計和存儲的知識之動力。這種動力轉化為想要嘗試不同的方式進行程式設計：指令性、事件驅動、流程驅動等。
這種激勵能量轉化為提出一些問題，比如“為什麼我們要這樣設計系統的這一部分？為什麼我們要在這個項目使用這種程式設計語言？為什麼我們要選擇這種基礎設施技術來擴充項目？為什麼我們要用這種方式來對項目的這部分進行編碼？為什麼我們要這樣設計錯誤處理？為什麼我們要這樣設計消息處理？”
問這些問題會讓你找到解決問題的方法。在項目上工作，會讓你不斷學習如何正确回答“為什麼……”這一系列問題，可以讓你更快地變得精通起來。
你要有動力去問為什麼，這樣你才能找出答案。
The Snowball Effect
When you overcome the difficulty of learning complex concepts and complex hurdles of your projects, it has a snowball effect on your confidence. I’ve seen that with my work. It’s not exactly the state of “flow”. It’s more of a kind of motivational energy that perpetuates your entire life. It’s the same effect as drinking coffee, going on a juice cleanse or living a healthy lifestyle. You ride a kind of energy wave of learning.
This motivational energy translates to wanting to learn all about infrastructure, design, and storage. This motivational energy translates to wanting to try programming in different ways: functional, imperative, procedural, event-driven, flow-driven, etc.
This motivational energy translates to asking why questions such as “Why are we designing this part of the system this way? Why do we use this programming language for this project? Why do we select this infrastructure technology to scale up our project? Why are we coding this part of the project in this way? Why are we designing the error handling this way? Why are we designing the messaging handling this way?”
Asking these questions will lead you to find out the how. Working on projects that will consistently allow you to learn the how to the right questions of why will allow you to become proficient much faster.
You are motivated to ask the why that allows you to find out how.
五、養成反複實踐的習慣，敢于冒險，勇于創新
你是自己程式設計生涯的主人。每個人對風險的接受程度并不一樣。是程式設計，讓我學會了在職業生涯中承擔一定的風險。是程式設計，讓我對自己解決問題的能力有了信心。是程式設計，讓我學會了要對自己的創造力充滿信心。
這一切都是因為我反複練習程式設計語言，而這些語言是我最熟悉的程式設計語言。反複練習未必枯燥乏味。事實上，要想真正精通一門程式設計語言，參加能讓你學習程式設計語言不同部分的項目是必不可少的。
隻有學會了不同解決問題的方法，你才能學會在解決問題的過程中發揮創造性。隻有在考慮編寫代碼的最佳方式時，你才能提高代碼的效率。隻有通過反複的練習，你才能對代碼片段産生“啊哈”的感覺，讓你編寫出最有效的代碼。
通過學習來提高效率和創造性，你學會了精通。
Building a Habit of Repeated Practice With Risk-Taking and Creativity
You are the owner of your programming career. Everyone’s different in the amount of risk they are comfortable with. Programming allowed me to learn to take measured risks in my career. It taught me confidence in my problem-solving abilities. It taught me to be confident in my creativity.
This is all due to my repeated practice of the programming languages that I’m most comfortable programming in. Repeated practice does not have to be boring. In fact, to be truly proficient in a programming language, taking projects that will allow you to learn different parts of the programming language is essential.
You can only learn to be creative in problem-solving if you learn different ways to problem-solve. You can only be efficient with your code when you think about the best ways to write your code. Only through repeated practice can you have “ah-ha” moments about pieces of code that will allow you to come up with the most efficient and effective code.
You learn to be proficient by learning to be efficient and creative.
六、依靠你所知道的來實作跨越
最後，當你已經學會并練習了你所熟悉的程式設計語言時，你現在就可以在職業生涯中實作跨越了。這通常就是當你從初級開發人員晉升到進階開發人員的時候。
你将憑藉掌握“原因和做法”的知識在面試中取得了優秀的成績，進入你的程式設計生涯的下一階段。你可以用自己所熟悉的語言以一定的靈活性來編寫代碼。
你不再長時間進行工作了。你終于有時間和你朋友出遊。你完成你的工作然後去休假。你開始指導初級程式員，你在工作中示範并使用最佳實踐。你在架構會議上踴躍發言，并發表自己的觀點。你在團隊中是出了名的專家。
恭喜你！你已經将你所學的程式設計語言内化成了長期記憶。現在，它就像你的母語一樣。
現在，你已經知道學習任何一門新的程式設計語言的過程了。你知道，在學習之旅中不能半途而廢。花在程式設計上的每兩個小時，就是你離開所愛的人的兩個小時。是以，要讓這兩個小時變得有意義。讓每一個兩小時，每天成倍增長，直到你學會并内化了這些概念。
一旦你在完成足夠多的項目之後變得精通了，你要知道，這遠非結束。這是一個新的開始。從零開始，再次學習并内化新的程式設計語言和新的程式設計概念。一旦你在整個程式設計棧中增加了新的知識廣度和深度，學習就會自然而然地流動起來，成為你生活的一部分。
你還在等什麼呢？
Relying on What You Know to Leap Forward
Finally, as you have learned and practiced programming languages that you are comfortable with, you can now leap forward in your career. This is usually when you progress from a junior developer to a senior developer.
You will rely on all your knowledge of the why and how to ace those interviews to move to the next stage of your programming career. By now, some of this is already in your fingers. You can code with a certain agility in the languages that you are comfortable with.
You don’t work long hours anymore. You have time to go out with your friends. You finish your workday and take vacations. You mentor junior programmers. You set examples and use best practices at work. You speak up at architecture meetings and put in your two cents. You are known for being a certain kind of an expert on your team.
Congratulations, you have internalized the programming language that you’ve learned into long-term memory. It is now in your fingers.
Now you know the process of learning any new programming language. You know that you can’t quit in the middle. Every two hours spent programming are two hours you spent away from your loved ones. So make those two hours count. Allow those two hours to multiply each day until you’ve learned and internalized the concepts.
Once you are proficient after working on enough projects, know that this is not the end. It’s a new beginning. Start from zero to learn and internalize new programming languages and new programming concepts again. Once you increase new breadths and depths of your knowledge throughout your programming stack, learning will flow naturally and become a part of your life.
What are you waiting for?
作者介紹：
Jun Wu，是單親媽媽，也是作家、技術專家和詩人。愛好廣泛，涵蓋了技術、人工智能、資料科學、上司力、心理學、育兒、教育、生活、工作和詩歌等等。
原文連結：
6 Stages of Learning a New Programming Language
Starting With Key Elements and Concepts
Initially, when you learn a new programming language, you want to focus your study on the key elements and concepts of that programming language. Making a list of the “core” learnings for a programming language and going through them step by step is the way to go.
You don’t know what you don’t know
If you want to learn Python, ask an expert Python programmer or a teacher of Python to draw you a list of “core” learnings. You can also go through a course that will step you through the foundations of programming in Python. Search for a list of interview questions for that programming language.
Branching Out to Ask Enough Questions to Hit the Right Ones
When you are learning “core” concepts in a programming language, do you frequently make a list of questions to ask? I usually find that I digress a lot. That is, I tend to follow my train of thought down the line until the very end.
So I started with concept A about Python, then ended up googling a whole lot about object-oriented programming in Python, which led me to scope out a potential project to do later. Through this process, I bookmarked syntax conventions, object-oriented programming concepts, and a list of frequently used data structures. The right questions to ask are probably buried in one of these webpages that I just bookmarked. By reading through these websites, I will be able to compile a list of critical questions.
You learn to ask the right questions to learn the core skills.
Building Habits to Learn Daily
Some of the best takeaways from learning many programming languages in my career are the habits of productivity that I’ve built into my life. Throughout my career, I dedicated at least two hours to learning every day. That is a lot of time: 2*365*15=10950 hours. Outside of work, just like a physical fitness routine, I have a mental fitness routine that spanned 10,950 hours over 15 years to allow me to learn new things. Most of the time, I just woke up at 5 a.m. instead of 7 a.m. or went to sleep at 11 p.m. instead of at 9 p.m. to give myself that added amount of time for learning.
You learn that learning is fun, learning is on your own time, and learning is a passion.
The Snowball Effect
When you overcome the difficulty of learning complex concepts and complex hurdles of your projects, it has a snowball effect on your confidence. I’ve seen that with my work. It’s not exactly the state of “flow”. It’s more of a kind of motivational energy that perpetuates your entire life. It’s the same effect as drinking coffee, going on a juice cleanse or living a healthy lifestyle. You ride a kind of energy wave of learning.
This motivational energy translates to wanting to learn all about infrastructure, design, and storage. This motivational energy translates to wanting to try programming in different ways: functional, imperative, procedural, event-driven, flow-driven, etc.
This motivational energy translates to asking why questions such as “Why are we designing this part of the system this way? Why do we use this programming language for this project? Why do we select this infrastructure technology to scale up our project? Why are we coding this part of the project in this way? Why are we designing the error handling this way? Why are we designing the messaging handling this way?”
Asking these questions will lead you to find out the how. Working on projects that will consistently allow you to learn the how to the right questions of why will allow you to become proficient much faster.
You are motivated to ask the why that allows you to find out how.
Building a Habit of Repeated Practice With Risk-Taking and Creativity
You are the owner of your programming career. Everyone’s different in the amount of risk they are comfortable with. Programming allowed me to learn to take measured risks in my career. It taught me confidence in my problem-solving abilities. It taught me to be confident in my creativity.
This is all due to my repeated practice of the programming languages that I’m most comfortable programming in. Repeated practice does not have to be boring. In fact, to be truly proficient in a programming language, taking projects that will allow you to learn different parts of the programming language is essential.
You can only learn to be creative in problem-solving if you learn different ways to problem-solve. You can only be efficient with your code when you think about the best ways to write your code. Only through repeated practice can you have “ah-ha” moments about pieces of code that will allow you to come up with the most efficient and effective code.
You learn to be proficient by learning to be efficient and creative.
Relying on What You Know to Leap Forward
Finally, as you have learned and practiced programming languages that you are comfortable with, you can now leap forward in your career. This is usually when you progress from a junior developer to a senior developer.
You will rely on all your knowledge of the why and how to ace those interviews to move to the next stage of your programming career. By now, some of this is already in your fingers. You can code with a certain agility in the languages that you are comfortable with.
You don’t work long hours anymore. You have time to go out with your friends. You finish your workday and take vacations. You mentor junior programmers. You set examples and use best practices at work. You speak up at architecture meetings and put in your two cents. You are known for being a certain kind of an expert on your team.
Congratulations, you have internalized the programming language that you’ve learned into long-term memory. It is now in your fingers.
Now you know the process of learning any new programming language. You know that you can’t quit in the middle. Every two hours spent programming are two hours you spent away from your loved ones. So make those two hours count. Allow those two hours to multiply each day until you’ve learned and internalized the concepts.