Category: productivity

0

最好的编程语言

我们经常会听到有人说,PHP是最好的语言,也有人会说Java才是最好的语言,很多时候这些讨论文章的唯一目的就是让我能笑一笑,其实我们大家都知道,哪有什么最好的语言,各种语言都有其擅长和不足的地方,那么在我们实际工作中,如何来选择一个最好的语言呢? 是否有性能要求 假如你有明确的性能要求,那么我们就需要来具体分析了: 秒级:任何语言都可以做到 毫秒级:任何语言,只要程序员本身过关也都可以做到 微秒级:这个量级,很多解释性语言就可以排除了(比如Python,当然它本身很好),一个很好地程序员使用JVM是可以达到这个量级的,同样的,我想C#应该也是可以做到的。当然,纯编译语言也是可以做到的。 纳秒级:大概只有汇编或者C能够做到了。 生态系统是怎样的 其实除了语言本身,它的生态系统也很重要。比如说我们使用Visual Studio,然后你会发现很多人使用它,它的生态系统很赞。相应的工具很重要,比如Eclipse,VsCode,他们都有很多各种各样的插件可以使用,这样一来,相关语言的开发就会省力很多。 线上帮助 我们都知道,哪怕你对一个语言再熟悉,也有不懂得地方,这个时候就需要去Google或者StackOverflow上进行查询和提问,这个时候,一个热门的语言会有很多人遇到类似的问题,这无疑对你的工作是有所帮助的。 团队成员的技能 很多时候,我们要使用的不是一个最好的,而是一个大家都熟悉的,尤其是使用团队成员了解并喜爱的语言可以极大地提升工作效率和激情。 商业方面的考虑 一个很现实的问题,就是你可能会选择一个需求量最大的语言,而不是最好的语言。毕竟这样一来,至少你换工作的时候能够有所帮助。从另一个方面来说,假如你是一个tech leader,你选择了一个“最好的”语言,但是没什么人会,你想招一个有相关经验的人可能都招不到。 不过总得来说,没有什么最好的语言,只有最合适的语言。归根结底,语言只是我们的工具,我们的目标是解决问题,针对问题来进行选择,也许这才是正确的做法。

0

六个初创公司常犯的财务错误

将经验丰富的企业家和新手区分的重要标准之一就是愿意和承受风险的能力。你可以从世界上最好的企业家身上看到这一点,包括Richard Branson,Arianna Huffington以及我们的马爸爸。 不管你的公司是什么类型和规模,小的公司也好,大的全球性的企业也罢,都有可能犯一些共同的财务方面的错误。 企业家们都很聪明,他们能够快速地解决问题,找到他们的领域的界限并突破他。他们总是在寻找每一个机会来发现自身的短板,并且在未知的领域奋斗。企业家愿意承担风险的趋势随着他们把风险和机遇结合能力的增加而增长。 另外一方面来说,承担风险的渴望使得他们更容易犯错。所以,企业家们总是不停地在犯错误。每一个成功者的背后都有着同样的失败次数。 有些错误可以立即修正,但是和钱相关的错误则很容易让你的生意尽毁。突然的资金链断裂,一个想不到的花费以及债务的迅速积累可以摧毁哪怕是最好的想法。 基于我的经验,这里是六个最大也是最容易犯的财务错误,让我们看看如何才能避免他们: 没有把个人账户和公司账户分开 哪怕你是自由职业者或者企业家,把这两个账户分开都是没有弊端的。 我们知道你认为没有分开的必要是因为不分开实在是太方便了。不过在你开始收费之前就创建一个独立的账号是很有必要的。 我让你在开始就创建是有道理的,因为这样可以让你的企业更加便利,在交税的时候也很方便,甚至可以方便为那些不可预测的未来做一些准备。 一个分开的账户可以让你更好地观察你的商业是否健康。让你企业账户和个人账户分开可以减少你区分它们的花费,也不会不小心在个人生活中是会用商业的基金。 甚至,最坏的情况下,你的商业在未来不太好了,他也不会影响你的信用分。 因此,把你的企业账户和个人账户分开可以确保你可以关注于你企业的增长和安全,不要把他们混合起来,分开他们吧。 为企业花费大笔的(很多时候不需要的)开销 当你开始创业的时候,你总是想什么东西都是最好的,比如最好的电脑,最好的办公室,最好的软件,最好的人才来帮助你把企业做大。 但当你准备做这些花销的时候,一定要好好想想。有些基本的花费是不可避免的,比如注册公司,开发一个网站,参加一个企业活动等等。 在花费任何一分钱之前,都好好想想这些花费能不能给你未来带来任何受益。 一些没有必要的花费,比如办公室的party,团队建设啊,以及很好的工作环境等等并不能提高你公司的成长基础。 在开始的时候,不要去一些流行的CRM上注册,可以先选择一个基本的或者便宜的选择。除了全职员工,可以考虑一些自由职业者,比如到Upwork或者LinkedIn上看看。 因此,早期一定要把钱花在刀口上,只把钱花在那些必须要花的,而不是那些最好有的方面。 无法修复你的信用分 当你学习如何把个人财务和企业财务分开的时候,你的个人信用分会影响你的企业财务状况。信用分的范围如下: 任何情况都不要让你的信用分低于646,假如他低于了这个分数,那么就影响到你在未来得到信用的能力。在早起,当一个投资者决定是否投资的时候,你个人的信用分也很重要。 企业家通常犯的最大的错误就是认为所有的东西都没有问题。当你的创业公司去贷款的时候,这有可能会让你遇到一些问题。所以,好好改进自己的信用分,这很重要。 一些额外的建议: 按时付每一个账单,最好能设置一个自动付款,这样你就不需要每个月都自己付款了。 当使用信用卡的时候了解自己的还款能力,你使用的钱最好不要超过信用能力的三分之一。 为个人花费贷款 很多企业家会把自己的资金投入到企业中,通常都是他们看到了一个新的机遇或者很看好某一刻市场的前景,认为可以赚到钱。 尤其是你企业的早期,你会遇到很多障碍。虽然失败不可避免,但是很多会让我们付出很大的代价。当你为买一辆车贷款或者买房贷款的时候,一个意外的企业花费可能会让你的存款减少。 所以,当你企业增长的时候,不管是在个人还是企业,都尽量的保持少得花销 没有为紧急情况或者停机做准备...

