「書くことができるサイクルはありませんか？」



私の最も人気のある記事は、 「なぜプログラマーがコーディングしたいのか」というタイトルです。 現在までに、62,000回以上読まれています。



この記事では、熱意とアイデアに満ちた会社に来たプログラマーのジェイミーについて語っています。 数年が経ちました-そして、ジェイミーは「コーディングしたい」人の一人になりました。 新しいアイデアや新しい働き方を提供しない人の一人-しかし、ただコードを書くだけでいい。

残念ながら、この話についてマネージャーや監督者からはほとんど返事がありませんでした。

誰かがその本質を理解していないようですので、私は直接言います。

技術マネージャー、そのような状況はあなたのせいです。

あなたは、「コーディングしたいだけ」で、流行の新技術だけに関心があると思われる意欲のないプログラマーに責任があります。

リーダーとして、あなたは誰もが問題解決に貢献できる環境を作る責任があります。

代わりに、多くのプログラマーは、プログラムのみを行うことのできる、モロニックな万能オタクと見なされているようです。



やめて 真剣に。



その記事の巨大な共鳴はあなたから地獄を怖がらせるはずです。 市場は暖かくなり、あなたを解任し、あなたをより良いリーダーに置き換える力を与えています。



私は彼らが地獄のように怒っていると感じており、もはやそれに耐えることはありません。



信じられない？ 続きを読む...



私は、マネージャーが理解することを期待してその記事を書きました。プログラマーは、頭を完全に引き付けようとしますが、環境があまりにも多くの場合、これを行うことができません。



代わりに、マネージャーからの理解を望んでいるプログラマーから何千もの返信（Mediumの「拍手」、コメント、メッセージ）を受け取りました。 彼らは彼らの文化が受け入れられ、彼らのアイデアが議論され、議論されることを望んでいます。



すべての中で際立っているコメントがあります...

「なんてこった！ この新しいアイデアの敵対的な受容現象は、地球全体の主な殺人者であり、すべての部門に害を及ぼします（これはプログラマーだけの問題ではありません）。



「仕事に来たとき、私は世界を変える準備ができていました。 今では毎日、真の考えを抑えようと全力を尽くしています。そして、物事がどうなるかを我慢してください。経営陣が間もなく問題を理解し始めることを本当に願っています。」



「似たようなことをしなければならなかったし、自宅でのプロジェクトをやめさえした。職場でのプログラミングは厄介で要求が厳しかったので、5か月後にやめてよかった！」



「現在の環境におけるプログラミング文化では、プログラマがアイデアを考えたり共有したりするのではなく、タスクを完了するだけで済むのは悲しいことです。」

Hasenというコメンテーターの意見は少し異なります。

「受け入れる」必要はありません。 私たちのアイデアが議論され、議論されていることを確認する必要があり、決定はその著者の立場ではなく、アイデアの価値に基づいています。



アイデアを提出すると、彼らはそれを議論し、それを拒否します。それは正常です。



アイデアを出して、彼らは私にこれをしてはいけないと言うだけで、現在の仕事をするだけなら、これは兵士として命令を実行することだけが許可されているという明確なシグナルです。



それが起こると、私は本質的に別の仕事を探します。」

この最後のコメントはそれを要約しています。 プログラマーが完全に貢献できる環境を作成します。そうしないと、最高のプログラマーが去ります。

物事を現実的に見ていきます。 チームに問題がある場合-1日で修正できません。 ただし、この問題を解決するために重要な手順を実行できます。

変更に取り掛かる

聴き始めて話をやめる

一部の開発者だけを放置したい場合、今日はすべてを変える素晴らしい日です。



次の一対一の会話でこれを始めてください。 （ 対面で話しませんか？まずはガイドをご覧ください ）。

ステップ1：謙虚になる

各従業員と再度会話を開始し、彼のアイデアに耳が聞こえないかどうか、「彼」を「リソース」と見なさなかった場合、そして失望しなかったかどうかを正直に尋ねます。



答えに関係なく、あなたはそのようなボスになりたくないとあなたが謝罪することを言います。 （ はい、あなたが気分を害するかもしれない人に謝罪することは常に良いことです。たとえあなたが上司であっても ）。



次に、彼の助けが必要だと言います。 彼の意見は改善するために必要です。 次回これを行うときにあなたを止めることができます-そして、プライベートな会話で、あなたの行動について意見を述べます。



最後に、あなたと一緒にいて、この大変な仕事をしてくれた彼に感謝します。 あなたに耳を傾け、あなたが彼らが必要とするマネージャーになるのを手伝ってくれて彼に感謝します。

ステップ2：もっと聞き、話すことを少なくする

チームとの関係で半分ほど話してください。 そして半分になります。



これはおそらく、特に「常に最前線から進んで」注文を発行している場合に、驚くことになります。



代わりに、お互いの話し方を聞いてください。 顧客、マネージャー、または他のチームについてどのように話しますか。 誰がフローを制御しますか？ 誰がまだアイデアを提案しようとしていますか？ そして、完全に黙っているのは誰ですか？



自由回答形式の質問を使用して、全員がディスカッションに参加できるかどうかを確認します。 一部の仲間が他の人に言葉を与えない場合は、 「トーキングスティック」の使用を検討してください。 問題を解決する方法について全員の意見を聞きたいことを慎重に明確にします。

ステップ3：言うよりも頻繁に尋ねる

ほとんどの開発マネージャーは、エンジニアに作業方法を伝えることに慣れています。 おそらく、彼ら自身は以前はエンジニアであり、彼らは「ソリューションを明確に見ている」からでしょう。



ただし、このような命令はチームを強化するものではなく、同僚を黙らせます。



それで、もっと質問を始めてください。 多くの質問「なぜ？」もちろん、好奇心をつなぎ、答えを注意深く聞く必要があります。



実際、作業の実行と何百万もの小さな決断は開発者に依存しています。 あなたは彼らの意見や彼らのアイデアの議論に非常に興味を持つべきです。



エド・シェーンの本「謙虚な質問」は、最高の質問をする方法を学ぶための素晴らしいリソースです。

マネージャー、手遅れになる前に修正する方が良いでしょう。

（まだ納得できませんか？ より良いマネージャーを必要とするフラストレーションのある開発者からの何百ものコメントを読んで、「これは私と一緒の状況ですか？」と自問してください。 ）



続き： 「ソフトウェア開発で学んだ無力感」