即将展现的是一篇包含大量建议的 blog ; 向前人学习对成功至关重要,但是,我们常常忘记另外一个重要警告: 几乎所有的建议都是上下文相关的, 但是,很少对上下文提供细节;

"你需要收取更多费用!" 这经营了20年的公司说, 多年以来收费"太低",无法赢得客户并取得成功;

"你需要将一切构建为微服务!" 该公司表示, 构建了一个快速的整体,获得了数千客户,然后,在开始遇到问题时, 全面转向了微服务;

如果不了解上下文, 建议就毫无意义,甚至更糟糕,有害; 如果那些人早点听从他们自己的建议,他们自己可能会因此受苦; 对于任何建议很难逃脱这个陷阱; 我们可能是我们经历的终点,但是,我们却是通过现在的镜头来观察;

因此,为了让你了解一下这些建议的来源,特此说明: 我在职业生涯的前半段担当软件工程师,为各种小型企业和初创公司工作, 然后,我进入咨询行业并在许多非常太的企业工作; 最后, 我开创了 Simple Thread, 我们从一个2人团队成长为一个25人的团队; 10年前, 我们主要和中小型企业合作,现在我们和大型和小型企业合作;

我的所有建议来自于:

几乎总是在小而精干的团队中,我们必须用很少的资源作很多事情
重视工作软件而不是特定工具
一直在开始新项目,同时还要维护一些系统
重视工程师的生产力,超过其它大多数考虑因素
...

我过去20年的经历塑造了对软件的偏见, 并使我形成了一些信念; 我试图将这些信念压缩为一个易于使用的列表, 希望你能发现她们的价值;

我们大多数人都被人这么说过, 而且可能听的太频繁了; 我们中许多人喜欢软件的原因就是因为我们是终身学习者, 在软件领域, 无论你从哪个方向看, 都有广阔的知识前景向各个方向发展, 而且每天都在扩展; 这意味着即便你在职业生涯中度过数十年, 但是, 和同样在看似相似的角色中度过数十年的人相比, 仍然存在巨大的知识差距; 越早意识到这点, 就能越早开始摆脱 "顶替者综合症" , 转而乐于向他人学习和教导他人;

2. 软件最难的部分是构建正确的东西

我知道在这点上算陈词滥调, 但是, 大多数软件工程师并不相信的原因是, 他们认为这在贬低他们的工作; 我个人认为这是无稽之谈；相反,这突出了我们必须工作的环境本身复杂性和不合理性, 这故居了我们的挑战; 你可以设计出世界上技术上最令人印象深刻的东西, 然后, 却无人愿意使用; 这种事儿一直在发生; 设计软件主要是一种倾听活动, 我们经常不得不成为竕软件工程师, 部分通灵师, 以及部分人类学家; 投资在这个设计过程, 无论是通过专门的 UX 团队, 还是通过简单的自我教育, 都将带来巨大的回报; 因为, 你如何计算构建错误软件的真正成本? 这不仅仅是损失工程时间...

关键参考

很有人不同意所有观点: January 25, 2023 at 7:25 pm

Hard disagree with most of the 20 items.

