我刚刚开始我的职业生涯，当时是一家中型公司的Web开发人员。一开始，我就完成了扩展现有应用程序的任务（多年来，由多个程序员开发的编码不佳的代码以不同的方式（零结构）处理相同的任务）。

因此，在我成功地使用所需功能扩展了该应用程序之后，他们给了我任务，以完全维护该应用程序。这当然不是问题，或者我想。但是后来我得知我被禁止改进现有代码，并且只在报告错误时才专注于错误修复。

从那时起，我像上面一样，又有三个项目，现在也要维护。我有四个项目，可以从头开始创建应用程序，我也必须维护它们。

目前，对于要维护的每个应用程序，用户（阅读管理员）的日常邮件使我略为发疯。他们希望我直接处理这些邮件，同时还要处理其他两个新项目（在那之后已经有五个项目在排队）。可悲的是，我尚未收到关于自己编写的任何内容的错误报告。为此，我只是偶尔收到了让我们做180度不同的变更请求。

反正这正常吗？我认为我所做的工作相当于整个开发人员团队。

当我最初希望情况有所不同时，我是白痴吗？

我想这篇文章已经变成了大声疾呼，但是请告诉我，对于每个开发人员来说，情况都不一样。

PS我的薪水几乎相等，甚至不低于超市的收银员的薪水。

在一次实习中，我发现我花了很多时间进行错误修复。您必须意识到，作为入门级员工，您不会获得最性感的工作，而您将获得别人都不想做的艰巨的工作。不幸的是，但这是每一项工作的方式。

此外，您必须意识到，对于公司而言，拥有有效的代码比拥有干净的代码更为重要。从公司的角度来看，您更改现有结构浪费了金钱，因为它们要重做已完成的事情并可能引入更多错误。通常，这些类型的公司不是计算机/软件公司，因此没有足够高的管理人员具备一定的技术背景才能知道有时您需要进行这些大修。就是说，如果您的公司由技术精湛的人员经营，并且他们了解良好代码的价值，那么您可能会获得更大的回旋余地，尽管有时您需要选择自己的选择（毕竟，企业的主要目的仍然是赚钱）。

也就是说，您希望能够在软件上留下自己的印记并希望进行更有意义的工作并非没有道理。不幸的是，在处理来自众多不同经理的请求时，您必须一次处理多个项目。

作为程序员，生活的事实是，与从头开始编写自己的代码相比，您将花费更多的时间来维护和修改其他人的代码。如果这对您来说是个问题，那么也许您应该坚持发展业余爱好并从事不同的职业。如果您可以维护代码，但是觉得自己没有被有效使用或不知所措，那么您需要与经理讨论。如果您的问题比那更严重，或者您觉得经理不知道如何有效地管理自己的技能，那么考虑在另一家公司找到职位将是一个好主意。考虑到您所说的低薪，这可能是您最好的选择。

听起来管理人员在管理工作量和确定任务优先级时遇到问题。您应该与您的经理交谈，并让他们了解您超负荷工作，并且如果每个人都不断用他们想要立即实现的要求轰炸您，则您将无法进行有效的工作。

这使您从一项任务转移到另一项任务上，浪费了很多时间在脑海中切换齿轮。为了进行有效的软件开发工作，人们应该能够将自己投入到一项任务中并完全专注于该任务。一个中断越多，上下文切换就会浪费更多的时间。研究表明，大约需要15分钟，浸泡，并获得州流在那里我们心灵的作品是最有效的。如果每15分钟中断一次，您将永远无法畅游，这对您和公司都是巨大的浪费。

因此，您应该尝试与经理协商一种更明智的工作模式。这应该包括对传入的请求进行优先级排序，并在一定程度上进行预先计划。所有用户请求都应按优先级排序在列表中。而且优先级不应该由请求者决定（因为自然而然每个人都认为他/她的请求是地球上最重要的），也不能由您来决定，而是由具有足够业务知识和对您所维护的整个产品概述的人来决定（该产品的所有者）。

理想情况下，所有传入请求都应输入到JIRA或Mantis之类的问题跟踪器中。或至少邮寄给产品所有者，而不是您。他/她还应该处理用户的所有抱怨，这些抱怨是“为什么我的请求还没有准备好？！”，使您可以专注于开发工作。如果这是无法实现的，那么在查看并处理传入请求时，至少应协商一些时间窗，为开发留出不间断的时间。

如果可能的话，下一步可能是在某种程度上提前计划。也就是说，估算实现最高优先级请求所需的时间，然后将您的时间安排到sprint中，每个时间可能要花一个或多个星期，然后将足够的任务分配给下一个sprint以覆盖您的时间。

您可能希望保留一部分时间来处理紧急请求，但其余时间可以提前计划。您可能还希望将不同项目的工作组织成单独的“条纹”，即在星期一进行项目A，在星期二至星期三进行项目B，在星期四上午进行项目C，在下午进行D，等等，以便进一步减少上下文切换。

这样，您对接下来一到几周的工作有一个大概的了解。此外，这也为您的客户提供了一个路线图：他们可以看到何时获得实施的请求。您可能会或可能不想在这里向经理提及“敏捷”一词-这基本上是敏捷开发，但是有些人反对敏捷，而实际上并不知道它是什么：-)

请注意，即使您的当前职位对公司而言价值较低，但您维护的项目越多，您的谈判能力就越强。

