「随笔」基于当下的思考

  马德,说好的技术blog,变成日记本了。。。

  下午的时候莫名其妙的感到很颓废,因为自己的不够强大感到忧虑和危机感十足。现在每每行走在技术的道路上,常觉得如履薄冰,如芒在背。

  上大学之前和现在的心态其实差别挺大的,视野的开阔远远不止局限于自己的脚下。不过,这里的「上大学之前」只是一个时间描述词,并不觉得大学是最适合学习的地方,我很失望。

  世界上的人无论性别,区域,宗教,兴趣爱好,总可以在互联网上找到志趣相同的人,总是可以不断打破自己的常识与惯性思维。总是有在相同领域比自己更强的人,挺好的。

  关于知识的更新。之前总是鼓吹python的强大和「非官方性」,几乎没有学校开办python学习的课程,但是今天晚上看到mooc网上有一位北理工的副教授开的python系列课程,现在正在讲python数据处理,爬虫系列早已讲完了,之后还有pygame之类的课程……其实从课程内容的新颖角度上来说,这些内容并不是最新的,已经进行了相当长时间的演变了(20多年)。但是随着技术的演进,现在大学教授的计算机语言一定会被淘汰的,技术的目光始终会聚焦在前沿的技术上。之前总是觉得前沿技术与自己无关,现在才意识到自己也可以在前沿科技的领域做些什么,嗯,做些什么,有些工程受限于当代的整体科技水平,但总是可以做些什么的。

  机器学习等总有一天会走下神坛,变成中国大学生泛泛而谈的东西,在此之前,需要有人在这些领域深耕。其实我总觉得,能被中国大学生社团利用的技术,大多进入门槛比较低,但能实现很多任务。就像神州大陆散布的令微软也无奈的windows系统,扮演着骡子的角色。

  关于创业,既然说开了,那索性多说一些。我一直对大学生创业很反感,跟社会风气有关。但我又对技术驱动的创业公司抱有一点幻想。所以也在了解、尝试和构想这件事,当然,由于性格缺陷(今年我要改变这一点)许多项目,止于幻想。下面贴一段今天在「道哥的黑板报」公众号的分享中看到的话(我对道哥了解不多,只知道中科大少年班毕业,之前在支付宝安全团队工作,后来创业,被支付宝收购后,现在又在支付宝负责安全服务,主要产品有“云盾”):

  

  

  如果不是已经掌握有超出时代五到十年的技术,再跑出去创业,那么,我想大多数人创业,都仅仅只是在已有的技术体系里做做改进,也许有商业模式的创新,但那和技术无关。
  

  因此对于一些热血的技术青年来说,一个很残酷的事实就是,如果你跑去创业,就会承受很大的业务压力,迫于业务压力和生存压力,很可能就无法再专注的做技术的钻研了。如果既想创业又想做最酷的技术怎么办?在我看来只有一个解法:认准一个代表未来的方向,靠融资的钱烧下去,不成功就成仁。这是很需要勇气的。

  讲了这么多,会发现做一个成功的创业者真的很不容易,需要有一个愿意跟着跳悬崖的团队,要有一颗磨灭了人性的冷酷的心和足够的领导力,要能画大饼会忽悠站上讲台不哆嗦,要交游广阔千杯不倒还不能迷失本性,最好还能有身经百战的丰富经验。这真的不是一个人能随随便便做到的,想打造具备这些条件的团队也绝非一朝一夕的事情。
  

  我讲这些,不是为了给创业者泼冷水,因为想创业的热血小青年是很奇怪的人,把困难给他们讲的越艰巨,他们会越兴奋,就想着去经历一次,恰如当年的我。
  

  我只是想告诉你们,如果你们现在不具备这些条件,却一定要去创业,那么无非就两种结局,要么倒在路上(或者半死不活),要么改变自己成为这样的人。而对于后者,改变的过程必然是痛苦的,甚至是痛不欲生的。所有想创业的人,先想想自己是不是要成为这样的人,是不是要过这样的生活。想明白创业后,自己失去的是什么。

  对于在做创业准备的人,我送给你们四个字 — 「厚积薄发」。积累再厚,真到创业的时候,都会觉得不够用。
  

  最后,还有一句很喜欢的话,忘了出自哪里了,也送给你们:

 

  「这个世界是不公平,但还没有不公平到让有能力的人无法出头的地步。」

    

    宿舍甚吵,心神难安,夜已深,还是睡了。

    暂时是个废柴了,不过也只是暂时吧。

时间: 2024-10-17 04:23:47

「随笔」基于当下的思考的相关文章

从「集装箱」思考Docker风潮

从「集装箱」思考Docker风潮 -- Docker潮流下的赢家策略 By 高焕堂 (台灣Docker聯盟 主席) 2015/02/20 前言 在许多革命性转折里,经常出现集装箱的身影:它就像幸运草一般,总是带来许多幸福和财运.现在Docker风起云涌,再现集装箱身影,如果开放视野.大力支持它,持续发挥它的潜能和力量,则幸运草就会出现在我们身旁了. 由于Docker集装箱带来的商机,其最直接的受益者是软件管理者(或称维运者),例如软件测试工具业者.测试人员等.因此在今天,不论您是开发者或是维运者

技术人员应对「考核」的一些思考

