プログラミングを始めたころとは考え方が全然変わっていることに気づいてびっくりした話 - 覚書
家にパソコンがはじめて来てから30年くらい、プログラミングを始めてから20年以上が経ちました。その間、IT技術に対する愛は変わらずに、ずっと走り続けてきました。では当時の自分と今の自分で何が違うのだろうと考えてみたところ、めちゃくちゃ変わっていたのでびっくりました。本記事では何がどう変わったのか、それを見てなにを思ったかなどを書きます。 昔は次のようなこだわりがありました。 大きなものは一つの仕事をする単純で小さなツールを組み合わせて作るべし ソフトウェアは可能な限り設定可能になっていてほしいし、それを自分の好みになるまでカリカリチューニングしたい 可能な限りすべてキーボードだけで操作できるようになっていてほしい いわゆるUNIX哲学をはじめとして、いろんな本やWebサイトなどに強い影響を受けていることがよくわかります。 ところが今は次のように全然違うことを考えています。 トラブルハマった
誤りを認める練習 - 覚書
明らかに誤ったことをしたのにそれを認められずに醜態をさらしている、場合によっては傷口を広げて自分を窮地に追い込んでいる人を大量に見てきた結果、「こうはなりたくないな」と思う気持ちがずっとありました。にもかかわらず、数年前に見事に過ちを認められずに、謝罪できずに無様な姿をさらしたことがありました。公の場でやったことではないし、もしかすると謝罪されるべきだった相手は気にしていなかったかもしれませんが、自分から見れば間違いなく無様でした。 こういうことがあって以来、誤りを認める練習をするようになりました。練習といっても、壁に向かって謝罪し続けるというような話ではなく、自分の言ったこと、書いたことが間違っていたとわかったら、何もしなくてもその場はやりすごせそうな小さなことでも即座に「これは誤っていた」と表明するということをやっています。小さな誤りを認められなければ、大きな過ちを犯したときにも認めら
「なぜ誰もやらない」と言うな、あなたもその一人だ - 西尾泰和のScrapbox
なぜ誰もやらないんだと嘆くより、まずは自分がその"誰もやらないうちの一人"であることを認めよう p.91
承認欲求モンスター、それは短所か長所か - シロクマの屑籠
ぼっち・ざ・ろっく！ ちょこのせ プレミアムフィギュア 後藤ひとり セガAmazon 昨日の『ぼっち・ざ・ろっく』の感想の続き。というか正月に書き損ねた話でもあったので書いてしまおう。 「承認欲求モンスター」についての話だ。 昨日の感想文のなかで 『ぼっちざろっく』は、確かに脱臭されまくったロックバンド女子アニメではある。ぼっちちゃんが本当は美少女であるのもずるいことだ。 と書いたところ、はてなブックマーク上で 脱臭された聖域でも、ぼっちちゃんの輝く世界は美しかった──『ぼっち・ざ・ろっく』感想 - シロクマの屑籠[ぼっち・ざ・ろっく！] 最も現実的(not都合の良い世界)なのがぼっちちゃんが中学時代に異常な練習量を積み上げていること(容姿なんかよりそれが才能)で、むしろそれが活躍の大前提なのは残酷だなとは思う(リョウ、虹夏も中学からの経験者)。2023/01/07 08:38 b.hat
ロードマップ指向とエコシステム指向 - アンカテ
IT業界の世代間ギャップを「ロードマップ指向 VS エコシステム指向」という図式でまとめるとうまく整理できるような気がしてきた。 他の業界でも、常に勉強してないと仕事にならない所では、似たような問題があるかもしれない。普通の人は「ロードマップ」の中では真ん中を進むべきで、「エコシステム」の中では真ん中を避けるべきだ、という話。 私は、80年代からずっとプログラマをしていて、今でも現場でコードを書く仕事をしているので、同世代の人から、彼らと現場の若い人との仲裁役というか通訳のようなことを期待されることが多い。 確かにそこには微妙なギャップがあって、自分はどちらの言い分にも共感する所があるので、なんとかそれを言葉にしたいのだが、なかなかうまく言えなかった。 プログラマという仕事は、今も昔も勉強をしてないと普通の仕事も成立しないのだが、その勉強の仕方というか意味づけが、違ってきていると思うのだ。
作者冥利に尽きる - ゆーすけべー日記
会社の朝会で話す番が回ってくる。 メンバーが入れ違いで自己紹介をするんだけど、 それに加えて「自分なりのこだわり」みたいなことを話す流れになっている。 自分の場合、つくってきたもの紹介とそれから学んだこと、みたいなのはどうだろうか。 結局こういうキーワードが出た。 作者冥利に尽きる。 今まで原動力になっていたのは、 プロダクトを使ってもらって嬉しい反応をもらうことだ。 なので「もしよろしければ、みなさんも（一緒に、じゃなくてもいいけど）作者冥利に尽きる体験をしましょう」 という流れにしようかと。上からだけど、まぁありでしょう。 で、作者冥利に尽きるにはどうすればいいか。メモを残す。 つくってきたもの いわゆる「個人開発」というものをやってきた。 特にWebサービスをたくさんつくってきた。数えたらエロ含めて70個、除いて48個だった。 以下のスライドで全部網羅してある。 僕がつくった 70個
自分を必要以上に過小評価することは、あなたを認めてくれている人にとっても失礼だよって話 - そーだいなるらくがき帳
クライアント先の社内ポエムだけど必要になることがあったので転記した。 @nekoya さんにお願いしたらそちらも公開してくれた。:圧倒的感謝: @nekoya さんの話がとても良かったので僕もポエムを書いてみる。 zenn.dev 僕もその昔はもちろん駆け出しのエンジニアで自信が無くて自分を低く見積もったり、ある程度自信があっても 謙虚であることが美徳 と思って自分を敢えて卑下するなんてことをよくやっていた。 脳ある鷹は爪を隠す、なんていうけど確かに周囲に低能力だと思われていたほうが便利なシーンもあるにはある。 しかし少なくとも社会で働く上で 自分の能力を適切に評価する ことは自分にとっても会社にとっても重要なことだ。 その前提の上で、自分を過小に評価することは、あなたの仕事の成果に対して高評価し、認めてくれている人たちにとっては裏切り行為と言える。 例えばとても良い仕事をしたのにも関わら
プログラミングに必要なブレイクスルー
Yoyo Code (Matyáš Racek's blog)より。 ソフトウェアの開発方法を劇的に変えるには、いくつかのブレイクスルーが必要だと感じています。ブレイクスルーといった場合、それは大きなブレイクスルーを意味します。例えば、「構造化プログラミング」のブレイクスルーのようなもので、プログラミングに対する私たちの考え方を完全に変えてしまうようなものです。ここでは、それに関するいくつかの見解とアイデアを紹介します。 グルーコードや定型文を書くのは無駄だ 私が書くコードのほとんどは、面白いことはするわけではなく、定型文か、サブシステム同士を繋ぐための糊のようなものです。この種のコードは、すでに何度も書かれていて、これからも何度も書かれるような気がします。それなのに、なぜまた書かなければならないのでしょうか? 問題は、コードがかなり異なっていることで、通常は既存のコードをそのまま使うこと
私がデザインエンジニアになるまでのキャリア | Offers Magazine
フロントエンドエンジニアへの転身 これでは良くないと思い、転職を期に私はWebデザイナーからフロントエンドエンジニアにジョブチェンジをしました。もともとコードを書くほうが好きだったので、それに専念したかったという面もあります。 時はHTML5隆盛の時期で、AndroidやiOSなどのネイティブアプリケーションのような振る舞いをHTML5製のWebアプリケーションでも求められるようになりました。ただ処理能力に乏しい端末、低速なモバイル回線など制限が多いのも事実でした。 フロントエンドエンジニアとして感じる限界 リッチなアプリケーションを求められるようになったのはユーザーインターフェイスもそうでした。グラデーションやシャドウを多用したUI、現実世界のオブジェクトに似せたキューモーフィックデザインはCSSだけで当然表現できるものではなく、画像ファイルを多用しなければならない実装だったのです。 フ
生産的になろう（Aaron Swartz のブログから）
Aaron Swartz さんのエッセイ、“HOWTO: Be more productive” の日本語訳です。Aaron くんは、ティーンエージャーにして W3C のコア・ワーキング・グループのメンバーで、RSS 1.0 仕様書の共同執筆者のひとりとしても知られる、才気煥発のスーパーハッカーさんです。どうしたらより生産的な人生を送れるのかについて考察したこのエッセイは、2005年の末に彼のブログに掲載されたもので、多くの注目を集めました。プログラミングに限らず、クリエイティブな仕事をこころざすすべての人にとって有用と思い（日本語訳もまだ出てないみたいなので）、翻訳してみることにしました。「この翻訳について」で案内しているフォームから、ご意見・ご感想などもお寄せください。 「君がテレビを見てた時間をぜんぶ合わせれば、」そいつは言った「いまごろ長編小説の一本も書けてたはずだ」。これにはたし
問題の切り分け - ちなみに
同僚が困っていそうだったので無意識にやっている問題の切り分けを言語化してみる。 「分かっていること」と「分かっていないこと」をリスト化する (頭の中でやっています) 分かっていないことの中で優先度をつける 簡単に試せて効果が高そうなものの優先度が高い 知識がないものも優先度が高い 試せそうなものについて仮説を立てる 仮説を検証する 試せそうなものは片っ端から試して「分かっていること」を増やす 知識がないことについて調べる 3に戻る それでもどうしようもなく分からない場合はあきらめて寝る。 その問題についてのアンテナが出来るのでそのうち解決のきっかけがみつかるはず。
エンジニアはもっと図を書こう - 生涯未熟
たまには軽い話題をば。 自分の中で信頼できるエンジニアかどうか？を見極めるひとつの指標で「込み入った議論の時に図を書くかどうか」というのがあります。 今までの経験上、図を書く派のエンジニアは割と良い感じの人が多かったので採用している指標なのですが、何故これが機能しているかというのを改めて考えてみた。 他者の認知負荷を理解している コンテクストを合わせることにコストをかけられる意識がある 自分の思考の整理するツールとして図を扱えている ザッと挙げましたが、この３つが機能している要因なのかなという気がしています. 他者の認知負荷を理解している あれやこれやエンジニア間で技術議論している中で、「Aさんはこの領域に詳しいけどBさんはこの領域にはほどほど詳しいくらいだな」という個々のレベル差に応じて認知の負荷がかかります。ただでさえ議論していると結構なスピードで話が展開されていくので、認知負荷が更に
手法にアイデンティティを見出すと呪われる - 下林明正のブログ
「ハンマーを持つ人にはすべてが釘に見える」的な話 「自分は[任意の手法]の人」という自負を持つと、そうなりやすそう [任意の手法]には例えば、スクラムとか、DDDとか、Reactとか、なんか適当な単語を入れる こういうのを僕は呪いだとなんとなく思っている [任意のネガティブな要素]でアイデンティティを得ると、そのネガティブな要素から逃げられなくなるみたいなのも近いと思っている 例えば毒舌キャラみたいな感じで確立してしまうと、毒舌をやめるにやめられなくなってなかなか幸せになれない的な とはいえアイデンティティはあったほうがキャリアとか築きやすそうな気がする おそらく「自分は[任意の課題]の人」という自負の持ち方の方が安全なんだろうな、と思った 例えば、不確実性への対処とか、ソフトウェア設計とか、ユーザー体験とか、なんかそういう感じで。知らんけど こっちのほうが賞味期限長そうな感じがするし、な
自分でやるべき（ように思える）ことを得意な誰かに任せるという考え方 - knqyf263's blog
完全なるポエムです。自分にとって斬新な考え方だったので思わず勢いで書いていますが、知っている人からすると当たり前ですし、冷静に読み返すとだから何だよという内容に仕上がっています。読んだあとにだから何だよと言われても責任は取れません。 はじめに とある方の話 他人に任せる 記事執筆 社外発表 社内発表 マネージメント まとめ はじめに 以前、苦手分野を思い切って捨てて得意分野に集中してみるという話を書かせていただきました。 engineer-lab.findy-code.io 今回も通ずるところはあるのですが、一歩踏み込んで自分の気の進まないことはいっそ得意な誰かに任せようという話です。一歩引いた視点で見れば上のブログの話も結局誰かが自分の穴を埋めてくれているので同じに見えると思うのですが、自分の気の持ちようとしては大きく異なるので書いています。つまり、これ苦手だけど一生懸命やってるので許し
プログラミングというより物事が出来るようになる思考法｜牛尾 剛
私が人生でずっと悩んで追い求めていたものがついに解決した。それは、なんでも良いから何かが「出来るようになる」ことだ。 昔からいくらその対象に時間をかけても、努力しても、人並みにすらならない。人にやってもらうとか自分がやらないことに関してはうまくいくのだが、自分が何かが出来るようになるということに関しては人生５０年目だが、絶望的で、それが自分の自己肯定感や、人並みに生きることへの罪悪感を生んでいた。人生で解決したかった問題 No.1 だ。だからそれをずっと解決しようと頑張ってきた。 ギター演奏での解決方法私はクソ不器用で、なにやってもできないので、人生で出来たらいいことを２つだけ定めた。ギター演奏と、プログラミング。ギター演奏に関しては少し前に解決した。根本的な問題を一つ上げるとすると、「ゆっくりから、メトロノームで練習する」これだけだ。 ギターはもう何十年も演奏しているのに弾ける感がなかっ
しいたけ on Twitter: "「コードだけ書いていたい」という気持ちは非常によくわかるんですが、その状況を作るためには周囲の多大なサポートが必要で、その労力に見合う価値をコード書くだけで提供できるかはよく考えたほうがいいです"
「コードだけ書いていたい」という気持ちは非常によくわかるんですが、その状況を作るためには周囲の多大なサポートが必要で、その労力に見合う価値をコード書くだけで提供できるかはよく考えたほうがいいです
肌着の色で持ち点減点…体育祭前から生徒間で“監視” | 西日本新聞me
大分県の公立中の男子生徒から「体育祭の得点の算出法がおかしい」という意見が届いた。競技だけでなく、日頃の肌着の色まで影響するのだという。競技結果と服装や生活態度は関係ないはずだが、なぜ結び付けられているのか。新型コロナウイルスの影響で開催に制限が出ているものの、5月は春の運動会シーズン。西日本新聞「あなたの特命取材班」が調べた。...
優秀さについて
Twitter で医師を拾ってきて Google のソフトウェアエンジニアにするだけの簡単なお仕事 - 白のカピバラの逆極限 S.144-3 はじめに 「【転職エントリ】Googleに入社します｜Lillian｜note」という、医師から未経験で Google のソフトウェアエンジニアになった記事があります。 note.com 私は、この記事に出てくる「とある元 Google のソフトウェアエンジニア」で、面接の対策を立てました。 記事が出た当初から大反響で、私もそれなりの反応を見まして、いろいろと誤解されているなあ、と思う一方、アドバイザーはあくまでもアドバイザーだから、アドバイザーとして知りえた情報については、口をつぐむべきだと思っていました。 ただ、あまりにも誤解されており、悪影響が大きく、犠牲者も多くなってきたと思ったので、… 同僚からこれについてどう思うか、と聞かれた。元の文章が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「時間がない」症候群、その傾向と対策
属人性 - 西尾泰和のScrapbox