寻找和培训新员工以维护所有这些项目，对公司来说要花费大量时间（=金钱）。您可能会正确地指出，您的代码比这些应用程序的遗留部分要好得多，因此不能以相同的金额轻松找到具有类似功能的候选人。更何况，如果他们不改善工作条件，他们将未来的家伙厌倦了和退出一样快，因为你......尽量让他们明白，这是在自己的最佳利益，让您和使您在哪里开心：-)这可以使您有能力谈判上述条件，和/或要求加薪。

您拥有多少谈判能力-这是一个大问题。您的管理层可能会或可能不会对这些想法持开放态度，并且可能会或可能不会足够尊重您以认真对待您的请求。但是，如果您打得很好，就会有机会。如果他们拒绝...您总是可以寻找一个更好的工作场所。对于每个初学者来说，这种情况都不尽相同，尽管（很遗憾）您的经验很典型。但是确实有更好的工作场所。工作场所的质量与地理位置之间的关系并不紧密，但我的感觉是，在北欧，您的机会要高于平均水平。因此，如果您不能使当前的状况得到明显改善，则应立即开始寻找，直到完全厌倦并疲倦为止。

在您仍然有工作的同时找工作要好得多，因此您不必仅因为立即需要钱就接受第一份工作。最终您会找到一个更好的地方:-)

附言：我的薪水与超市的收银员的薪水差不多，甚至不低。

嘿，我想写一些有关如何谈判的东西，直到我读完为止。现在我只能说离开！假设这是拥有学位的开发人员通常收入的一半。假设情况有所改善，并且它们立即为您带来10％的增长，您就可以算出到达那里需要多长时间。看起来您在工作中什么都没学到，似乎也没有被出色的工程师所包围，所以这是浪费时间。

我也处于类似的情况，我可以告诉你，如果你坚持下去，它永远不会结束。管理层将继续为您服务，因为...他们可以。

关于此主题，我还有其他想法。

1. 做你爱做的。如果您不喜欢它，请准备好尝试发现自己可能喜欢的东西。

2. 通讯。清楚地传达您无法实现不切实际的期望的能力。在我的类似经历中，建筑师（铲铲工最多）说：“您必须管理其他人对您的期望。”

3. 燃尽。如果您还没有倦怠感，请不要去吸引命运。它使您的生命和灵魂无法自拔。尽管尽了最大的努力，您的工作目标却变得灰暗，沉闷且毫无意义。我提供此建议是因为您必须不惜一切代价避免倦怠。

4. 训练。这是一线希望。实际上，您的培训和经验虽然令人沮丧，甚至可能被低估，但对您的职业生涯却非常有价值。实现此目的是您的节省之选，因为您可以吸收尽可能多的知识，并延迟任何不可避免的玻璃天花板。

专注于您正在发展的人才和技能……这些将带您度过职业生涯的下一个机遇。

您正在这里处理多个问题...让我们从显而易见的问题开始...

这正常吗？

一定不行。但是...这很常见吗？不幸的是。

关于错误修复的挫败感

尽管这并不能解决您必须处理的其他问题以及它们使您过载的多个项目，但我只是想简短地指出“仅修正错误”的方法，同时让您对开发人员感到沮丧，对于公司及其管理层而言可能是一种非常明智的方法。

Surface带来更多错误和成本

您接触的代码越多，就越有可能引入错误，即使您打算改进它也是如此。这意味着将延长开发时间，测试时间和成本。而且，如果它进入到具有中等到高缺陷的服务版本，那对他们来说就是一团糟。

日志中的噪音/雾气

从SCM的角度来看，如果您直接从服务版本的分支机构进行工作，这也很有意义，因为您希望清晰地了解与错误修正有关的更改。如果围绕一个错误修正实际进行了15次提交，其中数千次更改实际上需要进行1行代码更改，那么这有点烦人。

因此，作为一名新员工，要求您不要重构和/或增强软件更为明智，并且就我的观点而言，对您的错误修正尽可能“外科手术”是可以的。它只是使头痛。

你能做些什么吗？

现在，这并不意味着将有既可以实现法规的合理性，又可以使相关人员的思想透明的方法。大三时，他们应该让某人检查您的更改，尤其是错误修正，并确保在将其应用于服务版本之前将其批准。这样可以防止或限制重大变化，并且更加安全。

地狱项目

废话代码，成群的程序员，复制，废话体系结构

同样，这里是恶魔的拥护者，但只是表明您的初始请求包含一些无关紧要的位。

我的观点是这样的：我真的真的真的很少接手一个代码库，这不是在这种状态下。而且，在我偶尔这样做的情况下，它们是最近开始的项目或原型，这些项目或原型是由出色的程序员启动的。但是，其中绝大多数惊人地看起来像胡扯，而其中的可怕数目却是实际的胡扯。即使是由优秀或优秀的程序员开始的工作，最终也可能会被废话，截止日期和其他工作所帮助...

欢迎来到现实生活中的工业软件工程！

你知道有什么好玩的吗？在网络开发世界中，情况通常更糟。请享用！:)

项目和请求太多，没有足够的人力和时间

问题可能出在这里：

• 您的管理人员（可能在不知不觉中）虐待了您，
• 您的同事（可能不知不觉中）虐待了您，
• 您的（也许是在不知不觉中）没有掩盖您的屁股并没有进行足够的战斗。

