How to start learning programming?

In "Teach Yourself Programming in Ten Years" Peter Norvig revealed a recipe to be successful in programming. Here are some points:

• Get interested in programming, and do some because it is fun. Make sure that it keeps being enough fun so that you will be willing to put in ten years.
• Learn at least a half dozen programming languages...
  
• Remember that there is a "computer" in "computer science"... (or know your computer well)

I based on those points to give advices in QA style and create a list of recommended materials for a newbie who want to start learning programming (as much free materials as possible). Feel free to ask me if you need more information :)

Q: I don't know about programming. What programming language I should start with?

A: Start with a dynamic programming language (Ruby, JavaScript, Python, Perl ...) because it's easier to start and more fun than static type languages (C/C++, Java). You don't need to comply your code in-order to run program. And only with dynamic programming languages, you can interact with program via a command line tool.

Q: Which dynamic programming language should I choose?

A: For me, I prefer Ruby and JavaScript because I know them very well. I will recommend some excellent materials for learn both Ruby and JavaScript. Most of them are free.

Ruby

• why's (poignant) guide to Ruby: very funny, enjoyable but complete and insightful
  
• Humble Little Ruby Book
• The Little Book of Ruby: Learn by examples
  
• Programming Ruby (free access for 1st edition): Use as a reference book

You should learn from Ruby Object Oriented Programming (not Class Oriented :) and Meta-Programming.

JavaScript

• Excellent Video: Douglas Crockford, "The JavaScript Programming Language"
  
• Excellent Video: Douglas Crockford, "Advanced JavaScript"
• Eloquent Javascript: Small and nice for beginners. Code can run directly from links in the books (because JavaScript is the language of all web browsers)
• JavaScript Definitive Guide (free access for 2nd edition: not sure about copyright!): Use as a reference book

You should learn from JavaScript functional style and prototype-based object oriented.

Q: What next?

A: C/C++ and Erlang.

• C is today "assembly language". Most of computing systems is built in C: operation systems, database systems, core libraries for servers, desktops, mobile phones and embedded devices. I forgot to mention that, Ruby interpreters, Java virtual machine, JavaScript engines are all implemented in C/C++. So if you want to know the system well, want improve performance and utilize full power of systems. You must learn C.
  
• C++: To learn Object-Oriented Programming, Template Meta-Programming, Generic Data Structure and Algorithms in STL (Standard Template Libarary)
• Erlang: The world is concurrent. Now most of us use desktop or laptop with at least two cores. If 5 or 10 years, our machines will have 8, 16, 32, 64 or event 1028 cores. Sequential programming don't help to utilize their power. In this case, Erlang will help. You also learn about Functional Programming when using Erlang.
  

C/C++ books

• The C Programming Language
• Thinking in C++, vol 1 & vol 2: Very good and free
  
• The C++ Programming Language
  
• Effective C++: 50 Specific Ways to Improve Your Programs and Design

Erlang materials

• Programming Erlang: Software for a Concurrent World
• An Erlang course
• Concurrent Programming in Erlang (part 1 is free)

Q: Why not Java?

A: Because I don't use Java much in my programming career.

Q: What to read if I want to learn more about "science" in "computer science" that benefit programming directly?

A: I encourage you to read following excellent books:

• Concepts, Techniques, and Models of Computer Programming (can download draft version): will teach you all the concepts and paradigms of programming: stateless, statefull, concurrent, object-oriented ....
  
• Elements of Programming: Math foundation for programming
  

• Notes on Programming: same author and will be replaced by Elements of programming but easier and more enjoy to read. (more details here)
  

Above all, the most important thing is: "Before you start learning programming, make sure that you love it and it brings you a lot of fun."

Stepanov Programming Principle

(from Note on Programming, 2006 book)

I found Stepanov 's book (he is the father of Standard Template Library) while searching for material to enhance my C++ coding skill. You can find a lot of his love for programming in his writing. Here is an extraction: "Programming is a wonderful activity that goes well beyond the range of what a single programmer can experience in a life time".