0

StackOverflow 2020开发者调查报告

StackOverflow发布了2020年开发者调查报告,此次有65000名开发者参与了调查,比较可惜的是中国参与的开发者却很少。不过这份报告也大概体现了目前全球开发者的情况了,下面我们来看看具体的报告结果: 关键结果 过去五年来,Python一直在稳步上升,不过在最喜欢的技术排名中,它从去年的第二掉到了今年的第三,Typescript反超到第二。Rust连续第五年登上了最受喜欢技术的头把交椅。 在所有的职位中,站点可靠工程师和DevOps专家仍然是薪水最高的职位。80%的受访者认为,DevOps是有用的,44%的组织有最少一个专门的DevOps雇员。 52%的人发现他所搜索的内容以前曾今看到过的时候的反应是:“嘿,我的老朋友”。 当遇到无法解决的问题如何做的时候,90%的人会选择来Stack Overflow寻找答案。 75%的开发者会偶尔加班 — 一个季度一天或两天。25%的人一个星期加班1-2天。 澳大利亚的受访者用于平均最长年限的编程年限16.9年,紧接着是英国和美国。相应的美国和英国的开发者平均年龄最大,分别是33.7和33.1岁。 0.3%的受访者在做这个调查之前从来没有访问过Stack Overflow。 超过40%的受访者在除了Stack Overflow之外的开发者社区注册了会员。 超过15%的人认为Stack Overflow比去年更好了,这是个好消息,但仍然需要继续努力。 我们仍然看到有色人种在专业开发中的比例较小,但的确也看到了一些这方面的进步。 受访者分布 中国的受访者目前只占到了0.57%。 开发者角色 开发者类型 看来这是一个多选项,55%的受访者是后端开发或者全栈开发,单纯的前端开发只有37.1%。 代码是否是一个爱好 很多人在工作之外还在努力写代码,78%的认为他们会把写代码作为一个爱好。从受访者来看,有家庭的人以及妇女则更多的倾向于写代码不是一个爱好。 经验 学习代码多少年 主要是从学习代码到现在多少年 专业写代码多少年 这个就是我们正常说的码农工作多少年了,65%的人少于10年。看来不管国内国外,工作10年还在写代码的人果然不是主流。 各种岗位写代码的年限 基本可以看出,有越高年限编程经验的人,所处的职位也是相匹配的。前端开发果然所我们所想的垫底了,也许是以前前端开发不是你们流行。 几岁写第一行代码 最近流行写代码要从娃娃抓起,这个调查显示54%的人的第一行代码是在16岁之前写的,这果然验证写代码要从娃娃抓起的理论。...

