[和訳] 誰もが望む開発者になるための10のステップ~ キャリアアップの道は、難解なプログラミングの課題を解決するだけではない

過去に読んだ記事の中で私にとって有益だったものを翻訳して紹介します。今回はアンドリュー・C・オリバー氏著の「誰もが望む開発者になるための10のステップ」です。

  難しい言い回しが多かったので、誤訳があるかもしれません。原文も載せているので、間違いを見つけた方は指摘していただけると、とてもうれしいです。


 「誰もが望む開発者になるための10のステップ」は、もともとInfoWorld誌に出版されたものです。この記事を書いたアンドリュー・C・オリバー氏は、ノースカロライナ州ダーラムに拠点を置くビッグデータコンサルティング企業「Open Software Integrators」の社長兼創業者です。

原文は、以下にあります。

http://www.javaworld.com/article/2078724/mobile-java/10-steps-to-becoming-the-developer-everyone-wants.html

以下が和訳です。


You thought it was all about programming skills. But you were wrong! Great code is fine, yet commanding better work and a higher salary depends on ensuring more people know who you are. In other words, you need to market yourself. Here’s what seems to succeed.

あなたはプログラミングスキルがすべてだと思っていた。しかし、それは間違っていた!

素晴らしいコードを書くことはいいことですが、良い仕事を指揮し高い給料を得るかどうかは、どれだけ多くの人々があなたのことを知っているかに依存します。言い換えれば、あなた自身を売り込む必要があります。そのために必要だと思われることを以下に記します

Developer tip No. 1: ブログ

Set up a blog, and post more than once a month. Do real research and make sure you don’t sound stupid. Seriously, learn to write. Do the stuff your grade-school English teacher taught you: Create an outline, draw a narrative, check the grammar and spelling. Then, with great sadness, simplify it and shorten it to the point enough where someone scanning it will have an idea of what it’s about. The Internet does not tolerate nuance (nor does my editor).

ブログをセットアップして、月に一回以上は投稿して下さい。表面的ではない本物の研究を行い、内容が浅くないないことを確認します。真剣に、書くために学んで下さい。小学校の国語の先生があなたに教えたように、文章の構成を作成し、ストーリーを描き、文法やスペルチェックを行います。そして、誰かがブログを検索したときに、それが何についてのことであるか理解できるように、(惜しみながらも)的を射た簡素化と短縮を行いますインターネットはニュアンスを容認しません(私のエディターも同じく)。

Developer tip No. 2: オープンソースに関わる

Don’t believe the lies about open source. The younger among you may not remember the days where a developer could actually be unemployed, but even during the darkest stretches of the dot-bomb recession, all of the developers of the open source project I started were quickly back at work. Just make sure the open source code you produce reflects the kind of job you want. I wanted to solve hard problems with the simplest solutions possible, but I’ve interviewed developers who, as was clear from their open source code, wanted to complicate simple problems. Believe it or not, there’s a market for that, but make sure your code reflects the market you’re in.

オープンソースについての嘘を信じてはいけません。あなたの周りの若い人たちは、実際に失業者になるかもしれなかった日を記憶していないかもしれませんが、ドットボム不況の最も暗い期間が長期化する中でも、私が始めたオープンソースプロジェクトの開発者全員がすぐに仕事に戻ることができました。

あなたがつくるオープンソースコードは、あなたがやりたい仕事の種類を反映させるようにして下さい。私は可能な限り単純なソリューションで複雑な問題を解決したかったが、私が面接してきた開発者達は簡単な問題を複雑にしたがった(彼らのオープンソースコードから明らかであったように)。信じられないかもしれませんが、確かにそういう市場はあります。しかし、あなたのコードはあなたがいる市場を反映させるようにして下さい。

Developer tip No. 3: 半年ではなく、10年でもない

Don’t switch jobs every six months. Seriously, the end of 100 percent developer employment will come again. When that time arrives, nothing will haunt you more than job-hopping. On the other hand, don’t stay at the same place doing the same thing for 10 years. You’ll become insulated and institutionalized. To stay valuable, you have to be familiar with more than how to code IBM’s stack while at IBM in the IBM way. I haven’t hired anyone who was at IBM or a similar organization for more than a year or two. They usually impress me in the interview but fail the programming test.

