最近の記事

疑問を出せることが価値

勉強をやっていくにあたって、「疑問が出せない状態」ってのがあるなーと思っている。 上記の記事の内容だと、1. 無意識的意識か、2.意識的無能の状態だと思う。 新しくプログラミング言語を学ぶ時とかであれば、今までの経験から「この言語では、○○って機能は備わっているのだろうか」といった感じで疑問を作り出すことができるし、あと書かれている内容も雰囲気でわかったりする。 なので、疑問に対してもピンポイントでより上手く言語化できている感覚がある。 これが自分の全然知らない分野だと

    • 決め方を学びたい

      決めることへの恐怖もある中、じゃあ実際に何をどうやったら決められるのだろう。 意志決定に関する悩みを社内ですると、悩みすぎて決められないよりは、その時の環境や情報の中で早く決める。 その中で、ちゃんとその時の状況とどう決めたのかっていうのをロジカルに説明できることが重要だと言われた。 あとは、全員が納得できるような意志決定は無い。真の合議制ってのはないから、ちゃんと自分で意思決定した背景が伝えられることが重要とのこと。 そう聞いた時に、自分はそもそも意思決定のやり方をち

      • 決めることへの苦手意識

        「決める」ことについて、苦手意識があるなと思った時に、そう思う根っこの部分ってなんだろうと思った。 前は自分自身で決めることについては、自分で決めたことなので自分自身が納得していればそれでいいと思っていて、チームに影響するようなことは辛いと書いた。 なんで辛いかと考え、 たとえば間違った意志決定をしてしまい、そのせいで迷惑を掛けた場合に責められるのではないか。という恐怖を感じるからだろうな、と思った。 (もちろん、そういう事実があるわけではない。自分がそういった可能性を恐

        • おもしろそう

          ちょっと前に、以下の本をオススメされた まだ冒頭しか読んでいないけど、環境のノリに乗っ取られるという話、「ひとまずこれを勉強した」という勉強の有限化。結構面白そうな話があるので、合間合間に読んでいきたい

          問いかけと決めること

          頂いたフィードバックの中に、「問いかける」は上手くできている。 なので次は「決める」ことが上手くなると良い、といったことを頂いた。 自分自身でも「決める」ことには、ちょっとした苦手意識を持っている。 自分だけに関わることであれば、「えいや」という気持ちで決められるけど、周りの人やチームの意思決定に関わることが苦手だったりする。 自分自身に関する意志決定は、最悪自分自身に返ってくる話なので、自分自身が納得していればそれで良いし、自分自身がで責任を取ればいいと思える。 だ

          問いかけと決めること

          フィードバックの難しさ

          3Qが終わり、360度フィードバックを書いて、内容を貰った。 概ね自己評価と比べて大きな差異が無くて、自分の自己認識は周りとズレてないとわかって、少しほっとしている。 それと同時にあまり大きな驚きが無いなぁって思ったりする。 驚くような評価にならないってのは良いことなのかもしれないけど。 みんなから頂いたフィードバックを見て、みんなフィードバックの書きっぷりが上手いな、とか。自分でも忘れていたような出来事を出して評価してくれて嬉しい気持ちになる。 なので、自分が書いた

          フィードバックの難しさ

          ライブコーディングの魅力ってなんだろう

          スポンサーブースを出す機会があって、社内の人間と一緒にペアプロとTDDをDiscord上でライブコーディングをやってみた。 結果的には何人かは興味を持って見てくれていたと思うので良かったと思う。 なにより、やっている自分たちが楽しかったのがある。 自分たちの楽しいがその場で出せて、目の前でやっていることは重要なんじゃないかと思っていて、 そういった感情とかが伝搬するのはその場でやるライブコーディングならではなんじゃないか。 要素的には、 ・ライブコーディング中にコーデ

          ライブコーディングの魅力ってなんだろう

          ペアプロと雑談

          リモートワークになってから雑談が減った。どうしよう。といったお話を社内、社外問わず聞くことが多い。 ただチーム内の雑談については、現状特に問題無いなと感じている。 いま社内ではフルタイムでペアプロを実践していて、自然とコミュニケーションは発生するし(むしろ沈黙が続くペアプロは不健全とも言われてる)、ある程度余裕(ビルド時や長いテスト通している時など)があったりすると、「そういえば…」みたいな感じで雑談をすることがある。 お互い音声会話で繋がっているので、「そういえば」的

          ペアプロと雑談

          1ページだけ読み進める読書

          「2分以内で終わらせる」ことで習慣形成ができるようにする、という話で、1ページずつ本を読むのを実際にやってみた。 ・トリガーとしては、仕事中の休憩時。 ・やることは、1ページ「だけ」本を読むこと(文章が途切れていようが絶対1ページのみ) ・読み終わったら、入れ物にコインを入れる(習慣トラッカーで見える化) 今日で5ページ読めた。 たった5ページ?となりそうだけど、個人的には1ページだけしか読まない、という縛りの中でちゃんと5ページ読めたのは大きいなって思う。 ただ午後く

          1ページだけ読み進める読書

          続けられることを考える

          四半期ごとに個人目標を立てることになっている。 立てる目標としては、一昨日に書いたとおり並行処理の勉強をしていこうと思っている。 そのときに、いったんは立てた目標を忘れるように考えたい。 目指す姿としては並行・並列処理を理解した状態だけど、そこへ向かうのはとても遠い(何をもって理解したか、というのもある) まずは課題図書を毎日読むことを習慣づけたい。 ・毎日1ページを読む ・同じ時間に読む ・何か他の習慣に紐づけて読む ・コードの写経をする 1ページ読む、というのは

          続けられることを考える

          習慣トラッカーについて

          先日から読んでいる本で、習慣トラッカーの話が出てきた。 習慣トラッカーによって、はっきりさせ、魅力的にし、満足できるものにする。過程にフォーカスしたものである。 じゃあ自分でも習慣トラッカーを始めようと思ったときに、いくつかアプリがあったけど、結局は何か習慣を実践したらコインを溜めていくアナログに頼ることにした。 理由としては、 ・アプリだと毎回立ち上げるという行為が必要(些細なことだけど面倒である) ・物理的に見えるほうがわかりやすいから まだ始めたばかりなので、う

          習慣トラッカーについて

          10月〜12月で主軸に読む本

          10〜12月まではこの本を中心に読んでいこうと考えてる。 Rustにも若干興味もあったけど、一番は並行処理、並列処理についてちゃんと理解をしておきたいっていうのがある。 Kotlinを触っていて、並列処理を入れたときにスレッド枯渇したことがあったけど、 並列処理の内部の動きがどうなっているのかが全くわからなくて、あまり貢献ができなかったなというのがある。 なので、ちゃんと理解をするタイミングかなと思った。 あとはどの言語、どの場面でも並行、並列の話は出てくるので、潰しが

          10月〜12月で主軸に読む本

          ジェームズ・クリアー式 複利で伸びる1つの習慣を読んでる

          この本を読んでいる。4つ目の原則をいま読んでいる途中。 とても面白いし、自分も小さな習慣の積み上げをできるようにしたいと思った。今度のOKRはこれを意識して書いていこうかな

          ジェームズ・クリアー式 複利で伸びる1つの習慣を読んでる

          30時間とにかく一緒に勉強をしてみる

          知り合いのエンジニアと一緒に、夜2時間くらい使って、トピックを決めてプチ勉強会をやっている。 やった&やっているやつ10月:Django REST frameworkのチュートリアルすべてを音読しながら、写経してみる 11月:わかりみSQLの初級編あたりを音読して写経していく なんとなく、一緒に3h×10日=30hくらいで、その分野の入口くらいには立てる感じがして、結構よくない? という話をしている。 今の所のメリットは、 ・普段自分一人でなかなかやらないモノに手を

          30時間とにかく一緒に勉強をしてみる

          アート・オブ・アジャイルデベロップメントを読み始めた

          以下の輪読会イベントがあり、興味があったので購入。 (実際には1ページくらいしか読んでなくて、輪読会イベントには間に合わなかった) 本書に興味を持った理由と現状の課題感現場ではスクラムを取り入れた開発を行っている。 だから対外的にはアジャイルな開発を行っていると言っているのだが、疑問に思う時も多い。 ・そもそも何をやっていたらアジャイルなのか。ウォーターフォールで無ければいいのか? ・何のためにアジャイルやっているのか? というのが自分でうまく言語化できない ・受託の場

          アート・オブ・アジャイルデベロップメントを読み始めた

          データベース・リファクタリングを読み始めた

          最近新しいデータベースへ移行するためにテーブル設計をしている。 その業務自体が商品を取り扱うマスタで、いろんな業務に関わってくるので、いろんなところから参照される。 業務自体が複雑だし、データの持つ意味を紐解くのも大変ではあるけど、それ以前に自分自身が、 ・そもそもデータベースの設計経験が少ない ・データベースは一度決めると変更がしづらい印象を持っている→苦手意識 自分はテスト駆動開発が好きであるため、最初は拙いながらも、どんどんリファクタリングをしてコードの品質を上

          データベース・リファクタリングを読み始めた