Edited at

新人エンジニアの私が圧倒的貢献をするためにやっていること


はじめに

私は教員を辞めてエンジニアになってからまだ6ヶ月のいわゆる新人枠。それでもこの6ヶ月、どのような魔術を使えば圧倒的貢献に繋がるのかを自分なりに試行錯誤し、実行してきました。

そこで、私の失敗談やそこから得た経験が、新人エンジニア同志の方の参考になればという思いで今回の記事を書きました。

周りのエンジニアとのレベルの違いを感じすぎて魔術を使っていい現場なのかと引っ込みがちだった私が圧倒的貢献を目指してやったことが、エンジニアになりたての誰かのところに届けられたらうれしいです。一緒に圧倒的貢献をしましょう!


教員からエンジニアとして今の職場に転職した感想


  • ベンチャーは技術的負債ほぼゼロから開発しているため、ツールチェインが最新で最高


  • プログラミングって楽しい


  • 実はメタプログラミング技術はあったらあったで普通に使う


  • プログラミング楽しいなぁ


  • 競技プログラミングの経験は意外と役に立つ


  • プログラミングが楽しい


  • 人の書いたコード読むのってつらい


  • 東京つらい、大阪に帰りたい



歯車になりたい

これは僕がいつも思ってることです。若干の能美クドリャフカが入っています。

教員採用試験では「どんな先生になりたいですか?」と面接で絶対に聞かれる。

僕はこう答える。


「他の先生が気持ちを理解できない生徒に寄り添う先生になりたい。普通じゃない考えを持った生徒を許容して伸ばしてあげたい。今の教育に足りていないものだと思うから。」


教員採用試験って声でかくて体力ありそうな人が受かって行くような気がするんですよね。

でも、そういう先生ばかりだと嫌じゃないですか?

僕は嫌です。

いろんな先生がいるべきだと思うです。

閑話休題

僕みたいな駆け出しエンジニアが一人頑張ってもできることってたかが知れてると思っていて。

もっと言うと、どんなに素晴らしいソフトウェアができても営業しなけりゃ誰も使わないと思っている。

僕はモーターをやるのは好きじゃないんです。

つまり、人を使うことは得意じゃなくて、人に使われる方が好きなんです。

歯車の一つとして複雑な機構を支えたいと思っています。


わからないことがあったら聴く、わかった気になってもやっぱり聴く

ベンチャーだからできます。

エンジニア全員同じ島に座ってますし、他の人もそのへんにいます。

わからなくなったらとりあえず聴きます。

わかったと思ってもとりあえずアイデアを話します。

先輩は失敗の数が違うのですよ。

山ほどのバグを生み出して、修正してきたのです。

ありがちな失敗は大体話してるうちに判明するものです。

失敗してから相談するより、スループットが良いと思っています。


知識はいつか役に立つときのために蓄積する

先生をやっていると生徒に「こんなこと勉強して何かの役に立つのかよ」とか「生きるのにこんな勉強必要ない」みたいなことはよく言われます。

社会人でも「そんなものを学んでも仕事で使わない」などと似たようなことを言っているのをまれによく耳にします。

僕はそうは思っていません。

チャンスがきたときチャンスを手にすることができるのは日頃から準備を怠らなかった者だけです。

目の前の業務に終始せず興味をもって何かを学び続けよう。

与えられたタスクをこなすために技術を学んでいくのもとても良いことです。

役に立つ技術を身につけることができるでしょう。

しかし、僕が目指すのは不可能と思われていたことを技術力で可能にするようなエンジニアです。

だってそのほうがワクワクしますよ。

他の人が見えていないものを見るために必要なのは圧倒的な知識だと僕は思います。

いつ役に立つかわからないけど、いつか役に立つかもしれないからこそ今学ぶのです。


競技プログラミングのすゝめ

競技プログラミングを知らない人がいるかもしれないので説明する。

競技プログラミングには色々な形式がある。

最も典型的なものは与えられた問題セットを時間内にいくつ解けるかというタイプのオンラインコンテスト。

プログラミングで問題解決をするパターンを知る練習にもっとも良いと思う。

よく知られたアルゴリズムや、アルゴリズムのオーダーについて知っておくことは非常に価値がある。

