blocks|key|1190994|text|精益开发是一个显而易见的选择，取自Toyota的制造原则，以对抗强大的美国工业的规模经济。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1190995|entityMap|0|LINK|mutability|MUTABLE|url|http://www.amazon.co.uk/Toyota-Way-Management-Principles-Manufacturer/dp/0071392319^0|H|6|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Lean development is an obvious choice, taken from <a href="http://www.amazon.co.uk/Toyota-Way-Management-Principles-Manufacturer/dp/0071392319" rel="noreferrer">Toyota</a>'s manufacturing principals to combat economies of scale of the might U.S. industry. It fits well with the agile software engineering framework

blocks|key|1189295|text|这可能有点牵强，但在打乒乓球的过程中，我了解到，在你获得了一些基本技能后，你的大多数错误都来自于试图打得比实际情况更好--去打大满贯，你真的没有这种技能。更安全的做法是玩保守的游戏，让其他玩家高估自己。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1189296|在编写代码时，我尽量不要比我更聪明(运行由人进行的架构设计有助于实现这一点)。实现复杂的数据结构来管理脏读取和缓存过期很快就被否决了，因为该功能是为部分用户提供的，不值得花费内存或开发人员的资源。|1189297|我相信弗雷德·布鲁克斯会称之为“第二系统综合症”。|1189298|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

This may be a stretch, but while playing Table Tennis I learned that after you gain some basic skill, most of your mistakes come from trying to play better than you actually are - going for slams you really don't have the skill to make. It's safer to play a conservative game and let the other player overplay themselves. 

While coding, I try not to be cleverer than I am. (Running architecture designs by people helps with that). Implementing complicated data structures to manage dirty reads and cache expiration got shot down quicky, as the feature was for a subset of users, and wasn't worth the memory or developer resources. 

I believe Fred Brooks would call this the Second System Syndrome.

blocks|key|1189166|text|Eliyahu+Goldratt有一本名为“目标”的书，这是一本关于优化工厂的小说化商业书籍。它有很多关于如何确定现实(或者至少质疑你自己的概念)的很好的讨论，以及关于瓶颈的东西，这在整体可伸缩性问题上非常有用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1189167|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Eliyahu Goldratt has a book called "The Goal" which is a novelized business book on optimizing a factory. It has a lot of good discussion on how to determine reality (or at least question your own concept of it) plus stuff on bottlenecks which is very useful when an overall scalability issue.

blocks|key|1197113|text|心理学是其中之一。它不仅激励你自己和你的团队成员，而且使用技术来理解客户真正想要的是什么，而不是他所要求的。可用性是软件开发的另一个重要因素，它是一个以人为本的因素。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1197114|软件可能是一种技术职业，但开发应用程序是一种人类职业。|1197115|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Psychology is the one. Its not just motivating yourself and your teammates, but using techniques to understand what the customer actually wants instead of what he asked for. Usability is something else that matters to software development that is a person-oriented factor.

Software may be a technical profession, but developing applications is a human one.

blocks|key|1189342|text|就我个人而言，我发现数学和科学背景在进行故障排除和调试时非常有用。使用科学方法，在自己身上强制执行智力上的严谨，保持健康的怀疑论，并总是退回到“这个理论实际上最好地解释观察到的证据吗？”这个问题。在追踪根本原因方面有很大帮助，而不是被错误的线索绕过。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1189343|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Personally I find that a background in math and science comes in very handy when troubleshooting and debugging. Using the scientific method, enforcing intellectual rigor on yourself, maintaining healthy skepticism, and always stepping back to the question "does this theory actually explain the observed evidence best?" helps enormously in tracking down root causes instead of being side tracked by false leads.