来这个公司实习已经半年多了,在年前经历了一次年终考核,最终对我的工作的评级是 C(及格-符合当前职位的工作),让我不禁思考自己在项目中的一些工作的问题,为什么我是C?是我做的不够好吗?或者说在哪里做的不够好? 从考核流程来看,基本上是 CTO 与 Team Leader 对团队成员的「年终总结与次年工作计划」进行Rank,个人狭义的认为「考核」的主要支持材料就是这个总结了. 他山之石 其他公司是怎么考核的呢?说实话我也不太清楚,刚入行,只能通过搜索了解,在网上了解到有以下几种:发精品博客.发论文

大数据和「数据挖掘」是何关系?---来自知乎

知乎用户,互联网 244 人赞同 在我读数据挖掘方向研究生的时候:如果要描述数据量非常大,我们用Massive Data(海量数据)如果要描述数据非常多样,我们用Heterogeneous Data(异构数据)如果要描述数据既多样,又量大,我们用Massive Heterogeneous Data(海量异构数据)--如果要申请基金忽悠一笔钱,我们用Big Data(大数据) 编辑于 2014-02-2817 条评论感谢 收藏没有帮助举报作者保留权利 刘知远,NLPer 4 人赞同 我觉得 大数据

为什么说产品经理要有「傻瓜」的心态?

摘要 : 我最早听到类似的说法并不来自于张小龙,而是一本书.书的名字叫做<像外行一样思考>,作者是美国卡耐基·梅隆大学(CMU)的计算机科学和机器人研究所的金出武雄教授.金教授的学术固然在同行眼里高山仰止,行文也极为流畅.关于写作,他的观点是,无论写科普还是论文,都要像创作小说那样写出引人入胜的独特观点.这一点和 MacTalk 秉承的写作原则一脉相承. 微信之父张小龙曾经在「微信背后的产品观」里讲到:「产品经理要有傻瓜心态」.这里的傻瓜并不是真傻,而是一种外行心态.张小龙说,自己要经过5-1

「译」一起探讨 JavaScript 的对象

「译」一起探讨 JavaScript 的对象 原文地址:Let's explore objects in JavaScript 原文作者:Cristi Salcescu 译文出自:阿里云翻译小组 译文链接:github.com/dawn-teams/- 译者:灵沼 校对者:也树,眠云 一起探讨 JavaScript 的对象 对象是多个属性的动态集合,它有一个链接着原型的隐藏属性(注:__proto__). 一个属性拥有一个 key 和一个 value . 属性的 key 属性的 key 是一个唯

过去这几十年,分布式系统的「数据一致性」精华都在这了!

阅读目录 为什么需要事务 事务的来源 分布式系统中的事务问题 分布式事务的解决方案 结语 暂时还未涉及的园友们,可以收藏防身哦~ 本文是本系列的第三篇.与前两篇<不知道是不是最通俗易懂的<数据一致性>剖析了>.<烦人的数据不一致到底怎么解决?——通过“共识”达成数据一致性>形成完整的「数据一致性」合集. 一.为什么需要事务 如果说「共识」解决的是「水平」问题,那么「事务」解决的是「垂直」问题.是如何让一条绳上的蚂蚱共同起舞? 事务只是一个计算机术语,而事务的体现形式其实

从 Spring Cloud 看一个微服务框架的「五脏六腑」

原文:https://webfe.kujiale.com/spring-could-heart/ Spring Cloud 是一个基于 Spring Boot 实现的微服务框架,它包含了实现微服务架构所需的各种组件. 注:Spring Boot 简单理解就是简化 Spring 项目的搭建.配置.组合的框架.因为与构建微服务本身没有直接关系,所以本文不对 Spring Boot 进行展开.另外本文有一些例子涉及到 Spring 和 Spring Boot,建议先了解一下 Spring 和 Spri

分布式系统「伸缩性」大招之——「水平&amp;垂直切分」详解

如果第二次看到我的文章,欢迎右侧扫码订阅我哟~  ?? 本文长度为5389字,建议阅读14分钟. 坚持原创,每一篇都是用心之作- 没想到这篇文章写了这么长,一时半会没消化完的话,可以收藏一下先. 这是「伸缩性」章节的第四篇,先给新来的小伙伴们简单回顾下前三篇的内容. 做「伸缩性」最重要的就是先做好「无状态」,如此才可以随心所欲的进行横向“扩展”,而不用担心在多个副本之间切换会产生错乱.<分布式系统关注点——「无状态」详解>聊的就是这个. 不过,就算做好了横向扩展,本质上还是一个“大程序”,只是

程序员与新技术之间的「爱」与「恨」

我们大部分做技术的,对新技术是又爱又恨. 爱的是他能让枯燥反复的工作重新获得新鲜感. 恨的是新技术太多了,学不动啊. 真到了实际要运用的时候,不同人对待新技术的态度相差很大,有的看上去很积极,有的又看上去很排斥. 一般来说,技术团队的管理者往往是“排斥者”,而团队的成员是“拥抱者”的概率居多. 看看下面这个景象是不是很熟悉? 程序员小明:老大,XX系统太乱了,需要重构一下.我建议用XX技术,它的优点有XX.XX.XX.我开了一个分支,在项目中引入测试过了,没啥问题.重构应该要趁早,否则简直是煎熬