タグ

考え方に関するsanthiagomanのブックマーク (29)

  • Increasing number of attempts ver. 2021

    試行回数の増やし方 2021年度版です

    Increasing number of attempts ver. 2021
  • 【t_wadaさんの講演】技術の学び方 - だいたい死んでる

    2017/09/23にサポーターズコラボの和田さんの「【和田卓人氏特別講演】若手エンジニアに送る、"心構え"と"キャリア観"」の講演会に参加していました。 参加した経緯としては、友人からすすめられたのもあるのですが、最近テストを書くことが多くあり、調べた際にT和田さんの話が多く出ていたので興味を持ち参加することにしました。 講演を聞き和田さんがプログラマーとして生き続けるために必要なこととして「技術を学ぶことよりも、技術の学びかたを学ぶこと」がこの先プログラマーとして生きていく上で大切だと思ったのでまとめたいと思います。 今回の講演ではないですが、資料があったので参考までに以下に貼っておきます。 speakerdeck.com 技術の学び方を学ぶとは プログラミングの技術は小さなことから大きなことまで、毎日のように新しい技術が出て来る。そのため、出てきた技術をすべて学ぼうとすると、時間が足

    【t_wadaさんの講演】技術の学び方 - だいたい死んでる
  • キャリアキーノート / Career Keynote

    GMOテクノロジーブートキャンプでお話したこと。

    キャリアキーノート / Career Keynote
  • とにかく雑に作れ

    学生たちを見ていると、きちんと議論して、きちんと設計して、きちんと何かを作ろうとするみたいです。ときには副作用を考慮して、やっぱり作るのやめようかという話になり、再び議論に戻ることもあります。 ああ、もったいない、もったいない。私は適当な人間なので「なんてマジメなんだ、とりあえず何か作ればいいのに」と思います。デザイン思考ではそのことを「クイック&ダーティプロトタイプ」と呼んだりしますが、それだとなんだかカッコよすぎるので、私は「雑に作れ」と言ってます。 でも、言葉だけでうまく伝わるはずもなく、「どうすれば雑に作れるのか?」と再び議論を始めたりするので、なかなか難しいところです。 それでも「締め切り」というのは効果的なもので、次回までに何かを発表しなければいけないとなると、「議論してばかりじゃ話が進まない!」となり、ある種の覚悟を決めて雑に作ってくれるようになります。 私が印象的だったのは

    とにかく雑に作れ
  • 56歳からコードを書き始めて食べていく方法

    私は56歳、最近プログラミングを始めたんだ。 なぜかって?やりたいからに決まっているじゃないか。ようやく最近コツをつかめてきてね。でもコツをつかめたからといって簡単にはいかない。正直なかなか手こずっている。でもいいんだ。 アルゴリズムに挑戦して我を忘れるのは楽しいし、まだテストしたい事があって「あと数分だけ」と繰り返し自分に言い聞かせるのもいい。「今度こそ上手くいったかも、、」とドキドキしてから「やったぞ!ついに動いた。」となる瞬間も大好きだ。 でもこんな私には今まで趣味と呼べるものが何ひとつなかった。自分に見返りがない事に時間を費やすのは嫌だったんだ。ただ楽しみのためだけに何かをするのが好きじゃなかったのさ。休みの日にやる事といったら、ちょっとした小遣い稼ぎになるような事ばかりだった。 オーケー。もちろんコーディングだって小遣い稼ぎさ。上手くやればかなり稼げる。これだってあなたから見れば

    56歳からコードを書き始めて食べていく方法
  • 海外エンジニアが話題にしていて「なるほど」と思ったプログラミングに関する考え方3つ - ジンジャー研究室

    プログラミングに関する格言みたいなのは昔から結構あって、例えばYAGNIみたいに日でも十分浸透してるのは多いんだけど、やっぱり新しい概念はどんどん生まれていくので追いかけていると面白い。 というわけで、最近知った中でもっと日でも言及されても良いと思ったやつを3つ紹介。 Simple Made Easy Rich Hickey(Clojure言語の作者)による講演(2011年)のタイトル。全文はここで読める。英語しんどくてPOSTDに投げたんだけど音沙汰がない。まだ全部見てないから和訳欲しい。 内容としては、みんな安易に「簡単」なものを選びがちだけど「シンプル」なものの方が価値あるぜ、というもの。曰く、「シンプル」は絶対的・客観的な指標だけど「簡単」は相対的・主観的なもの。例えば英語の話者にとってドイツ語は難しいが、それは自分にとって「遠い」存在であるだけで悪いものじゃない。 「慣れてい

    海外エンジニアが話題にしていて「なるほど」と思ったプログラミングに関する考え方3つ - ジンジャー研究室
  • 「締め切りは絶対に守るもの」と考えると世界が変わる

    2011年にインプレスジャパンから「エンジニアとしての生き方」というを出版して以来、書籍よりは「メルマガ(週刊 Life is Beautiful)」の執筆を優先して来た私ですが、この度、とある編集者に説得されて「時間術」のを出版することになりました。 『なぜ、あなたの仕事は終わらないのか スピードは最強の武器である』(文響社) 「時間術」とは言っても、巷に良くある「どうやって時間を効率よく使うか」という話ではなく、実際の仕事の現場において「常に締め切り通りに仕事を終える人」になるための、私なりの「仕事に対する取り組み方」を解説した仕事術のです。 「いつも締め切りに追われている」「締め切り間際にならないと気で仕事ができない」という悩みを抱える人たちには是非とも読んでいただきたいです。締め切りを守れるかどうかは、締め切り間際のラストスパートで決まるのではなく、もっと前の段階での、「

  • 年を取って気がついた時間を無駄にしている悪習慣4つ | ライフハッカー・ジャパン

    常日頃からライフハックを駆使して時間節約を試みている私たち。確かに、塵も積もれば山となるのですが、若いころ無駄にした膨大な時間は、いくら後悔しても取り戻せません。 今振り返ると、筆者にはシステマティックに時間を捨てていたような悪習慣がいっぱいあったような気がします。 そこで、まだ間に合う人のために、筆者が若いころ時間を無駄にしていた悪習慣をいくつかお伝えします。これらを避けるだけで、かなりの時間とエネルギーの節約になるはずです。 時間の無駄1:助けを求めない大学を出てすぐに入った会社でのことです。最初の週、上司に膨大な集計表を渡されました。 「整理しといて」と言われたものの、私にはちんぷんかんぷん。無口で臆病者の私は、ただうなずいて席に戻りました。そして、何かわからないものかと、1時間ほどそれを眺めていました。 それでもわからなかったので、ようやく近くの先輩に、何をしていいのかわからないと

    年を取って気がついた時間を無駄にしている悪習慣4つ | ライフハッカー・ジャパン
  • 日本と米国で異なる「想定する物量」がソフトウェア開発の生産性の違いを生む - メソッド屋のブログ

    私は米マイクロソフトの DevOps のインターナショナルチームに所属しています。ただ、住んでいるところは日なので日側のオペレーションも実施しています。 前回のブログでも書いた通り、私はどうして米国のエンジニアが生産性が良いのかをずっと知りたいと思っていたし、今も研究中です。この2つのチームに同時に見えてきたことがあり、彼らの生産性の良さの一端に気付いたのでブログにして残しておきたいと思いました。 見えてきた「物量」の違い 私がインターナショナルチームと一緒に向こうでしているときに、仕事でアップアップになったことはありませんが、日だとしょっちゅうです。日のMSもはっきり言って過去に私が所属したどの会社より相当効率的で無理がないのですが、それでも存在するこの差はいったい何でしょうか?いくつかの事例を通じてだんだん見えてきたことは1つのことをこなすための「物量」が違うということです。

    日本と米国で異なる「想定する物量」がソフトウェア開発の生産性の違いを生む - メソッド屋のブログ
  • 人生は神ゲーだ

    気でがんばるとぎりぎり倒せるように絶妙のバランス調節がされた敵。 単純作業じゃ効率が悪いけど、工夫次第でどんどん効率を上げられる経験値システム。 リセット不可の緊張感。でもシレンとかよりずっと死ににくいからあんま気にする必要なし。つーか普通のゲームでもリセットなんて邪道じゃん。 全てのキャラが深い人間性と歴史を持って登場する、圧倒的リアリティ。 グラフィックが綺麗すぎ。多分、無限×無限ピクセルで、毎秒無限フレームで動いてる。色も多分無限色使える。夕焼けとかマジありえねー美しさ。 BGMの種類がほぼ無限。選曲も自由。自分で作った曲を流すこともできる。 人間が作ったとは思えない、とんでもなく複雑で洗練されたシナリオ。 リアル出産システム採用。自分と、自分よりも大切に思える相手の遺伝子を半分ずつ受け継いだ、奇跡のようなキャラを生み出して、そいつに自由に色々教えて育てることができる。すごく嬉しい

    人生は神ゲーだ
  • シミュレーション仮説 - Wikipedia

    シミュレーション仮説(シミュレーションかせつ)とは、人類が生活しているこの世界は、すべてシミュレーテッドリアリティであるとする仮説のこと。シミュレーション理論と呼ぶ場合もある。 哲学者ニック・ボストロムは、我々がシミュレーションの中に生きているという可能性を追求した[1]。彼の主張を簡単にまとめると次のようになる。 何らかの文明により、人工意識を備えた個体群を含むコンピュータシミュレーションが構築されている可能性がある。 そのような文明は、そのようなシミュレーションを(娯楽、研究、その他の目的で)多数、例えば数十億個実行することもあるだろう。 シミュレーション内のシミュレートされた個体は、彼らがシミュレーションの中にいると気づかないだろう。彼らは単に彼らが「実世界」であると思っている世界で日常生活を送っている。 そこで、以上の3点に「可能性」があるとしたとき、次の二つのうちどちらの可能性が

    シミュレーション仮説 - Wikipedia
  • ドラクエ風スキルマップ - nemorineのブログ

    あるとき突然『チームのキーマンが抜ける』というイベントが発生しました! まあ会社という組織ではよくありますよね(苦笑 チームメンバーが不安がっていたので、以前、楽天の川口さんに教えてもらったドラクエ風スキルマップを使って今の状況を可視化してみました。 これもまさにゲーミフィケーションって感じですねぇ~ スキルマップを作る過程 元々はWebアプリケーションエンジニアのスキルマップだったため、自分達に合うように数人でスキルマップを練り直しました。 これだけでもかなり盛り上がりましたッ!! 以下は川口さんのオリジナルから変更したところです。 要件定義のスペシャリストとして、商人を追加。 旅芸人はマネージメントのイメージに変更 スキルの方向を上方向に変更 盗賊のスキルレベルの見直し CやC++をイメージして文言を見直し 特性に対応するキーワードを追加 スキルマップを記述する チームメンバーに実際に

    ドラクエ風スキルマップ - nemorineのブログ
  • 知識を深めることができているかを確認するための3つの段階 - ジブンライフ

    知識を深めるとはどういうことなのでしょうか。 様々な考え方があると思うのですが、今回はぼくがを読んでいるときに感じる三つの理解の段階についてお話したいと思います。 第一段階が一番基的なものであろう「そのを理解する」こと、第二段階が特に同じ分野のを読んでいると感じる「色々なの共通点を見つける」こと、第三段階として「知識を組み合わせて新しいことを考える」と考えました。 それではそれぞれの段階について説明していきましょう。 第一段階:そのを理解する 第二段階:色々なの共通点を見つける 第三段階:知識を組み合わせて新しいこと考える まだ発展段階のもの 第一段階:そのを理解する もっとも基的なこととして、そのの内容を理解するということが第一段階としてあげられます。 ただし、理解することとを読み終えることは同じことではありません。 を読んで理解して(したつもりになって)、その内

    知識を深めることができているかを確認するための3つの段階 - ジブンライフ
  • 「努力する人」と「努力できない人」の6つの大きなちがい

    数々の「仕事のできる人たち」は、ほぼ例外なく努力をしていた。 無論、努力をしたからといって成功するわけではない。だが、努力なくして成功はない。努力は成功のための前提条件であり、要件である。 だが、「努力が苦手」という人は少なからずいる。頑張れない、続けられない、「どうしたら努力できるか?」と悩む方も大勢いるだろう。 私は、数々のコンサルティングの現場で数多くの「努力できる人」と「努力できない人」を見聞きし、そして、両者は一体何が違うのかということに強い関心を持った。 その結果、努力できる人とできない人は、「能力」が異なるのではなく「考え方」が異なるのだという結論に至った。 実際、能力の高低にかかわらず、努力を続ける人達がおり、現場ではそのような人たちが結果を出していた。 では、その「考え方」のちがいはどこにあるのか。それは大別すると6つある。 1.努力とは、精神論でなく、方法論である 努力

    「努力する人」と「努力できない人」の6つの大きなちがい
  • https://www.pasonacareer.jp/article/20151013/

    https://www.pasonacareer.jp/article/20151013/
  • 「できません」と言わないソフトウェア技術者の話。

    私の知人に、ほとんど「できません」と言わないソフトウェア技術者がいる。営業であれば、「出来ません」と言わない方は普通にいるのだが、ソフトウェア技術者では珍しい。 「GoogleAnalyticsのように、グラフィカルに表示できないですか?」 ⇒「なんとかしましょう」 「1週間以内に実装できないですか?」 ⇒「わかりました」 「応答のスピードを上げられますか?」 ⇒「やってみます」 彼は周りからたいへん頼りにされているのだが、かと言って安請け合いするわけでもない。仕様に問題があれば必ずディスカッションを求め、必ず納期は守る。 私は彼が「やったことはないですが、多分できるでしょう」と言い、そのとおりになったことを何度も見た。 最近すぐに「できません」という社員が増えているとの悩みを経営者の方々からお聞きする。無茶な要求をする 上司や顧客がいるのも事実だろうが、考えもしないで「できません」という

    「できません」と言わないソフトウェア技術者の話。
  • 日本Web技術界隈著名人の残念さ具合 - thinkchangの日々日誌

    追記:はてなおや氏を批判したことで、はてブでブラックリスト設定された模様 いくらブックマークされてもはてなおや氏を批判する記事はホッテントリに掲載されない仕様のようです。以下文 日のWeb技術者は結構な割合ではてなを見ていると思う そういう中で有名な人、について分析をしてみる 人気は勿論わかるんだけど、実績で見ていってみて、冷静に、どういう点で有名になって、今何が凄いのか?という点について考えてみる 伊藤直也氏 新卒でニフティ、はてな転職して、ブログ時代に知名度をあげる はてブを作って、はてブユーザにとっては神なのかもしれない。はてなCTO。 その後、グリーに転職し、スマホ事業部長。2015年の大赤字化したグリー。 経営の問題はあったのかもしれないが、明らかにスマホ事業の苦戦はスマホ事業の責任者であった、伊藤直也氏が作ったものだと言ってもおかしくはないと思う 「たいへんな所に来ちゃっ

    日本Web技術界隈著名人の残念さ具合 - thinkchangの日々日誌
  • あなたを次のレベルに押し上げる「集中的訓練」の方法

    ただ「できる」だけではない、多くの有能な人と最高レベルで競い合うことのできるスキルを磨くにはどうすればいいのでしょう? 一人の「天才」的な才能を生み出すのに必要な時間は、マルコム・グラッドウェルが Outliers で紹介したように、10000 時間と言われています。 しかしこれは必要条件であって、十分条件であるとは限りません。普通にチェスを 10000 時間実践していれば、たいていの選手よりは強くなれます。しかしあとになればなるほど時間あたりに得られる経験値は少なくなりますし、強くなればなるほど自分のレベルを高めてくれる相手を探すのが難しくなるので、グランドマスターになりたいのなら、さらに絞り込んだ訓練が必要になります。 ゲームでたとえるなら、「スライムばかり倒していてもレベルは上がらない」と言い換えられるでしょうか。 ただ秀でているというところから、当に「天才」というレベルにまで人を

    あなたを次のレベルに押し上げる「集中的訓練」の方法
  • 強面の社長が教えてくれた人たらしテク | コムテブログ

    地元の知り合いに人たらしのプロみたいな強面の社長さんがいた。風体はオールバックで髭を生やしがっちりしている。一見、一般人には見えない。 最近 SNS で見かけるような、インテリぶった貧弱そうな(男か女か分からないような)経営者ではない。背中に刃物を突き立てられても動じないような人で、事実開き直っていた。しかし何をやっても上手くいく強運な人だった。 最近連絡を取っていなかったが、その人に教えられた事を公開しようと思う。毒舌で失礼な文章なので気分を害しそうな人はスルーして下さい。 「飲み会不要」 付き合いが大切だと言う人間とは距離を置け。懇親会も出来るだけやんわりと断れ。人間関係は大切だが、賢い人間は皆が飲みに行く時間に不労所得を作る。 「成功者と失敗者の話しは聞くな」 すでに成功している人間や、うだつのあがらない人間の話はどうでも良い。それより頑張り屋さんに近づけ。実は頑張り屋さんに近づくと

    強面の社長が教えてくれた人たらしテク | コムテブログ
  • 一生プログラマであるということ | F's Garage

    Web系やシステム系のエンジニアは、一生プログラムを書いていたいのだろうか。僕自身は、こういう言説をどう捉えていいのかよくわからない。むしろこういう言説は少しネガティブだ。 僕自身のキャリアは、もともと機械製造業の電気制御の設計で、現場で物を作る立場から、設計へと移動した流れ。その会社では大卒入社組は製造での経験を経て、設計職に行くパスになっていた。いわゆるテレビ東京とかが好きな意味での「ものづくりの現場仕事」ではなく、設計を通じて「製造部門や調達部門に指示を出す役割」である。 もちろん電気制御なのでプログラムは書くが「プログラマー」ではなくて、あくまでも「技術者」という枠組みで捉えている。 ハードもソフトも全部やるってことだけど、全部を自分で作れるわけじゃなくあくまでチーム戦。如何に人にお願いし、いいものを作ってもらうかというのも技術者の仕事だと思っている。外注さんにもお願いするし、パー

    一生プログラマであるということ | F's Garage