「人の話が処理出来ない奴へのアドバイス」に関する補足元エントリにはてブが1700もつき、Twitterでも関連ツイートが千バズ、万バズになり、それらの閲覧数の合計が7桁になっていたのにはびっくりした。 「言語化されていないが切実な課題」だったのだな、と強く感じている。 そして、「自分の解釈を傍に置いて読む」ことができない人がたくさんいたのには、予想はしていたけどさすがに笑ってしまった。 まーそれが人間の仕組みだしね、とは思っているけど、やはり笑ってしまう。 その一方で、読めている人が、しっかり読んだ上で切れ味鋭くコメントしてきているのも事実。 世の中はすごい人がたくさんいるな、とも改めて思ったし、賢い人を甘く見てはいけない、という思いを新たにした。 ということで、フィードバックがあった点を中心に、情報を補足したほうが良いと思った点について、自分の考えを箇条書きで書いていく。 議論を理解する
早朝の寝る前ぐらいの時間にぼやっと下記の様なツイートしたらちょっと反応を貰ったので、取り留めは無いが自分なりに考えていることを書いてみる。 人を育てるのも仕事の内というのは完全にその通りなんだが、そこにドキュメントや本があるから読みます、触って作ってみます、生きたコードを読みます、以外に学ぶ方法なんかねえし、知らねえよ。ただやればいいだけの事に説明も何も無いんだよな……。マジ分からん……。— joker1007 (アルフォートおじさん) (@joker1007) March 2, 2023 タイトルは雑に書いたけど、能力を高めるというと範囲が広過ぎるので、技術的な意味でできる事が増える、ということをテーマとして話をしていこうと思う。基本的に自分の考え方の話なのでそこは御留意ください。 ツイートした通りで、状況や対象に依って割合は変わるかもしれないが基本的にそのためにやることは3つしかないと
ありがちな仕様とコードを題材に、よくないコードに立ち向かうための整理術を紹介します。 この Book にはデザインパターンや DDD やオニオンアーキテクチャや関数型プログラミングなどは一切登場しませんが、それらのエッセンスと日常のコーディングにおいて求められる基礎的な考え方の説明が含まれています。 この Book の内容は、特定の業務領域やプログラミング言語・フレームワークには限定されません。 Laravel でも RoR でも Spring でも React でも Nuxt.js でも、きっと役に立つはずです。 逆にこの本にはクラス設計のべき論や OOP vs FP のような議論は含まれません。 画一的なコードの良し悪しの定義は難しいですが、何かしら得るものがあったと感じてもらえたらうれしいです。
例を見ていただいたほうがわかりやすいですね。以下のようなテストコードをテックリードが初心者に示し、このテストが通るように実装コードを書くことを指示したと考えてください。 Javaを使っていますが他の言語にも置き換えて考えられます 開発環境はセットアップ済と考えてください 以下コード内import文は省略しています class DivideTest { private MathUtil mathUtil; @BeforeEach void setUp() { mathUtil = new MathUtil(); } @Test @DisplayName("通常の割り算") void test6Divide2Equal3() throws CalculationException { int expected = 3; int actual = mathUtil.divide(6, 2); a
Table of Contents generated with DocToc これは何 プラハチャレンジのコンセプト プラハチャレンジの卒業生にどうなって欲しいのか 教えるのではなく、一緒に考える 良い習慣を身につける メンターセッションの事前準備 質問を精査する 回答を書いておく サンプルを用意する(一緒に作る準備をする) 一次情報に近い情報源を探す 社内を頼る メンターセッション中 アイスブレイク 笑顔 愚問は存在しない 教えるのではなく問いかける 教えるのではなく一緒に考える(同僚のように接する) 宿題を残す 事実と解釈を分けて伝える 結論サンドウィッチ 30秒以上話さない 自信があるところ、ないところを区切って伝える メンターセッションの後 回答をジャンル毎のdocに整理する(知見を蓄積する) 記事を書く これは何 プラハチャレンジのメンターを担当するにあたり役立ちそうな行動や考
この記事は Classi developers Advent Calendar 2021 の 7日目の記事です。 こんにちは。顧客サポート基盤チーム兼、技術戦略室にてエンジニアをしています、中島です。 みなさんは、日々仕事をする上で必須である「誰かに質問をする」という行為について、自信を持って適切に行うことはできているでしょうか？ 先月弊社では外部講師である、株式会社フィッシャーデータのあんちべさん をお招きし、質問力向上のための研修を実施しました。今回はこの研修を実施するに至った背景、研修内容を少しお見せするのと、社内の反響をお伝えします。 質問力を向上しよう！と至った背景 弊社は2020年2月頃よりリモートワークへの移行を行い、1年半以上が経過しました。リモートワークのお困りごととして一般的にもよく聞かれる、コミュニケーションについての課題を見聞きするようになってきました。 （ちなみに
失敗から学ぶ、つまり「経験をもとに得た知識や教訓を自身に定着させる」ためには、失敗を経験することが必要だし、それをふりかえることが必要だろう。 ふりかえりの具体的な方法論については本で学んだり実践したりして知見を溜めてきたけれど、どんな経験をふりかえれば良いのかについては考えたことがまだなかった。なので今日ここでチャレンジしてみる。 ちなみにふりかえりの方法論はこの本にびっしりと載っている。チームのふりかえりをレベルアップさせるにはもってこいの一冊だと思う。 ＊ ＊ ＊ さて、学びの獲得に経験がどんな影響を及ぼすのかについては、コルブの経験学習理論が参考になりそうだ。 経験学習理論とは、新たな「具体的な経験」をした際に自分の中で意味付け・価値付けといった「抽象的な概念化」をする、という学習サイクルを指す。 そしてこの具体的経験⇔抽象的概念の変換に必要なことが「内省的なふりかえり」と「能動的
ある文系プログラマがテックリードを任されるまでに学んだこと ── 最前線で生き延びる4つの戦略 コンピュータサイエンスの専門教育を受けず、20代半ばで本格的なプログラミングを始めた文系エンジニアが、いかに学び、考え、生き延びてきたのかを伝えます。 こんにちは。白山（@fushiroyama）と申します。現在は新聞社のデジタル事業部署で、モバイルアプリ開発のテックリードをしています。 自分のエンジニア人生を振り返ると、これまでの道のりは決して平坦ではありませんでした。コンピュータサイエンスの専門教育を受けず、本格的にプログラミングを始めた年齢も23、4歳と決して早くありません。 そんな自分が、いかにして開発チームのリーダーを任せてもらえるまでになったか？ 考えてみると、次の4つの戦略で生き延びてきたようです。 自分だけの居場所を見つける 必要な知識を効率的に取捨選択する 他のエンジニアに差を
リーダブルコード要約とリーダブルコード要約の活用方法 今後コードレビュー時に「これってリーダブルコードの◯◯だよね？、こう直したほうがいいよね」と引用できレビューの時間の短縮化が実現できる。 リーダブルコードに登場する特殊ワードをチームのコーディングの共通語とする。デザインパターンのカタログ的な考え。 リーダブルコードを読んでない人も内容を短時間で把握できる。 チーム全体のコードを読みやすくメンテナンスしやすくし品質をあげる。 リーダブルコード教になりチーム以外にも広める。コードの品質が悪い人にはリーダブルコードの読書を進めてみる。ひどいコードのままコーディングしてもらうよりその時間を読書の時間に割り当てることも考える(結果的に時間が還元できるなら）。 リーダブルコードに書いてあることが全てのプロジェクトに適用てきるわけではないけれでもコーディングルールを考える際の指針にすることはできる。
guide.md 自己紹介 00:00 あいさつ 自己紹介 吉村総一郎 ハンドルネームは sifue 読み方は「しふー」 元々ニコニコ生放送の開発者を3年 その前は製造業向けシステムインテグレーターを5年 学生の頃は研究室で画像解析や数値解析のプログラムを書いていた 趣味は競技系のネットのゲーム、LoL、PUBG、Fortniteやハースストーンなど (弱い) 2016年よりN高等学校/N予備校プログラミング講師 N予備校 プログラミング 入門コースについて 00:05 この入門コースでは、みなさんにプログラミングを体験してもらって、1年間でWebサービスを作れるようになる この入門コースを終えて何か自分自身のものを作るとアルバイトやインターンをして問題ないレベルになる 対象者は、中学校で学習する数学と英語の内容をだいたい8割ぐらい理解できていれば大丈夫 実際は小学校卒業レベルでも大丈夫
「わかった？」は意味のない言葉 似たようなことでいうと、メンターは何かを教えた後に「わかった？」と確認してしまうことがあります。このとき、メンティが「わかりました」と答えたとして、何か意味があるでしょうか。先ほどの「心構え」と同様に確認しても観測できないことを問いかけている状態になってしまいます。 そうではなく、具体的に「今言ったことを、ひとりで試しにやってみて」とか「以下の話を図に書き起こしてみて」とかアウトプットを要求しない限り、わかったかどうかなんてわかりません。 学生時代に私は塾講師をしていたのですが、課題のプリントを生徒たちに渡して、「わからなかったら手を上げて」と言ってたのですが、そのときは誰も手を上げられなかったという体験があります。そのあと、どうしたらいいんだろうかと考え、「問題を解く手が止まったら手を上げて」と伝えるようにすると、手を上げてくれる生徒が現れました。 抽象的
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