您的经理应该意识到您正在管理的项目太多。如果不是，请确保它们尽快。还请确保他们知道，这并不是公园里所有挑剔的事情，您感到压力很大，需要停止。

尝试四处看看，并确保您的同事不会（直接说“ X能够解决这个问题”）或间接地（“我不是合适的人选”来转移您的更多任务和项目）这个，找到其他人”->最终成为您）。

个人轶事：几年前，我进行了一次实习，直到最后一天，当我得到我的评估时，我的老板告诉我，尽管对我的整体工作非常满意，但其中一位经理感到我当他们本来希望我接他们的时候，就一直在另一个实习生身上卸下一些“不太有趣的任务”。我羞愧让他们感到失望的，在这个想法，我会像我懈怠，当我的意图是完全相反的：我试图抓住更难的任务，并有其他年轻的实习生处理头发少拉问题。我几乎没有意识到，如果我一直处于他的位置，我会因为缺乏挑战而感到无聊，并且可能会感觉到他的方式。关键是，您需要进行交流以确保没有人对3个非常不同的事物做出错误的假设：

• 你能做什么，
• 你想做什么，
• 以及你愿意做些什么。

因此，让它成为这种方式在某种程度上也是您的错。但这很正常，这是每个人都需要学习的课程。它包含两个字母：N - O。

通常，您将它作为前缀使用，以获得更冗长但收费不高的答案：不，我不能这样做。不，我不知道该怎么做。不，我不确定我是否合适。不，我从未这样做过。

首先，很容易感觉到您可以说“是的，我会（最终）做到这一点”，然后把事情堆起来并完成，也许要花一些额外的时间。这是错误的。您需要了解，在您的技能之后，时间是您和公司最宝贵的资产。如果滥用，则会影响项目，截止日期和预算。就如此容易。

另外，您担心会有太多人要向其报告，这让人有些担心。可以与多个客户打交道，并且需要与多个项目所有者甚至主要利益相关者进行沟通。但是，总的来说，尤其是当您是新员工时，您应该只向少数几个经理报告（很可能仅向您的直接经理报告，并且可能是主管或高级开发人员）。它是怎么得到的？我不知道。这可能是您公司的组织问题，也可能是您帮个忙，然后直接与您联系，而拒绝说“不”的结果。就我所知，也可能是您的直接经理遇到调度任务的问题（我确实在猜测，但是这种模式是可以识别的并且众所周知）。

我建议您相当快地执行以下操作：亲自去拜访您的直接经理，解释其他经理可能有点急躁，或者（可能不那么发牢骚）您有太多人堆砌的东西，并且您需要他的输入（也可能需要他们的输入）才能确定要优先处理的输入。

180度变更请求

这些是另一个大问题。他们可能不是您的错，但您可以尝试帮助他们解决问题。

正如您精美而又准确地称呼它们为“ 180度变更请求”一样，它清楚地表明需求从一开始就很模糊，而且没有人会尽一切努力使它们随着时间的流逝而被清理和清除。

通常这是当有人需要打电话（或者更好的是，站着），用手抓住利益相关者并清楚地告诉他们：“那是我们的所在，那是您希望我们去的地方，您确定我们在吗？朝着正确的方向前进？”。在一开始就没有明确的答案是可以的，但是时间越长，它们应该变得越清晰，或者这个项目正在等待灾难的发生。

通常，我会说要抓住所有利益相关者，将他们放在一个房间，引导他们解决诉讼问题，并逐步尝试解决这些问题-并在解决问题时优先考虑。但是，根据您的情况，这可能不是您的要求。但是您提到他们确实给了您项目的责任；因此，如果确实如此，那就要承担责任并做到这一点。并且不要回避说“我们不能那样做”，甚至“我们不会那样做”。限制项目范围确实很重要。

如果没有范围，则讨论结束时没有明确的要求。

电子邮件超载

人们倾向于根据他们使用的通信媒介来表现不同。就我个人而言，尽管我是一个很会说话的人（并且大部分时间都在国外工作，所以我最终也不想和别人通电话），但我还是希望优先选择基于生产率的工作：

• 与人们面对面交谈，
• 和别人通电话，
• 通过即时通讯与人交谈，
• 通过电子邮件与人交谈。

电子邮件非常适合跟踪，获取确认，发送便笺。

对于安排，计划和讨论问题点，它们几乎是无用的。敲开他的门，直到他/她打开门，然后坐下来用记事本和您的文件副本进行澄清。完成后，请发送电子邮件并要求确认。如果返回否定答案或稍有隐藏的尝试在信封中偷偷摸摸的东西，请再次包围对话者的办公室。

这是软件工程。当您不敲键盘时，它通常会更有效率，并且实际上可以减少您需要处理的废话。

做好团队的工作

您是否正在完成相当于团队的工作？也许。

您是否正在完成与团队工作相当的工作？可能不是。

我的意思是，您的团队可能正在忙于工作，而您却过度劳累。这就是问题所在：您不知所措，应将其从当前项目时间轴中推出，或交给有时间的人。

当我最初希望情况有所不同时，我是白痴吗？

没有; 刚参加聚会。就像是第一次宿醉或恋爱。你会克服它。

我想这篇文章已经变成了大声疾呼，但是请告诉我，对于每个开发人员来说，情况都不一样。

