00:01
みなさんこんにちは、TRY-CATCH FMです。このポッドキャストは、
IBMに新卒で同期入社した中堅エンジニアの2人が、プログラミング学習、最新のテクノロジー、働き方、
現職などについてゆるく話していきます。では、今週もやっていきますか。
最近の、たまにやる時事ネタなんだけど、ファイアフォックスが久しぶりにちょっと大きめの不具合を出したじゃないですか。
これ知らなかったんですよ。いつ頃の話?今週?
1月の、あれ、いつだっけ?第1週とかそんぐらいじゃなかったかな。第2週入ってなかったからだと思うんですよね。
結構、いろんな環境で起きるみたいなやつで、起きる事象としては、再起動を繰り返すとか、
まともにブラウジングできる状態じゃないと。だから、いろんな解決法とか、ファイアフォックスを一旦使わなければいいよねみたいな話とかが。
今はもうバージョンアップで回避版が出てるのと、当時も一旦回避するんだったら、ユーザーからの情報を送る機能を全部オフにすると解決するっていう話があって。
実際そこの機能のバグだったらしいんだけど。
なるほどね。
いろいろ絡み合うし、本来そうなってるのかもしれないけど、もしなってないのであれば、ユーザーの情報を送るみたいなオプション機能の部分って、そこが止まってもブラウジングアップにできるようにしてほしいよね。
そうだよね。なんでメインの機能に影響を及ぼしちゃったんだろうと思うよね。
それすらも意図してない動作だったら、まあしゃーないんだけどね。どうなんやろなーって思ってそこまでは見てないけど。
確かニュースになってるな。1月14日、公式が謝罪。原因はhttp3のバグって書いてある。
ファイアフォックス使ってる?
ファイアフォックスね。一部使いやすいものがあるところとか。
アドブロック、広告ブロッカーがGoogle Chromeのやつと一調一端だったりするから、そういう特定のものはファイアフォックスで見るとかもしたりする。
なるほどね。いつもChromeで見てるから全然気づかなかったわ。
もうほぼChromeだから。
最近なんか洗練されてきてる印象あるけどね。ファイアフォックス。
そうだね。スマホは両方使ったりするね。
なるほどね。多分Chrome使えなくなったらファイアフォックス使うかもしれないな。
03:05
そうだね。他の選択肢がないっていう話もあるし。
なるほど。でもすぐ収まったから良かったんじゃないですかね。
そうだよね。早いよね対応がね。
はい、じゃあ本題の方参りますか。今回の本題がですね、ちょっと僕の今年のある種目標的な話にもなるんですけど。
これいつの記事だ?
去年の11月22日のノートで、これ結構バズった記事があるんですけど、タイトルがプログラミングというより物事ができるようになる思考法っていう記事で、ちょっと読んだことある人も多分いるかもしれないですけど、
書いてる人が牛尾強さんって読むのかな。アメリカのマイクロソフトのシニアソフトエンジニアの人ってプロフィールに書いてあって、
この記事何を言ってるかというと、この人多分今アメリカで働いてて、超優秀なエンジニアの人と一緒に仕事をしてて、あることに気づいたみたいなことを言ってて、
例えば新しいチームに入ってきて、そのシステムの概要とか教えてもらったりするじゃない、ドキュメント読んだりだとか、
その時にすごい優秀なエンジニアは1回くらい読めばなんとなくわかるんだろうなみたいな感じで思っていたけど、実はどんだけ優秀なエンジニアでもドキュメントをめちゃめちゃ読み込むっていう、
例えば同じドキュメントを10回20回見てわからないところはメモして担当者に聞くとか、これ一見当たり前じゃんと思うかもしれないけど、自分で振り返ってみるとあんまりできてないなと思って、
要は1回読んで、20パーク30パークしかわからないなみたいな感じになって、文章じゃ伝わらんだろうからしゃーないかなみたいな、実際にシステムに触れてだんだん覚えていくかみたいな発想になって、
実際にシステムをデバッグしながらなんとなく使えるようになっていくみたいな感じだと思うんだけど、やっぱり最初の理解にめちゃめちゃ時間を使うっていうのは大事なんだなっていうのはこの記事を読んで思ったところなんですよ。
06:12
今年は理解に時間をかけるっていうのを意識してやっていきたいなと思ったんですよね、これ見て。
そうだね、時間かけれるかどうかっていうのもだんだん難しくなってくるんだけど、あと習慣としてね、何分わからなかったら聞けみたいなのもテクニックとしてあったりするから、それをやってきちゃってるけど、やっぱり人に聞けない部分っていうのもあったりはするし、
そこを理解するっていう癖とか、自分がやったら理解できるんだっていう自信みたいなものは持ち続けたいなっていうのはあるよね。
いい感じにというか、いい意味でも悪い意味でも慣れが出てきてる、仕事に。だから分かんなくてもいい感じにやりくりする能力ってだんだん身についてくるじゃん。
それが多分最初にさらっとドキュメントを読んで、あとは業務で覚えていくみたいな、この方が効率はいいだろうみたいな、多分いつからかそういう感じになってきてるんだけど、
例えばプログラミング言語を新しく勉強するときでも、公式のチュートリアルを一通りやって、聞いたとか禅とかの記事とかを見てサクッとアプリケーション作って、
一旦この辺にして、あとは業務で使うかみたいな感じじゃない?それもできるっちゃできるんだけど、この記事で言う理解に時間をかけるっていうところとはちょっとほど遠いかなっていう気がするんですよね。
そうだねー。ちゃんと立ってその場で終えることと、ちゃんと理解してやらないと今後に響くものっていうのを分けて、かけるべきものに時間かけたいっていうのはあるよね。
最初の理解はちょっと甘い上でね、だらだら業務をやっていくと長期で見れば時間かかってるパターンが多分あるんだろうね。
そうだね。それは今新しい職場に行っても、なんか知らないことでこういうことが発生すると聞かないと分かんないがたくさんあるから、スタートアップとかっていうのもあって、それが発生するまでその業務があったことを現場に一緒に思い出せないみたいな可能性もあるから、
09:12
ちょっとどこかで体系的にやるっていうのもね、体系的に人が学ぶための方法をちょっと全体で考える必要があるなって感じはある。新しく来た人が、僕の次に来た人が同じような断片的に学ばなくていいようにっていうのはちょっと考えないとなとは思ってはいる。
自分がやるときもそうだし、人が入ってきたときもまさにそう。例えば自分がオンボーディングのミーティングとか入ったときに人に説明するときとかも、まあ説明口で言っても分かんないんでとりあえずやりましょうかみたいな感じで多分やりがちだよね。
気を使っちゃうのもあるしね。これでずっと説明されても困るよなみたいな。
なんかちょっと本題とはそれるけど、なんかテクニカルライティングっていう領域があるじゃない。
Googleのオンラインコースとかあるんだけど、なんかそれなんかずっと気になっててやれてないんだけど、多分要はそういうテクニカルドキュメントを書くときのノウハウみたいなのが多分詰まってるのかな。なんかそういうのやってもいい気がするんですよね。
そうだね。あんまり学んでこなかった領域だから、やってみようかな、今年。
多分ね、そこまで量はなかった気がするのね。ちょっと待ってね、検索してみよう。
テクニカルライティング全部でどれくらいの量あるんだ?
そうなんだよね、なんかコード書ける人が文章上手いとは限らないからな。
今聞いたから辿ったGoogleのって書いてあるやつを見に行ったら、オーバービューオブテクニカルライティングコースが2hが1つ、1hが1つ。
じゃあもう1日で全然できるような量なのか。
プリクラスがそれか、インクラスが両方とも2-2.5hだから、合計で6-7時間、1日でできるレベルだね。
12:14
でも全然いいね、やってみようかな。
あまりにも技術力あるでしょって、ある程度前提のもとに書いちゃったりするから、ここらへんどの塩梅で書けばいいのかとか教えてくれたりするのかな、わかんないけど。
やっぱり伝わるべきものっていうのができる人の方が見えてるだろうから、経験の蓄積的にもGoogleならいいのがあるんじゃないですかね。
そうね、ポッドキャストネタにもできそうだな。
これはありですね、やってみようかな。
確かに確かに。
これはフォースチューデンツなのか。
そうなんだ、いやでも全然普通に社会人エンジニアでもいいやつでしょ。
正直フォースチューデンツ読んでみて、これはもう読まなくていいわと思ったら、もっと上のやつをGoogleも出してるから出せばいいかな。
じゃあちょっと話を戻すと、
そうね、なので僕は今年はね、もうちょっとドキュメントとか読んでわかんなかった時に何回も読み返すっていうことを試してみようかなと思ってますね。
そうですね。
わかんなかったところはちゃんとメモして担当者に聞く。
どれくらい作業時間というか生産性に違いが出るのかっていうところをちょっと試してみたいなと思いました。
今回はこの記事のご紹介の回でした。
はい。
じゃあ終わりますか。
はい。
ではこんな感じでですね、週2回のペースで配信しているので、Apple PodcastもしくはSpotifyでおきの方はぜひフォローお願いします。
また質問箱のURLを概要欄に貼っているので、質問コメントなど送っていただけると嬉しいです。
では今週も聞いていただきありがとうございました。
ありがとうございました。またね。