0

我是如何从0开始做大一个SaaS产品的

对很多有创业精神的程序员来说,创建一个成功的SaaS的产品一直是一个梦想。在我创建我的SaaS的过程中,我发现和别的创业者一起分享和对比是这个过程中必不可少的部分。假如没有这些分享,我可能也没法创建一个个成功的SaaS的产品。本文,我就会分享,在我创建SaaS的过程中的所想所为,主要是我如何开始创建SaaS的产品以及到最后,我是如何获得第一个付费用户的。 不管你是想创建一个产品还是已经创建了产品,这篇文章都会对你有所帮助,你可以看看我是如何做的,然后和自己相比较,希望能带给你新的启发。 我个人每周都会特地去花5个小时分析别人是如何做的,我总是想看看新的想法,以及如何避免犯别人的错误,同时看看有没有什么新的策略可以用来提高用户的体验。 正是基于这样的原因,我的分享将不会有所保留,他会包括我已经做了的,以及什么我并没有做,我们的目标就是希望别人能够从中有所收获。 本文将按照时间顺序分为以下七个部分,基本上包含了所有我做过的事情: 探测问题 量化问题 分析竞争对手,并看他们是如何解决这个问题的。 开发第一个prototype 抛弃所有再次重新开始 得到第一个订阅 怎样继续前行 我开发的SaaS产品是Insepctor,他是一个实时的监控工具,可以用来帮助软件开发者检测他们的应用,以防止因为技术的故障而失去客户和金钱。 探测问题 过去10年和软件开发者打交道的经验告诉我,每天去处理和用户相关的技术问题,对他们来说太难了。 虽然开发团队和用户有着紧密的联系,但是这对开发软件产品的公司来说是非常危险的,因为当真的有问题的时候,你就会发现这种紧密联系是多么的脆弱。 客户不希望有问题,这个显而易见,没有人喜欢有问题,并且本能地会去把问题最小化。但是下意识的否则现实的问题其实并不能真正解决问题,甚至会让客户怀疑他是否还应该继续付费。 客户其实并没有兴趣帮你报告问题,他们只会简单的离开,选择一个新的应用,下次你再见到他可能也许是多年以后了。 尽管如此,很多我合作的团队还是在使用一个众所周知的方法来探测应用是否有问题:“假如有用户联系你,那么你的应用就是有问题的”,而这并不是一个技术的解决方案。 但是很奇怪的是,我们总是有各种各样的理由,比如budget有限,客户需要很急,管理的问题等等,让开发者有很大的压力,所以最终选择的总是一个修修补补的方案来解决这个问题。 我的经验告诉,这不是一个最终的解决方案。 量化问题 2019年的时候,我刚刚完成了一个项目,并且准备花点时间休息一下。以往几年,我总是用这样的机会来看看有没有什么商业上的机会,可以运用我的技术来帮助我做一些我自己的商业。 从我的开发经验来看,我发现一个简单的及时的检测系统将会帮忙开发团队来及时发现他们应用的问题,而不再需要依赖于用户来报告问题。但另一方面来说,我不需要一个能检测所有东西的工具,因为一般来说所有东西通常也意味着什么也不是。 并且我不想他很复杂,因为我不想让他们需要花费一一个月来学习怎么使用,或者需要雇佣一些人来专门做这件事,方便使用,易于上手是我的目标。 第一步,我需要看的是市面上是否已经有了类似的软件,所以我google了一下“应用检测”,出现了941,000,000条记录: 哇,看起来这是一个很普遍的问题。那这个问题究竟是有普遍呢? 我们知道软件开发团队有时效率很低是因为一个工作的预估的复杂度和对商业的影响有时有很大的差别。尤其在大规模的情况下尤为明显,Twitter上有一个调查的结果如下: 有50%的开发者花费超过50%的时间就是为了检测他们的应用是否还在正常的工作。 软件开发者的薪资都是很高的,通常我们付给他们钱是为了让他们开发程序,假如一个开发者每天都花费超过50%的时间来检测他们的应用是否正常工作,那么一个自动化的检测工具肯定是值得我们花钱去购买的。 那么问题来了,为什么还没有人来做这件事情呢? 评估竞争对手和他们解决问题的方法 我思考了一个公司在决定是否买一个工具来提供生产率的时候用来进行评估的两个参数: 易用性...