对于混乱的组织中的每个开发人员而言，情况都是一样的，无论它们是初创公司还是成熟的巨头，都没有经验或信心让事情发生一点变化，以使您的生存机会在规模的右边。

附言：我的薪水与超市的收银员的薪水差不多，甚至不低。

我为那些看上去很烂的工作做了可观的薪水。计数不是支票上的数字，而是上下文。您的工作，年龄，居住和工作的地方等...

话虽这么说，如果您的薪水严重不足，工作过多且不完全是初级，请去要求加薪或找一份新工作！

这很简单：

• 如果他们重视您的工作，他们会很乐意同意加薪，
• 如果他们不这样做，那么这家公司的前途看起来并不乐观（至少对您而言，这才是重要的），所以不要为离开而感到难过。

请注意，要求加薪是一件好事，即使一开始您都不会这样认为。它可以证明您一直在跟踪自己的工作，并暗示您在仍然愿意留任的同时关注其他选择。习惯于要求他们是一件好事，因为它们就像工作面试或讨价还价的一般：这是需要练习的东西，如果您自己无法达到要求，它们就不会从天而降。一些公司会在没有要求的情况下定期分发加薪，但这仅仅是因为它们足够聪明，知道它会使您半满幸福且不愿改变，而且他们想在脚下割草（大多数人会感觉到对于直接提出要加薪的提议有些不安）。

在这里，如何进行此请求超出了该项目的范围，因此我将不赘述。但是我建议您准备一个记录，记录您的SCM提交ID，已解决的错误和成就，并准备与团队的整体工作进行比较的报告。这条路：

• 您可以自己衡量自己是否有效地做得比同龄人好得多，
• 如果他们说您的要求不合理，那么您可以坚持自己的立场。

除了其他人的评论：

1. 是的，为入门级员工提供其他人都不想做的工作是正常的。

2. 您应该将其视为未来职业的基石。

那你该怎么办？为了证明自己是一名专业的开发人员，您需要确保工作的结构和计划是合理的，否则您可能会发现很难依靠当前正在做的好事情-因此，您应该尝试执行以下操作（如果您还没有）。

1. 准确记录每个项目的工作。因此，如果您花费一个小时来修复项目A的错误，请记录此时间。如果您想讨论工作量，这对向经理显示很有用。

2. 编写单元测试。您提到您维护的某些项目中充满了错误，因此我猜测几乎没有（如果有的话）单元测试。对于每个错误报告，编写一个复制该错误的单元测试，然后修复该错误。这将有助于确保不会发生退化，提高代码质量，并在有机会的情况下作为重构代码的平台（例如，它可以帮助您说服利益相关者相信重写某些部分可以改善代码）由于采用了单元测试套件，因此不会引入新的错误）。

3. 寻找新工作-您一次处理多个项目，从头开始编写代码，并且可能已经经历了整个项目生命周期-这些都是在其他地方应用的良好经验。

您的情况有点前卫，但仍然很正常。但是您处理它的方式非常糟糕。这是您需要做的：

• 尝试面对老板。您应该有一些证据（数字）来证明不良代码库实际花费了多少时间。如果他不了解技术债务之类的内容，请停止提及。这会伤到你的头，你可能会被标记为“态度不好”的家伙。教老板做他的工作不是你的工作。

• 维护您自己的待办事项（看板）。当有新任务出现时，将其结束，并告知预计的完成时间。

• 增加您的响应时间，每天检查电子邮件两次。通常在午餐前和就在您离开之前。（检查电子邮件后不应进行编码，因为这可能会伤到您的头）。

• 在每个任务中进行少量代码改进。改善您正在使用的代码，技能和工具只是您的工作。从长远来看，这也会提高你的道德。

• 白天没有项目切换。今天，您仅在X项目上工作，明天将开始Y的其他任务。

• 每天分配一小时以保持门禁。这意味着琐碎的小任务。如果此任务花费的时间超过10分钟（原因无故），它将进入待办事项列表，并且您通知管理员，此任务将被延迟。

现在是困难的部分。当前，经理之间并不相互交流，只是假设您将以最大的优先级完成他们自己的项目。这会给您带来很大的压力，因为您处于争论的中间。您需要迫使经理开始协调您的工作。最后，您应该有一个很好且简单的待办事项列表，经理们应该在没有您的情况下互相欺负。

因此，让我们做一些简单的角色扮演。有三个经理和项目（Xavier和X项目，Yvonne和Y项目以及Zed和Z项目）。您有两个星期的积压订单，X为5天，Y为5天。

• Z要求您完成某项任务（1天）
• 您回应说它将在11天内完成。
• Z表示这是一项简单的任务，不应花费超过一天的时间（注意Z施加的压力较小）。
• 您回答您当前正在为X工作，后者正在为Z工作。之后您可以完成她的工作。
• Z回答您无论如何应立即执行任务（压力增加，直接侵犯X和Y区域）。
• 您回答说，完成她的任务会延迟X和Y的工作。他应该先问他们。您也CC X和Y。

现在有两个目的：

• 经理们将开始互相吠叫，发送许多电子邮件，甚至可能召开一些会议……您应该远离，让获胜者为您分配任务。

• 什么都不会发生，Z将在两天后问您他的任务在哪里。您回答您当前正在为X工作，他没有提及有关项目Z的任何内容。再次CCX。