blocks|key|1189577|text|我差一点就在中学教信息通信技术了。我学到了很多：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1189578|你可以从周围的人身上学到很多东西，不管他们的技能如何levels|1189579|Preparation+success|unordered-list-item|1189580|
|1189581|Assumption+is+f**k-ups|1189582|1189583|Technology+|1189584|f**k-ups|1189585|Technology|1189586|1189587|1189588|1189589|1189590|1189591|1189592|你可以从你周围的人那里学到很多东西，不管他们的技能如何。|1189593|1189594|1189595|1189596|1189597|entityMap^0|0|0|0|0|0|0|0|0|1|1|2|2|2|2|2|2|1|0|0|0^^$0|@$1|2|3|4|5|6|7|15|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|16|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|17|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|18|8|@]|9|@]|A|$]]|$1|I|3|J|5|F|7|19|8|@]|9|@]|A|$]]|$1|K|3|H|5|6|7|1A|8|@]|9|@]|A|$]]|$1|L|3|M|5|F|7|1B|8|@]|9|@]|A|$]]|$1|N|3|O|5|F|7|1C|8|@]|9|@]|A|$]]|$1|P|3|Q|5|F|7|1D|8|@]|9|@]|A|$]]|$1|R|3|O|5|F|7|1E|8|@]|9|@]|A|$]]|$1|S|3|Q|5|F|7|1F|8|@]|9|@]|A|$]]|$1|T|3|-4|5|F|7|1G|8|@]|9|@]|A|$]]|$1|U|3|-4|5|F|7|1H|8|@]|9|@]|A|$]]|$1|V|3|-4|5|F|7|1I|8|@]|9|@]|A|$]]|$1|W|3|-4|5|F|7|1J|8|@]|9|@]|A|$]]|$1|X|3|Y|5|F|7|1K|8|@]|9|@]|A|$]]|$1|Z|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]|$1|11|3|-4|5|6|7|1N|8|@]|9|@]|A|$]]|$1|12|3|-4|5|6|7|1O|8|@]|9|@]|A|$]]|$1|13|3|-4|5|6|7|1P|8|@]|9|@]|A|$]]]|14|$]]

I nearly ended up teaching ICT in secondary schools. I learnt a lot:

<ul>
<li>Even teachers are still students -- still learning all the time.</li>
<li>The best teachers are also the best learners</li>
<li>You can learn a great deal from those around you, no matter what their skill levels</li>
<li>Preparation is often the key to success</li>
<li>Assumption is the mother of all f**k-ups</li>
<li>Technology changes too fast to keep up with all the latest developments -- admit you don't know everything.</li>
</ul>

blocks|key|3505869|text|设计模式最初是由架构师(即设计实际建筑的人，而不是软件架构师)使用的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3505870|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Design patterns were originally used by architects (i.e. people who design actual buildings, not software architects).

blocks|key|1191157|text|木工这句老话“两次测量，一次切割”一直适用于我所从事的开发项目。努力在第一次就把事情做好是有好处的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1191158|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The old carpentry saying "measure twice, cut once" has always been applicable to development projects I have worked on. It pays dividends to strive to get things right the first time around.

blocks|key|3505964|text|作为一名顾问，我学会了微笑，并满足用户的任何要求……|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3505965|在好的公司里，我不能说我是以什么职业为榜样的。|3505966|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

As a consultant I've learned to smile and give the user whatever they ask for...

I can't mention in good company what profession I've modeled this behavior after.

blocks|key|4974836|text|KISS+(Keep+It+Simple，Stupid)原理在这里适用，就像它在我的机械工程学习中一样。就编码而言，最有可能的是，开发人员和其他阅读代码的时间比编写代码的时间要多。因此，对于给定的问题，尽可能简单地设计会有很大帮助。这个领域的过度工程甚至会让最初的开发人员在三到六个月后抓挠他/她的头，说：“我到底为什么要这样做？”|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|4974837|只有我的0.02美元。|4974838|entityMap^0|6|1|B|1|E|1|L|1|20|2|28|2|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]|$9|O|A|P|B|C]|$9|Q|A|R|B|C]|$9|S|A|T|B|C]|$9|U|A|V|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|W|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|X|8|@]|D|@]|E|$]]]|I|$]]

KISS (Keep It Simple, Stupid) principle applies here just like it did in my Mechanical Engineering studies. As far as coding is concerned, it is most likely that more time will be spent by the developer and others reading the code than writing it. Therefore, it helps a lot to have as simple a design as possible for the given problem. Over-engineering in this field will have even the original developer scratching his/her head three-six months down the road, saying, "why on earth did I ever do that?"

