t_wada さんの講演メモ ー 技術書の読み方を中心に - 冷めたコーヒー
はじめに 和田さん（@t_wada）の講演が素晴らしく良かったのでメモを残しておきたいと思います。和田さんと言えば... t_wada ですね！本講演では、「技術の学び方を学ぶ」ことを目的として二部構成で論が展開されました。「技術の学び方の学び」とは、メタレベルの学びのことを指しています。すなわち、効率的に新しい技術を学ぶためにはどのように学べば良いのかという話です。内容は以下の通りです。 第一部 四半期ごとに技術書を読む 手を動かしながら学ぶ 毎年少なくとも一つの言語を学ぶ 身の回りをプログラミング対象にする アウトプットを行う 第二部 毎日コードを書く 年下から学ぶ 過去から未来を見る 人のつくる渦を見る 大事なことに集中する いずれも非常に興味深い内容だったのですが、細かい事項については2017年の講演メモのエントリーがありましたので、ぜひそちらをご覧いただければと思います。（記事へ
エンジニアはアウトプットによって成長できるのか？ / Grow with your output
このトークの目標は、参加者がアウトプットを始める前に気づくべき要素を知り、「成長を設計できる」ようになることです。 昨今ではカンファレンス・勉強会・技術同人誌・Podcastなど、アウトプットの機会や手段が増え、エンジニア文化として根付きました。 多くのエンジニアがその文化を当たり前のように受け入れていますが、なぜ私たちにとってアウトプットが重要だといわれているのでしょうか？ まだアウトプットをしていない人は「何をしていいかわからない、自分なんかにできない」と避けていませんか？ 現在アウトプットしている人は「何をすれば自己成長に繋がるか」を考えてアウトプットできていますか？ さまざまなメリットがあるアウトプットを成長のツールとして使いこなす為には、自身の成長戦略を描かなければなりません。 アウトプットについて正しく学び実践することで、自身を成長させ、またコミュニティ全体をも成長させることが
週報をやめて、週末にLTをすることにした ベーシック エンジニアブログ Basic->deploy('blog');
こんにちは。株式会社ベーシック CTO の @zaru です。 今回は 週報をやめて、週末にLTをすることにした 話を紹介したいと思います。 チーム週報という活動 弊社 開発部では1年前くらいから開発チームごとに週報をQiitaチームに書こうという取り組みが自主的に行われていました。個人ごとではなく、チーム単位での週報というのが良かったです。 チーム単位だと、プロダクトや事業など技術的ではない視点が入ったり、チームの中でも、各人がどんなことをしているのかを知っていないと書けないので、自然と情報共有が進みやすかったと思います。 書くのが面倒問題と反応が薄い問題 しばらくは良い感じで運用されていたのですが、いつしか週報が形骸化してしまいました。問題は大きく2つあると考えています。 1つは週報を書く行為自体がそれなりに大変なので、単にやったことを箇条書きで羅列するだけで終わったりして、読み手に伝
エンジニアの信頼を得るには良質なアウトプットが必要な話 - そーだいなるらくがき帳
先日、僕が大好きでリスペクトしてるソフトウェアエンジニアさんたちと意見交換会（呑み会）中にソフトウェアエンジニアの信用と信頼について話題になったのでメモ。 僕が「このソフトウェアエンジニアは信用できる」っていうのはどういう指標がありますか？って質問した時に出た意見としては コードに対して何らかの貢献をしている 新規プロダクトの開発など OSSのメンテナンスなど（パッチを送るなど） 自分の持つプロダクトに対する反応など が出てきた。 これらのような「良質なアウトプット」を定期的に行う頻度も大事だよねという感じ。 なるほど、確かにって思ったのだけど更にその中で良質なアウトプットとは何かという話題になった。 ソフトウェアエンジニアの属性 ソフトウェアエンジニアには得手不得手がある。 言語だったりレイヤーだったりで好き嫌いも含めて得手不得手がある。 更にもっと言えば「プロダクトの成長段階」でも得手
エンジニアがアウトプットすべき理由 | 外道父の匠
ブログが流行りだして10年以上が経とうとしているのに今更な内容ですが、エンジニアがブログを書く書かないについて再考する機会があったので、書き留めておきたいと思います。 書く人にとってはメリットがわかってるし、書かない人にとってはデメリットを流せるし、ぶっちゃけ好きにすればいいだけではあるのですが・・・ アウトプットとは ”発信”の方がしっくりくるのでどっちも使いますが、ここでは一般的っぽい”アウトプット”としています。私が思いつくアウトプットとは、 技術ブログを書くこと Wikiに手順やバッドノウハウをまとめること Twitterやコミュニケーションツールで短文メッセージを投稿すること 登壇発表すること 講師やメンターとして育成すること 書籍や連載を執筆すること ソースコードを公開またはプルリクすること で、どれも社内／社外どちらでも問わない、といったところです。ただし、社内におけるコード
勉強は「そのテーマで1時間講演が出来る」を目標に - 蕎麦屋
とある尊敬してやまない経済人の方と飲んだときの話。 その方を一言で評するなら「博覧強記」という方。分単位のスケジュールで動くレベルで仕事がお忙しいにも関わらず、どんな話題にも詳しく、面白い話をいつもしている。宇宙の話から財界人のうわさ話、スポーツの話題から話し相手の地元の歴史、そしてまた科学哲学に戻って、、、みたいな広がり方。それぞれの話で平気で5分10分は話してるし、それらがイチイチ面白いのだから困っちゃう。 あるとき、「どうやってそんな忙しい中でいろんな話を仕入れてるんですか。どうやって勉強してるんですか」と聞いた事がある。その時の会話。 「蕎麦君。君は楽器をやってたよね」「はい」 「上達の最大の秘訣は何だと思う？」「練習ですかね」 「そうだよな。それも、ただ練習してるだけじゃダメで、10個楽器をやるより、1つことに集中したほうがいいよね。あと、何で楽器弾いてるの？」「なんででしょうね
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
