Questions tagged «organization»

我最近辞掉了在mega-corp的全职开发工作，因此我决定找一份兼职工作。从那以后，我与六位潜在的雇主进行了交谈，当我说“兼职”这两个神奇的词时，他们每个人都有相同的反应-他们全都闭上嘴，变得可疑。现在，我知道这可能只是我自己，所以当我控制时，我问每个人如果我愿意全职工作会怎样，他们都说我可能会拿到一份薪水。 我的问题有两个： 为什么作为雇主，只因为他想每周工作3天而不是5天，就放弃一个有能力的，甚至很棒的开发人员？ 我如何更好地销售兼职故事？我通常只列出自己的原因，这些原因是我更喜欢目前的生活平衡，并且想从事自己的项目，但这使他们更加可疑-我是否要自己开始做某件事然后退出？我只是懒惰吗？

164 organization 

我目前是一家大型公司的高级研究软件工程师，在其他地方也可以担任“高级人员工程师”职位。我不确定新职位的头衔是横向变动还是晋升。 因此，在所有其他条件大致相同的情况下（薪水，专业知识等），这些软件工程师职称之间的外部区别是什么（通常，并且与任何特定的公司无关，如果可能的话）： 高级工程师 高级研究工程师 高级工程师 技术人员 首席工程师 编辑：让我详细介绍“技术人员”，因为这种情况很少见。我认为这是一个很高的称号，通常与研究相关。我知道Oracle，VMWare和旧的贝尔实验室都拥有这些头衔。请参阅：技术人员。我知道这是什么意思，但我不知道它与其他书名是如何叠加的，这就是我问的原因。

94 skills  experience  organization 

软件工程师也应该充当技术支持吗？也就是说，公司应允许工程师戴上软件工程师帽和技术支持帽。如果工程师的大部分时间都花在技术支持上，这似乎会消除编写软件的能力。

48 organization  technical-support 

我正在与一些同事争论整个代码库的团队所有权是否比其各个组件的所有权更好。 我非常支持为团队中的每个成员分配大致相等的代码库份额。它使人们为自己的创作感到自豪，为错误筛选器提供了分配入场券的明显第一位，并有助于缓解“破窗综合症”。 它还集中了一个（或两个）团队成员对特定功能的了解，从而使错误修复更加容易。 最重要的是，它是由拥有大量投入的人而不是由委员会来决定重大决策的最终决定权。 如果有人要更改您的代码，我不主张要求获得许可；当然，也许代码审查总是对所有者负责。我也不建议建立知识孤岛：这种所有权不应该排他。 但是，当向我的同事提出建议时，我得到了很多回击，当然比我预期的要多得多。 因此，我问社区：您对在大型代码库上与团队合作有何看法？关于保持集体所有权，我缺少什么吗？

48 team  organization  code-ownership 

我一直看到职位发布为“ Java Software Developer III”或“ Software Developer II”。是否有任何官方文件对这些区别进行分类？

39 terminology  organization 

3个月前，我以.NET开发人员的身份开始了我的职业生涯，在针对各种技术，模式和概念进行了长期培训之后，负责监督我的开发人员决定我准备加入该公司处理的众多项目之一。 我很高兴终于能够开始编码。我加入的团队目前很小，因为正在开始一个新项目，这很棒，因为我参与了该项目的整个生命周期。它是一个基于Web的SPA项目，其支持使用ASP.NET MVC / ASP.NET Web API，并且在前端提供Durandal框架和相关库。 我的问题是，在与同事开会并确定下个月的任务和估计后，我发现自己处于一个不知道自己是否有能力承担任何任务的职位。 我从未完成任何已创建的任务，而且我不知道该如何进行。 例如，创建的任务之一就是为整个应用程序创建通用的错误处理机制。 当面对他从未完成的任务时，通常如何进行？

37 design  development-process  organization  junior-programmer  development-approach 