Just my $0.02.

blocks|key|1197332|text|检查清单！它们不只是飞行员的专利：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1197333|The+Power+of+the+Checklist|offset|length|1197334|entityMap|0|LINK|mutability|MUTABLE|url|http://www.newyorker.com/reporting/2007/12/10/071210fa_fact_gawande^0|0|0|Q|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

Checklists! They're not just for pilots:

<a href="http://www.newyorker.com/reporting/2007/12/10/071210fa_fact_gawande" rel="nofollow noreferrer">The Power of the Checklist</a>

blocks|key|1191277|text|虽然不完全是一种职业，但我认为我们也需要从创造性的类型中吸取教训。例如，写入者通常会把自己锁起来，以便在一段时间内不受干扰地写作。保罗·格雷厄姆在Hackers+and+Painters之间有很强的相似性|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1191278|entityMap|0|LINK|mutability|MUTABLE|url|http://www.paulgraham.com/hp.html^0|21|K|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

While not exactly a profession, I think we also need to draw from the creative types. For example it's common for a writer to lock themselves away for blocks of time to write without interruption. Paul Graham draws strong parallels between <a href="http://www.paulgraham.com/hp.html" rel="nofollow noreferrer">Hackers and Painters</a>

blocks|key|1189229|text|任何类型的建筑活动-我总是对巨大的建筑(桥梁和建筑)感到惊讶，而不是伟大的软件。因为你总是有更多的软件测试机会(单元，压力，用户验收和地狱般的质量检查)，但想象一下你可以为一个好的结构做多少事情好的物理和数学背景肯定会提高你的编程技能|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1189230|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Any sort of Construction activities - I always have amazed on the vast constructions(Bridges and Buildings) than on great softwares. Because you have always have more oportunity in s/w to test(unit,stress,User acceptance and hell lot of quality checks), but imagine how much you can do about a great structure
Good background in Physics and Maths will surely boost your programming skills

blocks|key|1189405|text|在某种模糊的意义上，建筑教会了我从效率的角度思考。当你在工地上打包你的工作包，拖着木材，在杂乱的、未完工的房间和走廊里拖着电源线，通常会把一大堆木材和胶合板变成一座房子时，你很快就会明白，你走的每一步都必须做一些有用的事情。尤其是当你身后有一个小企业主老板，每次你从a点走到b点时，他都会大喊大叫，抱怨他在你没有带东西的情况下如何赔钱。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1189406|在编程中，它通常是相同的。然而，你不是在节省时间，而是在努力节省时间。这采取了易于维护和可重用代码的形式。每次你创建一个新函数来做一些痛苦的与另一个函数相似的事情，或者你创建一个新的类，这个类可以很容易地继承自更通用的东西，但几乎相同的，你正在剥夺你自己的时间和金钱，就像一个成帧者来回6次去做一些他或者(很少)她可以在一次旅行中完成的事情。在这两种情况下，回报都是花更少的时间在一项愚蠢的大工作上，以及一个更快乐、更富有的老板。|1189407|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

In, sort of a vague sense, construction taught me to think in terms of efficiency. When you're on a jobsite packing your work bags around, hauling lumber, dragging power cords through cluttered, unfinished rooms and hallways and generally breaking your back turning a huge pile of lumber and plywood into a house, you learn quickly that every move you make has to do something useful. This is especially true when you have a small business owner boss behind you, yelling about how he loses money every time you walk from point a to point b without taking something with you.

In programming, it can often be the same. Instead of saving your back, though, you're trying to save time. This takes the form of easily maintainable and re-usable code. Every time you make a new function to do something painfully similar to another function, or you make a new class that could easily be inherited from something more generic, but almost the same, you're robbing yourself of time and money, just as much as if a framer takes 6 trips back and forth to do something he, or (rarely) she, could have done in one trip. In both cases the payoff is less time working on a big stupid job, and and a happier richer boss.

