一谈及企业数字化，大部分的企业领导与员工都会想到那是技术的事儿，既然是技术在一些领导的眼里 感觉就很简单，无非就是买个软件、上个系统、找个技术团队开发一下，然后想当然的认为问题就解决 了，数字化就完成了。但问题是技术侧的水比想象中深得多，然比技术更深更复杂的是技术背后的认知 与思维变革。今天老杨不谈所谓的转型与变革，就通俗的从技术视角讲讲企业数字化的技术难点究竟有 哪些。 这个问题在企业信息部门的眼里看起来是再清楚不过了，可问题是信息部门无法将这些技术问题向高层 决策者完全阐明其背后的复杂性与长远影响，导致技术规划常被简化，专业的问题被弱化，最后企业又 不得不花费更多的时间和成本去弥补因初期认知不足带来的各种技术债，今天老杨就来总结一下数字化 技术侧的几个关键难点。 第一，技术选型如"赌博" 大部分的传统企业开始做数字化首要面对的问题就是究竟选择何种技术路线，可以说是技术路线如"赌 博"一场，稍有不慎便满盘皆输。不同的技术架构、开发语言、部署方式与生态适配，直接影响系统未 来的可扩展性与维护成本。比如一些企业盲目跟风选择热门技术栈，却忽视自身业务场景与团队能力， 导致系统上线即"瘫痪"，还比如一些企业没有任何 ...

MacTalk . 墨问创始人，极客时间创始人。关注 AI 产品、科技创业，也写随笔和故事。笃信长期主义，用文字与 你同行。 本文来自微信公众号： MacTalk ，作者：池建强，原文标题：《给还在大厂工作的朋友 21 条忠 告》 当我14年前加入谷歌时，我以为这份工作就是写出优秀的代码。我只说对了一部分。但待得越久， 我越意识到能真正成长的工程师未必是代码写得最好的那批人——而是那些懂得如何在代码之外游刃 有余的人：在人与人之间、政治、一致性以及不确定性里找到路径。 以下文章来源于MacTalk ，作者池建强 这些教训我希望自己能更早知道。有些能让我减少几个月的挫败感；有些花了我几年时间才彻底理 解。它们不涉及具体技术——技术变化太快而不值得押重注——它们讲的是一个又一个项目、一个又 一个团队里不断重复的模式。 我分享这些，是因为我曾经得到许多工程师的慷慨相助并获益良多。把篇文章看做我力所能及的一次 回馈吧。 1.最好的工程师痴迷于解决用户问题。 沉迷于一项技术、到处找机会使用它，这件事充满诱惑。我做过，大家都做过。但创造最大价值的工 程师是反向思考的：他们对用户问题产生深度痴迷，让解决方案从这种理解中自然 ...

Core Insights - The article emphasizes that technology selection, particularly programming languages, often masks deeper issues related to personal identity and emotional attachment rather than purely technical considerations [1][4][18] - It highlights the importance of recognizing the hidden conversations that influence decision-making processes in technology choices, which can lead to significant financial implications for companies [17][19] Group 1: Case Studies - The first case involves a company, Takkle, where a new CTO's decision to switch from PHP to Perl resulted in a 9-month delay in product launch and a doubling of monthly burn rate from $200,000 to $500,000, ultimately leading to financial distress [5][6] - The second case at Google illustrates a similar pattern, where a vice president's push for Rust over Go was based on emotional and identity-driven reasoning rather than a thorough analysis of technical merits [7][8][11] Group 2: Decision-Making Dynamics - The article distinguishes between visible conversations focused on technical attributes and invisible conversations centered on personal identity and professional aspirations [9][10][18] - It argues that decisions driven by identity can lead to substantial costs, as technology stack choices account for 40% to 60% of total development costs over a product's lifecycle [17][19] Group 3: Recommendations for Improvement - Companies are encouraged to shift the focus of technology discussions from "which language is best" to "what are the costs associated with this language," encompassing all dimensions that affect survival and growth [19][20] - A framework is suggested to make hidden costs visible, allowing for more rational and economically driven decision-making in technology selection [19][20]

Core Insights - The article illustrates the paradox of success in technology, where a highly efficient system can lead to the perception that fewer developers are needed, ultimately jeopardizing the use of that technology [1][29]. Group 1: Technical Debt - The company had a traditional tech stack and needed to develop a real-time service to support 100,000 concurrent users, displaying user activity information [2]. - The initial choice of Ruby was deemed inadequate, prompting discussions on technology selection [3]. Group 2: Technology Selection Battle - The development team proposed using Rust, but management was cautious and requested comparisons with other languages [4][5]. - Concept validation versions were created using Elixir, Rust, Ruby, and Node.js, with Rust being developed by a novice [5][6]. Group 3: Performance Results - The performance results showed Rust as the fastest and most memory-efficient option, followed by Elixir, Node.js, and Ruby [8][10]. - The final decision favored Rust not only for its performance but also for its versatility in future applications [10]. Group 4: Rapid Development - Due to time constraints, a single developer with Rust experience was tasked to lead the project, collaborating closely with the team [11][13]. - The architecture was designed to handle 100,000 connections efficiently, utilizing a WebSocket-based API and in-memory data storage [14]. Group 5: Performance Challenges - The service performed stably under the expected load, but management later decided to shift it to maintenance mode, leading to a lack of oversight [16]. - The service was initially successful, but as the company expanded, management questioned the need for Rust developers due to the service's stability [19][20]. Group 6: Management Decisions - The new director's perspective led to the departure of experienced Rust developers, as they were deemed unnecessary due to the service's lack of issues [22]. - The decision to abandon Rust in favor of more mainstream technologies raised concerns about the existing Rust service's future [23]. Group 7: Node.js Rewrite Attempt - The attempt to rewrite the service in Node.js failed due to its single-threaded nature, which could not handle the required load [24][25]. - The company resorted to using a third-party service, which also proved inadequate [26]. Group 8: Lessons Learned - The Rust service continued to operate effectively but without a dedicated maintenance team, highlighting the risks of having a highly efficient system [28][29]. - The article concludes that sometimes, a less-than-perfect system may be perceived as safer, emphasizing the impact of management changes on technical decisions [29].