ソフトウェアエンジニアリング回想録

私は高成長の新興企業でソフトウェア エンジニアとして 4 年間働き、非常に貴重な教訓をいくつか学びました。それをここで振り返ります。このリストは増え続けており、今後も追加し続けます。

• 仕事は常に変化しています。特に会社が小さい場合はそうです。私が 180 人目の従業員として OpenGov に入社したとき、1 か月後に当時と同じ仕事をしているかどうかはわかりませんでした。状況は急速に変化しており、同社は市場での地位を確立しようとしていますが、それには常に進化する要件が伴います。
• あなたは文化そのものです。会社が小さい場合、あなたが導入した新しいもの、プロセス、技術的改善はすべて、エンジニアリング組織全体で採用される可能性があります。（場合によっては会社全体）そして会社が成長するにつれて文化の一部になる可能性があります。私の意見では、それは非常に充実したものですが、誰もがその機会を得ることができるわけではありません。常に改善できる点に注目し、議論を始めるようにしてください。面倒な作業をすべて自分で行う必要はありません。何を改善できるかを特定し、その最初の一歩を踏み出すことが大いに役立ちます。
• スタックのすべての部分に触れてください。スタートアップでエンジニアとして働いている場合、特に若手エンジニアとして仕事を依頼できる「こと」の役割に明確な境界線があることはほとんどありません。フロントエンド、バックエンド、インフラストラクチャ、データベースなどの作業が期待できます。機能の JIRA バックログの整理から関連コードのデプロイまで、すべてが仕事の一部です。
• 物が壊れる。システムを破壊するコードをデプロイするか、本番環境以前の環境と同様に動作しないコードをデプロイします。場合によっては、インフラストラクチャが故障し、何もデプロイできなくなることがあります。これらはすべて学び、改善する機会です。opengov では、このような問題に対処するための専任の Devops チームがいましたが、エンジニアである私たちはソフトウェア エンジニアリングの運用面にも触れていました。
• 文書化は重要です。私たちはコードを書いて出荷することに忙しいので、ドキュメントは後回しになりがちです。定期的に時間をかけて新しいドキュメントを作成し、既存のドキュメントを最新の状態に保つことは価値があります。私の意見では、優れたドキュメントはチームのパフォーマンスが高い証拠です。人の出入りがあり、特に新興企業に当てはまりますが、ドキュメントは新しい人材を受け入れ、既存のチーム メンバー内にさまざまなシステムやドメインの知識を広めるのに役立ちます。
• コミュニケーションは難しいです。技術プロジェクトに対してさまざまな関係者から同意を得るには、それが顧客にどのような価値をもたらすかを説明する必要があります。次の数スプリントをアプリの状態管理のリファクタリングに費やしたいですか? それがなぜ重要なのか、製品または EM に説明する準備をしてください (EM はさらに上層部に説明する必要があります)。アプリの読み込み時間の短縮、UX の向上など、エンド ユーザーに直接的なメリットがある場合もあります。また、開発者エクスペリエンスが向上し、将来の機能開発が促進されるというメリットがある場合もあります。それが何であれ、その物語を正しく形成するのは難しい場合があります。たとえあなたが交渉に関与していない人であっても、常にズームアウトしてユーザーの視点から自分の仕事を見ることをお勧めします。
• 適切な指導者を見つけること。他の分野と同様に、メンターシップは若いエンジニアにとって状況を変える可能性があります。メンターは、あなたに何かを教えるために手を握る必要はなく、むしろあなたを正しい方向に導いてくれます。彼らはこの分野で豊富な経験を持ち、経験豊富な専門家であり、学んだことを喜んであなたと共有します。尊敬しているチームや会社の人々に連絡を取り、解決している問題、執筆中の技術設計ドキュメント、または指導が必要な事柄について話し合います。