勝負をすることが好きな人はコンテストで勝ち負けを競い、レートを上げることで鍛えるのが良いだろう。

あまり勝負に気乗りがしない人は過去のコンテストページを眺めていくつかの問題に挑戦すると良い。

良質な問題で定評がある日本の競技プログラミングのコンテストとしてAtCoderをおすすめしておく。

AtCoderのコンテストは週末に開かれている。

ちなみに僕は週末を楽しみすぎてコンテスト中にゲーセンで音ゲーに熱中していることが多い。


数学って楽しい

数学がわかっているのとわかっていないのとでは見えるものが違ってきます。

僕も数学わからないので勉強中です。

数学はどこにでも潜んでいます。

数学と仲良くなりましょう。

僕も数学わからないです。


勉強会に行く、発表する

会社なんて所詮狭い井の中ですから、大海に出て知見を集めたい。

その道のプロから知識を吸収するのが最も効率の高い勉強方法であるのは明確。

やはり勉強会に行くのがいいのではないか?

東京に引っ越してきて思う、やっぱりその手のイベントが多い。

せっかくなので行くか。


行った感想

寿司!

ピザ!

勉強会終わった後の食事!

楽しい!


せっかくなので発表する

C++の神としてはばちこり発表もしていきたい所存。


突然ですが開発談です


なんだかコードがすごく冗長

一つの操作を行うのに数十行のコードが書かれている。

実は、採用したライブラリがそうせざるをえないような設計になっている。

当然、代わりに使えるライブラリの調査を行う。

しかし、現状の使い方を想定したライブラリは無いように思えた。

ならば、作るしか無い。

そのライブラリがあるとビルドの依存関係もなんか面倒い。

僕がそのライブラリ使うの嫌すぎて3日かけてライブラリを構築した。

ライブラリを間違った運用で使うよりは、自前で作ったほうが圧倒的にマシ。

C++でライブラリを作るためには現状テンプレートメタプログラミングができる必要がある。

ライブラリのユーザーは何をしでかすかわからない。

適切にコンパイルエラーにならないライブラリはただのそびえ立つゴミの山でしかない。

(SFINAE-friendlyになってないライブラリほんま許さんからな)

あと、ドキュメントは必要。Doxygenは早くC++17に対応して欲しい。

当然テストはしっかりとやる、ライブラリがバグってたら目も当てられない。


それクラスにする必要ある?

ある優秀な学生アルバイトさんが、

「クラスなんて作らなくても、標準ライブラリの組み合わせでよしなに実現できますよね?」

と僕に尋ねた。

当時、適当にその時思っていたことをなんか答えた気がするが、あらためて考えてみた。

おそらくは半分正しいが、半分間違っている。

密結合な構造を作らずに疎結合な部品を組み合わせてプログラミングするというのは非常に重要な考え方だ。

それを考えると優秀な学生アルバイトさんの言っていることもうなずける。

問題は、C++の標準ライブラリがそれをそのまま使ってプログラミングが簡易に組み立てられるようになっていないということだ。

どう考えても必要な部品が複数かけているし(i.e. networking)、どう考えても何でもできるようにしておいたから自分でカスタマイズしてくれと主張しているライブラリ(i.e. <random>)も多数見受けられる。

結局のところ、使いやすいようにクラスに包んで使うのが正解なのだろう。

あと、雑魚いプログラマに何でもできる部品を与えるとろくな組み立て方しないからマジで。

Rustとかだったらいいんだけど、C++は危険だからマジで。

型の話もしたいけど、長くなるので今回はやめとく。


まとめ

エンジニアになって6ヶ月、新神エンジニアとか関係ない、技術力で殴っていいんだと思いました。これは私だけでなくこれから神になる人、今神になりたてでもがいてる神、神になって少し慣れてきたけど成長をなかなか実感できない神みんなに共通して必要なことなのではという気持ちでこの記事を書きました。

周りのエンジニアにできないことをできるように、精進を怠らない。そうしているうちに神という限られた力で圧倒的貢献をし、最終的に信仰を集めるエンジニアになれるのではないかと感じました。

1人前の神になれるように日々の精進を絶やさないようにしましょう!

Twitterでも毎日イラストを山ほどRTしてます。よかったら覗いてみてください!