Writing software is difficult, tedious and needs real work. No silver bullet libraries, no methodology, no framework, no IOT, no amount of unit tests will get the work done faster.
Developers collect tools, libraries and pet technologies and make projects go over their time and budget by doing it.
Code should encapsulate algorithms and not be structured other wise. Code should follow the business logic and be readable and match business requirements easily.
Forgetting history keeps the productivity and industry down. Microsoft re-discovering the same old technology which existed on 1960s mainframes for the 7th time just to sell products, trademark buzzwords, training, certification and everything is an anchor around the modern developer’s neck. Think file transfer -> X12 -> serial communication -> raw socket packets -> corba -> xml soap -> xml http -> Rest JSON http -> gRpc as a 50 year journey of rediscovering the same thing repeatedly, each not really that much better than the older technologies, wrapping mounds of interlarded crud on top of fragile, hard to program libraries and the square peg in a round hole mismatch.
Refusing to hold W3C and large tech companies accountable for not fixing web HTTP, HTML, CSS and JavaScript for 25+ years. – How can I create a control which has HTML, CSS, JS which has encapsulated CSS, encapsulated HTML, encapsulated JS without a 10,000 file framework? – How to match HTML DOM elements with JS without using quoted magic strings? Quoted magic strings were proven anti-productivity and anti-quality in the 1960s – How to have a UI without the everything is a call back and function pointer? Function pointers with modern wrappings are just as bad as the 1060s computed jump to function tables
Forgetting that tech is a business with a 7 year hype cycle, with the new thing being embryonically hyped for 2 years by cutting edge bloggers, then 2 years by sales marketing of companies, then 3 years of disappointment for companies trying to implement it. Followed by, abandonment when the ROI does not work out. Resume driven development, just for business persons. And yes, there’s a new hype every 2 years to waste time and money on
Not holding tech companies accountable when they release major products, .net core, which have less than a 5 year full support lifecycle. Long term support .net is under 3 years. That is a forced upgrade every 3 years for every .net system just to pass the IT auditors at a large company
Devaluing your own worth and work as a developer by telling everyone that the proposed product/task is easy. Software dev is hard work, less than 1 of a 1000 people can even do it poorly. I would not go to a brain surgeon that told everyone that what he does is easy.
Forgetting that software development is a hard, tedious, isolated job where people desiring lots of human interaction will rapidly leave the field by their own choice and lots of people not getting into the field by their own choice.
Not telling people that you as a developer have to say “No, it’s too expensive” or “No, it’s too risky” as a regular part of your job. Persons not developing software treating you poorly with career ending consequences just because you won’t accept the death march cross to bear of impossible requirements of an impossibly short deadline
Not helping your fellow developers out. Speak well of your co-developers, team, and industry. Don’t downplay the difficulty, complexity or contribution of software.
Not calling people out when they think that more data, metrics for everything will automatically solve problems. Ask for a business case, ask for the questions they want to answer (in written form), get the business case and questions they want to answer from the requestor, make sure they are approved before committing to a tight deadline
Not damaging the next developer on your project – too many technologies, framework of the month, just another nuget package, one more class, have another 3 patterns, data on disk, data in database structure and consistency is not important and, yes, this system will never receive/send upstream/downstream data
Accepting code without parameter checking, error handling or in-line comment documentation (cough vendor’s happy path ‘doc’ page or cough signature only documentation with no example code or error handling.)
Misguided acceptance that best practices are best and not just a short nicely sized blog entry. Best practices, in many cases, do not scale for large 1,000,000+ line of code systems and make maintenance harder.
Not challenging the ‘more technology is better’ approach

logging

版本记要

..
230201 ZQ init.

            _~∽&`~_
        \) /  ◷ ◴  \ \/
          '_   V   _'
          \ '--.--' \

...act by ferris-actor v0.2.4 (built on 23.0303.201916)

be Rustaceans

20年来作为软件工程师学到的20件事

注意:请先阅读此内容

建议清单:

1. 我仍然懂的不是太多

2. 软件最难的部分是构建正确的东西

3. 最好的软件工程师像设计师一样思考

4. 最好的代码是没有代码,或是你不必维护的

5. 软件是达到目的的手段

6. 有时你必须停止磨锯,直接开始砍屎

7. 如果你不能很好的理解所有可能性, 就无法设计出好的系统

8. 每个的了了的都很糟粕,克服丫的

9. 无人问足"为什么"

10. 我们应该更专注于避免0.1x 程序员,而不是寻找 10x 程序员

11. 高级工程师和下级工程师间最大的区别之一是他们已经形成了对事情应该如何发展的偏见

12. 人们并不是真想创新

13. 数据是你系统中最重要的部分

14. 寻找技术鲨鱼

15. 还要把谦逊误认为无知

16. 软件工程师应该定期写作

17. 尽可能保持流程简洁

18. 软件工程师和所有人一样,需要有主人翁精神

19. 面试对于告诉某人将成为团队成员有多赞,几乎毫无价值

20. 始终努力构建一个更小的系统

你的故事呢?

refer.

Hard disagree with most of the 20 items.

logging