半年ごとに仕事替えてはいけません。冗談ではなく、100%の開発者の雇用の終了は再び来きます。その時に、何度も転職を繰り返すようなことに悩まされるでしょう。逆に、10年前から同じ場所にとどまり、同じことをやってもいけません。あなたは、外部から遮断され、その組織に組み込まれた存在になるでしょう。IBMの中で価値のある存在でい続けるためには、IBMにいる間、IBMのやり方で、IBMの製品をコーディングする方法に精通しなければなりません。私は、1、2年以上IBMまたは同様の組織にいた人を誰も雇っていません。彼らは通常の面接では好印象を残しましたが、プログラミングテストでは結果を出せませんでした

Developer tip No. 4: 新しいものに目を向け、実際に手を動かす

Exceptionally young developers have a tendency to work on the shiny. Ruby is probably my favorite programming language, but it doesn’t pay (on average) as much as Java, and the market is smaller. This may not always be true. Scala looks like it’s coming on strong, but don’t kid yourself about the market size — it isn’t here yet. On the other hand, don’t stay still so long that you are the future equivalent of a COBOL or PowerBuilder developer either.

非常に若い開発者達は、輝かしい分野で働く傾向があります。 Rubyは、私の好きなプログラミング言語ですが、Javaほどの利益を上げていないし(平均して)、市場も大きくありません。ただし、それが今後も同じであるとは限りません。 Scalaは、まだ十分に普及していませんが、市場規模を軽んじてはいけません –– 今はまだ最大の市場規模には達していません。一方、COBOLやPowerBuilderの開発者の未来が、今と同等にあり続けると考えてはいけません

Developer tip No. 5: 独自のドキュメントを書く

I can’t tell you how many times I’ve worked on a project, only to be pulled into an executive meeting because I wrote a document or presentation they saw and understood. I always begin with an executive overview — that is, the page you really have to read — while the rest boils down to details in case you don’t believe me. The question is: What does a very busy person have to know about the topic if it’s not the only thing they’re working on? What most managers want to know: Who can drive this to completion and won’t BS me about how it’s going? Write that way.

私が取り組んできたプロジェクトは数えきれないほどありますが、経営幹部が見て理解できるドキュメントやプレゼン資料を書くことが多かったため、結果的には幹部会議に引き込まれることばかりでした。私はいつも、経営の概要で始めました — つまり、経営幹部が本当に読まなければいけないページから始め — 残りは疑問がある場合に細部を集約しながら説明します質問です:非常に忙しい人は、それが取り組んでいることの全てではない場合、どのような話題について知らないといけないでしょうか?ほとんどの管理者が知りたいことは:誰がそれを完成させることができ、状況報告について嘘がないかどうかか、ということです。ドキュメントはそのように記述して下さい。

Developer tip No. 6: 簡潔は本質なり

One thing you learn about management right away is that the people who know what they’re talking about tend to give shorter, more concise answers. When the responses grow long and complicated, it often means they don’t know or won’t commit. You also learn that tone is often inversely proportional to the importance of the topic. When really bad news hits, someone comes in the office, shuts the door, and whispers. When something is not inherently important but bothers someone anyhow, they will try and raise its prominence with an inflammatory tone.

マネージメントの中で最初に学ぶことの1つに、話す内容を理解している人はより短く簡潔に答える傾向があるということがあります。応答が長く複雑であるということは、しっかりと理解していないか、最大限の努力をしていないことを表す場合が多いです。また、多くの場合、声のトーンはトピックの重要性に反比例するということを学びます。本当に悪いニュースがあった場合、人はオフィスに来て、ドアを閉め、小声で話します。本質的に重要ではないが、とにかく誰かの平静を乱すような話をするときは、煽情的な声のトーンで意図的に抑揚をつけます。

Don’t be that guy. Know what you’re talking about, figure out how to summarize it, and have the details, but don’t load every sentence with minutiae and don’t build up the hype — the sky probably isn’t falling (but maybe someone should take a look at Jenkins because we haven’t had a good build in a while). When all else fails, lead with the money. Make sure your numbers are well thought out, plug them into charts, and clearly demonstrate that one point is superior to another in dollars and cents.

