V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  exploreXin  ›  全部回复第 14 页 / 共 14 页
回复总数  266
1 ... 5  6  7  8  9  10  11  12  13  14  
2019-04-30 09:18:19 +08:00
回复了 pipinstallpy 创建的主题 程序员 某公司的考核,各位感觉如何?
只要钱给够,火箭我都能给你搞出来,bug 一次扣一千没啥,月薪给我三十万,随便扣。另外一点,公司如果能找到可以 0 bug 编程的大师,我每个月倒给公司 50 万,怎么样,问问你们公司敢不敢试一下 ~~
2019-04-29 09:26:55 +08:00
回复了 jziwenchen 创建的主题 C 问一个初级问题:为何 C 指针这么难
内存地址比喻成酒杯,那么地址里存的值就是酒,酒杯装酒,这是很好理解的。但是你见过装酒杯的酒杯吗,也就是酒杯里装的是酒杯,这就是指针变量的大致比喻,因为生活中不长见到这样的场景,所以也就不好理解了。如果要深入理解指针,前置知识有计算机体系结构,计算机硬件知识,另外还要有一些操作系统的知识打底,才能充分理解指针,觉得指针难理解只是前置知识不够,如果这些前置知识你都学的很溜的话,指针也就迎刃而解了,只是目前市面上大多都是业务逻辑程序员,函数类库都有人给封装好了,拿来直接用就行了,没有机会直接面对底层问题,所以对指针会很疑惑。
2019-04-25 18:38:17 +08:00
回复了 yazoox 创建的主题 程序员 有没有 Google/FB/Amazon 的大神,分享一些有关扁平化的经验?
@yazoox 想要可以马上上手操作的话,可以看一下《第五项修炼》,里面提倡的“学习型团队”,可以降低人与人之间的沟通成本,如果想修炼管理方法内功的话,推荐斯图尔特-克雷纳的《管理百年》,里面讲了从管理学产生至今的管理界潮流变化,讲了管理方法从重视工作成果到重视人性的转变过程,是对管理学全景式的回顾与总结,只是这本书不太好读,时间跨度大,出场人物众多,但是细细研究的话,相信一定会很有收获。
2019-04-25 13:25:00 +08:00
回复了 shanlan 创建的主题 程序员 能说说为什么你要是使用 Linux 系统开发吗?
大家可以问自己一个问题,我担任的岗位是开发岗位,但是我所用的思维方式是开发思维吗?

多年的所见所闻,让我差异的是,绝大部分人担任的是开发岗位,但是用的却是用户思维。我曾经和一个国内某大型上市公司出来创业的资深开发人员交流过,此人据说有 20 年 Java 编程经历,我发现对方也是用户思维。

有人会问,什么思维跟操作系统有啥关系啊?你吃过猪肉吧,也见过猪跑吧,但是你见过卖了一辈子猪肉没见过活猪的人吗?现实生活中不存在这样的人,但在软件开发界,没见过猪跑的人大有人在。

没有人否认 Windows 在个人计算机领域所取得的成就,视窗操作就是便利啊,有问题可以点击一键恢复,垃圾可以一键清理,安装软件一路下一步就好了,遇到类库依赖也是根据提示狂点同意,安装就好了,多爽啊。

是啊,是很爽,可是你想过没有,为什么你轻松点击一下就可以满足自己的目的,这样的便利性是与生俱来的吗?当然不是,你的便利性是开发人员呕心沥血开发出来的。你是计算机用户,电脑对于你来说只是一个黑箱,你不用精通里面的原理,只要会用就行。回过头来再说一下用户思维的开发者,虽然你是开发岗位,但是你只是用黑箱思维在开发程序,现在市面大部分程序员都是应用程序员,意思是只管逻辑,写完在 Windows 下跑一跑,代码没问题,直接传到服务端 Linux,工作就完活了,多轻松。但你想过不同环境的兼容问题吗?性能问题呢?这些问题不是不存在,而是系统的开发人员帮你解决了而已。Windows 环境的便利性是有代价的,代价就是丧失了主导权。在用 Windows 开发的时候你不用过于关心底层,直接使用就好了,这个过程实际是 Windows 包裹着你,你是用户,是高层受益者。而 Linux 就完全不同,它是另一种截然不同的思维方式,Linux 的黑框框让你必须以底层思考方式来对待日常工作,当系统出问题时没有一键恢复,没有一键清理,你必须一步一步去排查进程,去解决冲突,这整个过程是你在 Control 计算机,你是底层,系统是上层,虽然丧失了便利性,但是你的权利更大了,视角更宽广了,你不再是黑箱外面的人,你是内部的操纵者,这样的开发人员,才是开发思维,要记得你要用自己的聪明才智,辛苦劳动,给别的用户创造便利性,而不是以一个用户思维复制一下代码,简单调试一下程序就够了,这样的思维是用户思维,不是开发思维。