He said that "The book does not present scholarly consensus. It present my personal opinions... The book does not attempt to solve complicated problems. It will attempt to solve very simple problems which most people find trivial: minimum, maximum, linear search and swap. These problem are not however simple as they seem. I have been forced to go back and revisit my view of them many times."

He learn from his experience that we should solve simple problems carefully, and master them in order to solve complicated ones. He said "I do understand that most people have to design system somewhat more complex than maximum and minimum. But I urge them to consider the following: unless they can design a three line program well, why would they be able to design a hundred thousand line program".

So, before you coding, you should read Stepanov Programming Principle:

• The code should be partitioned into functions
• Every function should be at most 20 lines of code
• Function shouldn't depend on the global state but only on the arguments
• Every function is either general or app specific. Where general function is useful for other apps
• Every function that could be made general should be made general
• The interface to every function should be documented
• The global state should be documented by describing both semantics of individual variable and the global invariant

By appling that principle. He got a nice result:

• The code didn't contain serious bugs
• 95% of the code was in general functions !

His conclusion:

• Decomposing an app into a collection of general purpose algorithm and data structure make it robust
• General code grow with the grow of app size

His believe:

• In most desktop apps, the non-general code should be well under 1%

You can read his whole book Note on Programming, 2006 (free) he used to teach programming at Adobe. It's not about C++ and STL. It's about what his learn from his programming career.

Got my first vote on RefactorMyCode :)

RefactorMyCode.com is a quite fun place for developers. I found it yesterday morning and can't help playing with code there. It is a huge playground for every programming language: Ruby, PHP, JavaScript, Java, C/C++, C#, VB, Python, Perl, LISP, Erlang and even Bash.

My favorite is JavaScript. It's a dynamic, functional, prototype-base OO programming language. JavaScript is the language that teach me functional programming. I use Firefox, my favorite browser, combine with Firebug plugin to code and debug.

I got first vote for this refactor. It helps to increase my rank from #96 to #23.

If you have some freetime. Let visit RefactorMyCode.com, refactor other people code or post the code you don't know how to deal with there. People will help to improve it. Fast and Fun :))

Lập trình viên giỏi và đầu bếp giỏi

