必要的思考

  今天突然想发些牢骚,说说我今天关于自己和兄弟的思考。

  先说下对于兄弟的思考。

  今天微信一个初中同学群上,新增了一个同学。一开始并不觉得有什么奇怪,后来发现他是我曾今初中最好的兄弟。想着我们都长大了,过去的事毕竟都过去了,我毫不犹豫的发起了好友添加的邀请。他同意了邀请,然后我问他是不是那个人,他也刚好问我是不是我。才发现其实或许我们之间还有些联系,隔了这么久,真的是太久没联系了。初中时代的记忆对于我来说,只有和他一起玩耍的日子是最清晰的。

  问他现在在干嘛,还在读书,我觉得挺好,他的经历对我来说是陌生的,然而我自以为我能够理解。翻了翻他的朋友圈,发现他跟以前不一样了,也发现了很多以前的影子。我觉得都挺好,他一直在为自己和未来奋斗,也在不停的思索着自己的未来和身边的朋友。或许这是我们两个人之间要走的路,注定不能一起奋斗,一起进步。也许是因为太久没说过话,没一起处事,也没见过面,我在跟他聊天的时候,聊着聊着发现我们之间失去了很多话题,指尖舔在键盘上,却迟迟发不出力。不过还好,他在的地方离我挺近的,或许我会去找他,或许他并不想见我,可是,假如我真的取见他了,我要怎么取面对他呢。他长成什么样了,还会不会是我脑海里的样子,这些现在只能靠猜测。初中时代,在我最迷茫最懵懂的时候遇到了他,我觉得这是一件很幸运的事情,因为他真的教会了很多我所不知道的事,因为他的感染,我踢了6年的足球,因为他的影响,我开始意识到读书对于人的成长是多么重要的一件事。然而没想到的是,因为我的自私和无知,和他感情决裂。那个时候我还TM地觉得着并没有什么,感觉朋友可以再交。随着年纪慢慢变大,我才知道我错了,那个时候我曾试想过复合。更没想到得是,就连最后得决裂也教育了我,让我懂得了,不是每个人都可以叫做兄弟,不是每个人都值得你掏心相对。所以之后的我变得珍惜周围对我好的人,也尽力去保护他们。如果可以,我希望我们还能向以往一样,不过这次,我来罩你。

  再说下对于自身技术发展的问题,以及所引发的一些思考。

  刚出来的应届生初来公司公司,尤其是像我这样技术生,或多或少会发生一些这样的事,就是你发现某天你在公司里没什么事做了,该做的都做了,也没人给你指导或者布置任务,这个时候,你们都在干什么呢。会不会无聊刷网页,还是自己熟悉了解公司项目或者部门项目的代码业务呢。前面两者相比下,我觉得后者会比较好,第一,不会让领导看到你太无聊,第二,对于项目的熟悉会让你在以后的项目过程中使你得心应手。

  我看到过网上很多这样的人觉得在公司基本上就做些基本事情,混了个一两年,觉得自己技术成长太慢,然后觉得很迷茫。我也不知道你们是否也这样,不过在这里,我认为技术这种东西是需要积累的,公司的事如果不能满足你的需求,自己要及时清除自身的问题所在,然后仔细思考自己未来是否要走这条路,如果要走,需要作出怎么样的改变,还是那句话,你不能靠别人,只能靠自己,如果你决定好了,那你就应该为自己寻找出路,最好能为自己规划出一条具体的技术学习和积累路线。这样的话,你就不会在公司没事做或者觉得公司里所做的事满足不了自己了。当然这只是我的看法,我也是这么做的,不过最好能做成什么样,纯看自己的坚持和时间的积累。

  目前总结就到这里了,虽然写得不怎么好,但我会一直坚持和努力下去。

  感谢支持。

      

时间: 2024-10-05 08:46:21

必要的思考的相关文章

关于迭代測试的一些思考

作者:朱金灿 来源:http://blog.csdn.net/clever101 一个软件的功能的越来越多,怎样建立一个规范的測试流程来保证对开发的功能进行充分的測试,是摆在我们面前的难题.在改动bug中经常会出现一种"按下葫芦浮起瓢"情形--改动了A模块的bug,却造成了原来測试没有问题的B模块出现了新的问题.这就促使我们思考:怎样保证測试的百分百的覆盖率.为此我设想一种迭代測试和迭代公布的流程.这个流程详细是这种:全部功能測试分为常规功能測试和新功能測试.所谓常规功能測试是指之前測

关于重构工作的一点思考

最近两周一直忙着和重构相关的事情,本文将简要概述从开始制定重构方案,到具体执行的过程中遇到的问题,以及对重构的一点理性思考. 起因: 本系统是2015年11月开始建设,当时为了快速投入使用,大量的烂代码,后期一直保持快速前进,没有进行过实质性的重构. 具体表现: ● 分层不清,sql哪都有,dao有.service也有,就差controller没写了.同样dao也包含业务逻辑. ● sql用的是spring jdbc,并没有使用mybatis,导致sql写起来有些复杂,封装不够基本都是原始sql

