你觉得哪些技术点觉得难，哪些觉得简单

[luffy]

每个人的背景，基础，处境都不太一样。 都来说说，自己觉得哪些技术比较难，哪些又相对容易。

觉得难的话，大概可能表现就是：要花很久的时间，很费脑子，随便看个文档都要搞个大半天，或者看别人的代码，完全看不懂之类。

觉得简单的话，大概可能的表现：看文档或者教程特别顺利，很容易就理解，学起来特别快，很容易上手。

[lscho]

感觉学会的都非常简单，没学会的都非常难

[agagega]

所见即所得编辑器。思路可能不难，但想想细节太可怕了。

[AX5N]

难，怎么理解。指的是必须要堆人力的复杂，还是想出解决思路所需要花费的时间精力？

[cpper]

图形学挺难的，需要经验，需要不停的学习

[CoderGeek]

命名 缓存

[Building]

什么东西研究到了最后都会很难，只是门槛有高低罢了

[dcoder]

最难当然是看别人写的垃圾代码

[xiaotianhu]

@Richard14 操作系统也是在处理业务吧,只不过是处理计算机相关的业务,所谓"底层"业务

当然还是觉得算法难,动归到现在也没弄明白.主要是算法不是靠自己就能想明白的,业务逻辑大部分都可以.业务太复杂了还可以简化,总归能做出来.
但是数学不会, 不会就是不会.

[agriphar]

@lscho 这个说的在理
其实大部分人都是以自我为中心的，
我学会了的东西都是 so easy ，你不会是你蠢
我学不会的东西，要么是太难了，非正常人类能够理解的；要么就是教的人太蠢，没把我教会

[jack778]

@Bingchunmoli 何出此言

[jack778]

你不懂的是最难的

[24bit]

会的不难，难的不会

[hhjswf]

就我们开发人员来说，做编译器相关应该是天花板吧

[NoString]

模电 编译原理 大学时期完全学不明白的课程

[mmmfj]

楼上都说信号与系统，我也投一票

[Richard14]

@xiaotianhu 所以说就是需要数学时不会就感觉难，最后学会了又感觉没那么难了

[secondwtq]

这要说的话肯定是“架构编程”最难，这个“架构编程”指的是“决定你的程序该干什么事情”，虽然程序也不一定是，甚至一般不是你写的，但是哪怕写得烂也没关系，这一层的东西直接决定了项目的前途。换句话说就是战略级别的“对人编程”。
不过这个一般是姓 C 的人考虑的事情，跟大多数人没啥关系。要说工程层面的话，我认为是“know-how”，先帝懂王普的时代，这个词经常出现在大明的新闻里，不知道还有没有人有印象。
各种领域的原理、公式、算法，这些写在教科书、论文里的东西，正常人只要肯下功夫，大多数都能搞懂。但是看完之后再用到 non-trivial 的项目里面经常会发现和书上写得不完全一样，这才是真傻眼的时候。
举个例子吧，比如前端做个页面效果，虽然做完交差了，但是自己看着总“差那么一点意思”，怎么折腾都调不好，虽然别人可能不会在意，但是事后想起来总有一种便秘的感觉。前端库很多，资料教程很多，你技术都掌握了，但是就 TM 差这么一点 ...

其实可能就是哪一组参数不太合适的问题，但是怎么定位到问题？我找到了之后又该怎么调？
类似的例子还有很多，比如为啥某某软件很流畅，某某就很卡；挑个手机经常会看到什么屏幕 /摄像头 /续航的“调校”，手机是高科技产品，那你 TM 从技术的角度给我解释下这个“调校”是啥；基础算法大家都会，项目里面的实际问题需要设计新算法该咋办；一个 ML 的项目，选啥模型，怎么调 ...
这个也不局限于软件领域，做个饭都有刀工、火候、调味的讲究，同一所学校，有的人平常看着普普通通考试必然前三，有的人天天做题成绩也就那样。不过情况都是一样的，同样的工具，别人的结果比你的更好，你还不得不服。

所以某些公司喜欢折腾什么“XXX 原班人马打造”——人家之前搞出来过的 XXX 大家都知道，都能抄，但就是抄不出那个“味儿”，偏偏最关键的就是那个“味儿”。这就是我对“know-how”的理解，写在书上的都不是最难的，没写上去的，或者没法写上去的才最难。

[killeder]

不方便验证和推导的最难

[Bingchunmoli]

@jack778 不走规范，自成体系，对新手不友好，文档太乱。 我朋友学会了，回头找看过的文档，就又是找半天，因为学了 layui 又对 ES6 不理解