0

Stand-Up 2.0: 是时候抛弃从1993年就创建的每日站立会议了

每日站立会议是失败的 毫无疑问,这是30年前就创立的东西,但是我们现在还每一天都使用同样的方式来运行。 当每日站立会议在90年代早期创立的时候,软件开发流程和现在比起来有很大的不同。那时候没有git,没有Jira,没有任何合作的工具。没有DevOps。自动化工具也不存在,分析的工具也不存在。 别误会我,其实我还是很爱90年代初期的。 开发者的典型技术栈已经有了很大的变化。 我们使用git来管理代码,我们的同事可以通过GitHub,Gitlab或者Bitbucket来进行交流。 我们有无数的DevOps工具可以使我们的工作自动化。 我们通过Slack和Teams和同事交流。 我们有分析仪表盘来衡量所有的东西。 这些技术已经改变了我们工作的方式。哪怕相比5年之前,软件开发现在也更加连接,合作,自动化,以及数据驱动了。 因此,为什么我们每天最重要的活动去按照一个已经30年之前的架构来运行呢,他已经过时了,他没有集成Jira的数据,没有自动化,没有使用这些工具。 个人的问题 个人来说,对于每日站立会议的几乎所有角色,我都感觉不太舒服 —  作为一个开发者,作为一个团队的leader,作为一个scrum的管理者,作为一个工程师VP或者作为一个产品的leader。 下面这些是我经历的,看到的或者听说的问题: 开发者是怎样认为每日站立会议的 咖啡第一,然后才是别的事情 大多数我知道的开发者只想把他们的状态更新到Slack,然后回去继续工作。假如没有什么block他们的工作,为什么要去参加站立会议。 这就是问题所在,大多数开发者都不认为站立会议是为他们设计的。这个是我们团队的leader或者scrum master或者产品的leader来设计的会议。反正肯定不是为了我设计的。当团队中大多数人都觉得这个会议没有价值,宁可取消掉,那么这个会议就会有问题了。 还有另外一个问题,就是很多开发者不喜欢在他的同事面前寻求帮助,对很多人来说,说要帮助是一件很难得事情。所以在他们和这个会议最有价值的部分之间,其实是有壁垒的。 还有一件事,我就直说吧。我出现在这个会议上,我听每一个人分享他们的update,尽管我可以在Slack上看到这些update,然后我分享我的update,我们花费了很长时间。然后还是会在之后的白天ping超过10次来询问相关事情的进展。那么这个会议的有什么意义。 开发团队的leader和scrum master是如何看待每日会议的 当我是一个团队的leader的时候,我发现每日会议特别有用。它是我来保证分析迭代风险以及保证我们在轨道上的重要工具。但是我也有我的问题。 对那些新手,我需要得到所有的更新才能得到我关心的内容:障碍和风险。我们可能花费了80%的时间在分享状态的更新。只有很少的时间在有价值可以操作的讨论上。尽管我们的目标是把解决问题放到会后,但是我很难有足够的时间收集足够的信息以便于我会后去处理。 我们花费了很多时间讨论Jira是否更新了,而大多数情况他都没有更新。 每个人都在用一个固定方式分享他们的状态,这让我很难受。他们有些只说了10个单词,花费了20秒。有些人则分享了过去24小时整个长长的历史。 最糟糕的地方在于很多时候,我不能得到整个事实。对一些开发来说,让他们说出问题,有时就像拔牙一样。 尽管我们有一个时间限制(每人2分钟),我们几乎还是每一天都超时了。大多数时候,我都能够感觉到每个人只想回去继续工作。 CTO,VP和工程Directors是如何看待每日会议的 当我是一个工程VP,我喜欢偶尔去参加一个团队的站立会议,或者去看一个我关心的商业功能的开发状况。 我知道他们在我在的时候会表现得不一样,甚至会说得更少,但我还是会出现,因为对我来说,我没有别的什么更好的机会可以看到团队所有的人。...