そんなことをしてはいけません。自分が話している内容を理解し、それを要約する方法を見つけ、詳細化して下さい。ただし、些細な点を含む文は載せず、誇大広告をつくり上げてはいけません。 — おそらく空は落下しません(しかし、しばらくの間ビルドに失敗するようであれば、おそらく誰かがJenkinsを確認する必要があります)。八方手を尽くして駄目なら、お金につなげて下さい。数字がよく考え抜かれていることを確認し、チャートにそれらを差し込み、はっきりと金銭的に他より優れていることを示して下さい。

Developer tip No. 7: 観衆を沸かせる

Figure out how to give presentations and learn how to speak in public. Research a topic and make yourself at least an expert, if not the expert. Presentations to the public are generally better if they are in part entertaining. It takes a lot of embarrassing mishaps to develop this skill, but an engineer who can explain the matter in plain English to management and give an expert talk on a topic will almost always command a higher salary than one who doesn’t.

プレゼンテーションをする方法を理解し、人前で話す方法を学んで下さい。ある話題について研究し、専門家ではないのであれば、最低限でも自分自身を専門家にして下さい。公共へのプレゼンテーションは、面白さを含んでいれば、一般的により良いものになります。このスキルを開発するためにはたくさんの恥ずかしい事故を必要としますが、話題に関して経営陣に平易な言葉で問題を説明し、専門的な話を伝えることができるエンジニアは、それをほとんどしないエンジニアよりも高い給料を得ることができます

Developer tip No. 8: 現実的であれ

Sure you like Erlang, but the market for Erlang isn’t big. You should know more than one language, as well as “new” or newly hyped topics, but avoid such immature statements as “I won’t code unless it’s in Erlang” unless you’ve truly considered the business issues. It can pay to be a narrowly focused expert, but even that has a cost — you’ll be typecast according to your specialization, which may leave you high and dry when it’s out of fashion. Sure, NoSQL is a better fit for your little project, but the company won’t invest in it for a small one-off system. The RDBMS will work fine for this one.

あなたはきっとErlangが好きでしょうが、Erlangの市場は大きくありません。あなたは複数の言語(ならびに「新しい」または新しくて刺激的な話題)を知っているべきです。そして、ビジネス上の問題を正当に検討している場合を除いて、「Erlangでない限り、私はコーディングしません」というような未熟な回答を避けるべきです。狭い範囲に焦点を絞った専門家にも報酬は支払われます、それでもコストはかかります。 — あなたは、自身の専門分野に応じて型キャストされます。時代遅れとなった時、あなたは見捨てられた存在になる可能性があります。確かに、NoSQLは小さなプロジェクトにより良くフィットしますが、企業は小さな単発のシステムのためにそれを投資しません。RDBMSは、これに対して正常に動作します。

Developer tip No. 9: 難しい問題を解く、ツールを知る

Put in the time to learn a few tools other people don’t commonly know. What tools do you have that few know/use/understand and make you more effective than the people next to you?

他の人が普通は知らないようなツールを学ぶために時間を費やして下さい。知っている/使っている/理解している人がほとんどいなくて、周りの人よりあなたを生産的にできるツールを持っていますか?

For example, Aspect4j is not for everyone, but it sure as heck is for me. I use it for things that are wrong — very wrong. I’ve rewritten .class file operations to make them run in Tomcat instead of WebSphere, though the original source was missing. I’ve fixed memory leaks in proprietary software. I’ve implemented a poor man’s Wily Introscope. At each point, I looked like some kind of supergenius because I had a tool that few people had grokked yet — and bothered to keep going when others decided to wait for the vendor. I live/breathed eclipse.org/mat so that I could not only fix leaks but tell you what struts action and parameters caused your OOME. There are others, but these simple tools for complex problems put a shine on a developer.