现在，这种行为可以使您被解雇。但是您的情况是不可持续的，无论如何您可能很快就会退出。仅当管理人员相互竞争（通常）时，此解决方案才有效。您还应该保留工作记录（积压），以防有人抱怨您懈怠。

七年前，我做了一段时间几乎100％的维护工作，并写了一篇关于它的文章：维护编程的艺术。您可能会发现有用的一部分：

1. 喜欢它

谁能喜欢维护编程？开发人员梦想着成为团队的首席架构师，而当他们最终维护现有软件时，感觉就像是一种惩罚。不必一定是这样：维护程序设计有其自身的挑战，并且需要很多创造力，适应性，耐心，纪律和良好的沟通。这也可能对您的职业生涯有好处：简历中有“ Architected n-tier 24/7 enterprise application”等大型条目看起来不错，但雇主实际上很看重解决问题的人。维护编程可能是证明您解决问题的技能的好机会。

您的问题听起来像是您经常听到的某事。这似乎是一项很容易适合《每日WTF》的工作。

许多组织更注重销售或功能推销，而不是质量。这些公司看不到的是，软件的外部品质不仅仅体现在外部。沃德坎宁安（Ward Cunningham）创造了技术债务一词。

您可能还想阅读有关技术债务的史蒂夫·麦康奈尔（Steve McConnell）。他有一些有趣的观点。在Google Tech Talk中，Ken Swaber讨论了敏捷软件开发。很大一部分是关于一个与您相似的故事。他谈到了一个软件项目，该项目在经过各种程序员的10年编程之后，已经成为“脑残”，而从未进行任何重构。我认为，如果您看到此视频，将会发现与您描述的内容有很多相似之处。

扩展任何软件系统的质量都会降低。实际上为了征求意见，必须这样做。在雷曼法律解释这个原理相当不错。最终它将归结为以下问题：“我如何说服您的老板进行重构？” 。

我如何处理类似的问题：

• 我遇到了老板，并解释说，随着我们的不断发展，代码质量会下降（雷曼法则）。
• 我试图向老板解释技术债务的概念。从长远来看，他让您工作的方式将使他付出金钱。
• 为了实际显示问题的严重性，我（在自己的时间内）进行了静态代码分析。老板不懂软件，但是他们懂数字。尽管代码指标有其缺陷，但最好还是有一些可以衡量的话题。尝试找出这些指标的正常读数，将其与自己的代码库进行比较时会感到惊讶。
• 如果没有任何帮助且没有任何变化，那么您唯一能做的就是说明某种新功能将需要对代码库的其他部分进行一些修改。解释一下，如果您有重复的代码，并且他们想更改某些内容，那么更改的成本也会重复。
• 对上述观点的一个常见答案是，没有人要求这样做，因此没有为这项返工付费。“也许”这种返工是多余的。您将不得不解释，软件将始终必须进行更改。就像雷曼法则所说；它必须进行更改才能继续使用。如果没有，其他进行更改的程序将永远失效。那些期待改变并能够适应改变的人才能生存。这就是敏捷软件开发的全部内容。（维基百科）

如今，我的老板使用技术债务的概念来向客户说明，有时我们需要对所构建软件的某些部分进行返工。只是为了证明-如果您有一个合理的老板，就有可能使事情变得更好。

对于许多新生来说，您面临的情况几乎（即使不是完全一样）。

这发生在职业的最初阶段。这里有个要点：我们必须克服这个问题，并向公司（无论是中型还是MNC）证明我们的价值。我们应该能够根据情况需要我们做决定。因此，只要您为工作付出努力并以个人身份工作就可以了。如果您物有所值，该公司将予以通知！Adios，祝您好运。

我认为，禁止重构的公司不值得工作。重构是一项必不可少的软件开发技能，而版本控制工具使隔离开发非常容易，而又不会破坏“主干”（以防重构确实破坏了某些东西）。正如鲍伯叔叔说的那样（释义）：“您应该不要求成为专业人士并做好工作。”

维护编程绝对不应永久保留错误的代码。

五年前，我收到了我一位朋友的来信。

Email body:    

一名新加入的实习工程师问老板“评估的含义是什么？”

老板：“你知道辞职的意思吗？”

见习生：“是的”

老板：“那么，让我通过将其与辞职相比较来使您理解评估是什么”

Comparison study: Appraisal and Resignation
|---------------------------------+----------------------------------| 
|       Appraisal                 |       Resignation                |
|---------------------------------+----------------------------------|
|     In appraisal meeting they   |    In resignation meeting they   | 
|     will speak only about your  |    will speak only about your    |
|     weakness, errors and        |    strengths, past achievements  |
|     failures.                   |    and success.                  | 
|---------------------------------+----------------------------------|
|     In appraisal you may need to|    In resignation you can easily |
|     cry and beg for even 2%     |    demand (or get even without   | 
|     hike.                       |    asking) more than 10-20% hike.|
|                                 |                                  |
|---------------------------------+----------------------------------| 
|     During appraisal, they will |    During resignation, they will |
|     deny promotion saying you   |    say you are the core member of|
|     didn't meet the expectation,|    team; you are the vision of   | 
|     you don't have leadership   |    the company how can you go,   |
|     qualities, and you had      |    you have to take the project  |
|     several drawbacks in our    |    in shoulder and lead your     | 
|     objective/goal.             |    juniors to success.           |
|---------------------------------+----------------------------------|
|     There is 90% chance for not |    There is 90% chance of getting|
|     getting any significant     |    immediate hike after you put  |
|     incentives after appraisal. |    the resignation.              |
|---------------------------------+----------------------------------|