现实中开发还是 Windows 环境居多,毕竟是个人场景的计算机使用。什么系统真的不重要,重要的是思维方式,用 Windows 操作系统也可以是开发思维,深入底层研究系统运作原理,只是 Linux 是必须有底层思维才能使用,而 Windows 可以给用户使用,也可以给开发者使用。了解一下 Linux 的生态,将让你见识一片崭新的世界。

最后说一个我认识的卖猪肉但是没见过活猪的鲜活例子。我以前有一个同事,是 IOS 开发,人品极差,我们都没人愿意和他多交流,几句话就把你怼的说不出话。他平时开发用的是 mac 笔记本,视窗的那种,基本没用过里面的命令行,都是手动点击,有一次他看我用“ Linux 黑框框”,就跟我说,你们这个黑布隆冬的东西难用的一比,不知道为什么还有那么多人再用,我的 mac 才是王道,劝你赶紧迷途知返,赶紧把这东西扔的远远的。他的口气还不是开玩笑,是很认真的那种。当时我很想告诉他,你的 mac 用的也是 linux 内核。这种就是典型的没见过活猪的人,用着 linux 生态的东西,骂着 linux。你可以说黑框框不好用,你可以说你喜欢视窗,可辱骂黑框框这种行为就不能容忍了。正是你看不上的这个黑框框让你有了工作,正是这个黑框框让你可以复制复制代码每月就可以有大把薪水,对于给你工作给你酬劳的恩人恩将仇报,这样的人,实在不想再过多评论。

再一次问一下那个问题,我们大家应该都有了自己的答案 ...... 你是开发思维吗?
2019-04-25 12:45:14 +08:00
回复了 yazoox 创建的主题 程序员 有没有 Google/FB/Amazon 的大神,分享一些有关扁平化的经验?
扁平化的管理方式,到底扁平了什么?

先说说当年满大街都流行的敏捷开发吧,当时我们的团队在开发过程当中,沟通繁琐,返工频繁,效率特别低下,当时主持我们技术团队工作的是我们的产品经理,这位产品经理在被老板长时间反复催促项目进度之后,义正言辞的跟我们说,咱们这样下去是不行的,工期延误的情况太严重了,我决定明天向老板请示,以后咱们要引入敏捷开发,以后每个人的每项任务工期在评估的基础上缩短三分之二,任务下来了先做,有问题的时候再沟通,咱们有些人工作就是喜欢拖拉,以后要坚决杜绝这样的情况,我们要成为一个有战斗力的团队,敏捷就是做事要快!!不能拖泥带水!!

大伙听了这样的话不知是否似曾相识,也许之前就有类似的人说着类似的话,干着好像喜剧电影里才会出现的不可思议的滑稽事情。可事实证明,现实远比电影精彩。

好一个敏捷就是要快,所以说当管理并不是颐指气使的发发指令就可以舒舒服服的躺着赚钱了。连最基本的敏捷方法产生的原因,解决的问题都没有搞清楚,就想当然的拿过来一个流行概念自己给重新包装了一下,美其名曰追赶潮流的行为,最终公司在如此改革之后,原来的员工逐个离职,最终公司的结局可想而知,对于公司当时的情况,我只能用四个字形容 —— 好死不死。

对于概念的解释有无数种,这种情况存在于工作生活当中的方方面面,哪些解释是救命灵药,哪些解释是致命毒药,需要自己去探索寻找。可以看出,你的敏捷和大众的敏捷根本就不是一个敏捷,同样的,你的扁平化和成功公司的扁平化也不是一个扁平化。有多少公司是在仔细分析了自己所在领域,工作当中出现的问题,自身组织结构是否需要优化之后,决定采取扁平化来优化工作方式呢?你真的明白大公司的扁平化是什么样子吗?很可惜,中小型企业几乎没有做这些预准备工作。为什么不做呢?原因很直白,它们没有资源与能力。对于每天挣扎在生存边缘的企业,请不起年薪百万的职业经理人来打理公司,它们只是找一些自己认为差不多,有过几年相关工作经验,基本能够胜任的人来担当管理岗位,这样的人大多也只是复制黏贴式的去 copy 自己在别的公司的管理方式,真正的管理内涵,管理的本质,认知度基本为 0。要承认,我国现阶段根正苗红,有过大公司实战经验的高级管理人才,是极度稀有的。

我们再来看一下大部分公司 copy 过来的 “形式主义” 扁平化是个什么样子,笔者工作多年,在多个大大小小的企业担任过许多岗位,形式主义式的扁平化,一个实施起来有几点:

1. 岗位名称更换
公司里面不许要这个总那个总,要直接叫名字,有的公司为了进一步淡化层级关系,还会让每个人自己取一个英文名字,工作的时候只许叫英文名,如果叫了某人老总,就要扣钱,以儆效尤。

2. 取消管理人员的独立办公室
公司里除了大老板,其他管理人员都要与自己的队员坐在一起,同吃同住,荣辱与共。

3. 权力下放
公司决策权利由原来的个人分配到了多人手中,意愿是决策时人人都能行使权力,提高效率。

4. 工资调整
管理人员待遇降低到与普通员工同一水平。

5.取消绩效考核
取消绩效,工作全凭个人荣誉感。

实际工作当中还有很多方式,就不全部列举了,在这里着重讨论以上几点。可以看出,企业的初衷还是好的,目的是提高效率,消除隔阂。只是在制定规章制度的时候没有做足够的调研,照搬照抄别人家的东西,结果事倍功半,不得其索。

分别说一下以上一点在实施过程中的问题,第 1 点名称更换的实施,看上去让大家没有层级的沟通,实际上过度弱化了员工之间的关系,同事之间互相称呼英文名字,半年之后,你会发现你已经忘了对方的真实姓名了,这种方式是的同事之间的关系被禁锢在工作当中,工作至于的社交被阻隔了,没有好的人际关系做铺垫,好的同事关系从何而来,所以对于小公司来说,这种方式弊大于利。

第 2 点,取消独立办公室,管理人员需要自己独立的空间,这样能够让自己更好的思考,决策。乱哄哄的环境下会影响管理人员的决策效率,需要知道的是,管理人员的作用,不在于你干了多少脏活累活,管理的重大作用是提供企业发展路线,规避风险,不管是高层管理,还是中层管理,本质都是一样的。所以对于纯管理岗位,决策对于企业有巨大影响的人员,有能力的话还是配备独立办公室为上策。

第 3 点,权利下放,这一点初运行起来,你会觉得效果很好,大家都可以行使权力,效率显著提高了。可是时间一长,所有积累的问题都将像河口决堤一样喷涌而出。这个文件是谁同意的?这个打印机是谁买的?这个大门的钥匙都谁有?混乱从此开始一发不可收拾。所以下放的权利要经过严格论证,不能成为后续工作的阻碍,这样的权力下放,才会产生积极的作用。

第 4 点,干了更多的工作,承担更多的责任,待遇却不升反降,人不是机器,人有情绪,在积累到一定程度之后,就会爆发,带来的影响,将是不可挽回的。我们还在社会主义初级阶段,小企业就不要谈什么责任,荣誉感了,大家都是要吃饭的,按劳分配,才是资源配置的根本原则。

第 5 点,绩效考核还是必须的,不能全凭绩效,也不能没有绩效,多劳多得,有劳有得,没有相关的工作情况统计,谁还有干劲去努力工作呢。

可以看出,光有形式是远远不够的,这样的扁平化,有还不如没有,如此下去 ,只有曲终人散的下场。

那么扁平化,我们到底应该扁平什么?答案就是:我们需要扁平“人际关系高度”。
是的,人与人之间的人际关系,是有高度的。

人与人之间的高度,决定沟通成本和效果,低成本比如好朋友之间,没有任何利益冲突的闲聊,可以看做低成本沟通,成本最低的沟通可以说只有父母对孩子不求回报的照顾与呵护,可以看做接近 0 高度沟通。相反,拥有巨大人际关系高度差的沟通场景,就好像开头的产品经理和手下沟通一样,只顾自己利益,不看实际情况的沟通,领导高高在上的发出指令,手下艰难的执行,这样的人际关系高度下,领导说出的话语,可以砸死手下的兄弟,这样的方式怎么能产生好的工作成果。

所以说扁平化扁平的不是岗位,不管你是否施行扁平化管理,领导还是领导,层级关系是不变的,层级高度也是不变的,它是静态的,相差一级的层级关系,距离就是 1,相差两级距离就是 2,以此类推,这个是到什么时候也改变不了的。扁平化真正要解决的是人际关系高度,人际关系高度低的领导,可以降低沟通过程中产生的问题与矛盾的冲突程度,极限状态的领导可以像家长一样,毫无所求的耐心沟通,指导手下工作,有了这样的条件,在公司就可以实现“亲如一家”的工作环境。当然了,这种极限条件在现实生活中可以认为几乎不存在,因为实现的前置条件过于苛刻。

