Martin Fowler分n了他关于ThoughtWorks的看法,q是一家关注可持箋性以及经和C会公正的Y件开发公司。Martin谈到了他是如何开始了在ThoughtWorks的工作,他ؓ什么会喜欢q家公司的文化,以及Ҏ的Y件开发者的?/span>
InformITQ?/strong>你是怎样得到?a >ThoughtWorks的工作? Martin FowlerQ?/strong>围绕一个当时他们正从事的项目的域模型,他们让我做些咨询工作。我们进展的不错Q最后我p然而然地加入进来了。在此期_他们大步地{向极限编E这一软g开发风根{约九个月后Q他们向我提供了一份offer。由于他们是我最喜欢的客P我就军_加入他们?/span>
InformITQ?/strong>你在那儿工作多长旉了? Martin FowlerQ?/strong>12q?/span>
InformITQ?/strong>ThoughtWorks与其它公司有何不同? Martin FowlerQ?/strong>Ҏ上,q种不同要归lؓ人。他们善于雇佣既聪明又乐于合作的人。特别是Q这里会更多C正直的态度d注h。我发现Q相比于q去多年中共事过的大多数客户Q我更加信Q我的同事。还有对完成高质量工作ƈ期望做到更好的真挚热情,对于像我q样的作者,q是极好的素材?/span>
InformITQ?/strong>对于在那儿工作,你最喜欢的是什么? Martin FowlerQ?/strong>ThoughtWorks有许多东西可?a >d。只是困难之处在于,我要挑哪块儿去讲q呢?/span>
InformITQ?/strong>工作在ThoughtWorksQ你最自豪的是什么? Martin FowlerQ?/strong>我最自豪的是Q我们从一家几百h的美国公司成长ؓ在世界范围内拥有两千人的公司Q而且原封不动C持了公司文化中的_N。我不确定我在其中扮演了什么角Ԍ但这里一直是我喜Ƣ工作的地方Qƈ且公怸直在宣传我,使大家能有兴与ThoughtWorks协作Q我Ҏ感到高兴?/span> 管如此Q我仍不能肯定这U情冉|否要大大地归功于我。在与我本h更明相关的工作中,我必d_我很高兴在过dq中建立?a >martinfowler.com。ؓ了关注今后在改进q个站点时所做的事情Q该站点已成Z个丰富的资源和永恒的q题?/span> 在更需要协作的工作前沿Q我实很高兴地看到我的一些同事已l成Z内D重的"大嘴"。我不认为我在这其中有很大的作用--我给予的M帮助能够L地超q他们自w的努力--但这实是我最惛_的A献?/span>
InformITQ?/strong>Z么会有h想着去ThoughtWorks工作Q?/span> Martin FowlerQ?/strong>对于l验的人,我想最大的吸引力是Q能在许多不同类型的目中学会做好Y件开发的能力。当ӞThoughtWorks的项目ƈ非完,但我认ؓ它们比绝大多数Y仉目要好得多。我听过很多ThoughtWorks前员工们谈到他们在公司工作的岁月中对于Y件开发学C许多?/span> 而在所有的原因当中Q旅行机会也是很重要的。如果你惌上一大段旉在世界上不同的地行工作,例如在美国h在印度工作,或巴西h在中国工作,那么ThoughtWorks提供了大量的此类Z。这也与我们日益兛_C会正义的问题有养I我认为对于许多有l验的h来说q也是一个重要的因素?/span>
InformITQ?/strong>对于一个刚刚开始在ThoughtWorks工作的新员工Q你有什么徏议吗Q?/span> Martin FowlerQ?/strong>对于在ThoughtWorks工作的h们,最沮的事情之一是我们不做职业规划Q这׃很容易危险地在项目间漂来漂去。对于有些h来说q不是问题,但如果你惌定一个职业方向,那么你必d自己d。这意味着大量的交际,L机遇QƈU极推进。这不是一U直接的途径Q但在我成ؓ独立咨询师之前,没有q种促进我前行的职业计划Q就会有相反的效果?/span>
InformITQ?/strong>告诉我们一?只会发生在ThoughtWorks"的故事?/span> Martin FowlerQ?/span>我记得有ơ被拉去讨论一个和BigCo相关的很有前景的目。这W交易确实很大,在初始阶D就要耗费U?0+?q。但存在着一些对BigCo在道徯录方面的担忧Q尤其是在发展中国家。在q一讨论中,Ua的ThoughtWorks要义是,CFOhȀ昂地反对接下q笔高利润额的工作,而所有的高领导们则們着一位来自南方国家最q才受雇于ThoughtWorks的初U开发者,他描qCBigCo的行径是怎样损害着他的国家?/span>
This week, I read some articles about some API and tools that developers, especially Java guys, must know. Fortunately, I really know some of them, but unfortunately, I really miss something.
Please let me introduce some cases at first: 1. In our real projects, we only use JDK 6, but the version had been in End-Of-Life; we never touch JDK 7, but JDK 8 is upcoming. I don't know how much time we would spend on accepting Lambda expression. In fact, at present, a lot of Java developers cannot understand Generics exactly, however the syntax has been introduced for more than 8 years. Of course, Java Generics is a bit ambiguous, so it may be difficult to understand. 2. Ant was ever the standard for building, and it still being used by many projects, even new ones. Maven was designed to terminate Ant due to the older cannot make life easy. Some conceptions of Maven, such as build life cycle, dependency management, default directory structure, are very advanced. But Maven dependency and transitive dependency management is nightmare, you have to include/exclude this or that. And extending Maven is also a hard job. I have real experience on both of them, I even wrote some popular preliminary blogs about Maven several years ago. But what I really don't know? I don't know Maven is becoming legacy, and worse, a new super star Gradle is on stage. Outspokenly, I never hear of the artifact before this week :-( Outstanding Spring framework is a very case about the trend. At beginning, obviously Spring is built by Ant, then the framework switched to Maven some years ago, but last year Spring migrated to Gradle. 3. Google-Collections was well-known if you used it or not, and I know Guava however I never use the API. But what I really don't know? I don't know google-collections was closed several years ago, and even it was combined by Guava, which is a new rock star in Java ecosystem.
OH, something is born, and then grows, and then rests in peace. That's nature, and we have to face it, but why I don't know? Exactly, I have no idea. World has been changing, and is changing faster as never before. How to keep us up-to-date with new fashion? I think the question may be asked by every "old" developer. After a long term career life, some of us may become veteran, but absolutely, it's impossible that everyone become expert, particularly the expert in underlying fields. We just be proficient in some programming languages, frameworks, APIs, or tools. So we must update our brains continuously. Maybe the issue is one of the middle life crisis problems, good luck for you and me :-)