php各种设计模式简单实践思考

前言 我一直觉得什么框架,版本,甚至语言对于一个coder来说真的不算什么,掌握一个特别高大上的一个框架或者是一个新的,少众的语言真的不算什么,因为你可以,我要花时间也可以,大家都是这样的.所以基本的显得额外重要,即是算法和数据结构,再就是好的设计模式了,,,听过一句话,是好的数据结构是让计算机更快的工作,而一个好的设计模式则是使开发者工作的更快! 单例模式 单例模式特点 $_instance 必须声明为静态的私有变量 构造函数和克隆函数必须声明为私有的,这是为了防止外部程序 new 类从而失去

由爬虫引发的思考

前言 花了两天时间写一个简单的爬虫程序.目前所用的技术十分简单.就是获得目标页面的html文档内容,然后解析其中有用的内容.既没有实现模拟登陆,也没有任何防止反爬虫的措施,甚至没有使用多线程.不过在其中遇到的问题还是引发了我很多的思考与问题,比如爬虫的合法性问题以及爬虫的危害等.于是写下这篇文章记录一下.由于本人经验有限,引用参考了大量文章,有问题请指出. 爬虫的作用与危害 爬虫的作用 网络爬虫(Web Crawler),又称网络蜘蛛(Web Spider)或网络机器人(Web Robot),是

第二十三篇:信号机制的两个思考

前言 前文介绍了最基本的信号接收和处理,但这有无可能带来一些问题呢? 本文将通过两个思考,来分析可能带来的问题以及解决方法. 思考一:中断的系统调用 如果用户正在执行系统调用,如 write read.如果这个时候程序跳转到了信号处理函数后返回,则是否重新执行这个系统调用? 结论 这要分情况讨论:如果是磁盘 I/O 的系统调用,则自然需要自动重启:而如果是终端 I/O,则不需要自动重启. 在信号函数族中,有很多函数都是支持设置是否重启选项的.当然,用户也可以使用类似下面的代码自行实现重启: 思考

sql monitor生成不了报告& FFS hint不生效两个问题思考

事情的发生就是这么偶然,一步步的深入才能汲取到更深入的知识~~ -------------------START-------------------------------------------   来了一个query running longer than 4hours的邮件,来看看里面有哪些sql: SID    SERIAL#    INST_ID SQL_ID        Run_in_sec OS_user     MACHINE       SQL_TEXT         

MapReduce源码分析之Task中关于对应TaskAttempt存储Map方案的一些思考

我们知道,MapReduce有三层调度模型,即Job-->Task-->TaskAttempt,并且: 1.通常一个Job存在多个Task,这些Task总共有Map Task和Redcue Task两种大的类型(为简化描述,Map-Only作业.JobSetup Task等复杂的情况这里不做考虑): 2.每个Task可以尝试运行1-n此,而且通常很多情况下都是1次,只有当开启了推测执行原理且存在拖后腿Task,或者Task之前执行失败时,Task才执行多次. 而TaskImpl中存在一个成员变

职场思考--对产品经理岗位的技术思考(上)

有的时候就在想,技术特别牛的人是不是会一直做技术呀!毕竟,一直习惯了自己的那个技术圈子.要从那个圈子里出来,去考虑市场,运营,行业.......一系列的问题.相当于从自己已有的一个优势中跳出来,会有多少的不习惯.但最近通过跟一些朋友的聊天才发现,对于产品经理这个职位而言.又有了一个更为深入的思考. 从市场行为倒推论技术研发 做技术的人讲究要严谨,一丝一毫的差距可能都会影响最终产品的性能.而做产品经理,你所要考虑的就不仅仅是技术.换一个角度来说,对技术,你可以要求细节.但对一些看似反常的市场行为来

关于过拟合、局部最小值、以及Poor Generalization的思考

Poor Generalization 这可能是实际中遇到的最多问题. 比如FC网络为什么效果比CNN差那么多啊,是不是陷入局部最小值啊?是不是过拟合啊?是不是欠拟合啊? 在操场跑步的时候,又从SVM角度思考了一下,我认为Poor Generalization属于过拟合范畴. 与我的论文 [深度神经网络在面部情感分析系统中的应用与改良] 的观点一致. SVM ImageNet 2012上出现了一个经典虐杀场景.见[知乎专栏] 里面有一段这么说道: 当时,大多数的研究小组还都在用传统compute

企业级产品思考(二)

接着这个话题写完吧,以前弄到腾讯内部的产品架构ppt,其中谈到一条:不为企业产品做架构!这点深有体会,因为重口难调,极端的可能是两个需求对应两种完全不同的架构,比如我们老版本的客户端重写了explorer,优点是我们可以控制用户行为,缺点是容易出bug,同步不流畅,容易卡死,新版本参考svn做了同步功能,体验爽了,流畅了但是控制不了用户行为,这个时候用户提出一个需求:同步下来的文件我不想员工轻易复制走!!何解?那么如何思考企业产品的设计来迎合需求,我想这个问题永远只有一个临时答案. 我想从第一篇