见习学员：“是的，老板，我现在已经了解了我的未来。要进行评估，我将不得不辞职……！！！”

如果您是我，我会在下班后花一些时间免费重建应用程序。这可能是一个有趣的任务。完成后，向老板展示。如果它可以正常工作并且您正在对其进行维护，那么他就不必担心。这将使您的工作更加轻松，并使更高层次的公司看到您在公司中的潜力。

我是一名全职大学生，在做兼职实习，每小时10美元。我所做的质量检查工作很无聊，重复且容易。我认为自己非常幸运，因为我知道有一天它将为更大更好的地方敞开大门。

是的，您将始终需要维护由您和其他人编写的应用程序。唯一的例外是，如果您编写的程序永远不需要任何维护。因此，您最好擅长维护。

我认为您的方法存在缺陷的问题中有一个微妙的暗示。也就是说，修复错误不涉及改进代码。

但是后来我得知我被禁止改进现有代码，并且只在报告错误时才专注于错误修复。

我不敢相信有人告诉过您“您必须在不改进代码的情况下修复错误”。这既困难又不可能。您不能做的就是仅仅因为您不喜欢或很难理解现有代码库中使用的方法而重新编写应用程序。

我的建议是学习重构。每当您修复错误时，就有机会至少改进一些代码。重构多少代码库取决于错误是什么以及代码的好坏。但是，如果您要修复错误并故意在各处散布代码的味道，那么您就不会做自己的工作，并且会增加技术负担。

实际上，仅通过重构就可以修复一些错误，有时重构对于帮助您理解代码很有用。这是因为重构应该改善代码的可维护性和一致性。

当我估计一个错误修复程序时，通常会决定是否进行大型重构是实现此目标的最佳方法，并考虑到这一点。单元测试也一样。这两件事都应该是您编写代码的一部分，而不应是涉及额外时间的可选内容。

因此，您不应该问“修复错误后是否可以改进代码？” 因为无论如何你应该。您不应该问“我可以使用重构来修复该错误吗？” 因为如果迫切需要重构导致应用程序故障的代码，则无论如何都应该这样做。您不应该问“修复此错误后可以编写单元测试吗？” 因为您甚至应该在尝试修复错误之前就编写回归测试。

注意：我觉得这个答案应该归功于杰夫·阿特伍德（Jeff Atwood），因为我链接了他的3篇文章。

这全是关于金钱的。我的猜测是，作为一个入门者，对于那些已经获得了超出其支付能力的客户，您可能会太客气了。

学习为新要求报价。这远非易事，客户经常会尝试您。如果可以，请寻求经验丰富的项目/产品经理的帮助。

一旦您考虑到金钱，与管理层的交流就变得容易得多。如果您当前的客户提供全职资金，则不应选择新项目。但是您会了解到，管理层仍然会尝试欺负您。

如果您确实对公司有价值，那么您将获得议价能力。您可以要求他们雇用更多的人，减少新项目的产生，帮助您减少维护工作量或增加薪水。

如果禁止您改进现有法规，则不应该由您的雇主决定对您进行微观管理。使用您自己的专业判断。当您估计工作量时，如果将来可以提高生产率，我会考虑增加时间以进行一些重构。

无论如何，看来您没有与雇主有效地沟通。

1. 您有证据表明重构可以节省成本。为重构项目起草提案，并演示企业可以节省多少时间和金钱。精确概述您将对代码进行哪些更改以及需要多长时间。

2. 保留准确的日志以记录您在编码，会议和应答电子邮件上花费的时间。如果您不按计划进行，这将为您提供保护。

3. 慢一点。这似乎有点反常理，但是如果您快速进行所有操作，只会浪费您的时间。如果您少做事，人们会更加尊重您的时间。例如，我每天只检查一次或两次电子邮件。否则，您可能会精疲力尽。

4. 考虑到您的工资水平，不值得头疼。确保您每天准时离开。不要在没有额外补偿的情况下加班。例外是，如果有很好的晋升选择，或者公司的声誉会大大提高您的履历，那么您只需要吸收履历即可。

在不了解更多信息的情况下，我只建议您尝试与经理保持更加开放的态度。也许开始增加您的任务估计。不断提醒他们您的工作量有多忙。另外，您应该与老板会面，并说明您希望在未来六个月内增加薪水，并询问如何改善业绩以实现这种加薪。

祝好运。

以我的经验，学术界或面向技术的初创公司的头6到12个月是您遇到真正空白的仅有的两个可靠领域。他们俩都有自己的成本，但是如果您喜欢编码，并且经常被野外发现的编码质量吓倒，则应该开始将职业指向这些方向之一。

尝试与您的雇主交谈，看看是否可以解决此问题。听起来您对此事不敢恭维，这与成为一名不良程序员无关。

小型网络公司倾向于同时进行许多项目，这在很多方面都使您处于困境。尽量利用自己的情况，或者如果可以的话尝试寻找新工作。我保证那里会有更好的编码工作，所以不要让第一个吓到你。

祝您好运，我希望您和您的同事都了解自己的努力或努力！

个人经验

