在错误的地方,正确的地方

我是一个性格内向的人,喜欢戴耳机并独立工作,而不必担心一次通话长达数小时。 因此,成为我的支持代理人并不是最好的主意…… 当我2014年1月加入Appian时,我最初加入了解决方案工程团队(当时称为支持工程)。 我敢肯定,你们中的许多人会看到“支持”,并想象有人在忍受不满的客户打来的电话而忘了插入路由器的电话,但这远没有那么简单。 在这里,我们不对您父母的15岁戴尔台式机进行故障排除。 没有“脚本”。有时问题很小,但是有时它们是客户大规模企业级网络体系结构中复杂的性能问题。 有时会很烦人,但是当您解决了一个重大的,影响收益的问题时,您会收获颇丰。 但是这项工作并不适合每个人。 此外,我真的很想念更接近编写代码的过程…… 我在车队度过的最忙碌的一个周末, 仍然让我臭名昭著。 从周五下午到周日晚上,我工作了近40个小时。 我开始通过电话聊天失去了声音,并一直处于疲惫状态,直到半夜才被唤醒。 当您让非技术经理喘不过气来解决这些复杂的问题时,很难不向别人开枪。 当您质疑您是否真的可以解决问题时,随之而来的是一个绝望的品牌。 在与我们的澳大利亚小组交接后,我终于在周日晚上8:00 pm左右注销。 我倒在床上,松了一口气,那问题已经解决了。…

我在编码训练营的前七周学习到的知识

在过去的七个星期中,我参加了由多伦多大学管理的在线编码训练营,而且训练营非常紧张。 事情开始的很好,最初的热情是开始新的事物,而重新唤起人们对做我小时候曾经爱过的事情的记忆。 最初的几周没有问题。 设置编码环境并习惯了一切后出现了一些小故障,但是讲座非常彻底,我的工作主要包括遵循非常好的书面和详细的说明。 随着课程的进展,他们开始参加DIY课程,要求您做以前做过的事情,但是这次没有任何笔记,因此课程变得没有任何难度。 在五个星期的时间里,我写了一个关于我自己的非常基本的静态页面,创建了一个在线课程管理系统,该系统首次使我们了解Javascript,用户管理和来自AWS的流视频。 但是我不想谈论我所学的技术,有很多,其中一些很棒,但是我意识到我正在学习的东西,比什么都重要的是如何在苛刻的环境中学习和这是值得反思的技能。 因此,以下是我对改变职业时的学习的看法: 您会感到沮丧-学习任何新东西都会带来沮丧,尝试在50岁时这样做会更加困难。 您花费了一生的掌握技能,将自己带到了现在的位置,现在这种感觉已经消失了。 适应它。 没有人说换工作会很容易,所以要准备好自己的深度,接受您将需要寻求帮助并在需要时去寻求帮助。 随时随地通过Google交流的人们-结识新领域的大师或专家。 尽管Google真是令人赞叹的天赐之物,但没有什么比让某人解释一个概念或使您更容易解决了。 但是,不要滥用它们,先做腿部工作,与问题搏斗,然后才去寻求帮助。 走走一会儿-现在,它在我身上发生的次数超出了我的估计。 我整天都在努力使某些事情正常运转,但失败却惨痛。 我修复了一个错误,并显示了十个错误。…

设计软件实体:从需求到编码

如何对应用程序的组件进行编程 从广义上讲,无论一个人可以实施哪种软件开发过程,基本上所有软件项目共有五个重要阶段:(1)需求收集,(2)软件设计,(3)软件构建,(4)软件测试和(5)维护。 其中,对于项目的整体效率而言,最重要的可能是软件设计 :将是系统一部分的实体(也称为组件,类或元素)的定义和规范。 软件设计阶段包括对涉及软件的任何项目都至关重要的几个方面,包括但不限于:软件体系结构,软件设计模式,用户界面设计和算法效率。 此阶段的目标是将系统分为独立的组件,可以对它们进行考虑,实施,更改和测试,而对其他实体的影响最小。 那么为什么这很重要? 像这样说: 一个好的软件设计可以为任何特定的开发节省多达50%的时间和预算 。 换句话说,糟糕的软件设计可能会非常昂贵。 如此之多,以至于您应该始终特别考虑软件设计方面的问题,尤其是当您要处理非常定制或复杂的应用程序时,因为当今大多数软件都在使用。 进一步反映,设计实体来自软件系统需求的分解。 假设您已经从一组给定的需求中识别出了实体,那么以下几点将以一个非常简单的示例并且以一种非常详细的方式凝结:如何设计和编码一个软件系统的每个实体 ,无论使用哪种设计符号或您使用的编程语言。 值得一提的是,这不是一种标准化的方法(尽管它从更通用的“ 测试驱动开发”过程中汲取了一些想法)。 但是,这些从经验中采取的简单步骤可以帮助您从需求到编码快速且最少的错误。…

看板和格里夫的五个阶段

在过去的几周中,Adzerk一直在测试我们看板流程的变化,该流程受ElisabethKübler-Ross的五个悲伤阶段的启发。 我们发现这种模型特别适合我们的组织-一家拥有8个开发人员的Clojure商店,以及一支技术支持和客户管理团队高超的团队。 将产品开发系统建立在对死亡的反应上似乎是病态的,但是软件是一个不断变化的世界,随着变化而来的是损失。 最好保持这样的观点,即我们所有的代码最终都会崩溃或变得过时,而不是假设我们编写的代码将永远存在。 (更不用说推出的功能会被客户遗弃或无法解决他们的问题。)最终,悲伤与软件开发并非无关紧要。 切换到基于悲伤的方法论阶段并不困难-只是对我们以前基于看板的过程的微小修改。 Trello中列的新标签是最明显的区别,我们的产品副总裁Larry Karnowski超越了一切,以确保在工程站立和会议期间使用新名称。 阶段1:拒绝 “拒绝”并不意味着无视事实以支持首选现实。 相反,在我们的方法论中,“拒绝”指的是对所建议的功能或问题是否应按照卡片中所述进入开发流程的怀疑态度。 即使我们的支持团队能够重现客户报告的错误,其卡片仍将处于“拒绝”状态,直到我们确定使用该卡片可以解决根本的问题为止。 可以通过新功能或更改客户实施方式更好地解决该错误。 第二阶段:愤怒 老实说-软件开发令人沮丧。 编码人员可以工作几个小时,在票证上没有任何进展,甚至可以恢复以前的进度。 我们不认为开发阶段是一个平滑,线性的过程,而是接受在编码阶段会出现Anger。 这并不意味着我们期望我们的开发人员在编写代码时真的会生气(至少他们通常不是)。…