blocks|key|4974703|text|我花了14年时间做工业工程类型的效率研究。这教会了我如何采访人们以获取信息，特别是当他们不合作的时候，以及如何从采访以外的来源获得信息(在收集需求时非常有用)，以及如何进行分析思考，尤其是如何从业务角度和用户角度真正理解数据。这在设计数据库时特别有用。当你不得不从许多设计糟糕的数据库中提取数据时，就像我在分析时不得不使用的一样，你会了解什么是有效的，什么是无效的。与普通程序员不同，我从成千上万个不同的数据库中提取数据。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4974704|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I spent 14 years doing industrial engineering type efficiency studies. That taught me how to interview people for information especially when they aren't cooperative and how to get information from sources other than interviews (very useful when gathering requirements) and how to think analytically and most especially how to really understand data from both a business perspective and a user perspective. This is especially useful in designing databases. When you've had to extract data from as many poorly designed databases as I had to use when I was ana anlayst, you learn what works and what doesn't. Unlike the average programmer, I've used the data from literally thousands of different databases.

blocks|key|4974766|text|有太多的东西无法计数，它们以各种方式联系在一起，使得这个问题有点修辞，因为编程本质上是逻辑和数学的混合，旨在与任何其他领域交互，为现实生活中的情况提供解决方案/自动执行任务。但是要实现这一点，您必须实现该域逻辑的一个很好的部分，以便做出一些有用的事情。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4974767|所以软件开发不是目的，它可能是一个解决方案，或者每个问题的解决方案都隐含着来自领域本身的概念。|4974768|我不知道我的答案是否涵盖了这个问题，因为在我看来，这个问题有点太笼统了。|4974769|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

There are too many to count and they relate in such various ways that make the question a little bit rhetorical because programming in essence is a mixture of logic and math designed to interact with any other field to provide solutions / automate tasks for real life situations. But to provide this you would have to implement a good part of that domain logic in order to make something useful.

So software development it's not the purpose, it's possibly a solution, or the solution to every problem implies notions from the domain itself.

I don't know if my answer covers the question because it's a little too general as i see it.

blocks|key|1197346|text|戴尔制造厂的一段视频启发了基于队列的分布式内容聚合系统的体系结构。队列上的消息表示工作项，具有从一个站传递到另一个站的工作表、任务、部件等。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1197347|每个站点代表一个特定的工作原型，每个站点在将消息转发回路由以进行转发之前更新工单。|1197348|系统在第一个版本发布后7年仍在生产中，每小时处理约30K个作业。|1197349|第一次看到系统“呼吸”是一个激动人心的时刻。|1197350|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

A video of Dell's manufacturing plant inspired the architecture of a queue based distributed content aggregation system. A message on the queue represented workitems, with jobsheets, tasks, parts etc. passed from station to station. 

Each station represented a specific stereotype of work, each station updated the jobsheet before forwarding the message back to routing for onward dispatch.

System is still in production 7 years after 1st release processing around 30K jobs per hour.

It was a thrilling moment to see the system "breath" for the 1st time.

blocks|key|1189748|text|好奇心和坚韧。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1189749|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The software development community is always open to new ideas to improve the way we develop software, and it seems to me that we innovate more than other engineering disciplines or professions.

However, it seems that it would be unfortunate if our relatively young industry failed to learn from established professions. There must be some great ideas discovered by people outside of software developmentthat we could benefit from.

Can you describe any ideas, techniques or processes used by other professions, that you have applied successfully (or not) to your software development?

What ideas from other professions have you applied to software development?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

软件开发社区总是乐于接受新的想法，以改进我们开发软件的方式，在我看来，我们的创新似乎比其他工程学科或专业更多。然而，如果我们相对年轻的行业不能向成熟的专业学习，这似乎是不幸的。软件开发之外的人肯定会发现一些伟大的想法，我们可以从中受益。你能描述一下其他职业使用的任何想法，技术或过程，你已经成功地(或没有)应用到你的软件开发中吗？

问您在软件开发中应用过其他职业的哪些想法？
EN

回答 18

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问您在软件开发中应用过其他职业的哪些想法？EN

回答 18

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问您在软件开发中应用过其他职业的哪些想法？
EN