如果当初学习编程时能有人给我这些忠告该多好

http://blog.jobbole.com/52761/  原文链接

伯乐在线导读： Cecily Carver  是多伦多的一位程序媛，和 Jennie Faber 一起创办了一个游戏制作工作室。她喜欢歌剧、舞蹈和弹钢琴。Cecily 在这篇文章分享她在编程道路上的所感所想，给出很多值得思考的编程箴言以及一些思想误区，比如在你学习编程之前思考一下你的目标、编程不是什么神秘的东西、坚持比方法更重要等，可以让我们在编程路上少走一些弯路，从而有更多的时间学习技术让自己变的越来越强大。

 

在你学习编程之前思考一下你的目标

要知道编程大多时候就是在创造，当你有最终目标感时道路会更加的清晰。如果你的目标是“学习编程”而不是更具体的学习哪种程序及如何让你的生活更好，那么你可能会发现这不过是一次令人沮丧的实践。

我有点惭愧地承认我学习计算机科学的部分动机是为了证明我聪明，及我想干“聪明人”的工作。我也喜欢思考数学和理论（《哥德尔、艾舍尔、巴赫:集异璧之大成 》这本书在我易受影响的年纪进入了我的脑海），编程是一个不错的选择。当然这并不足以使我坚持这么久，真正让我坚持的是我发现了编程可以将科技与我真正喜爱的东西（如音乐和文学）连接到一起。

那么，你想要写什么？网站？游戏？iPhone应用？致富的商业软件？交互艺术？你是想让老板印象深刻？或你是想自动执行一些乏味的任务以让你有更多的时间看水獭照片吗（译者注：这里应该指有更多的时间看外面的风景）？也许你只是想更具有就业竞争力，因为可以将技术流行词添加到简历，或者只为了实现你的教育需求。所有的这些都是有价值的目标，你得确定知道哪个才是你想要的目标然后相应的去学习吧。

 

没有什么神秘的东西

编程跟其他东西一样，是一门技术。跟语言学习一样，有需要掌握的语法和词汇；跟数学一样，有解决特定类型问题的流程方法；像各种工艺和艺术创作一样，有技术、工具以及人们经年累月发展起来的最佳实践方案，专门解决各种不同类型的任务，你可以自由的使用、修改或弃之不用。

Joel Spolsky（一个非常聪明的家伙，他的一些其他的观点我也很喜欢且频繁认同）曾论断：在有着“程序员真正思想”的人和缺乏该领域成功所必备的知识能力的任何人之间有一条很清晰的界限。据他所言，这条界限包括指针和递归（这里和这里有为感兴趣的人提供的入门资料）。

我在学校学习过指针和递归，当我掌握了过后，大脑发生了一次愉悦的波动—这种智力快感使我想要将学习计算机科学排在第一位。但是，除了课堂练习外，其他时候用指针和递归来完成任务的次数就相对较少了。后来在一次次的帮助他人学习时，我发现大家根本不用掌握这两项技术中的任何一项就可以完成一些非常有趣有益的项目。

想知道或怕知道自己是否“足够聪明”其实没什么意义。当然，你的任务越复杂越深奥，你需要掌握的知识水平就越高。不过这也同样适用于其它的任何领域。除非你计划完全靠编程生活，否则你可能并不需要成为一个掌握递归的天才来完成你的任务。

 

第一次运行一般不成功，第二次第三次也可能不成功

当你第一次学习编程时，你会很快遇到这样的特殊经历：你认为已经按照所想的完成了每一件事，检查了一遍又一遍，却发现仍然运行不了（出现bug了）。你完全不知道该从哪开始修复它，错误信息（如果你够幸运只有一个的话）好像在说“fuck you”。你可能就此放弃，心里想着自己恐怕永远也解决不了了，那么你就不适合干编程这行。我一开始就有这种感觉，尝试着用C++写一个程序然后运行它，却只得到“segmentation fault”这个麻烦。

但是这种经历对所有不同技术水平的程序员来说都太普遍了，这绝对与你的智商、技术悟性或者是否适合干编程这行没有任何关系。初学者会碰到这样的情况，经验丰富的程序员也会碰到这种事情。主要的区别就在于你如何应对这种情况。

