Thế giới năm 1997
Ở thời điểm đó, thế giới là một nơi có chút khác biệt. Website không có các cảnh báo cookie. Tương lai của web là các cổng thông tin điện tử (portal) chẳng hạn như Excite.com. AltaVista là công cụ tìm kiếm tôi yêu thích. Email của tôi lúc đó là kosmacze@sc2a.unige.ch – có nghĩa là website cá nhân được đặt tại http://sc2a.unige.ch/~kosmacze. Công nương Diana vừa qua đời. Steve Job nắm giữ vị trí CEO của Apple và thuyết phục Microsoft đầu tư 150 triệu USD vào công ty này. Tập đoàn Digital Equipment Corporation (DEC) thời đó đang kiện DELL. Hài cốt của Che Guevara được tìm thấy và đưa về an táng tại Cuba. Phần thứ 4 của series phim hài Friends bắt đầu được trình chiếu. Gianni Versace bị sát hại ngay trước hiên nhà. Mẹ Teresa, Roy Lichtenstein và Jeanne Calment (những con người sống thọ nhất thế giới tính đến thời điểm đó) vừa mới qua đời. Mọi người chơi Final Fantasy 7 trên những chiếc PlayStation của họ một cách điên cuồng. BBC 2 bắt đầu các chương trình phát thanh qua Teletubbies. James Cameron sắp ra mắt phim Titanic. The Verve trình làng bản hit Bitter Sweet Symphony và sau đó phải trả 100% số tiền thu được từ bài hát đó cho Rolling Stones.
Smartphone (điện thoại thông minh) lúc đó trông giống như chiếc Nokia 9000 CommMasterskillstor, có 8MB trong bộ nhớ, CPU 24 MHz i386 và chạy hệ điều hành GEOS. Smartwatch (đồng hồ thông minh) lúc đó trông giống như chiếc CASIO G-SHOCK DW-9100B, không có nhiều ứng dụng như hiện nay nhưng tuổi thọ pin lâu hơn rất nhiều.
IBM Deep Blue lần đầu tiên đánh bại kiện tướng cờ vua Garry Kasparov. Một hacker có tên là “_eci” đã công khai một mã C tạo ra lỗ hổng bảo mật cho Windows 3.1, 95 và Windows NT được gọi là WinNuke – kiểu tấn công DoS (tấn công từ chối dịch vụ) trên TCP ở port 139 (NetBIOS) gây ra hiện tượng màn hình xanh chết chóc (Blue Screen of Death). Thật tình cờ, năm 1997 cũng là năm mà Malala Yousafzai, Chloë Grace Moretz và Kylie Jenner chào đời.
Cốt truyện của nhiều bộ phim cũng được hoàn thành vào năm 1997 như Escape from New York (Trốn thoát khỏi New York), Predator 2 (Tiêu diệt ác thú 2), The Curious Case of Benjamin Button (Dị nhân Benjamin), Harry Potter and the Half-Blood Prince (Harry Potter và Hoàng tử Lai), The Godfather III (Bố già 3) và theo Terminator 2: Judgement Day (Kẻ hủy diệt 2: Ngày phán xét), Skynet sẽ bắt đầu tự nhận thức được vào lúc 2:14 sáng ngày 29/08/1997. Điều này đã không xảy ra; tuy nhiên, một điều thú vị khác đã xuất hện đó là tên miền Google.com đã được đăng ký vào ngày 15/09 năm đó. Cho đến năm 1997, hai năm sau sự kiện Y2K và giới truyền thông bắt đầu khiến mọi người lo lắng về điều đó. Đại loại, tại thời điểm tôi bắt đầu giấc mơ trở thành Developer thì thế giới là như vậy.
Công việc phát triển đầu tiên của tôi
Công việc đầu tiên của tôi bao gồm viết các trang ASP tại một số nhà xuất bản, từ Microsoft FrontPage, HotMeTaL Pro cho tới EditPlus, quản lý tính tương thích của nhiều trình duyệt giữa Netscape Navigator và Internet Explorer 4, viết các stored procedure (một tập hợp các câu lệnh SQL dùng để thực thi một nhiệm vụ nhất định) trong SQL Server 6.5 cung cấp cho một website thương mại điện tử hoạt động ở các nước Nhật Bản, Nga, Anh và Tây Ban Nha – mà không có bất kỳ sự hỗ trợ nào của UTF-8 (một phương thức encoding rất phổ biến để miêu tả bảng mã Unicode trên bộ nhớ) qua ngăn xếp phần mềm (software stack). Sản phẩm tạo ra từ những nỗ lực này chạy trên máy chủ Pentium 2 được đặt tại một nơi nào đó ở Mỹ với ổ đĩa cứng lên tới 2GB và RAM có dung lượng 256 MB. Đó là máy chủ duy nhất chạy Windows NT 4, SQL Server 6.5 và IIS 2.0 phục vụ khoảng 10 nghìn khách mỗi ngày.
Ngôn ngữ lập trình đầu tiên tôi sử dụng được gọi là VBScript và chắc chắn là cũng có một chút JavaScript phía client – thi thoảng thôi với khá nhiều câu lệnh như “if this is Netscape do this, else do that” (Nếu là Netscape thì làm điều này, còn nếu không thì làm điều kia) bởi vì ở thời điểm đó, tôi vẫn chưa hiểu làm thế nào để sử dụng JavaScript một cách chính xác. Điều thú vị là bây giờ đã là và chúng ta gần như cũng chẳng hiểu gì về cách làm bất cứ thứ gì trong JavaScript.
Unit test (kỹ thuật kiểm nghiệm các hoạt động của mọi chi tiết mã với một quy trình tách biệt quy trình phát triển phần mềm nhằm phát hiện sia sót…) chưa bao giờ được nghe đến. Agile Manifesto (Tuyên ngôn về Agile – phát triển phần mềm linh hoạt) cũng chưa bao giờ được viết. Continuous integration (một tập quán trong phát triển phần mềm) chỉ có trong mơ. XML thậm chí còn chưa phải là thuật ngữ thông dụng. Chiến lược QA chỉ bao gồm khởi động lại máy chủ 1 tuần/lần bởi nếu không làm như vậy, nó sẽ dừng hoạt động lúc nào chẳng biết. Chúng tôi đã phát triển COM+ Component trong Visual J++ để phân tích cú pháp các tập tin JPEG đã được tải lên máy chủ. Ngay khi các tập tin JPEG 2000 đã được mã hóa bắt đầu xuất hiện, Component của chúng tôi cũng bị phá hủy một cách kinh khủng. Chúng tôi không sử dụng source control, kể cả CVS, RCS hay SourceSafe. Subversion cũng chưa tồn tại. Điểm Joel Test của chúng tôi là -25.
6.776 ngày
Trong 6.776 ngày trước, tôi uống một tách café vào mỗi buổi sáng và viết code bằng các ngôn ngữ như VBScript, JavaScript, Linux, SQL, HTML, Makefiles, Node.js, CSS, XML, .NET, YAML, Podfiles, JSON, Markdown, PHP, Windows, Doxygen, C#, Visual Basic, Visual Basic.NET, Java, Socket.io, Ruby, unit test, Python, shell scripts, C++, Objective-C, batch file và gần đây nhất là Swift. Trong 6.776 ngày này cũng có rất nhiều thứ đã xảy ra; quan trọng nhất là tôi đã kết hôn. Tôi nhảy việc 6 lần và bị sa thải 2 lần. Tôi bắt đầu kinh doanh riêng và ngay sau đó cũng nhanh chóng đóng cửa nó. Tôi hoàn thành chương trình học Thạc sĩ. Tôi đã ra mắt một vài dự án mã nguồn mở và một trong số chúng đã giúp tôi xuất hiện trong một bài viết đăng trên tờ Ars Technica (tác giả Erica Sadun). Tôi cũng được góp mặt trong chương trình truyền hình Swiss and Bolivian. Tôi xem các bài thuyết trình trực tiếp của Bill Gates và Steve Jobs tại Seattle và San Francisco. Tôi cũng đã tham gia diễn thuyết và đồng tổ chức các hội nghị tại 4 lục địa. Tôi viết và xuất bản 2 cuốn sách. Tôi cũng đã kiệt sức hai lần (không phải vì những cuốn sách, tự bản thân tôi thôi) và rất nhiều thứ khác đã xảy ra, cả những điều tuyệt vời lẫn những thứ tồi tệ.
Tôi thường suy nghĩ về việc rời bỏ công việc này. Tuy nhiên, bằng cách nào đó, những dòng code ấy luôn gợi nhớ lại cho tôi về quá khứ. Tôi thích viết các ứng dụng, hệ thống, phần mềm. Để tránh kiệt sức, tôi phải phát triển các chiến thuật. Trong bài viết này, tôi sẽ chia sẻ cho bạn 12 kinh nghiệm của tôi. Bạn có thể tham khảo hoặc chọn lọc để áp dụng cho mình. Nhưng dù gì đi nữa, tôi vẫn tin rằng 40 tuổi, bạn vẫn có thể trở thành một Developer nếu bạn sẵn sàng theo đuổi nó.
12 lời khuyên dành cho các Developer mới vào nghề
1. Hãy quên đi những lời phóng đại
Lời khuyên đầu tiên của tôi dành cho tất cả các bạn đó là đừng để ý đến những lời phóng đại. Mỗi năm, sẽ có một ngôn ngữ lập trình, framework, thư viện, mẫu (pattern), kiến trúc thành phần (component architecture) hay paradigm mới nổi lên khiến cho giới blogger bỗng nhiên đạt được thành công vang dội. Mọi người điên cuồng với nó. Các hội thảo được tổ chức. Sách được viết. Các biểu đồ Gartner hype cycles tăng, giảm liên tục. Các chuyên gia tư vấn nhận được những khoản thù lao vô cùng lớn để dạy, triển khai…. hay “phá hủy” cuộc đời của rất nhiều người trong lĩnh vực này. Báo chí ủng hộ cho những sự hỗn loạn đó và sẽ khiến bạn cảm thấy tội lỗi nếu như tỏ ra phớt lờ họ. Đừng lo lắng về những lời phóng đại. Hãy tiếp tục làm những gì bạn đang làm, học những thứ bạn đang học và tiến về phía trước. Chỉ đế ý đến chúng nếu như bạn thực sự quan tâm hoặc nếu cảm thấy rằng chúng có thể mang đến cho bạn những lợi ích ngắn hạn hoặc dài hạn. Lý do cho những lời nói dối này đều dựa trên thực tế đó là, giống như người Roman đã từng nói, “nihil sub sole novum” (chẳng có gì mới lạ dưới ánh sáng Mặt Trời cả). Phần lớn những gì bạn thấy và học được về khoa học máy tính đều đã xuất hiện hoặc nhen nhúm xuất hiện trong khoảng vài thập kỷ trước. Thực tế này được che đậy có chủ ý dưới hàng đống lý thuyết marketing, sách vở, blog và những câu hỏi trên Stack Overflow. Mỗi kiến trúc mới chỉ đơn thuần là một sự tưởng tưởng lại và mô phỏng lại một ý tưởng mà đã “trôi nổi” trong hàng chục năm trước đó.
2. Lựa chọn “thiên hà” một cách khôn ngoan
Trong lĩnh vực này, mỗi công nghệ sẽ tạo ra một thứ mà tôi tạm gọi là “galaxy” (thiên hà). Những thiên hà này nổi bật với các ngôi sao nhưng cũng đồng thời là các lỗ đen (black hole); những ngôi sao băng bay vụt qua bầu trời mỗi tối, nhiều hành tinh nhưng chỉ có một phần rất nhỏ trong số các hành tinh đó tồn tại sự sống, nhiều bụi vũ trụ và vật chất tối (dark matter). .NET, Cocoa, Node.js, PHP, Emacs, SAP… là những thiên hà. Mỗi một thiên hà lại nổi bật với những người truyền giáo, các nhà phát triển, blogger, podcast, hội thảo, sách, khóa đào tạo, dịch vụ tư vấn và các vấn đề liên quan khác. Các thiên hà được xây dựng với giả thuyết rằng công nghệ cơ sở của chúng là câu trả lời cho tất cả các vấn đề. Do đó, mỗi công nghệ đều được dựa trên một giả thuyết sai lầm.
Các nhà phát triển đến từ các thiên hà khác nhau là hiện thân của những quan điểm “nguyên mẫu” rằng sẽ mang công nghệ đó vào cuộc sống. Họ gắn chặt với các ý tưởng và sẽ hăng hái mặc những chiếc áo phông, đồng thời truyền đạt cho những người khác về các lợi ích đạt được từ sự lựa chọn đó của họ. Quả thật, tôi sử dụng thuật ngữ “thiên hà” để tránh việc phải sử dụng một thuật ngữ khác có thể gây ra những tranh cãi không đáng có là “sự sùng bái” (religion) – từ mà có thể mô tả đúng hơn hiện tượng mà tôi muốn nói.
Riêng tôi, tôi dành 10 năm đầu trong sự nghiệp của mình trong “thiên hà Microsoft” và 9 năm sau đó dành trọn cho “thiên hà Apple”. Tôi dám nói rằng, một trong những lý do lớn nhất tại sao tôi thay đổi các thiên hà đó là Steve Ballmer (cựu CEO Microsoft). Tôi đã quá mệt mởi bởi thái độ chung của những người trong “thiên hà Microsoft” khi chống lại phần mềm mã nguồn mở. Mặt khác, tôi cũng phải nói rằng “thiên hà Apple” là một nơi tuyệt vời, đầy rẫy các nghệ sĩ, nhạc sĩ và các cây viết xuất sắc – những người mà, dù tình cờ hay không cũng bắt đầu quan tâm tới lập trình phần mềm. Tôi cũng đã tham dự các hội thảo của “thiên hà Microsft”, chẳng hạn như Barcelona TechEd vào năm 2003 hoặc các buổi Tech Talks ở Buenos Aires, Geneva hay Lodon. Tôi thậm chí còn là diễn giả tại Microsoft DevDays (Geneva) vào năm 2006. Đa phần, các nhà phát triển trong “thiên hà Microsoft” không hề thân thiện, “đoàn kết” và ràng buộc nhau một cách bí mật, đầy rẫy các thỏa thuận không tiết lộ (NDA) và các quá trình IT cồng kềnh. Quay trở lại năm 2006, “thiên hà Apple” đối với tôi lại trái ngược hẳn: đầy rẫy những con người là nhạc sĩ, nghệ sĩ, họa sĩ; những người viết phần mềm để thỏa mãn đam mê của họ và họ cũng viết bằng chính niềm đam mê đó. Nó tạo ra mọi sự khác biệt và ngày đó, tôi vẫn vô cùng thích thú “thiên hà” này, “thiên hà” mà tất cả chúng tôi cùng ở đó, ngay tại thời điểm bây giờ và nó đã kết nối chúng tôi lại với nhau. Khi đó, iPhone cũng ra đời và phần còn lại thuộc về lịch sử. Thế nên, đề xuất của tôi dành cho bạn đó là: hãy lựa chọn thiên hà một cách khôn ngoan, sống hết mình hoặc hời hợt với nó như bạn muốn nhưng hãy giữ kính thiên văn của bạn hướng về những thiên hà khác và sẵn sàng để nhảy thật xa sang một nơi mới nếu cần thiết.
3. Tìm hiểu về lịch sử phần mềm
Học cách mà công nghệ yêu thích của bạn xuất hiện. Bạn có thích C# không? Bạn có biết ai tạo ra nó? Dự án .NET được hình thành như thế nào? Ai là kiến trúc sư hàng đầu? Những trở ngại của một dự án là gì và tại sao ngôn ngữ lại trở thành thứ quan trọng như ngày hôm nay? Hãy áp dụng công thức này cho bất kỳ ngôn ngữ hoặc kiến trúc CPU nào bạn thích hoặc yêu: Python, Ruby, Java hay bất cứ ngôn ngữ lập trình nào khác: hãy tìm hiểu về nguồn gốc của chúng, chúng xuất hiện như thế nào. Tương tự, hãy tiếp tục làm như vậy với các hệ điều hành, các công nghệ networking, phần cứng và tất cả những thứ khác. Hãy khám phá và học cách mà mọi người tiếp cận với những ý tưởng này, mất bao lâu để họ nắm vững và chinh phục chúng. Bạn biết đấy, một phần mềm tốt còn phải mất đến 10 năm mới hoàn thành quá trình phát triển cơ mà.
Những câu chuyện xung quanh nguồn gốc của ngành công nghệ thông tin rất hấp dẫn và cho bạn thấy hai thứ: đầu tiên, mọi thứ là một sự xáo trộn trở lại. Thứ hai, chính vì cái thứ nhất mà bạn có thể trở thành người xáo trộn lại thứ to lớn tiếp theo. Không, hãy thay đổi tư duy của bạn thế này: bạn sẽ trở thành nhà sáng tạo của một thứ gì đó vĩ đại kế tiếp. Và để giúp đỡ bạn đạt được điều đó, tôi sẽ cung cấp cho bạn một số đầu sách lịch sử mà tôi rất thích: Bạn cũng sẽ học cách đánh giá cao những thứ mà vẫn đứng vững trước sự dịch chuyển của thời gian: Lisp, TeX,Unix, bash, C, Cocoa, Emacs, Vim, Python, ARM, GNU make, man pages. Đây là những ví dụ điển hình của các công nghệ mà mang lại lợi ích trong thời gian dài – những thứ đáng được chào đón, ca ngợi và học hỏi.
4. Tiếp tục học hỏi
Học. Học bất cứ thứ gì. Muốn học Fortran? Hãy bắt đầu đi. Cảm thấy Erlang thú vị? Tuyệt vời. Nghĩ rằng COBOL có thể là điều lớn lao tiếp theo trong sự nghiệp của bạn? Thật tuyệt. Cần biết nhiều hơn về Functional Reactive Programming (Lập trình hướng luồng dữ liệu)? Được chứ! Thiết kế? Chắc chắn càng ổn. UX? Bạn buộc phải học. Thơ văn? Nên tìm hiểu một chút. Nhiều concept phổ biến trong Khoa học máy tính đã được xuất hiện khoảng vài thập kỷ trước càng khiến việc học những ngôn ngữ lập trình và framework cũ càng trở nên đáng giá, ngay cả khi đó là những thứ “bí mật”. Đầu tiên, nó khiến bạn trân trọng thực trạng hiện tại của ngành bạn đang làm (hoặc ghét nó) và thứ hai, bạn sẽ học cách sử dụng những công cụ hiện tại hiệu quả hơn – có thể là bởi vì bạn sẽ hiểu cả nguồn gốc lẫn những di sản của nó. Tip 1: Tìm hiểu ít nhất một ngôn ngữ lập trình mới mỗi năm. Tôi không phải là người đề xuất ý tưởng này mà là cuốn sách này: The Pragmatic Programmer. Tất nhiên, nó hiệu quả. Một ngôn ngữ lập trình mới mỗi năm không hề quá khó. Hãy bước vào giai đoạn “xin chào, thế giới” và tạo ra thứ gì đó hữu ích bằng cách sử dụng ngôn ngữ đó. Tôi thường xây dựng một phần mềm tính toán đơn giản với bất cứ công nghệ mới nào mà tôi học được. Nó giúp tôi làm rõ cú pháp và làm quen với API hay IDE… Tip 2: Đọc ít nhất 6 cuốn sách mỗi năm. Tôi đã liệt kê một danh sách ở trên gồm 6 cuốn sách bắt buộc phải đọc có thể khiến bạn bận rộn trong khoảng 1 năm tới và dưới đây là 7 cuốn cho năm sau đó nữa mà bạn có thể tham khảo:
6 cuốn sách mỗi năm nghe có vẻ nhiều nhưng tính ra 2 tháng bạn chỉ phải đọc duy nhất một quyển. Và đa phần những cuốn tôi kể ở trên đều không quá dài, dễ hiểu, hài hước và chứa rất nhiều điều thú vị. Hãy nhìn vấn đề theo hướng này: Nếu bây giờ bạn đã 2 tuổi, đến tuổi 30 bạn sẽ đọc được hơn 60 cuốn và 120 cuốn khi bạn bằng tuổi tôi hiện tại. Và lúc đó, bạn cũng đã được “đùa giỡn” với ít nhất 20 ngôn ngữ lập trình khác nhau. Chỉ cần nghĩ đến điều này trong 1 giây thây cũng đã đủ hạnh phúc để muốn bắt đầu ngay rồi! Một số trong 12 cuốn mà tôi đã chọn cho bạn ở trên được viết ở thế kỷ 17, một số ở thế kỷ 18, 19 và cuối cùng, đa phần là được viết cách đây khoảng 10 năm. Chúng là những tác phẩm tuyệt vời về phát triển phần mềm mà tôi đã đọc. Tuy nhiên, đừng chỉ đọc chúng. Hãy ghi chú, đánh dấu, viết lên những trang sách đó và sau đó, hãy dành thời gian đọc lại. Borges đã từng nói rằng sự thỏa mãn lớn hơn việc đọc một cuốn sách là đọc lại nó. Và tất nhiên, làm ơn hãy mua sách giấy nếu bạn thực sự thích chúng. Tin tôi đi. Sách điện tử được đánh giá quá cao (so với thực tế của chúng). Không gì có thể đánh bại những thứ được cầm nắm thực sự cả. Hiển nhiên, bạn cũng cần biết rằng khi bạn bắt đầu già, số lượng những thứ mà được cho là mới và/hoặc quan trọng sẽ bắt đầu giảm rất mạnh. Hãy chuẩn bị cho điều đó. Không có gì ngạc nhiên nếu bạn cảm thấy buồn khi nhận ra nó cả.
5. Dạy lại cho người khác
Một khi đã học được, hãy dạy lại cho người khác. Đây là điều rất quan trọng.
Điều này không có nghĩa bạn nên thuê phòng học và mời mọi người tới nghe bạn “lảm nhảm” (mặc dù sẽ tuyệt vời hơn nếu làm được như vậy!). Ý của tôi ở đây là đối với những câu hỏi được đặt ra trên Stack Overflow, hãy đưa ra những câu trả lời ý nghĩa và tốt nhất; là bạn hãy viết một cuốn sách; xuất bản một podcast chia sẻ về công nghệ yêu thích của bạn; hãy viết blog; viết trên trang Medium; đi tới các quốc gia khác, mở lớp/trường dạy lập trình bằng cách sử dụng Raspberry Pis (một chiếc máy tính siêu nhỏ) hoặc giúp đỡ những nhà phát triển mới vào nghề bằng cách trở thành cố vấn của họ (mặc dù vậy, đừng làm điều này trước 30 tuổi nhé vì bạn chưa đủ kinh nghiệm đâu). Dạy lại cho người khác sẽ giúp bạn biết khiêm tốn hơn bởi vì quá trình này sẽ chỉ ra rằng kiến thức của bạn hạn hẹp tới mức nào. Đây cũng là cách tuyệt vời để học hỏi. Chỉ bằng cách kiểm tra kiến thức của bạn với người khác thì bạn mới học một cách đúng đắn. Thêm nữa, truyền đạt lại cho mọi người những gì bạn biết cũng sẽ khiến bạn được tôn trọng nhiều hơn bởi các nhà phát triển và những người đam mê công nghệ khác; mỗi ngôn ngữ, bất kể chúng tầm thường hay “cao quý” thì cũng đều có chỗ đứng trong Tao of Programming (Đạo của Lập trình) và chỉ qua giảng dạy thì bạn mới có thể cảm nhận được nó. Và trong suốt quá trình dạy lại cho người khác, bạn có thể thực sự, thực sự tạo sự khác biệt trong thế giới này. Quay trở lại năm 2012, tôi nhận được một email từ một người mà đã tham dự một trong những buổi đào tạo của tôi. Cô đã từng làm việc trong vai trò là một nhà phát triển Adobe Flash. Bạn còn nhớ ActionScript và tất cả những thứ đó chứ? Không có gì ngạc nhiên khi sau 12 năm làm việc trong vai trò là một freelancer mảng phát triển Flash cô bỗng nhiên cảm thấy mình thất nghiệp, cô đơn cùng với một đứa con để chăm sóc. Trong email cô nói rằng khi tham gia buổi đào tạo của tôi, cô đã rất hứng thú và cũng học một vài thứ hữu ích. Sau đó, cô tìm được một công việc về phát triển web cho di động. Cô gửi cho tôi lời cảm ơn. Tôi không dám tuyên bố rằng tôi có thể thay đổi thế giới nhưng có lẽ, tôi có thể khiến nó “dịch chuyển” chút ít sang một vị trí khác (hy vọng rằng) sẽ tốt hơn. Suy nghĩ này đã khiến cho bài học mà tôi rút ra được từ thời điểm đó trở nên đáng giá và ý nghĩa hơn rất nhiều.
6. Môi trường làm việc thật khủng khiếp
Đừng mong đợi các công ty phần mềm gợi mở cho bạn một con đường phát triển sự nghiệp. Nếu ở Mỹ, có thể điều này sẽ xảy ra nhưng tôi chưa bao giờ nhìn thấy chúng có ở châu Âu. Điều này có nghĩa bạn buộc phải tự chịu trách nhiệm cho thành công trong sự nghiệp của mình. Không một ai nói với bạn rằng “ồ, vâng, năm tới bạn có thể phát triển để trở thành một trưởng nhóm, sau đó là quản lý, tiếp theo là giám đốc công nghệ…”.
Không hề có chuyện đó. Thực tế lại là điều ngược lại: bạn đã từng là, bạn là và sẽ là một nhà phát triển phần mềm, nghĩa là, một công nhân nhà máy tương đối có “giá”, các công việc của bạn nhà quản lý hoàn toàn có thể sử dụng dịch vụ thuê ngoài (outsource) bất kể họ có nói gì với bạn đi nữa. Đừng nhận một công việc chỉ vì tiền. Các công ty phần mềm đang dần trở thành những công xưởng đầy mồ hôi nước mắt – nơi bạn được cho là sẽ tìm cách chứng minh cho mức lương cao vô lý của mình bằng những giờ làm việc “không ai biết” và những kỳ vọng vượt quá giới hạn. Và, trong trường hợp ở Thụy Sĩ, đó là không có tổ chức công đoàn nào sẽ giúp bạn nếu mọi thứ trở nên tồi tệ. Quả thật, ở quốc gia này cũng có công đoàn nhưng họ không thực sự quan tâm tới các tình huống mà không tới mức sẽ tạo ra một cuộc khủng hoảng truyền thông thực sự. Bất cứ lúc nào trưởng phòng nhân sự nói rằng “bạn buộc phải làm điều đó bởi vì chúng tôi trả lương cho bạn” thì hãy nhớ câu sau để trả lời: “bạn trả lương cho tôi nhưng tôi đã dành tặng cho bạn chất xám của tôi và tôi từ chối “thỏa thuận” này”. Và điều tệ nhất là họ sẽ đặt bạn vào trong một không gian mở và vì một vài lý do nào đó họ sẽ tự hào về điều đó. Những không gian mở có thể là một vết ung nhọt. Họ làm như vậy mà không mảy may nghi ngờ rằng họ sẽ tạo ra một văn phòng làm việc vô cùng tệ hại và chẳng phù hợp gì cả để phát triển phần mềm – hay bất kể một dự án nào cần sự hoạt động của não bộ. Hãy nhớ điều này: thực tế là bạn hiểu thứ gì đó không nghĩa rằng bạn phải đồng ý với nó. Bên ngoài kia vẫn còn những môi trường làm việc tốt, không nhiều nhưng chắc chắn có. Tôi rất may mắn khi được làm việc tại những nơi như vậy. Bạn cũng có thể. Đừng để những công việc tẻ nhạt giết chết nhiệt huyết của bạn. Nó không hề xứng đáng. Hãy phá luật và dịch chuyển. Hoặc tốt hơn nữa là trở thành một nhà phát triển độc lập.
7. Hiểu rõ giá trị của bạn
Bạn có thể đã từng nghe đến bí ẩn về “10x Software Engineer”. Thực tế, điều này chẳng có gì bí ẩn cả, nhưng nó không xuất hiện theo cách mà bạn vẫn nghĩ là nó sẽ diễn ra như vậy.
“10x Software Engineer” là người mà tạo ra giá trị gấp 10 lần bất kể nhà tuyển dụng có “trả giá” họ bao nhiêu đi chăng nữa. Họ luôn làm ra được những thứ với giá trị lớn gấp nhiều lần so với những gì ông chủ nghĩ họ có thể làm được. Và chắc chắn, họ sẽ được nhận tiền thưởng và thậm chí là cổ phần. Hãy đọc Karl Marx và Thomas Piketty để biết rõ giá trị của bạn. Hãy giống như một chú cá mập luôn tiếp tục bơi bởi vì những kỹ năng của bạn cực kỳ có giá trị. Hãy dám đề nghị mức lương mong muốn của bạn dựa trên thực lực để sếp và đồng nghiệp hiểu rõ những gì bạn có thể làm. Bạn càng dũng cảm công khai mong muốn của mình thì sự bất công sẽ được làm dịu.
8. Hãy biết khiêm nhường
Nếu bạn là người da trắng thì hãy nhớ một điều rằng tất cả những đặc quyền mà bạn được hưởng từ lúc sinh ra chỉ bởi vì bạn được sinh ra theo cách đó. Trách nhiệm của bạn là thay đổi cuộc sống của bạn và xóa bỏ định kiến rằng bạn đang xứng đáng được hưởng nhiều đặc ân hơn người khác. Hãy đưa ra các quyết định dựa trên nhận thức của bạn. Hãy nhận ra những hành động và tác động của chúng tới mọi người xung quanh. Đừng e thẹn hay cảm thấy ngượng ngùng khi thay đổi ý kiến. Hãy nói “tôi xin lỗi” khi được yêu cầu. Hãy lắng nghe. Đừng trở thành một con người quá khôn khéo trong ứng xử. Hãy chính trực và có lòng tự trọng. Đừng chỉ trích hay trêu chọc sự lựa chọn của người khác. Họ đều có lý do khi lựa chọn hay theo đuổi một thứ gì đó. Tất cả những lựa chọn đều đáng được tôn trọng. Hãy sẵn sàng để thay đổi tư duy bất cứ lúc nào trong quá trình bạn học hỏi. Một ngày có thể bạn thích Windows nhưng rồi sẽ có ngày bạn thích Android. Không có gì là bất biến cả.
9. LLVM
Mọi người say sưa nói về Swift nhưng quả thật thứ tôi chú ý nhiều hơn những ngày này đó chính là LLVM.
Tôi nghĩ rằng LLVM là dự án phần mềm quan trọng nhất hiện nay được đo lường bởi những tác động dài hạn của nó. Các Block trong Objective-C, Rust & Swift (hai loại ngôn ngữ lập trình rất được yêu thích khi viết và biên dịch theo khảo sát các nhà phát triển của StackOverflow ), Dropbox Pyston, Clang Static Analyser, ARC, Google Souper, Emscripten, LLVMSharp, Microsoft LLILC, Rubymotion,cheerp, các ứng dụng watchOS, Android NDK, Metal, tất cả những thứ này được hỗ trợ hoặc được xây dựng từ LLVM. Có nhiều trình biên dịch đang sử dụng LLVM như là chương trình phụ cho khá nhiều ngôn ngữ lập trình quan trọng nhất hiện nay. Cuối cùng, .NET CLR cũng sẽ tương hợp với LLVM và Mono cũng đã sử dụng nó. Facebook hiện đang cố gắng tích hợp LLVM với HHVM và WebKit gần đây đã chuyển đổi từ LLVM sang trình biên dịch JavaScript B3 JIT mới. Thế nên, hãy học tất cả về LLVM. Đây là “thiên hà” nơi mà sự cải tiến thật sự đang xảy ra. Đây cũng là nền tảng cho 20 năm tới.
10. Hãy làm theo linh cảm của bạn
Tôi có cảm giác chắc chắn (dù không thể giải thích nổi) rằng .NET sẽ trở nên lớn hơn khi tôi xem sự kiện ra mắt nó vào tháng 6 năm 2000. Tôi cũng có đúng cảm giác đó với iPhone là nó sẽ càn quét thị trường điện thoại di động khi tôi xem buổi giới thiệu vào năm 2007. Quả thật, trong cả hai tình huống đó, mọi người đều cười tôi. Nhưng cũng hai lần tôi tin vào linh cảm của mình thì chúng đều đúng. Hãy nghe theo linh cảm của bạn vì biết đâu may mắn sẽ đến.
11. API là “ông hoàng”
API tuyệt vời sẽ giúp tạo ra những ứng dụng tuyệt vời. Nếu API chẳng ra gì thì ứng dụng của bạn cũng đáng vứt vào sọt rác, bất kể giao diện của nó có đẹp đến mức nào đi chăng nữa. Đừng phát minh ra thuật toán bảo mật của riêng bạn. Hãy học một vài công nghệ server-side và chắc chắn Node là một trong số đó. Hãy đặt REST sang một bên và rộng mở đón lấy Socket.io, ZeroMQ, RabbitMQ, Erlang, XMPP; tìm hiểu tính năng thời gian thực (realtime) như là bước tiếp theo trong quá trình phát triển ứng dụng. Thời gian thực không chỉ dành cho các ứng dụng chat. Và đừng quên bắt đầu xây dựng các bot với những API này.
12. Chống lại sự phức tạp
Đơn giản hơn sẽ tốt hơn. Luôn luôn như vậy. Hãy nhớ nguyên tắc KISS (Keep it simple, stupid). Và ý của tôi không chỉ là ở cấp độ giao diện người dùng mà là tất cả mọi thứ cho tới khi bạn đạt đến những lớp sâu nhất trong code của bạn. Refactoring, unit test, code review, pull request, tất cả những công cụ này bạn có thể tùy ý sử dụng để chắc chắn rằng mã mà bạn di chuyển là kiến trúc hoạt động được đơn giản nhất có thể. Đây là cách mà bạn xây dựng các hệ thống có tính đàn hồi trong dài hạn.
Kết
Điều quan trọng nhất ở đây cần phải nhớ đó là tuổi tác của bạn không là vấn đề. Miễn là trái tim của bạn nói với với bạn rằng hãy tiếp tục coding và tạo ra những thứ mới thì bạn vẫn còn trẻ lắm. Chắc chắn là bạn không biết điều gì sẽ xảy ra trong vòng 19 năm tới nhưng tôi có thể nói với bạn 3 điều có khả năng rất cao sẽ xảy ra:
