プログラミングが退屈になったらどうするか

同じプロジェクトで同じ会社で長い間働いていて、状況、使用されているテクノロジー、プロジェクト自体を変えることを考え始めました。 以前は、この状況から抜け出す方法は1つしかないと確信していました。新しい仕事を見つけることです。 私たちが発行しているこの記事は、私の心を変えました。 プログラマーの仕事を退屈させ、彼の成長と発展を支援するアプローチを説明しています。 PayOnlineの支払い受諾を整理するサービスであるこのサービスでは、著者が説明した同様の問題が発生した場合に、この方法論に精通し、雇用主と共有することをお勧めします。 以下は、直接、翻訳です。

私が開発者だったとき、私は2年以上同じ仕事にとどまったことはありませんでした。 私の場合、すべての新しい仕事は、キャリアの成長という点で私にとって良い動きでした。 高い離職率は私たちの専門分野では一般的なことですが、以前の雇用主は私を離れることについて冷静だったとは言えません。 そのうちの何人かは私を滞在させようとしましたが、仕事が退屈になり、もう滞在できなくなりました。 すぐに説明します。プログラマー自身よりもプログラマーの方が仕事が多い場所に住んでいたのは幸運でした。 転職のオプションは誰もが利用できるわけではないことを理解しています。

現在、 Enkiの創設者およびCTOの1人として、エンジニアリングカルチャーを担当しています。そのため、以前のように、開発者が作業に興味を決して失わないようにすることが私の責任です。 チームとともに、この問題に対処する戦略を考案しました。 私たちは毎日この戦略を使用していますが、この戦略はこれまでずっと良いことを示してきたので、ここで共有したいと思います。

エンキの私たちは、困難ではあるが興味深い問題に取り組んでいるため、非常に幸運でした。 魅力的な問題をコーディングして解決することはたくさんあるので、私たちのチームへの関心が失われるという問題は価値がありません。 しかし、プロジェクトの作業の開始時にはこれは非常に自然ですが、退屈は静かになり、最も不快な瞬間に攻撃する傾向があるため、時間が経つにつれてすべてが変化します。 だからこそ、私たちが仕事に常に情熱を傾けることができるよう、前もって文化を作り上げようとしているのです。

素早く変化し、新しいことを学ぶ

開発者が退屈し始めている最も特徴的で明白な理由は、長引くプロジェクトです。
私は最初の仕事でこれを個人的に確信しました。 私のチームは、財務データを準備および表示するための便利なAPIの作成に取り組みました。 最初は、プロジェクトの複雑さと範囲のため、作業は魅力的でした。 高性能データ分析技術とAPI設計について多くのことを学びました。 ただし、1年後も、同じデータセットに取り組み、最初と同じテクノロジーを使用していました。 私は徐々に狭すぎる専門家になり始めました。 私が学ぶことができる新しいものは何もありません。

チームやプロジェクトを変更することはできませんでした。会社の目標に関しては不合理すぎるからです。 彼女は同じ場所に私を必要としていました。 私はデータとテクノロジーに精通していたので、私を置き換えることは不可能でした。 同時に、何か新しいことを学びたいという欲求のために、「自分のために」テクノロジーを変えることはできませんでした。 私は雇用主に、私はどんな絶望的な状況で、どんなに疲れているのかを話しましたが、彼は何もしなかったので、先に進まなければなりませんでした。

そのような状況から身を守るには？

私たちのチームは、同じ製品、つまり3か月以上のデータセットに誰も取り組む必要がないようにしています。 もちろん、そのような期間は私たち自身の好みに基づいて選択され、大企業にとっては短すぎるかもしれませんが、一般的に、私たちは迅速な交換を信じています。

これがすべて成功するように、統合されたアプローチを開発します。 各開発者は、ソースコードベースの任意の部分で作業するか、その方法をすばやく学ぶことができます。

予防のもう1つの重要な部分は、すべてのチームメンバーとの継続的な対話です。 毎週、個別のセッションを開催し、特定の開発者が心配することすべてを率直に話し合う機会を設けています。 彼があまりにも快適に感じ始めたり、プロジェクトのある部分に過度に深く入り込んだら、状況を変える時が来ました。

コードサポートが仕事を退屈にする方法

この場合、開発者は新しい機能を開発する代わりにバグの修正に時間の90％を費やすため、プロジェクトが公式にサポートされているかどうかをいつでも簡単に判断できます。 おそらく誰かが改善と更新は避けられず、古いコードを維持する必要があることに反対するでしょう。 ソフトウェアの作成は、家を建てることに似ています。古い家を良好な状態に保ち、時々更新する必要があります。 それとも間違ったロジックですか？

はい、いいえ。 問題はあなたの考え方にあります。

たとえば、私の指導者の1人は、コードサポートのある状況について非常に冷笑的でした。 彼にとって、これは当たり前のことでした、彼らは言うべきことはありません、ソフトウェア開発の世界はとても整理されており、人生は複雑なものです、あなたはそれに慣れなければなりません。

この状況をどのように簡素化できますか？

時々、コード追跡モードで立ち往生するのは、勇気の欠如と相まって不十分な技術的解決策の結果です。 複雑な依存関係を持つ大規模なモノリシックソースコードベースには、メンテナンスの観点から追加の作業が必要です。 対照的に、適切に設計されたマイクロサービスベースのインフラストラクチャはより柔軟です。 欠陥のあるマイクロサービスは簡単に交換できます。 別の言語または技術を使用してゼロから書き換えることができます。 したがって、継承されたコードにパッチを適用する代わりに、何か新しいことを学ぶことができます。 また、アーキテクチャがまだマイクロサービスの使用を許可していない場合は、DevOpsの知識レベルを上げながら段階的に改善できます。

マイクロサービスを使用する戦略は、「退屈な」コード保守の問題を解決するためのアプローチの1つにすぎません。 一部の企業は、追跡プロセスをより効率的で楽しいものにするスマートツールを作成しています。 鮮やかな例は、FacebookとPHPソースコードの巨大なデータベースを最適化するアプローチです。 同社の開発者は、独自のコンパイラーとHack言語を作成しました。これは静的型付けを使用し、PHPで実行されます。 これにより、メンテナンスプロセスが簡素化され、ワー​​クフローが合理化されました。 この方法で、継承されたコードのすべての問題が解決されたわけではないのではないかと思いますが、そのおかげで、開発者はおそらくもっと楽しくなったでしょう。

通常のコピーと貼り付けが退屈な仕事をする方法

コーディングがありますが、コーディングがあります。

私の以前の活動を見ると、多くの無駄なコードを作成していることが明らかになります。 たとえば、データを統合するためのスクリプトをGroovyとPythonで書いたことがあります。 構造は複雑で、何十もの一貫性のない回路が含まれていたため、意味のある自動化を実現できませんでした。 そのため、多くのコードを作成する必要がありました。 私と一緒にこの仕事に携わった同僚は、その過程で多くの新しい有用な情報を受け取ったと信じていました。

しかし、実際にはそうではありません。その理由を説明します。

問題は、私のコードの50％がStack Overflowを使用した直接コピーアンドペーストであり、残りの40％が他のスクリプトのコピーアンドペーストであり、その作成者は同僚または私であるということです。 プロセスは非常に単調であることが判明し、あまり創造性も新しい学習もありませんでした。

私たちのチームはこの問題にどのように関係していますか？

1つのチームであるため、私たちはそれぞれが作成するコードのタイプを慎重に分析します。 共同のコードレビューと回顧で一緒にこれを行います。誰かが完全に役に立たないコードに1週間を費やした場合、その理由を理解しようとしています。



問題は本質的に技術的なものである場合があります。 スクリプトや構成に時間を費やすことができます。 これは、より大きな自動化を実現する必要があることを意味しています。 コピーペーストを使用する本当の理由がある場合、プロジェクトへの統合をすべての参加者に均等に分割するようにします。

通常、内部ツールは退屈な仕事をします

開発者として、特定の問題を解決するための独自の内部ツールを作成するのが好きです。なぜなら、私たちにとって何か新しいものを作成することは刺激的なプロセスだからです。 さらに、特定のニーズに適応したソリューションの作成は、既存のツールのニーズに適応しようとするよりも、よりクリーンなアプローチを意味することがよくあります。 しかし、他の人々のクローズドソリューションの研究は、人気のあるオープンソーステクノロジーの研究よりも10倍エキサイティングではないと思われます。

なんで？

独自のツールについて友人と議論することはできないからです。 あなたがそれらを知っていると自慢することはできません。 それらはブログで書かれることはありません。また、ハッカソンで使用したり、第三者の秘密プロジェクトで作業したりすることもできません。

それにもかかわらず、多くの企業は何かを作成するというaddsに陥りますが、それは後に落胆を追加するだけであり、したがって努力する価値はありません。 私は、将来さらに不安をもたらすためだけに短期的な不安を緩和するような開発について話している。

私自身の経験から、これは以前の仕事の場で確信していました。そこでは、大規模なデータ統合のために内部で開発されたドメイン固有の言語を使用する必要がありました。 私が実際に勉強しなければならなかったものは、少し誇張ではありますが、次のSQL用語と呼ぶことができます。 より大きな欲求で、私はむしろSparkのようなある種の低レベルのオープンテクノロジーを研究し、使用します。この場合、私は10倍より複雑になり、コードが同時に2倍冗長だったとしても、それはすべて同じです5倍の生産性が得られます。

そのような状況を防ぐために、会社の文化はどうあるべきですか？

私たちは、オープンソース技術に対する強いバイアスを維持しようとします。 問題に直接関連し、以前に考えた興味深いものを使用する機会があれば、それを行います。 最新のソリューションを回避することはしませんが、独自のコードを、十分な成熟度に達するとすぐに、同様のオープンテクノロジーに置き換えます。 また、ソースコードの独自性が失われるとすぐにソースコードを公開します。

エラーは時々発生します。 たとえば、しばらくの間、サーバー側のタスクをスケジュールするためにagenda.jsライブラリを使用しました。これは、それを現代的で興味深いと考えたためです。 しかし、私たちの場合、それはすべてを複雑にすることが判明したため、古くてより信頼性の高い技術である古き良きクーロンに戻ることが決定されました。 それでも、私たちにとって貴重な経験だったので、この実験を後悔していません。

モンキーコーディングが退屈になる理由

仕事への関心を失うもう1つの一般的な理由は、人々の管理の悪さです。 私は、トップダウンの管理構造を意味します。これは、開発環境で使用され、多くの場合、より高いものの独裁につながります。

リーダーは、気付かないうちにそのようなアプローチを使用し、善意からそれを行うこともあります。 これは、プロジェクトで物事がうまくいかない場合、または締め切りが近づくと、特に頻繁に発生します。 議論を中断し、「ブレインストーミング」を最小限に抑えようとするプレッシャーのある人の自然な反応です。 もちろん、これはすべて時間を節約して目的の結果を得るために行われます。

理解して状況を理解している部下が、起こっていることに不満を持つ必要はありません。 実際、ワークフローを簡素化するため、何をすべきかについての特定の指示を喜んで受け取る人さえいます。 もちろん、そのような指示が適切に与えられていれば、これはすべてです。

ただし、このアプローチには隠れたコストがあります。 どのコードを書くべきかを正確に知ることは、作業の開始前であっても、プログラミングを知的で創造的なプロセスから純粋に機械的なプロセスに変えます。 つまり、「開発者」は「コーダーデコイ」になります。

同時に、プロセスに関与しているアクティブな開発者は、反対に、これが必要な理由の本質を理解しようとしますが、もちろん、一時的なパッチや境界線のケースを回避するためのハックなどの明白なことについて話している場合を除きます。 しかし、彼が特定の重要な決定とその背後にある理由に無関心であることを認識し始めたら、仕事を変える時が来ました。

そのような状況を防ぐ方法は？

これに必要な主なものは、オープンな議論を促す文化です。 戦略を策定し、1つのチームとして一緒に計画を立てる、定期的な議論のためのプラットフォームを作成します。 この文化を維持することは、すべてのチームメンバーの仕事です。 ワードがより大きな声で話すべきであり、彼らの指導者は注意深く聞くべきであるのは最も困難な時代です。

毎日の日常はつまらない

最後になりましたが、重要なポイントです。 限られたスペースに身を置き、ある種の日常的な活動に従事するよりも、興味や趣味を殺すためのより良い方法はありません。

この問題は、ソフトウェア開発や技術分野だけでなく、あらゆるオフィスワークでよく見られます。 毎日同じ部屋にいて、同じ人がいて、同じ仕事の責任を果たしているなど、ほとんど変わらない環境で...そして、ワークスペースが急速に拡大し、その内部の安定性が客観的に有用であっても、人々はとにかく、彼らはすべての良いものを当たり前のように取り始め、好きではないものに悩まされ始めます。

私たちはこれとどのように戦っていますか？

予防の重要な要素は多様性です。 背景や背景が異なる人を雇います。 私たちの現在のチームは6人で構成されており、その中にはイギリス、フランス、ロシア、ギリシャの代表者がいます。 毎日同じ人に会うことは、それぞれが一般的な文化に新しいものをもたらすことができれば、間違いなくはるかに興味深いものになります。

また、日常の活動を多様化し、通常のワークフローを超えようとします。

たとえば、私たちは一緒に公開会議やハッカソンに行きます。 サードパーティのプロジェクトがあり、さらに、お気に入りのオープンソースツールの開発に貢献しています。 スタッフの採用、マーケティング、製品の配布など、コア以外の作業でチームの他のメンバーを支援することもあります。 もちろん、これをすべて理解しているとは言えませんが、変更のためだけにそれを行っています。

さらに、チーム全体（シークレットシネマなど）と一緒に出かけたり、事前に合意したプログラムなしで毎​​週「enkiton」（Enki + hackaton）を行ったりします。 そのような会議中に、何かを一緒に分解したり、新しいアイデアを「ストーミング」したりすることがあります。 時々、League of Legendsをプレイするか、パブに行くだけです。 すべての魅力は、最後の瞬間まで、一緒に決定するまで何をするかわからないということです。

少しの混乱が退屈のレシピの最後の要素です。 そして、他のレシピと同様に、無限に改善できます。 何かがそれほど単純ではない場合は、材料またはその比率を変更して、再試行します。

ご覧のとおり、「退屈なコーディング」のレシピはオープンでシンプルです。 あなたがチームのリーダーであろうと普通の従業員であろうと、仕事をより効率的で面白くすることができます。 特に目標に取り組んでも適切な結果が得られない場合は、開発し、新しい目標を目指して努力し、1つのタスクに集中しないでください。 時々、他のプロジェクトに注意を向けてください。 あなたの仕事を分析してください、それは集合的に優れているので、あなたはすぐに「問題領域」を見つけるでしょう。 新しいアイデアを表現すること、創造的にすることを恐れないでください。さもないと、プログラミングは機械的なプロセスに変わります。これは単に退屈です。 そしてもちろん、同じ会社で働いているという事実以外に、他の共通の基盤なしに団結することは困難です。 状況を変え、同僚と一緒に休んで、一緒に新しい視野を探りましょう。そうすれば、あなたは去りたくないでしょう。

公開用の資料は、電子決済を受け入れるための国際的なシステムであるPayOnlineによって作成されました。 サイトで支払いの受け入れを整理する必要がある場合は、お気軽にお問い合わせください 。 また、当社の企業ブログを購読してください。もっと面白い投稿があります。