我发现新手程序员和有经验的程序员之间一个很大的不同点，就在于一种信念（指有经验的程序员所具有的信念）：相信事情出错是因为逻辑原因并且一定能找出来；相信bug可以修复；相信有办法实现目标。从“运行错误”到“运行正确”的过程可能不是很明显，但是有耐心你通常都可以找出问题。

 

总是有人说你做错了

括号应该另起一行；括号应该放在同一行；用tab键来缩进，但是tab很邪恶哟；你应该使用存储过程，但实际上你又不应该用它们；你应该总是对代码进行注释，但是好代码不需要注释。

基本上对于一个特定的问题总是有许多不同的方法，没有所谓单一的“正确方法”。许多程序员都非常擅长倡导他们首选或偏爱的方法，但是那并不意味着这是“唯一正确的方法”。如果与人们面对面争论后告诉我：我是错的，那么我也会尽力搞明白是否他们就一定是正确的，这是我早期职业生涯比较重要的一个方面。

如果你在一个小组里与其他人一起编程的时候，肯定会有人总是对你做的东西指指点点，有时候他们说的的确是正确的，但是总是值得去探究下看你是否真的“做错了”。但有时候他们完全就是胡扯或只是再次引起了一场古老而没有意义的争论，那么你最好适应这样的情况然后忘掉它吧。另一方面，如果你个人喜欢这种古老且没有意义的争论的话（比如语法狂，一直看着大家），那么不用多说，你来对了地方。

 

总是有人说你不是一个真正的程序员

HTML不属于真正的编程；如果不用vi的话，你就不够严肃认真；真正的程序员要懂C；真正的程序员不用Windows；有些人从来都学不会；你不应该学习编程； 你不是一个计算机程序员（但是我是）。

“编程”对不同的人有着非常不同的含义，而且现在看起来与过去也不太一样。有趣的是，大家都知道，工具、包和框架能够让初学者甚至受过训练的开发者更快更容易的做开发，但正因如此这些东西往往被贴上“不是真正的程序员”的标签。（看：“Return of the Real Programmer”）

其实这背后隐藏的是一种害怕心理：“如果“任何人”敢自称他们自己是一个真正的程序员，那么这篇文章的题目就没有意义了（译者注：也就是都不敢自称自己是真正的程序员）。但是我认为这种保守行为是非常具有破坏性的。

使用那些让你最容易开发的工具吧。如果这意味着你的游戏是用Stencyl 或者GameMaker做的，而不是自己从头开始写的，没关系啊。如果你首次编程用的是HTML或者Excel宏，也OK啊。只要你能坚持下去就行。

当你越来越舒服的时候（没任何挑战力），你会自然的开始找出那些工具受限的不足的（而不是有帮助的）地方接而寻找功能更加强大的工具，但是大部分情况，很少有人会去看你的代码或问你用什么工具—你用这些工具实现了什么功能才是关键。

 

忧虑所谓的“极客声誉(geek cred)”相当于慢性自杀

如前所述，我过去（尤其在学校）一度非常担心从我的穿着，我的讲话，我选择的阅读资料，甚至我的软件定制选项是不是证明了自己“不是一个真正的极客”（不是真正的极客貌似就没啥资格进入技术社区），这严重消耗了我的精力，后来我决定完全不考虑这些东西后我的技术更强了（译者注：与其花时间搞那些没意义的东西不如多学点技术，这样你的技术就会越来越强）。

你需要谨记一点：你擅长编程的能力与你到底有多适应各种极客亚文化没有一丁点关系。如果你内心深处知道自己永远都不会适应这些亚文化（而因此焦虑的话），那就需要加倍的记住了。你为了证明自己所浪费的精力应该用来做真正有有意义的事情，并且就算你是一名无可争辩的极客，眼窝中流露中可信赖的光芒，那么也请记住：当你评价其他人的信誉水平时，也并不意味着你认为的就一定对，一定是事实。

 

坚持比方法更重要

我们永远不缺像学习编程的“正确”或“最佳”方法这样的文章，其实还有很多潜在的方法。你可以从一本书或通过完成互动练习或通过调试其他人所写的东西来学习概念。当然，在你第一次学习的时候有许多的语言供你选择，每种语言都有相应的宣传和倡导。

关于“自学编程”流程和讲习班的一个常见的抱怨就是：一开始你会很愉快的轻松度过初级材料的学习，然后会越来越困难，这时你就会很快走上陡峭的学习曲线。你知道如何在页面上打印输出一些文本行，但是你不知道从哪开始进行一个“真正的”有用的项目。你可能感觉你只不过遵循了一些指南而没有真正的掌握，然后你可能就会指责学习资料。

当你到了这一步后，大部分可用的教程和在线资源都不是那么有用了，因为他们已经让你成为一名有经验的程序员了。然后困难进一步加剧为这样一个事实—“你不清楚自己还有哪些不知道的东西”，而且试图搞清楚你下一步到底要学习什么本身就是一个难题。

不管你遵循的是什么“编程”方案，冲破这堵墙的唯一方法就是持之以恒。这意味着你要持续的尝试新东西，学习更多的知识，并且一步步的搞明白怎么去开发你的项目。如果你非常清楚自己为什么要将编程放在首位的话，最后你也非常有可能成功。

如果你坚持一点一点的铺砖，可能会花费很长时间才能得到一道墙，但是最终你还是会得到。这时候我先前提到的信念就派上用场了。如果你相信随着时间和耐心，你可以完成整个编程任务，那么到时候你肯定会达成所愿的。

https://medium.com/learning-to-code/565fc9dcb329 英文链接

Things I Wish Someone Had Told Me When I Was Learning How to Code

And what I’ve learned from teaching others

• Cecily Carver in Learning to Code

Before you learn to code, think about what you want to code

Knowing how to code is mostly about building things, and the path is a lot clearer when you have a sense of the end goal. If your goal is “learn to code,” without a clear idea of the kinds of programs you will write and how they will make your life better, you will probably find it a frustrating exercise.

I’m a little ashamed to admit that part of my motivation for studying computer science was that I wanted to prove I was smart, and I wanted to be able to get Smart Person jobs. I also liked thinking about math and theory (this book blew my mind at an impressionable age) and the program was a good fit. It wasn’t enough to sustain me for long, though, until I found ways to connect technology to the things I really loved, like music and literature.

So, what do you want to code? Websites? Games? iPhone apps? A startup that makes you rich? Interactive art? Do you want to be able to impress your boss or automate a tedious task so you can spend more time looking at otter pictures? Perhaps you simply want to be more employable, add a buzzword to your resume, or fulfill the requirements of your educational program. All of these are worthy goals. Make sure you know which one is yours, and study accordingly.

There’s nothing mystical about it

Coding is a skill like any other. Like language learning, there’s grammar and vocabulary to acquire. Like math, there are processes to work through specific types of problems. Like all kinds of craftsmanship and art-making, there are techniques and tools and best practices that people have developed over time, specialized to different tasks, that you’re free to use or modify or discard.

This guy (a very smart guy! Whose other writings I enjoy and frequently agree with!) posits that there is a bright line between people with the True Mind of a Programmer and everyone else, who are lacking the intellectual capacity needed to succeed in the field. That bright line consists, according to him, of pointers and recursion (there are primers here and here for the curious).

I learned about pointers and recursion in school, and when I understood them, it was a delightful jolt to my brain — the kind of intellectual pleasure that made me want to study computer science in the first place. But, outside of classroom exercises, the number of times I’ve had to be familiar with either concept to get things done has been relatively small. And when helping others learn, over and over again, I’ve watched people complete interesting and rewarding projects without knowing anything about either one.

There’s no point in being intimidated or wondering if you’re Smart Enough. Sure, the more complex and esoteric your task, the higher the level of mastery you will need to complete it. But this is true in absolutely every other field. Unless you’re planning to make your living entirely by your code, chances are you don’t have to be a recursion-understanding genius to make the thing you want to make.

It never works the first time

And probably won’t the second or third time

When you first start learning to code, you’ll very quickly run up against this particular experience: you think you’ve set up everything the way you’re supposed to, you’ve checked and re-checked it, and it still. doesn’t. work. You don’t have a clue where to begin trying to fix it, and the error message (if you’re lucky enough to have one at all) might as well say “fuck you.” You might be tempted to give up at this point, thinking that you’ll never figure it out, that you’re not cut out for this. I had that feeling the first time I tried to write a program in C++, ran it, and got only the words “segmentation fault” for my trouble.

But this experience is so common for programmers of all skill levels that it says absolutely nothing about your intelligence, tech-savviness, or suitability for the coding life. It will happen to you as a beginner, but it will also happen to you as an experienced programmer. The main difference will be in how you respond to it.