可以看出,扁平化真正扁平的是什么,深刻认知这一点之后,上述所列的几点具体实施方式才有意义,否则只会是形式主义,得到的结果也将是南辕北辙,有还不如没有。现在越来越多的公司放弃了扁平化,不是扁平化本身不行,而是公司没有抓住主要矛盾,好的方法只借鉴了表面,没有深入内部去一探究竟,这样的事情,是值得我们花一些时间仔细思考与研究的。
2019-04-23 13:06:08 +08:00
回复了 rizon 创建的主题 程序员 认真的问,要不要学学 go 语言?爱好级别的学习
当我们讨论编程语言优劣的时候,往往忽略一个很重要的问题:编程语言的本质,承载人类发出的控制信息,用于指挥计算机产生某种行为,从而满足人类的生产,生活等需求。如果不明确这一出发点,就不能深刻认识到我们将要讨论的问题。

从编程语言本质可以看出,编程语言的作用是承载信息用于控制计算机,那么所承载的信息是哪里来的?答案是人脑。我们几乎绝大部分工程师在参与软件开发的过程中都没有认识到一件事情,真正的终端是人脑,信息产生于人脑,网络连接的是人脑与人脑,人脑是信息产生处理的源头和终点。计算机只是量变了人脑之间的通信,至少在强人工智能实现以前,都不会质变这个过程。所以计算装置的总设计纲领产生于人脑,而软件也包括在内,编程语言就更加属于这个范畴。

现在再来看要不要学某门语言的问题,编程语言之间的最大区别其实是底层编译器的区别,编译器的区别在于编写编译器的开发人群之间的区别,所以最终产生区别的发源地是开发人员对于世界认知的不同,导致不同的编程映射方式,有的语言语句不用分号结尾,有的语言可以有分号,也可以没有分号,这些区别都不是浑然天成的,他们产生于软件作者的不同世界观,才产生了不同的语言差别。一个开发者如果融入符合自己世界观的开发者社区,将会如虎添翼,如果进入了与自己世界观不同的社区,将犹如进入地狱一样,极端的例子例如:Linus 极度讨厌 C++。

当然了,世界观也是一点一点养成的,早年的经历,工作当中接触的技术会影响我们的世界观,再加上自身性格与对世界的认知,最终形成我们对于编程语言的口味,使你在用某个语言时特别舒服,而某些语言让你生不如死,但是对于别人,也许这生不如死的语言正是他们的最爱,这也是编程语言战争的导火索,我们都倾向我们喜爱的语言,痛恨另自己难受的语言。所以产生语言战争的根本原因不是语言的优劣,而是我们人脑的偏见导致的。

有人说,我这么多年也没有过热爱什么语言,也没有痛恨过什么语言,这是为什么呢?这是因为,我国信息产业还处在初级阶段,国家层面上的研发还停留在应用开发的阶段,我们的底层研发人员凤毛麟角,这切断了我们产生自主软件世界观的源头,我们只是拿国外开发的系统,语言来用,融入别人的世界观,然后贡献自己的代码,而我们东方特有的世界观极少有机会能够产生自己的软件生态,知乎上无数人追问为什么国内没有产生伟大的编程语言,就是因为这些原因,想来甚是可惜。不过随着国家的不断发展,我相信总有一天国人能够拥有自己的软件生态,不再受制于人。

那么问题来了,到底要不要学 Go,不同的人答案不同,如果你的底层世界观和 Go 语言社区相一致,那么果断融入,也许将来能够赶上下一波潮流,以后升职加薪那是少不了的。如果自己所在领域,以前的语言与 Go 的哲学差异很大,那就要慎重一些,毕竟不同世界的事物想要融合,将需要巨大的时间去催化,而开发人员的时间又是及其宝贵的,所以建议慎重选择。如果单纯想提高哦收入,学一套自己所用语言的新的框架,时间利用率会高的多。

最后,如果你读了上面的文字,觉得像神仙打架,不知所云,那么说明你还停留在代码搬运的表层阶段,闲暇之余多读一些计算机科学方面的书籍,有助于改善这个问题,底层知识的力量就在于能够让你彻底认知一个问题,而不是流于表面,人云亦云,别人说的就一定对吗? No,要我自己审视推敲证明是对的,才能说是对的,否则我们就只能像个路由器一样,接收转发,没有一点自主权利。对于 Go 呢,我还是推荐了解一下 Go 语言的,国内不流行不说明就不优秀,看看 Go 语言创始人都有谁你就会知道,至少冲着大神们的招牌,应该错不了,具体怎么样,等细细研究过 Go 语言之后,相信定会受益匪浅。
1 ... 5  6  7  8  9  10  11  12  13  14  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5335 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 21ms · UTC 06:57 · PVG 14:57 · LAX 22:57 · JFK 01:57
Developed with CodeLauncher
♥ Do have faith in what you're doing.