像这里的许多人一样，我也了解您的情况。我基本上是第一个低薪的编码工作，并且不得不维护很多结构较差的内置代码。起初，我发现学习新知识很有趣，但是当我最终要维护很多项目，要制作新项目以及白板每天都在做着越来越多的事情时，我发现自己没做完，我意识到它没有用。

忍了两年之后，我辞职了，几个月后又找到了另一个编码工作，非常适合我。

无论如何，很多时候可能不仅仅是问题所在。当我得到工作的认可和尊重时，我发现自己在工作场所更舒适。您所处的情况的问题在于，您的雇主可能只注意到由创建的项目引起的错误，而不是消除所有其他错误所花费的时间。

薪水

如果您想要更多的钱，通常可以得到。在不到两年的时间里，我设法将我的薪水提高到33％。

基本上，请考虑您的工作价值以及公司对您的需求量。如果他们负担不起给您的薪水，那么公司要么需要考虑他们的支出，要么要意识到他们的业务无效。

正如许多人在这里提到的，我同意，您是公司难题中非常宝贵的一部分。地狱，您可能是唯一可以解决这个难题的人。:)

由于我是这个Stack Exchange网站上的潜伏者，因此我无法发表评论，所以我将在此处添加信息。

1. 由于您才刚刚起步，因此除非您去过像Microsoft，Amazon之类的大公司工作，否则您的薪水将不会很高。但这不应该是杂货店员工！不要长期忍受，要积累经验做自己的事情，并在出现更好的机会时继续前进。

2. 对于入门级演出，这很正常。您的工作量太高，但是工作类型是预期的。要成为更好的开发人员，您必须学习别人的错误。您看到的越多，您就会变得越好。但这意味着您正在寻找可以学习的东西，而不是学习不良习惯...

3. 维护与项目工作的比例应随时间推移而变化。如果不是这样，则意味着您所在的公司没有意识到如何留住优秀的开发人员。他们打算让您日复一日地做同样的事情。为自己设定年度目标，明智地考虑薪水和工作期望，并相应地移动。

4）如果你不开心，就走！生命太短了，无法与愚蠢的人打交道。

祝一切顺利。

您开始使用问题跟踪器来跟踪待办事项列表。

这不仅可以帮助您跟踪关键问题，而且可以帮助用户和老板了解当前的工作量。

另外，如果他们再雇用第二个开发人员（或者您辞职并且您的替代者现在承担了您的工作量），这将有助于管理工作量，并且您将能够避免互相踩脚。

打破这一链条的唯一方法是开发新的基础架构，这些基础架构的设计旨在提高灵活性，并经过完整的单元+集成测试。

如果您设法将其出售给管理层（在1：1会议中将其他开发人员和管理人员签到该概念），则可以慢慢达到一种状态，其中大多数应用程序的代码都在基础结构中，并且很容易扩展和维护，而实际应用程序的权重很轻，可以很快地编写出来。

基础设施的发展可能使得一开始可以替换现有应用程序的一部分，而在一会儿（可能要花费几年）之后才能替换整个应用程序。

从长远来看，它可以大大减少新应用程序的开发时间和未来现有应用程序的维护时间。

新开发需要至少80％的奉献精神（最好是更多的奉献精神），并且要有一个以上的团队（一个人比一个人更好）。所有开发人员都将需要能够创造性地思考并打破现有的观念。

尝试定义和高层设计这样的新基础架构，然后将定义呈现给您的对等方和管理层。

根据您的工作条件，要求领导一个新的基础架构团队来处理这些问题（根据您的定义和设计），并请新的开发人员维护旧的东西，同时在必要时为您提供帮助（最多占10-20％）。时间）。如果管理层同意这个想法，您可以要求重新谈判您的条款。如果他们拒绝，请准备寻找另一份工作。（请记住，您的工作需要技能，知识和经验，要像您付给他们的钱那样，您就不那么容易被替换了。）

您的经理是否了解所有这些变更请求（维护请求）？他/他是否意识到您的时间已经花在了您无权进行制裁的筛选上呢？还是您每次经理问您时都进行更改？

在我看来，您的第一个停靠站是将它们全部放在经理的办公桌上。没有人应该直接来找你。问题应该通过这样的领域来解决-通常是一个支持团队。通常，您会在较短的交接期内（通常是一周左右）来支持代码。在任何将自己归类为“中等规模”的公司中，更改都应计入成本并收取费用（转移费用），而且这似乎已被绕过（难怪它们会淹没您-您就像舞会上的荡妇）。

应该有适当的请求程序来提出问题和更改请求。支持/维护是关于修复错误和问题（符合原始规范，但由于代码中的错误或外部事件（例如，断电或上游系统损坏等）而失败。

如果您的公司不提供任何服务，并且希望您应对众多随机请求并对此负责，那么您就需要认真考虑。薪水总是最差的-在我的第一份编程工作中（差不多25年前），我在同一家公司工作了8年，薪水涨幅很小（尽管它总是比收银员高得多！）。离职后的两年内，我的收入翻了一番-两年后，我的收入是我开始时的十倍（但后来成为独立承包商）。与往常一样，为您赢得马刺，学习您的贸易，然后跳船到温暖的环境。

也许您可以去找经理说：“看，我会很坦率的告诉我。我的薪水太糟糕了，作为X的入门级程序员，我可以获得N倍的薪水。

我在A，B和C上做太多事情。我无法维持这一点。老实说，我并没有故意冒犯，我要带着固定的或者我的辞职信离开你的房间。现在一切都已浮出水面，我们如何才能共同努力实现这一目标？”