(Dịch từ http://amix.dk/blog/viewEntry/19328)

Một người đầu bếp giỏi dùng những nguyên liệu cơ bản nhất để tạo ra một món ăn ngon. Một người đầu bếp tồi cho dù có được những nguyên liệu tốt nhất vẫn tạo ra món ăn tồi. Cũng có những đầu bếp tạo ra những món ăn quá cầu kỳ (ví dụ như dùng quá nhiều nguyên liệu) hoặc có đầu bếp không chú ý tới vệ sinh và không trình bày món ăn sao cho đẹp mắt nhưng lại rất giỏi về việc phối hợp các nguyên liệu và gia vị.

Một vài mô tả về đầu bếp giỏi:
* Thức ăn của họ rất ngon
* Họ có thể làm đương đầu tốt với deadline và stress
* Thức ăn của họ được trình bày đẹp
* Món ăn đơn giản mà vẫn ngon

Khi xem chương trình nấu ăn trên truyền hình, bạn sẽ thấy có sự giống nhau giữa đầu bếp và lập trình viên. Lập trình viên dùng những nguyên liệu cơ bản (ngôn ngữ, công cụ, thư viện) và tạo ra chương trình. Sau đây là một vài ví dụ về sự tương đồng:
* Món ăn rất ngon nhưng trình bày kém => Chương trình chạy tốt nhưng việc thực thi rất tệ
* Nguyên liệu làm nên món ăn không tốt => Ngôn ngữ / thư viện làm nên chương trình dở tệ
* Người đầu bếp sử dụng 20 nguyên liệu cho một món ăn mà lẽ ra chỉ cần 4 nguyên liệu => Lập trình viên viết một phần chương trình mà nhẽ ra có thể dùng thư viện
* Người đầu bếp bỏ quá nhiều thời gian vào việc trình bày món ăn và quá ít thời gian vào việc nấu ăn => Lập trình viên bỏ quá nhiều thời gian vào việc làm cho code dễ nhìn và quá ít thời gian vào việc thực thi tính năng

Sự tương đồng này có thể nhận thấy ở một số phần mềm nổi tiếng:
* Facebook: Dùng những nguyên liệu cơ bản nhất (PHP+MySQL) và scale ứng dụng để phục vụ hàng triệu người dùng. Họ là những đầu bếp tài năng nhưng nguyên liệu của họ dở tệ.
* Universal feed parser: Tạo bởi Mark Pilgrim (nhân viên của Google). Phần mềm rất tốt này chỉ có 1 file với khoảng 3000 dòng lệnh. Đây là một ví dụ của một đầu bếp tài năng nhưng có những thói quen không tốt và trình bày không đẹp
* Django: Code, tài liệu và trình bày đều đẹp và đáng yêu

Để trở nên giỏi hơn nữa, bạn nên học tập theo cách những lập trình viên hàng đầu làm việc:
* Họ thực thi những chương trình đơn giản nhất có thể và không thể đơn giản hơn được nữa
* Họ sử dụng idioms (của ngôn ngữ lập trình) một cách thành thạo
* Họ viết code có tính nhất quán cao (ví dụ như cách đặt tên biến và hàm)
* Họ tổ chức chương trình rất tốt (không nhét tất cả vào một file)
* Họ bổ xung comments khi cần thiết
* Họ kết thúc công việc đúng hạn
* Họ tạo ra những chương trình mà các thành phần có sự dính kết và cao nhưng ít phụ thuộc vào nhau

Refactoring

What is refactoring?

"Refactoring is the art of safely improving the design of existing code. The purpose of refactoring is to make software easier to understand and modify".

(Refactoring, Martin Fowler, 1999)

"Rewriting, reworking and rearchitecting code is collectively know as refactoring. Refactoring your code (moving functions around and updating early decisions) is really an exercise of PAIN MANAGEMENT. Changing source code around can be pretty painful. Let face it! "

(The Pragmatic Programmer, Dave and Thomas, 1999)

Refactor early, refactor often

• At it's heart, refactoring is redesign.
• "Don't live with Broken windows".
• Don't live with bad design, wrong decision, poor code ...

(The Pragmatic Programmer, Dave and Thomas, 1999)

Why we need to do refactoring?

Increasing code value

• A significant fraction of our valuation is the state of our code base
• A low quality code base is a liability
• Microview: coding convention
• Macroview: program architecture
• Both microview and macroview are equal important

(YUI Theater — Douglas Crockford: “Quality” )

Paying off code and design bills

"If programmers got paid to remove code from software instead of writing new code, software would be a whole better place".

(Nicholas Negroponte, MIT, OLPC project)

Software development is like gardening, we need to take care of it everyday

"Rather than building construction, software is more like GARDENING. It's more organic than concrete. We constantly monitor the health of the garden and make adjustments as needed. Business people are comfortable with the metaphor of building construction but we're not building skyscrapers - we aren't constrained by the boundaries of physics and the real world. The gardening metaphor is much closer to the realities of software development".

(The Pragmatic Programmer, Dave and Thomas, 1999)

Refactor to make code more maintainable

maintaining code takes 80% of the time, writing new code only takes 20%. (YUI Theater — Nicholas Zakas: “Maintainable JavaScript”)

All Programming is Maintenance Programming

"we spend a large part of our time in maintenance mode, reorganizing and reexpressing the knowledge in our systems.Most people assume that maintenance begins when an application is released, that maintenance means fixing bugs and enhancing features. We think these people are wrong. Programmers are constantly in maintenance mode. Our understanding changes day by day. New requirements arrive as we're designing or coding. Perhaps the environment changes. Whatever the reason, maintenance is not a discrete activity, but a routine part of the entire development process."

(The Pragmatic Programmer, Dave and Thomas, 1999)

When should we refactor?

• Duplication (not DRY)
• Non-orthogonal Design
• Outdated knowledge
• Bad performance

(The Pragmatic Programmer, Dave and Thomas, 1999)

"When you have to add a feature to a program and the code is not structured in a convenient way to add the feature, first refactor the program, then add the feature"

(Refactoring, Martin Fowler, 1999)

Three strikes and you refactor

• The first time you do something, just do it
• The second time you wince at duplication, but you do the duplicate thing anyway
• The third time you do something similar, you refactor

(John Tobler's "Three Strikes" Refactoring Rule, see page 20 )

When should we stop refactoring?

Refactor to "good enough" software

• know when to stop
• we can't write perfect software

(The Pragmatic Programmer, Dave and Thomas, 1999)

Refactor to "maintainable code"

Maintainable code is:

• Understandable
• Intuitive (seem to be in a right place)
• Extendable
• Debuggable

(YUI Theater — Nicholas Zakas: “Maintainable JavaScript”)

How should we refactor?

"before start refactoring, check that you have a solid suite of tests. These tests must be self-checking. Change the program in small steps. If we make a mistake, it's easy to find th bug".

Refactoring cycle

• choose the worst smell
• select a refactoring that will address the smell
• apply the refactoring

(Refactoring, Martin Fowler, 1999)

Note: smell means "bad code", "select a refactoring" and "apply the refactoring" mean select and apply a refactoring method described in Martin Fowler's Refactoring book (extract method, move method, replace conditional with polymorphisms, .. for example).

The rhythm of refactoring

• test, small change,
• test, small change,
• test, small change,
• ......

(Refactoring, Martin Fowler, 1999)

What is bad smell?

I just list the most common ones

• Dupplication
• Long method
• Large class
• Long parameter list
• Devergent change
• .....

(Refactoring, Martin Fowler, 1999) Note: you can read refactoring book to find the approriate refactoring method for each bad smell. Read this nice lecture CMSC 433: Refactoring Still want to see more? Visit this link

Đứng lên coders :)

Lập trình viên ngồi quá nhiều. 8 đến 10 tiếng ở cơ quan, về nhà lại ngồi máy tính tiếp 2-3 tiếng. Một ngày có 24 tiếng mà ngồi đã mất nửa thời gian. Ha ha ha ....

Thế là tớ quyết định sẽ đứng và lập trình tại nhà. Lý do: ngồi nhiều hỏng cột sống, sau nay già khổ lắm :) May quá cái bàn làm việc có thanh ngang bên trên để máy in và các đồ lặt vặt. Tớ bỏ máy in xuống, dọn dẹp sạch sẽ. Sau đó mang em màn hình ra giường, hì hục lấy tốt vít lột hết chân tay rồi cột em cao lên như trong hình.