例えば、Aspect4jは、他の人にとってはそうではありませんが、私にとっては間違いなくそういうツールです。 私は間違った(そう、非常に間違った)用途にそれを使用します。オリジナルのソースが無いにもかかわらず、WebSphereの代わりにTomcat内で.classファイルの操作を実行させようとして、実装を書き換えことがありました。プロプライエタリなソフトウェアのメモリリークを修正したこともありました。安価なWily Introscope(※1)を実装したこともありました。そのそれぞれの時点で、まだ理解している人が少ないツールを持っていたので、私は超天才であるかのように見られました — そして、他の人がベンダーを待つことを決めるしかない状況でも調査を続けました。私はリークを修正するだけでなく、OutOfMemoryErrorの原因となっていたStrutsのアクションとパラメータを教えるために、eclipse.orgのMemory Analyzerを活用しました。他にもありますが、これらの複雑な問題を解決する簡単なツールは、開発者に輝きを与えます。

※1 Wily Introscope:J2EEアプリケーション運用監視ソリューション

Developer tip No. 10: 実践の謙虚さ

This is the least common skill among developers. Sometimes it means you get your hands dirtier than you want. Other times it means you don’t let it go to your head when you pack a room. Geek fame comes and goes, but remember, it’s what you did recently that brings them in. Next week, it could all be gone. In the words of Tyler Durden, “You are not special.” Yes, trolls, I’m fully aware of the irony.

これは開発者の中で最も一般的なスキルです。ある時は、それはあなたが望むよりも、あなたの手を汚すことを意味します。また別の時は、聴衆を満室にしたときでも、うぬぼれないことを意味します。ギークの名声は行ったり来たりします。しかし、覚えいておいて下さい。それはあなたが最近やったことによるものであるということを。来週になれば、それがすべて無くなっている可能性がありますタイラー·ダーデン(※2)の言葉を借りれば、「お前は特別な奴じゃない」ということです。そうだよ、トロール(※3)、私はその皮肉を十分に認識していますよ

※2「お前は特別な奴じゃない。」 :映画「ファイト・クラブ」でブラッド・ピット演じるタイラー・ダーデン(Tyler Durden)が発した言葉。”You are not special.”。

※3 トロール:インターネット上の掲示板などで、挑発的で不快な投稿をする人。

自分が引っ張りだこであることがどのように分かりますか?

Look left, look right: Is there a row of people doing basically what you’re doing? Then you’re not there yet.

左を見て、右を見て:基本的にあなたと同じことをやっている人々の列ありますか?そのとき、あなたはまだそこにはいない

Here are some signs that you’ve arrived: You’re sitting in a row of people and they’re all looking at you. People take their picture with you and you’re not an American traveling in Japan. Your speaking engagements fill the house, and people tell you about how much they not only enjoyed your talk but also the last two you gave. The sales and marketing people actually value your opinion. Does that sound like you? Congratulations, you’ve made it.

ここまで到達すると、いくつかの兆候が見られるようになります:

あなたが人々の列に座っていると、彼らのすべてがあなたを見ています。人々は、あなたと一緒に写真を撮ります。あなたが日本を旅行するアメリカ人というわけでもないにもかかわらず。あなたの講演の仕事は家を埋め、人々は、どのくらいあなたの話を楽しんだかについて話してきます。販売やマーケティングの人々は実際にあなたの意見を大切にします。そのようなことがあなたの周りで起こっていますか?もしそうだとすれば、おめでとうございます、あなたはそれをつくり上げたことになります。

That said, fame and success are fleeting, and you have to keep it interesting. Ironically, as you become a more sought-after developer, you code less and less. It becomes more economically efficient to communicate to and motivate others, as well as to delegate your “tend to” stuff. That may or may not be what you signed up for.

とは言うものの、名声と成功はつかの間であり、あなたは興味を持ってもらうことを維持しなければなりません。皮肉なことに、あなたが求められている開発者になればなるほど、コーディングする時間は少なくなります。あなたのスタッフに仕事を委任するだけでなく、他の人と対話し、やる気を引き出すことに対して、より経済的な効率化を図ることになります。

There will be times in your future when, once again, not every software developer who wants a job can get one. Particularly when the atmosphere becomes Darwinian, effective self-promoters do better than quiet toilers.

あなたの未来にももう一度、ソフトウェア開発者のほとんどが望んでいる仕事をできない状況が来ることがあるでしょう。特にダーウィニズム的な状況になれば(適者生存の状況になれば)、効果的なセルフプロモーションができる人は、与えられた仕事を寡黙にこなすだけの人よりも優れた存在になります。

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中