我想知道将我正在处理的项目分成两个存储库而不是一个存储库是否有意义。 从我可以说： 前端将用html + js编写 .net后端 后端不依赖于前端，前端不依赖于后端 前端将使用后端实现的一个宁静的api。 前端可以托管在任何静态http服务器上。 到目前为止，存储库具有以下结构： 根： 前端/* 后端/ * 我认为将两个项目都放在同一个存储库中是一个错误。由于两个项目之间没有相互依赖关系，因此它们应属于单独的存储库，并且如果需要，则应具有包含子模块的父存储库。 有人告诉我这是没有意义的，这样做不会给我们带来任何好处。 这是我的一些论点： 我们有两个互不依赖的模块。 长期拥有两个项目的源历史记录可能会使事情复杂化（尝试在历史记录中搜索前端中的某些内容，而您有一半的提交与所寻找的bug完全无关） 冲突和合并（这不应该发生，但是让某人推送到后端将迫使其他开发人员提取后端更改以推送前端更改。） 一个开发人员可能只在后端工作，但总是不得不拉扯前端或反过来。 从长远来看，将是时候进行部署。以某种方式，前端可以在拥有一个后端服务器的同时部署到多个静态服务器。在每种情况下，人们都将不得不要么克隆整个后端，要么创建自定义脚本以仅将所有前端推送到所有服务器或删除后端。如果只需要一个，则仅推/拉前端或后端比两个都容易。 反驳论点（一个人可能同时在两个项目上工作），使用子模块创建第三个存储库并进行开发。历史记录保存在各个模块中，您始终可以创建标签，在这些标签中，后端/前端的版本确实可以同步工作。将两个前端/后端放在一个仓库中并不意味着它们可以一起工作。它只是将两个历史合并到一个大型仓库中。 如果要将自由职业者添加到项目中，将前端/后端作为子模块将使事情变得更容易。在某些情况下，您实际上并不想授予对代码库的完全访问权限。如果您想限制“局外人”可以看到/编辑的内容，拥有一个大模块将使工作变得更加困难。 错误介绍和修复错误，我在前端插入了一个新错误。然后有人修复了后端的错误。对于一个存储库，在新错误之前回滚也将回滚后端，这可能使其难以修复。我必须将后端克隆到另一个文件夹中，以使后端工作，同时修复前端中的错误……然后尝试重新合并东西……拥有两个存储库将很轻松，因为移动了一个回购的HEAD不会改变另一个。并且针对不同版本的后端进行测试将是轻而易举的。 有人可以给我更多的论据来说服他们，或者至少告诉我为什么将项目分为两个子模块是没有意义的（更复杂的）。该项目是新项目，代码库已有两天的历史，因此修复还为时不晚。

30 project-management  version-control  git  mercurial  organization 

背景： 我目前是一个由4人组成的团队的成员：1个经理，1个高级开发人员和2个开发人员。我们为大约3500名员工的组织执行了一系列定制的内部系统/项目（例如6-8周），以及以前创建的系统所需的所有维护和支持。我们没有足够的精力来完成可能要走的所有工作-人手不足。管理层承认这一点，但是预算限制限制了我们向团队招募更多成员的能力（即使我们将薪金返还给了储蓄）。 改变 这使我们离开了现在的位置。我们的经理将继续担任牧场的新职务，团队中有空缺。管理层正在利用这一机会重组我们的团队，这将看到团队经理的角色被另一位开发人员和另一位高级开发人员所取代。他们的逻辑是我们需要更多的开发人员，因此这是一种为其筹集资金的方法（其中一个角色部分由另一个空缺职位提供资金）。 团队将没有直接的直线经理，而职位和职责将由上级和（相对较新的）服务经理（非技术角色，几乎没有开发知识/经验，其重点是共享的）来划分其他团队和个人）-谁将是我们在食物链中的下一位实际经理。 我猜最后一个问题是： 是否可以在没有经理的情况下运营开发团队？你有经验吗？哪些事情可能出问题/对我们有好处？ 理想情况下，我想“以这种方式来做事”，或提出一些反对的意见。

28 project-management  team  organization  team-leader 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 6年前关闭。 已锁定。该问题及其答案被锁定，因为该问题是题外话，但具有历史意义。它目前不接受新的答案或互动。 我正在阅读美国有线电视新闻网（CNN）上有关美国最高薪工作的文章。一个软件架构师被列为＃1。一个软件工程师列为＃9。和一个软件开发者（程序员）列在＃35。我认为用程序员代替计算机科学家是正确的，对吧？ 在此之前，我一直认为“软件工程师”是经验丰富的程序员和团队负责人的头衔。但是，“软件架构师”又适合什么地方呢？我阅读了CNN说明，但是它们并不能真正满足我的需求，因此我假设我可以从这里的优秀用户群中获得更详尽，经验更丰富的说明。 预先感谢您收到的所有回复。

24 terminology  organization 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 与其他3名Web开发人员组成的团队一起，我已经获得一年的首席Web开发人员的头衔。这是我的第一份工作。 我很确定我的角色是来自管理层。我很好奇其他高级开发人员的工作。我主要是好奇其他人作为其他组织的负责人/高级开发人员应承担的责任；因为我只在中小型公司工作过。 （a）一个组织的高级/主要Web开发人员会期望得到什么（无论规模大小）？ （b）网站开发负责人和高级网站开发人员之间有区别吗？ 我回顾了一些主题，只有一个主题在讨论您何时应该称自己为高级开发人员，而没有全面讨论高级开发人员应如何与其团队合作。

20 web-development  skills  organization 

我发现，每当我想运行一个过去的项目时，要花很长时间才能找到它，并且要重新设置一切才能运行它。 例如，我有在Linux中创建的python项目，它依赖于可轻松在Linux中安装的软件包，但是我不再拥有正在使用的Linux VM。我的其他一些项目依赖于其他变量，例如Web服务器配置，PATH变量，SDK，IDE，OS版本，设备等。 有人有解决此问题的有效方法吗？到目前为止，我只关心备份源代码，但是很难重建工作开发环境，也很难保持工作开发环境。

19 project  organization  development-environment  backups 

在任何团队中，您都将需要更多灰白色的开发人员和一些幼崽。一些原因包括： 钱。通常，有些任务不需要相同水平的经验即可交付，因此不要为完成这些任务付出高昂的代价。 能源。新人们可以带给团队充满活力和热情，以阻止其变得过时和过时。更高级的人可以带来平静和智慧。 知识转移和职业发展。无论是在项目还是在技能上，教人和学习新知识都是有用的，而且常常很有趣。帮助“培养”新的团队成员感到很满意。 我意识到有一些最前沿的项目，对于其中的高级人员要比初级人员要多，这可能很重要，但是总的来说，团队中是否有理想的经验组合，还是完全取决于项目？

19 team  organization 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 “跨职能团队”的一般含义是将达到目标所需的不同领域的专家组合在一起的团队。 但是，在敏捷看来，跨功能意味着不仅要合并不同的专家，还要使他们混合在一起。Henrik Kniberg 以此方式定义了跨职能团队：“跨职能团队意味着整个团队拥有构建产品所需的所有技能，并且每个团队成员都愿意做更多的事情，而不仅仅是他们自己的事情。” 但是线在哪里？是否要求开发人员成为测试人员进行迭代是否正常？

18 agile  team  organization 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引文回答。 5年前关闭。 我认为使用代号非常普遍。我们公司也在使用它们。 但我主要担心的是这些名称通常在任何地方都没有记录。意思是通过口耳相传。这些名称与它所命名的工具或实体的功能无关。 我看到了内部测试机以星座命名的模式，面向公众的服务器是以希腊众神命名的。项目以地名或一些随机选择的电影明星或人物的名字命名。但是，无论机器是Windows还是Linux，都无法直接从名称中获得任何信息。32或64位服务器。或项目是什么。 当我看到VCS的提交消息，即有人刚刚分支了“ Gandalf”项目或“ Callanish”项目或任何项目时，我只是感到不好过。出于同样的原因，您通常不会这样命名函数和变量。 我提议，至少对于新实体，我们应该使用更具描述性的名称，但是我面临着强烈的反对。显然，除我以外，组织中的每个人都喜欢这样命名。 那么为什么要使用非描述性的代号呢？ 不要误会我的意思，我没有问题地命名程序版本和里程碑，也没有出于营销原因而使用好的产品名称。但在所有其他地方，我希望看到描述性名称。 编辑： 为您提供一些背景信息：Gandalf是移植代码64位的项目。Callanish是将其移植到Android的...我宁愿将前一个分支称为64bitporting，将后者称为androidporting。也许附有后缀，表示我们计划将其发布的目标版本。所以每个人都知道它的名字。 有问题的服务器是我们在其上测试产品的虚拟机映像。不过，我不知道它实际运行的物理机。因此，将它们称为windowsxp_32，windows7_64，debian_32或solaris_64完全可以。

16 naming  organization 

我还是另一个Subversion用户，他在分布式版本控制的Tao中苦苦地对其自身进行重新教育。 使用Subversion时，我非常喜欢次项目方法，并且与大多数以前的雇主一样，我们将构建存储库分支；标签和主干如下： branches-+ +-personal-+ | +-alice-+ | | +-shinyNewFeature | | +-AUTOMATED-+ | | +-shinyNewFeature | +-bob-+ | +-AUTOMATED-+ | +-bespokeCustomerProject +-project-+ +-shinyNewFeature +-fixStinkyBug tags-+ +-m20110401_releaseCandidate_0_1 +-m20110505_release_0_1 +-m20110602_milestone trunk 在实际的源代码树本身中，我们将使用（类似）以下结构： (src)-+ +-developmentAutomation-+ | +-testAutomation | +-deploymentAutomation | +-docGeneration | +-staticAnalysis | +-systemTest | +-performanceMeasurement | +-configurationManagement | +-utilities +-libraries-+ | …

16 mercurial  organization  continuous-integration  svn  configuration-management