Còn một vấn đề nữa là làm sao để bàn phím và chuột đủ tầm cao khi đứng. Thử nghiệm 1: bỏ em case lên bàn, fail thảm thiết. Em case to quá, nặng quá, chắn hết chỗ, lại còn kêu phì phì nữa. Rồi mỗi lần nhét đĩa ra đĩa vô cũng bất tiện. Nhìn ngang ngó dọc phát hiện ra em loa Yamaha. Em này bị thằng cu tí (con mèo nhà tớ) cào cho tan nát cái màn chắn loa nên trông có vẻ đồng nát nhưng mà chất lượng ngon lắm đấy. Ông anh rể quý lắm mới để lại cho cơ mà :))

Em loa nằm ngang, để em bàn phím và em chuột trèo lên, thế là vừa tầm cao. Năm ngoái về thăm nhà, gạ mua được em bàn phím HHK của một anh đi Nhật về, ai dùng máy mình cũng cằn nhằn sao mà khó dùng thế, lại bé tí nữa chứ, ứ thích. Vậy mà bây h mới phát huy tác dụng đấy. Cái loa xinh xắn là thế mà cũng để vừa cả bàn phím và chuột. Ha ha ha ...

Đứng và dùng máy tính cũng có cái thú riêng của nó, thấy tự do và tập trung hơn. Tự do đung đưa và nhịp chân theo nhạc, tự do đi lại (không cần chuyển trạng thái từ ngồi sang đứng nữa). Tập trung hơn vì khi đứng phải thẳng lưng, mắt nhìn thẳng và chỉ tập trung vào màn hình. Khi ngồi có lúc nghẹo bên này, nghẹo bên kia, có lúc gác chân lên bàn nữa .. nói chung là ngả ngớn làm giảm sự tập trung. Ngoài ra đứng giúp tránh việc dùng máy tính quá lâu. Ối giời ơi, đứng được một tiếng là em chân em cẳng đã khóc không còn ra tiếng nữa. Phải giải lao 15, 20 phút cho hai em hồi sức.