I’ve found that a big difference between new coders and experienced coders is faith: faith that things are going wrong for a logical and discoverable reason, faith that problems are fixable, faith that there is a way to accomplish the goal. The path from “not working” to “working” might not be obvious, but with patience you can usually find it.

Someone will always tell you you’re doing it wrong

Braces should go on the next line. Braces should go on the same line. Use tabs to indent. But tabs are evil. You should use stored procedures, but actually you shouldn’t use them. You should always comment your code. Butgood code doesn’t need comments.

There are almost always many different approaches to a particular problem, with no single “right way.” A lot of programmers get very good at advocating for their preferred way, but that doesn’t mean it’s the One True Path. Going head-to-head with people telling me I was Wrong, and trying to figure out if they were right, was one of the more stressful aspects of my early career.

If you’re coding in a team with other people, someone will almost certainly take issue with something that you’re doing. Sometimes they’ll be absolutely correct, and it’s always worth investigating to see whether you are, in fact, Doing It Wrong. But sometimes they will be full of shit, or re-enacting an ancient and meaningless dispute where it would be best to just follow a style guide and forget about it.

On the other hand, if you’re the kind of person who enjoys ancient but meaningless disputes (grammar nerds, I’m looking at you), you’ve come to the right place.

Someone will always tell you you’re not a real coder

HTML isn’t real coding. If you don’t use vi, you’re not really serious. Real programmers know C. Real coders don’t do Windows. Some people will never be able to learn it. You shouldn’t learn to code. You’re not a computer programmer (but I am).

“Coding” means a lot of different things to a lot of different people, and it looks different now from how it used to. And, funnily enough, the tools and packages and frameworks that make it faster and easier for newcomers or even trained developers to build things are most likely to be tarred with the “not for REAL coders” brush. (See: “Return of the Real Programmer”)

Behind all this is the fear that if “anyone” can call themselves a programmer, the title will become meaningless. But I think that this gatekeeping is destructive.

Use the tools that make it easiest to build the things you want to build. If that means your game was made in Stencyl or GameMaker rather than written from scratch, that’s fine. If your first foray into coding is HTML or Excel macros, that’s fine. Work with something you feel you can stick with.

As you get more comfortable, you’ll naturally start to find those tools limiting rather than helpful and look for more powerful ones. But most of the time, few people will ever even look at your code or even ask what you used — It’s what you make with it that counts.

Worrying about “geek cred” will slowly kill you

See above. I used to worry a lot, especially in school, about whether I was identifying myself as “not a real geek” (and therefore less worthy of inclusion in tech communities) through my clothing, my presentation, my choice of reading material and even my software customization choices. It was a terrible waste of energy and I became a lot more functional after I made the decision to let it all go.

You need to internalize this: your ability to get good at coding has nothing to do with how well you fit into the various geek subcultures. This goes double if you know deep down that you’ll never quite fit. The energy you spend proving yourself should be going into making things instead. And, if you’re an indisputable geek with cred leaking from your eye sockets, keep this in mind for when you’re evaluating someone else’s cred level. It may not mean what you think it does.

Sticking with it is more important than the method

There’s no shortage of articles about the “right” or “best” way to learn how to code, and there are lots of potential approaches. You can learn the conceptsfrom a book or by completing interactive exercises or by debugging things that others have written. And, of course, there are lots of languages you might choose as your first to learn, with advocates for each.

A common complaint with “teach yourself to code” programs and workshops is that you’ll breeze happily through the beginner material and then hit a steep curve where things get more difficult very quickly. You know how to print some lines of text on a page but have no idea where to start working on a “real,” useful project. You might feel like you were just following directions without really understanding, and blame the learning materials.

When you get to this stage, most of the tutorials and online resources available to you are much less useful because they assume you’re already an experienced and comfortable programmer. The difficulty is further compounded by the fact that “you don’t know what you don’t know.” Even trying to figure out what to learn next is a puzzle in itself.

You’ll hit this wall no matter what “learn to code” program you follow, and the only way to get past it is to persevere. This means you keep trying new things, learning more information, and figuring out, piece by piece, how to build your project. You’re a lot more likely to find success in the end if you have a clear idea of why you’re learning to code in the first place.

If you keep putting bricks on top of each other, it might take a long time but eventually you’ll have a wall. This is where that faith I mentioned earlier comes in handy. If you believe that with time and patience you can figure the whole coding thing out, in time you almost certainly will.