答案是尝试用可以理解的术语进行解释；

• 这就像换油。它们并不紧急。。。但是必须定期进行。
• 涂上铁锈，看起来会很棒。直到流血为止
• 在不加强支撑的情况下建造新的屋顶露台屋顶桌。它可能会工作一段时间。然后它将崩溃并伤害人们，您将承担责任。
• 空调很棒。一个窗户单元适合一两个房间。试图在一栋公寓楼中放置146扇窗式空调，您将遇到问题。
• 教5个孩子很好。10还不错。但是有限制。尝试非正式地教75个孩子，您会看到的。

如果这些没有引起共鸣。离开-写作的第一天，而不是第二天！拥有新工作后，请零通知离开。从字面上看就是那天不来。但是，请确保您有一个或两个知道您的工作的同事。如果可以帮助公司，这实际上可以通过向他们表明他们的不尊重和傲慢是有代价的，从而帮助公司。上一家公司，我在6个月内就进入了四项技术三项殊荣，没有工作可去。它至少发表了一个声明，并给离任者一次很好的机会说：“是的，很高兴您每天都说，但是您实在太忙了，我什至没有让您满意我的通知。

最后，一定要知道，这件事是NORM和20年前的标准，然后敏捷，tdd，bdd和重构才成为标准。您可能正在与高级人员交谈，他们会立即做出反应：“好吧，我自己做了，这很好，等等，等等，等等。” 好吧，肯定的马车在150年前就运转良好。在技​​术领域，20年前的技术与150年前的运输一样过时。如果他们拒绝这项罚款。只需知道，他们将永远不会聘用任何会留下来的体面的现有技术开发人员。他们会遇到最坏的情况，这将严重损害他们的业务。如果他们依赖技术并且无法适应，那么它们将失败，最终这可能是您的最佳回报。它'

听起来您的管理层从根本上不尊重您或不了解您的工作负担。

您不应该实现所有通过的功能请求。您的经理应该充当您和传入请求之间的缓冲（也许最简单的中断/修复请求除外）。然后，他或她应与您坐下来，确定所有批准的请求的可行性和优先级。

另外，您应该赚到的钱至少是他们付给您的钱的2倍。

听起来他们可能真的真的需要至少1个开发人员才能与您一起工作，但是如果他们付给您的钱听起来很不可能。

如果他们不愿支付足够的薪水或帮助您管理工作量，我会寻找一份新工作。您想在团队的某个地方工作，并与您的管理层一起完成项目。尽快下沉那艘沉船。

在一个团队中成为英雄只会让你筋疲力尽。

我只是一个学生（仍然），但这很正常（从我的实习经验来看）。这就是在支持和Web应用程序中工作时得到的。

我建议您在开始编码之前了解客户（经理）的需求。这可能很棘手，因为有时他们自己不知道，所以要与他们一起工作，直到他们达成共识。在编写最终解决方案之前，请确保双方都同意。

另外，如果您是维护者，则可以在代码中进行几乎任何更改-只需确保它不会更改行为或引入错误即可。我希望管理人员不要“允许”您进行任何更改，因为他们已经习惯并对现在的状况感到满意，并且他们不想为任何新的更改付费。

最后，不要担心是否因为做其他事情而无法处理某些事情。我建议您让人们知道您不堪重负，他们的要求将需要时间。如果您不这样做，经理只会认为您很懒。让他们知道您已经在工作，他们可能会雇用更多的人。他们没有其他方法可以知道一个人的工作量太大。

这是一个项目管理问题。使用某种项目管理来确定最优先处理的事情。

a）您需要处理积压的项目。您已将改进代码的计划放在了积压中。

b）所有错误均已积压

c）待办事项的优先级。

d）您按优先顺序进行所有操作。

错误可能是一个更高的优先级，但是，一旦修复了所有错误，您就有时间花在新功能或重构设计上。

如果您只是逐步进行重构，这是最简单的，因为您可以跳过那些有问题/错误要修复的部分。然后您可以告诉管理层：“我必须修复A，但是B基本上被破坏了，我必须执行解决方案C来解决所有问题，以便将来D变得更容易/更便宜”。反模式，C =解决方案，D =未来收益

如果您不能将工作证明为值得做的投资，那么商人永远不会接受。

这和往常一样。只要您继续在那里工作，您就会被剥削。继续使用此模型，而不是让您对自己的工作感到高兴，符合公司的最大利益。归根结底，他们并不在乎。这是关于为他们创建可靠的代码，如果您是单人乐队，那么他们肯定会帮助您。他们为什么要改变？

所有这一切的好消息是，即使他们不知道，您还是他们的VIP。我建议要做的是在跳船之前排队更多的机会，然后抓住机会，要求更高的薪水。如果不能再寻求更好的机会。我认为，您应该很快就能找到更多激动人心的工作。力求最高。进入开发人员商店后，您会更快乐，例如Google或一些有趣的创业公司，那里有协作的开发人员文化，您将真正感到高兴。

我个人所做的就是使用一个猎头承包商组织，并迅速获得了很多出色的经验，在彼此之间迁移的同时仍然保持承包商的稳定工作。它可以防止您感到无聊和挑战。最终，在业余时间，我建立了一些小公司，后来发展为实际业务，然后我从承包工作中跳了出来。