1樓：程式碼丸子
1、盡量進大公司，不能進的採取『曲線救國』的策略，邊學習邊準備。
2、選個有成長性的公司，錢不錢剛開始不重要。
3、工作中，主動學習，自我反省，學會總結，經常覆盤。
4、不管胃口好不好，遇到大餅的時候一定要躲避。
5、工作中適當划水，你是去工作，不是去賣命。
6、身體最重要，養成每天鍛鍊的好習慣，畢竟加班是常態。
7、不要迷戀新技術，它的背後都是基礎。
2樓：sjjf sjjf
程式不僅僅是程式，它是你對這個世界認識的反映。
程式設計是在現實世界模型與基於機器模型之間的編碼對映過程。
在術業專攻的今天，每一部分都有人在研究的很深入了。
比如機器模型的研究，它不僅僅是圖靈機的計算模型，還有lambda形式的，生物計算機，量子計算機等。
機器語言的描述是相當繁瑣的需要大量的描述資訊量，於是基於該機器語言上有很多增強的語言進行擴充套件，其目的都是在實現相同功能，在不減低效率的情況下，減少問題描述的資訊量。通常，這一部分都是搞編譯器的人做的事情。
在物理機器執行大量各種不同的任務後，人們發現有很多經常重複的動作序列集合，它們的變化比較少或者變化形式有限，於是便被抽取出來，形成新的介面，並賦以更貼近人類思考方式的概念意義。比如file，process（被翻譯為程序，實際是處理的意思），這些概念整合起來，便是作業系統。它以更高階更通俗易懂的方式讓人們去驅動一台機器。
判斷某乙個邏輯模型是否能在乙個特定的平台上實現，以及如何實現，實現的週期多長，實現的質量（效能，可靠性等）有多高等。是應用程式設計師幹的事情。
如何將現實世界中的問題以及其解決方案抽象成邏輯模型，是需求分析師與系統設計師幹的事情。
其實我想表達的是，這涉及的每乙個部分，拼到最後，都是拼數學……
3樓：PY Yin
開始寫程式覺得很奇妙，5年之後覺得自己很牛，10年之後有點疲倦，15年之後很可憐，20年之後......已經看得很淡了，但是每當坐在電腦前，曾經的激情卻總在湧動。哦......
我明白了，推動程式設計師不分晝夜地奔跑的，是熱愛。
4樓：Fireman A
全世界程式設計師團結起來
在混混愕愕地幹了十年IT行當以後，我發現我對IT就業的未來充滿了信心。究其原因，是因為我現在把我所見到的人分為兩類：當得了程式設計師的，和當不了程式設計師的。
請注意我的分類是相當粗糙和武斷的。如果比較具體地說，那麼我需要引用JeffXiong(熊節)微博裡讀到的一段話：
「軟體開發的本質挑戰在於把物理世界的問題建模為乙個圖靈機可計算的（嚴格來說是NP可計算的）問題。這個建模過程是非直覺的、需要專門訓練的。人人都能邏輯地思考，這事在人類歷史上從來就沒發生過，所以我也不期望它在未來會發生。
」我願意把這個表述改得更加寬鬆一些，即你只需要能夠把物理世界問題「表達」為乙個圖靈可計算的問題。任何乙個直接參與軟體製造步驟的人都必須參與這個建模（或者說是這個表達）過程。因此他們必須擁有該種能力。
具有這種能力的人不一定都去當了程式設計師（實際上好多在當CEO），但是沒有這種能力的人當不了程式設計師。為了方便起見我們稱他們為麻瓜。
與程式設計師不同的是，麻瓜不僅缺乏這種能力，而且絕大多數沒有意識到這種能力區分的存在。這種能力的缺乏被模糊地歸類為「不懂技術」或者「溝通不良」，從而斷絕了麻瓜彌補這一能力的機會。
聰明的讀者大概意識到，以下兩個條件的組合可以充分保證非麻瓜在各行各業的光明未來：
1. 資訊科技應用規模的不斷擴大。
2. 保證麻瓜的數量。
由於1是不言而喻的，因此，所有IT業人員應該團結起來，避免麻瓜的覺醒。要未雨綢繆，象保護生態平衡那樣保護麻瓜的存在。各行各業中的麻瓜的存在保證了非麻瓜的優勢地位，如同食物鏈一般，麻瓜供養了非麻瓜。
對麻瓜的保護，最重要的莫過於避免指出麻瓜與非麻瓜之間關鍵能力區別的精確定義。如果該區分不能被清晰地定義，則沒有辦法建立起有效地轉化麻瓜的手段。
全世界程式設計師團結起來，為保護麻瓜而奮鬥！
作為程式設計師，你闖過哪些大禍？
搬磚一工兵 誤把總和環境的作業手冊在產品環境執行，刪掉了queue，還好現場的高手手動恢復了。教訓，作業人員必須通讀手冊，有疑問要向老手特別確認。老手的命令不一定是老手深思熟慮過的。老手也應認識到新人不會知道黯默的規則，從新人的角度看手冊中的危險，煩，總比錯好。與同行互勉。 Mr.曹 晚上加班走的晚...
作為程式設計師，2023年你有哪些正在做的個人專案？
Ray odt 我18年10月開始寫的離線光線追蹤渲染器基於RTGU peter的one weekend 三卷本小冊子然後部分pbrt 接下去準備寫完全pbr的其實就是基本移植pbrt 然後單獨的幾個小型測試工程 PPM SPPM 這種拉出來單獨試試 git wenxiwu777 圖形學太有意思了一...
作為程式設計師，你有哪些最大限度降低bug率的辦法？
florent TDD是你必須嘗試的方法。如果實在不適應，也應該盡可能的增加測試的覆蓋範圍，這樣雖然不能完全避免bug，至少可以讓你debug的時候大大的縮小需要考慮的範圍。 初級程式設計師的一點心得 出bug不是最可怕的，最可怕的是出了bug但不知道錯在哪，為了防止跑飛，我寧可在每個迴圈和判斷之後...