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

[luffy]

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

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

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

[cmdOptionKana]

算法最难…… 但话说回来，编程几乎可以说是等于算法。

[Zenyet]

底层的感觉难。。

[Caturra]

电磁场与微波技术，没有之一
（不算歪楼吧？）

[xiaofan305]

有些面试官的问题最难

[devoter]

因人而异，技术难度高的就难吧

[pengtdyd]

算法最难

[coconut5200]

不会的觉得难，会的觉得简单

[Richard14]

其实都是隔行如隔山的问题，真正处理业务代码都不难，用到数学知识觉得难了，学会了又不难了。另外越底层越难显然是误解，以前学生时代导师做 IC 设计，IC 底层大都执行一些相当单纯的逻辑，在该视角的工程师来看是不复杂的。同理，你做系统级编程会发现，系统的基础组件也在处理很死板的逻辑。写业务代码的不了解所以就感觉难了

[frisktale]

对我来说应该是 fsharp 吧，完全无法理解。

[bruce0]

@Richard14 确实有这方面的因素, 以前觉得做游戏挺难的, 主要是不了解游戏的运行原理, 毕业后去了游戏公司, 感觉做游戏服务器也没啥, 和写 web 后台差不多, 就是一个用 HTTP 另一个用 socket. 但是有些东西是了解后还是觉得难, 比如数学, 感觉高数就是我的天花板了, 尝试听过几次傅里叶变换, 完全听不懂在说啥, 当然还是一些复杂的算法, dp, 神经网络这些没去了解过 觉得应该也不简单

[Bingchunmoli]

最难的莫过于 layui

[nicevar]

工作上的还能应付，上学时的信号与系统是真的难

[ffxrqyzby]

觉得难得是没有参考, 完全自己设计, 需要提前学习大量知识, 模型, 尝试改进

[smdbh]

不知道的领域都难

[darksword21]

模电，个人向

[cssk]

模电，高频，通信原理

[feather12315]

没有头绪的最难，有头绪的只是复杂程度。

有头绪但没接触过，复杂度高，难点在于不知道怎么找资料、找怎么资料。
有头绪接触过的，只是看花费多少时间罢了。

[dfkjgklfdjg]

WebGL ，看到这个需求，脑子里想的都是提桶跑路。

[a852695]

信息与系统是大学课程中最难的，用算法去解决干扰的问题，涉及到很复杂的底层处理逻辑，非常细节和微妙；
后来工作了基本上都是应用型的内容，没有深挖某些算法，感觉整体上是没有当年课程复杂。

[lsdvincent]

跨平台桌面应用

[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 不理解