Còn một tác dụng phụ nữa là tối ngủ rất ngon ... vì mệt. Ha ha ha ...

Bánh Big Macs vs. người đầu bếp tài năng

(lược dịch từ http://www.joelonsoftware.com/articles/fog0000000024.html)

Tại sao một số công ty IT lớn nhất lại trở nên dở nhất?

Có sự liên hệ gì nữa MacDonal’s (dây chuyền sản xuất Hamburger tệ nhất) và sự kiện trên?

Bí mật của bánh Big Macs là mọi chiếc bánh đều dở giống hệt như nhau. Một bí mật nữa là chỉ cần IQ của anh đần là đủ để tạo ra bánh Big Macs “dở giống hệt nhau trên toàn thế giới”. Nếu một chiếc Big Macs được rán 37 giây ở Mỹ, nó cũng được rán đúng 37 giây ở Singapore (đúng 37 giây, không hơn, không kém). Để tạo bánh Big Macs bạn chỉ cần tuân theo những luật cứng nhắc đó.

Những luật đó đã được thiết kế một cách cẩn thận bởi những con người thông minh (ở trường đại học McDonald’s Hamburger) sao cho những người bình thường nhất cũng có thể làm theo được. Những luật đó bao gồm tất cả quy trình tránh lỗi (failsafes) như là rung chuông nếu bạn rán bánh quá 37 giây. Hệ thống đó về cơ bản luôn giả sử rằng mọi người sẽ mắc phải rất nhiều lỗi.

Hãy so sánh một đầu bếp của McDonal’s, người luôn tuân theo luật một cách tuyệt đối với một đầu bếp tài năng. Đầu bếp tài năng không dập khuôn theo một cuốn cẩm nang nấu ăn nào hết. Anh ta không đo lường (rán đúng trong 37 giây chẳng hạn). Khi nấu ăn, bạn sẽ thấy thức ăn như nhảy múa dưới bàn tay người đầu bếp tài năng. “Chúng ta chỉ cần cho thêm một ít bột nêm vào đảo đều”, anh ta nói. “Hãy dải đều rau thơm lên trên món ăn nào”. Thế là xong, chúng ta có một món ăn tuyệt hảo!

Hiển nhiên là thức ăn của người đầu bếp tài năng ngon hơn rất nhiều so với bánh Big Macs. Có vẻ như là ngu xuẩn nhưng sẽ rất đáng giá nếu bạn đặt câu hỏi “tại sao?”. Tại sao một công ty nhiều tiền của, đa chi nhánh, có thể thuê những đầu bếp tài năng nhất lại không thể tạo được một bữa ăn ngon miệng?

Hãy tưởng tượng người đầu bếp tài năng quyết định mở cửa hàng ăn. Vì thức ăn của anh rất ngon nên cửa hàng vô cùng đông khách. Công việc kinh doanh hết sức thuận lợi nhưng cũng rất nhanh, anh ta nhận ra rằng nguồn thu nhập của cửa hàng không tăng hơn được nữa bởi một mình anh không thể tạo ra nhiều thức ăn. Vì vậy anh ta quyết định thuê thêm đầu bếp và mở thêm nhiều chi nhánh ở các thành phố khác.

Lúc này, vấn đề bắt đầu nảy sinh. Dân kỹ thuật chúng ta gọi là bài toán mở rộng (scalability problem). Khi bạn cố nhân bản một nhà hàng, bạn phải quyết định giữa việc thuê một đầu bếp tài năng (trong trường hợp này người đầu bếp được thuê sẽ muốn giữ phần lớn lợi nhuận của cửa hàng mới do anh ta tạo ra) và một đầu bếp trẻ tay nghề chưa cao và khách hàng của cửa hàng mới sẽ sớm phát hiện ra chất lượng thức ăn không tốt và không tới cửa hàng đó nữa.

Cách thông thường để giải quyết bài toán mở rộng là thuê một đầu bếp rẻ tiền và đưa cho anh ta một tập các luật cứng nhắc để anh ta có thể tạo ra thức ăn đủ tốt.

Vấn đề là nó không hoạt động như ta mong muốn. Có hàng ngàn thứ mà một đầu bếp nhàng nhàng không thể bắp chước hoặc làm giống hệt như một đầu bếp tài năng được.

Tổng kết

* Để làm được một việc thật tốt, chúng ta cần tài năng thực sự
* Nhân bản tài năng là cực khó
* Một cách để nhân bản tài năng là để cho những người tài tạo ra những luật mà người bình thường có thể làm theo
* Chất lượng của việc nhân bài tài năng như trên thường là thấp (big macs)

Bạn có thể thấy điều tương tự ở những công ty tư vấn IT. Bạn đã bao nhiêu lần từng nghe câu như thế này:

Tuấn rất không vui. Anh vừa thuê một công ty IT lớn xây dựng hệ thống hỗ trợ bán hàng. Những nhà tư vấn IT mà anh vừa thuê cứ mải mê nói chuyện về “Methodology” và tiêu tốn hết hàng trăm triệu đồng mà chẳng làm nên trò trống gì hết.

May mắn thay, Tuấn tìm được một lập trình viên trẻ và tài năng. Tay lập trình viên này xây dựng xong hệ thống trong một ngày với thù lao 200 nghìn và một tô phở. Tuấn rất vui. Anh giới thiệu tay lập trình viên này cho bạn bè của mình.

Chàng trình viên trẻ bắt đầu kiếm bộn tiền và nhanh chóng nhận ra rằng anh không thể làm hết khối lượng công việc được đặt hàng và liền thuê nhiều người để giúp việc. Những người giỏi có thể đòi quá nhiều cổ phiếu vì thế anh ta quyết định thuê cả những lập trình viên trẻ mới tốt nghiệp và đào tạo họ trong vòng 6 tuần.

Vấn đề là khóa đào tạo ngắn hạn không tạo ra những lập trình viên đủ tốt để giữ cho chất lượng sản phẩm đủ tốt. Vì thế, chàng lập trình viên liền tạo ra một tập các luật với mục đích là để giúp tạo giữ cho chất lượng sản phẩm không đổi. Sau 6 năm, tập luật ngày càng nhiều lên và nó trở thành 6 tập sách dầy được gọi là Methodology.

Sau vài chục năm, công ty nhỏ bé ngày nào đã trở thành một tập đoàn lớn. Rất nhiều nhân viên của tập đoàn này hằng ngày vẫn răm rắp tuân theo Methodology cho dù nó đã lỗi thời hoặc có một vài chỗ hoạt động không hiệu quả bởi vì họ không có thể nghĩ ra cách khác để hoàn thành công việc — vì họ không phải là những lập trình viên tài năng. Họ được thuê hàng loạt với giá thị trường. Đến lúc này, một lập trình viên trẻ tài năng khác xuất hiện và một chu kỳ mới lại bắt đầu.

Mọi công ty tin học đều muốn phát triển thật nhanh, nhanh hơn khả năng tuyển dụng được người tài. Các công ty đó phát triển dựa trên tầng tầng lớp lớp những luật và quy trình nhằm đảm bảo chất lượng đồng nhất. Nhưng hãy nhớ rằng, những luật đó chỉ hoạt động khi không có biến cố.

Bài học rút ra

* Người tài không muốn làm bánh Big Macs
* Hãy thận trọng với Methodologies
* Chỉ mở rộng khi tìm được người tài

Để thành công trong lập trình

(Lược dịch từ “Teach Yourself Programming in Ten Years” của Peter Norvig)
Công thức để thành công trong lập trình là:

- Yêu thích lập trình vì cảm thấy lập trình rất thú vị. Chắc chắn rằng lập trình đủ thú vị để bạn có thể tiếp tục luyện tập trong 10 năm

- Trao đổi (với những lập trình viên khác) và đọc mã nguồn quan trọng hơn nhiều so với bất kỳ cuốn sách hoặc khóa học lập trình nào.

- Chương trình là trọng tâm. Cách học tốt nhất là “vừa làm vừa học” (learning by doing). Ngưỡng cao nhất mà con người có thể đạt được trong một lĩnh vực không phụ thuộc vào kinh nghiệm tích lũy được (có quan điểm cho rằng khi một người làm việc quá lâu trong một lĩnh vực, họ không thể nâng cao trình độ hơn được nữa). Ngưỡng đó có thể được nâng lên kể cả với những người giàu kinh nghiệm bằng cách luôn cố gắng cải tiến. “Cách hiệu quả nhất để nâng cao trình độ là có một đề bài được định nghĩa tốt với mức độ khó phù hợp cho từng cá nhân, thông tin phản hồi, và cơ hội lặp lại và sửa chữa lỗi” (opportunities for repetition and corrections of errors).

- Học đại học (thường là 4 năm) hoặc học cao hơn nữa sẽ giúp bạn tìm được công việc đòi hỏi bằng cấp, và học tập còn giúp bạn hiểu sâu hơn về lĩnh vực theo học. Nhưng nếu bạn không thích trường học, bạn có thể đạt được kinh nghiệm cần thiết cần thiết cho công việc (bằng cách tự học). “Giáo dục về khoa học máy tính không giúp cho ai đó có thể trở thành lập trình viên lão luyện, nó giống như việc nghiên cứu cây cọ và màu vẽ không giúp cho ai đó trở thành một họa sỹ tài năng”. Tôi (Peter Norvig) đã từng thuê một lập trình viên chỉ học hết cấp 3, anh ta đã làm ra những phần mềm lớn và có đủ tiền để mua một hộp đêm cho riêng anh ta.

- Làm việc nhóm với các lập trình viên khác. Là người “giỏi nhất” trong một số dự án, là người “dở nhất” trong một số dự án khác. Khi bạn là người giỏi nhất, bạn thực hành khả năng lãnh đạo và truyền cảm hứng cho người khác bằng tầm nhìn của bạn. Khi bạn là người dở nhất, bạn học hỏi cách những người giỏi làm việc, và học cả những việc mà người giỏi không muốn làm (vì họ sẽ bắt bạn làm những việc đó).

- Tham gia những dự án với tư cách là người đến sau. Hãy hiểu chương trình viết bởi những lập trình viên khác. Hãy ngẫm nghĩ xem để hiểu chương trình do người khác viết thì cần có những thông tin gì và bổ xung thông tin đó (nếu thiếu). Suy nghĩ xem nên thiết kế chương trình thế nào để thuận tiện cho những người sẽ tiếp tục phát triển chương trình của bạn.

- Học ít nhất 6 ngôn ngữ lập trình. Bao gồm một ngôn ngữ hỗ trợ trừa tượng hóa lớp (class abstraction) như là Java hoặc C++, một ngôn ngữ hỗ trợ trừa tượng hóa hàm (funtional abstraction) như là Lisp hoặc ML, một ngôn ngữ hỗ trợ declarative specifiaction như là Prolog hoặc C++ templates, một ngôn ngữ hỗ trợ coroutines như là Icon hoặc Scheme, một ngôn ngữ hỗ trợ lập trình song song như là Sisal.

- Hãy nhớ từ “máy tính” trong cụm từ “khoa học máy tính”. Phải biết cần bao nhiêu thời gian để máy tính thực hiện một lệnh, đọc một word vào bộ nhớ (khi có hoặc ko có cache miss), đọc những words liên tiếp từ đĩa cứng, và tìm kiếm vị trí mới trên đĩa.

- Tham gia chuẩn hóa ngôn ngữ. Như là tham gia ANSI C++ committee, hoặc đơn giản hơn là quyết định xem coding style của bạn để lề (indentation) theo kiểu 2 ô trắng hay 4 ô trắng. Hãy học xem cái gì làm người khác lại thích ở một ngôn ngữ lập trình, họ thích đến mức nào và nếu có thể tìm hiểu vì sao mà họ thích.

- Hãy sử dụng những chuẩn bạn học được (một cách thích hợp) càm sớm càng tốt.