投稿元:
レビューを見る
・カナ入力を覚える
・テキストエディタを使う
・ツリー構造を意識(頭文字を頭につけておく等)
・internet archive
・''で囲んで検索
・ループの最適化
投稿元:
レビューを見る
PIE Program Intently and Expressively
プログラムを書くときは何を意図しているか常に明確にせよ。来週の自分は他人だと思い、常にいつ読んでも理解できるプログラムを書くことを徹底する。
KISS Keep It Simple, Stupid!
シンプルにしておけ、この間抜け!基本的にプログラマは人間の頭脳を信用しない。そこで極力プログラムの内容をシンプルに保ち、誰が見ても理解できるようにしておく。シンプルに保つことは想像以上に難しい。
今、文字の綺麗さに価値を見出されるビジネスパーソンはいない。むしろ、世の中にはびこる大量の情報から、仕事に必要な情報だけを抜き出し、そのエッセンスをまとめるキュレーション能力が求められる。
Markdown記法
YAGNI You Aren't Gonna Need It
君が今必要だと思う機能を、君がいつか必要とする日は来ないだろう。未来があるかどうか分からないものの未来を心配してもしょうがない。
ユビキタスキャプチャ
ユビキタス:偏在、つまりあらゆる場所と時間
キャプチャ:捕まえる
→ありとあらゆるタイミングで、ピンと来たら情報を捕まえておく
人は忘れることでより多くのことを覚えることができる。
積極的に忘れることで、頭の中のフリーメモリーを増やして、
より脳を効率的に動かそうという試みである。
スマートフォンとEvernoteを駆使する。
Evernoteに保存したメモは、Evernoteにログインさえすれば、世界中どこからでも確認できる。
「このページ気になるな。あとで読みたいな」と思ったらEvernoteのボタンをワンクリックするだけで
そのページの内容があなたのEvernoteにコピーされる。
図書館にある膨大な蔵書を効率的に検索するために図書館学は発達してきた。
「検索」という、ITの基本的な機能の起源は、図書館にある。
図書館を効率的に運営するために、情報を分類・整理する必要があったのだ。
つまり、情報科学は、図書館学から派生したものだ。
プログラミングで常に意識するのはデータ構造である。データ構造を定義することがプログラマの仕事の半分だ。
データ構造の設計がプログラム全体の効率を左右する。
Gyazo(ギャゾー)
画面の一部を切り取ってネットにアップロードし、同時にクリップボードにURLをコピーしてくれる。
Gyazoで取得した画像やムービーはEvernoteにそのまま取り込むこともできる。
最適化こそがプログラマが持てる力の限りを尽くして取り組む頭脳戦であり、
プログラムの性能を決定づける最重要スキルである。
些細に思えるようなことであっても出来るだけ手間を省く。
最適化の原則は「ループの内側から最適化しろ」である。
例えば、女性が永久脱毛をしたがるのも、
ムダ毛処理という手間のかかる処理を日々の生活というループ処理から追い出すという意味で
立派な最適化処理である。
情報収集の大前提として「本当に重要な情報はWebで検索できないことが多い」
ライブラリ化されている情報というのは有用であるが、重要でない。
Web検索は��くまでも「重要な情報」に辿り着くための手がかりとして利用する。
プログラマは自分の興味有る情報を収集するために、むしろ情報を発信する。
本を探すくらいなら本を書く。
勉強会に参加して、ただ座って聞いているのではなく、
積極的にライトニングトークで発表する。
飲み会に参加するのではなく、飲み会を開催する。
イベントが開かれるのを待つのではなく、自分で主催する。
これが最強の情報収集手段なのだ。
ネットに公開されている情報は、情報の受信者のためではなく、
情報の発信者のために作られている。
情報の交換とはギブアンドテイクが基本である。
ブロガーは言わば情報の前払いをし続けることによって情報を収集する仕事である。
インターネットワーク:人的ネットワーク同士をつなぐこと。
こういう方法でしか、本当の情報を持っている人にはたどり着けない。
世界中どこであろうと、呼ばれたら行く、というポリシーが結局のところ情報を集めやすくする。
究極の情報収集は情報そのものを作り出すこと、すなわちクリエイトすることだ。
とにかく移動する。できるだけ泥臭い方法で。これこそが究極の情報収集といえるだろう。
本当に重要な情報は泥臭い手段でしか手にいれることができない。
ハッカーの道とは、
持続的な改善と反復を積み重ねていくこと。
ハッカーとは、物事は常に向上できる余地があり、完璧なものは何もない
と信じている人のことです。マークザッカーバーグ
人は常に判断ミスを犯している。
プログラマの職業的美点は、他のどの職人よりも自分が無能であることに自覚的であることだ。
経験を積んだプログラマは大きなバグは繰り返さない。
戦術的なミスは不可避。戦略的なミスは外部から直すしかない。
ダンドリ。実際に仕事を行う前に仕事に必要な手順やチェックリストを整理しておくと、
極めてスムーズに仕事を進めることができる。
こういう手順や仕事の構造を決めることを「アーキテクチャの設計」と呼ぶ。
なんとなく、でやるのではなく、実行に先立って様々な状況を想定しながら仕事の構造を事前に決めておく。
アーキテクチャを洗練させていくことで仕事はより効率的に無駄なく遂行できるようになる。
戦略的ミスの大半は、トップの「思い込み」によって起きる。
プログラマの考え方は「配られたカードで勝率を最大化する方法を考える」ことだ。
「思い込み」も無くすことは出来ないと考える。
リーダーは視野狭窄に陥りがちだ。それは自信がないからだ。
そうしたときに本当に重要なのは、現場の声に耳を傾けることだ。
多角的な意見を得るためには匿名の意見を集めることが重要だ。
匿名による気軽さで本当に思ったことが言えるようになる。
仕事を進める上で「何かおかしい」という違和感を感じた時、
プログラマは決してほったらかしにしない。
なぜなら違和感はバグの温床だからだ。
順調は信じるな。本当に順調なら、報告すべきことや相談すべきことが何か出てくるはずだ。
順調という言葉のベールに隠されているのは触れられたくない厳しい現実である。
順調という言葉で報告するのではなく、
具体的に「何をしたのか」、「後は何をいつまでにしなければならないのか」という点をハッキリさせる。
フェイルセーフ:失敗への備え
フールプループ:愚か者でも安心
例外処理は万が一に起きる不測の事態を未然に防ぐ。
事前に解決することはできないが、事後に被害を最小限度に留める。
事前に行動計画をイメージしておくことを「プリフェッチ」と呼ぶ。
フェッチ:プログラムを取ってくること
プリ:事前に
パイプラインハザード:割込み処理が入ってプリフェッチが無意味になること。
プログラムに急な変更がない方が最も効率的に頭を働かせることができる。
クライアントがなるべく早くという場合、普通はどんなに遅くとも24時間以内に対応すれば問題はない。
デルメルの法則:情報を意図的に制約することによって、理想的なコミュニケーション状態を創り出す
コミュニケーションを取ることと同じくらい取らないことが重要。
プログラマだけが本当のプロジェクトの進め方を知っている。
プロジェクトにおけるリーダシップにおいて、
優れたリーダーを決める要素は「仕事を完遂できる人間」ということだけだ。
トラブルが常に起きるのは当たり前だ。
トラブルが全く起きなければ仕事がうまくいった「はず」である、などという甘えた考えは
ビジネスの世界では通用しない。
ビジネスとは人の命を奪わない戦場である。すなわちビジネスリーダーは戦場の指揮官である。
言い訳は何の役にも立たない。リーダーは言い訳ができない立場なのだ。
プログラマは常に自分の仕事の責任として、
「必ず完遂する」ことを要求される稀有な職業だ。
プログラマがリーダーに向いている理由は、
プログラミングという作業そのものがリーダシップと同じだからである。
プログラムとは何か、突き詰めていうと、
自分のいないところで、自分の思い通りに自分以外の存在を動かすこと、である。
ビジネスの上で起こる様々なトラブルを解決することは「デバッグ」作業そのものだ。
トラブルは必ず解決出来る。それを誰より知っているのはプログラマだ。
プログラマは決して額に汗して働いてはならない。
プログラマが行うのはプログラミングであって、計算(コンピュート)ではない。
現場に立つことは一見尊く見えるし、
現場に積極的に立つリーダーは尊敬を集めやすい。しかし、現実的にはリーダー失格だ。
なぜなら、リーダーはその集団の中で最も給料が高いのが普通だからである。
給料が最も高い人間が、
給料が最も安い人間でもできる仕事をするのは
給料という貴重な資源の無駄遣いにほかならない。
リーダーとメンバーの関係は、プログラマとコンピュータの関係である。
リーダーの主要な役割は、
チームビルディング、ディレクション、トラブルシューティングである。
優れたリーダーは一時の尊敬を集めることに執着しない。
結果を出すことだけが彼の能力���保証する唯一の方法だ。
仕事全体を細かな単位に細分化し、それぞれを専門的に行うことによって
仕事を効率化に進める。→命令パイプライン
投機的実行:予測できない現象Aに対して、仮説Aと仮説Bの両方を先に計算してしまって、
最後に否定された仮説の実行結果を捨ててしまうこと。積極的に捨て駒を作ることで全体のスピードを上げる。
リソースが2倍かかっても、YES/NOどちらでも期待できる利益が3倍以上であればリスクをとる価値がある。
戦略とはAかBどちらかに賭けるのではなく、どちらの場合でも生き残るための方法論であるべきだ。
フェイストゥフェイスが必要な場面と必要でない場面をハッキリ区別する必要がある。
フェイストゥフェイスが重要だからこそ、リーダーは情報収集のために絶えず世界中を飛び回っているべきだ。
進捗会議のような場面にはオンラインでもいいからできるだけリアルタイムで参加する必要がある。
短いスパンで小規模なチームによるスプリントレースのような試作プロジェクトを行うことをハッカソンと呼ぶ。
遺伝的ハッカソンは短期間にアイデアの検証から改良まで出来るため、非常に効果的な方法である。
ハッカソンを行う際は、人材の多様性を担保することがまず大事である。
リーダーとして成功する人物の条件をGoogleが求めたところ、
学歴や知能指数といったことろではなく、
「行動や反応が予測しやすい人がリーダーとして成功しやすい」ことが発見された。
リーダーは予測可能かつ一貫していなければならない。
予測可能であればあるほど、部下は働きやすい。
予測可能な上司はそもそも仕事に干渉してこない。
なぜなら、上司が予測可能であれば部下は「上司が求める仕事」が出来るからだ。
結果的に上司も干渉する必要がなくなる。
怒るときは激しく怒る。怒るのは疲れるし、面倒くさいし、つい避けてしまいがちだ。
しかし、怒るべきときにはしっかり怒らないと、伝わるものも伝わらない。
怒るときも褒めるときも重要なのは、どのような価値観でやっているかである。
家事にしろ、食事にしろ、一人の人間が独立して行なっているからこそ起きる問題である。
さらにコストの面では、会社の近くに住むと家賃が高くなる。
家族や兄弟、恋人や友人とのルームシェアを考えるのは
生活の最適化を考える上で避けては通れない視点だ。
プログラミングでは負荷分散と呼ぶ考え方だ。
共同生活を送るのが効率化の視点からなのか、それとも愛情の視点からなのかは
ルームシェアという言葉を使っている限りはハッキリしない。
ルームシェアの欠点は、なかなか始められないし、一度始めるとなかなか辞められないことだ。
こうした状態をスケーラビリティが低いと呼ぶ。スケーラビリティを確保したければ、シェアハウスや居候の方が良い。
取締役が果たす役割は
「利益に貢献するきっかけを作る」ことであって、利益を直接生み出すことは期待されない。
フレームワークとは既に有効であることが分かっているプログラム全体の仕組みを指す。ライブラリは特定の目的に対して専門的な機能を提供する。
プログラマはフレームワークに対して自分の作りたいプログラムの差分をプログラミングする。フレームワークが主で、プログラマは従だ。
一方、ライブラリはプログラマがそれを明示的に呼び出すまで一切の動作をしない。プログラマが主で、ライブラリは従だ。
フレームワーク型の取締役は会社としての方針をインプットすれば、勝手に売上を上げてくれるプロジェクトリーダー型の人物だ。
一方、ライブラリ型の取締役は本人の資質や能力といったことよりも人脈や経験といった、その人物しか持ち得ない特質を期待される。多くは社外取締役になる。
成功するために唯一必要なことは失敗しても諦めずに継続することである。
投稿元:
レビューを見る
プログラマーじゃないオフィスワーカーがよむといい。プログラマーはリソースやれいがいしょり、最適化など、シンプルにするための方法を常に考えている。業務効率の基本はこれに尽きる。
投稿元:
レビューを見る
非プログラマの人が、プログラマの考えをインプットすると、こんなに仕事を効率化できるというような話が載ってる本。
自分はプログラマの端くれなので、まあ分からんでもないというような話だった。非プログラマの人が読んで分かるものなのかどうか。
引用>
給料が最も高い人間が 、給料が最も安いアルバイトでもできるレジ打ちや商品陳列をするのは給料という貴重な資源のムダ遣いにほかならない 。
CEOだからってのもあるんだろうけど、やっぱり時間にはシビアですよね。自分も偉くなりたければ、時間を大事にしないとなと思います。
投稿元:
レビューを見る
高速化Tips
・辞書登録でメール処理を高速化
・親指シフトでタイピングを高速化
・エディタ活用: SublimeText, Visual Studio Code
・Gyazoで画像の登録を高速化
投稿元:
レビューを見る
ハウツーを知りたいのに関係のない文章を読まされていると感じるところもあった。基本は下線部と見出しを読んでいればOK。
投稿元:
レビューを見る
don't repeat yourself はいい言葉だな。仕事術の本で久しぶりにいい言葉に出会いました。
投稿元:
レビューを見る
まだ学生なのもあり、仕事の話では共感できる部分が少なかった。プログラミングの概念を上手い具合に現実世界に当てはめてるのは面白かった。基本的には啓蒙書で、それをプログラミングの概念を混ぜて書いたという風に感じた。
投稿元:
レビューを見る
・やりたいことしかやらない悪魔の流儀が目白押し
・リーダは働いたら負け
・プログラマーはすごいだろ感が強い
※詳しくはブログで
http://amazones.momokuri777.com/entry/2017/05/05/000000
投稿元:
レビューを見る
偏ったプログラマー至上主義とほんのり厨二病感がある著者だけど、業界では超有名インフルエンサーなので、心地よく読める。
仕事術、ライフハック、tips集として読むのが良い。
---
15
DRY (Don't Repeat Yourself)
20
徹底的な辞書登録
33
(議事録など)ビジネス文書の場合、SVOを明確にしておくことが非常に重要である
34
KISS (keep it simple, stupid!)
38
議事録にはWordを使うな。テキストエディタとMarkdown記法を使え。
46
プレゼン資料は直前に書け
62
プログラマーにとって典型的な情報分類はツリー構造とリスト構造である
129
今日と明日に急な予定は入れない
投稿元:
レビューを見る
フールプルーフ
ハッカソン
オペラント条件付け
前日に仕事を入れない
ある時点の預金が同じなら、借金と預金は同じ
スケーラビリティ
投稿元:
レビューを見る
プログラマーまで行かなくてもプログラムを
作ったことがある人にとっては常識な項が多い
「一般的ではないのか」と言う意味で新しい発見がある
「再利用可能な状態にしておく」
「ループの内側から最適化しろ」
とか
仕事術の本にたまにある読んでる途中で
「自慢か?」と思ってしまうタイプの文章がいまいち
投稿元:
レビューを見る
なんとなく感じていたことだったが、それが腑に落ちた。ソフトウェアの開発技術は、世の中の最先端かもしれない。
以下注目点
ノートブックのエクスポート
最速の仕事術はプログラマーが知っている
清水 亮
1 辞書登録でメールを5秒で送信 DRY(Don't Repeat Yourself)
ハイライト(イエロー) - ページ3 ?位置167
仕事の上で典型的なことをすべて再利用可能な状態にしておくのだ 。
ハイライト(イエロー) - ページ5 ?位置188
署名に最初からあいさつ文を書き込んでおく
2 タイピングを見直して生産性3割アップ かな入力と親指シフトキーボード
ハイライト(イエロー) - ページ15 ?位置295
親指シフトを使うと 、例えばかな入力ではツ ータッチが必要な濁音や半濁音もワンアクションで打てる
3 主語・動詞・目的語で議事録は書け PIE(Program Intently and Expressively)
ハイライト(イエロー) - ページ18 ?位置318
来週の自分は他人だと思い 、常にいつ読んでも理解できるプログラムを書く
ハイライト(イエロー) - ページ18 ?位置320
コメントで本来の処理を書いたコ ードを残した上で最適化したコ ードを書く
ハイライト(イエロー) - ページ20 ?位置335
誰が何をどのようにするのか
4 紙の資料でもリンクを張れ KISS (Keep It Simple, Stupid!)
ハイライト(イエロー) - ページ21 ?位置348
極力プログラムの内容をシンプルに保ち 、誰が見ても理解できるようにしておく
ハイライト(イエロー) - ページ22 ?位置357
ビジネス文書も常にシンプルであるべき
ハイライト(イエロー) - ページ22 ?位置361
企画書をはじめとするビジネス文書は 、短ければ短いほどいい
ハイライト(イエロー) - ページ24 ?位置385
ビジネス文章が長すぎると要点を見失う
5 長文にWordを使うな テキストエディタとMarkdown記法
ハイライト(イエロー) - ページ26 ?位置403
M a r k d o w n記法
ハイライト(イエロー) - ページ29 ?位置417
S u b l i m e T e x t
ハイライト(イエロー) - ページ30 ?位置428
V i s u a l S t u d i o C o d e
6 企画を宇宙戦艦にするな YAGNI (You aren't gonna need it)
ハイライト(イエロー) - ページ32 ?位置444
今必要なのはどれ ?
ハイライト(イエロー) - ページ32 ?位置446
ユ ーザが自分一人でも楽しい企画
ハイライト(イエロー) - ページ32 ?位置453
最初の体験 」が面白くなかったら
7 プレゼン資料は直前に書け 新製品発表会とライブコーディング
ハイライト(イエロー) - ページ33 ?位置461
アイデアというのは一度形にしてしまうと 、そこで成長がとまってしまう
ハイライト(イエロー) - ページ33 ?位置465
最先端の話題をきちんとフォロ ー
ハイライト(イエロー) - ページ35 ?位置486
人の心を震わせるのは 、常にライブなのである 。
1 情報を覚えておく時代はもう終わった ユビキタスキャプチャ
ハイライト(イエロー) - ページ40 ?位置530
ユビキタスキャプチャ
4 1秒でスクショ、2秒で共有 Gyazo(ギャゾー)
ハイライト(イエロー) - ページ54 ?位置653
G y a z o (ギャゾ ー )
��� フォルダに穴を開けて取り出さずにサインする 最適化とループ処理
ハイライト(イエロー) - ページ62 ?位置716
最適化の原則は “ル ープの内側から最適化しろ ”で
7 Webに本当に大事な情報は載っていない Webの発達と情報の格差
ハイライト(イエロー) - ページ70 ?位置793
ライブラリ化されている情報 (この場合はプログラム )というのは有用ではあるが 、重要ではない 。
9 一次情報を集める最も効率のいい方法 情報発信とインターネットワーク
ハイライト(イエロー) - ページ77 ?位置862
ブロガ ーはいわば情報の前払いをし続けることによって情報を収集する仕事
ハイライト(イエロー) - ページ79 ?位置884
世界中どこであろうと 、呼ばれたら行く 、というポリシ ーが結局のところ情報を集めやすくする 。
投稿元:
レビューを見る
プログラマーの良いところを美化しすぎな感はあるが、一般の会社員はかなり非効率な働き方をしているのも事実なので、みんながこの本に書かれていることを意識した方が良いと思う。
でも抵抗勢力はありそう。「そうは言っても直接会った方が、メールではなく電話をした方が」など言う人はまだまだ多いだろう。徐々に変わっていくとよいね。
投稿元:
レビューを見る
プログラマの問題回避や効率的な処理を、仕事術に応用できるという話。プログラマと話すと、「それは効率的じゃないのでやりたくない」とか言われまくるので、日頃から実感してる。そして、やり方まで考えてくれるプログラマは最高!
リーダは、展開する情報を絞ったりしながら、絶対に自分で作業してはいけない、という話は自分の胸に突き刺さって痛い。