50代のフルスタックエンジニア - nunulkのプログラミング徒然日記
はじめに この記事について 以下の記事を読んでわりと「うんうんわかるわかる」と思いながら読みましたが、50歳に至るまでの間にもうひとつ別の景色も見えてきていたので、そのあたりを一度言語化してみようという試みです。 note.com フルスタックとは 上記記事へのブコメには「フルスタック」と書きましたが、自分としてはあまりフルスタックと名乗りたくない、という気持ちはありまして、普段は「ウェブアプリケーションエンジニア」と自称しています。 ただ、今回は、元の記事に合わせるために本記事における「フルスタック」の定義を定めておきます。 以下の領域の技術を理解し使える インフラ アプリケーションが動作するサーバや協調するミドルウェア バックエンド サーバーサイドのアプリケーションに用いる言語やライブラリ フロントエンド クライアントサイドのアプリケーションに用いる言語やライブラリ すべてを理解してい
認知負荷とキャッチアップ - stefafafan の fa は3つです
以前会社で「Team Topologies読書会」に参加した際に、認知負荷には3つの種類があることを知りました。それ以降新しいメンバーのキャッチアップについて考える際に毎回この3つの種類について思いを馳せるようになっています。 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 作者:マシュー・スケルトン,マニュエル・パイス日本能率協会マネジメントセンターAmazon 心理学者ジョン・スウェラーが提示する三つの種類とは「課題内在性負荷」「課題外在性負荷」「学習関連負荷」です。Team Topologiesにも書いてあったようなことを元に軽く紹介します。 課題内在性負荷とはタスクに直接関連する負荷であり、プログラミング言語そのものの知識などを含むそうです。 課題外在性負荷とはそのタスクというよりは周りの環境に関連する負荷であり、覚えにくいコマンドの羅列だったりするそうです。
Webアプリケーションエンジニアとして1on1してもらう際に考えていること - stefafafan の fa は3つです
同僚が1on1の際に他の人がどういう話をしているのか気にされていたので、便乗してブログに書きます。 ということで人が1on1の時間に何を考えてどう使っているのか気になっている1on1で何を話すか考えてる - tomato3713’s blog 前提 株式会社はてなは新卒から所属しており、今年で9年目 現在チームでテックリードをしている。Webアプリケーションエンジニアとしてコードも日々書いている とはいえ自分もメンティーは持っていなくて、1on1してもらう側の1人 最近1on1に向けて考えていること 前提に書いてある通り、自分はこの会社では古参で普段の仕事の仕方だったり同僚とのやりとりやカルチャーについての大きな悩みや不安はないです。その代わり、テックリードや30歳になったエンジニアとしての悩みや考えはあります。ということで以下のようなことを考えています。 テックリード どのような振る舞い
仕事における感情の変化に1on1で向き合った話 - taxin's notes
勤労感謝の日なので (?) 仕事の話をします。 記事のタイトルにある通り、仕事と感情の変化についてSREのテックリード (TL) と1on1で会話する機会がありました。 最近は、エンジニアとして「気分良く」仕事ができるかということを考えています。もちろん仕事の締切を守るとか求められるアウトプットを出すように最大限勤めるとかは前提とした上でです。 仕事におけるモチベーションや行動力につながるのはもちろんですが、自分の傾向として「気分が良い」方が視野が広くなり興味関心や思考をチ－ム外・社外の物事まで向けやすくなるというのがあります。 私の所属するチ－ムでは2週間スプリントでスクラムを行っているのですが、あるスプリントで「気分良く」仕事ができていない状態になっていました。 タスクが想定より時間がかかってしまった タスク完了までに設けているチェックポイントに達するまでの時間もかかっていた 自分でコ
テックリードとして技術的施策をチームに提案する際に意識すべきポイント - stefafafan の fa は3つです
私はいま会社でテックリードをしていますが、いちエンジニアとして技術的改善をチームに提案するスキルに関してまだ課題感を持っています。その際同じくチームに所属しているエンジニアリングマネージャー（EM）の方にヘルプしていただき、実際に提案資料をペアライティングした中で湧いたイメージがあるのでブログとしてまとめて自分の考えを整理してみようと思います。 効果的なストーリーテリングのための既存のフレームワーク 技術的な提案をするには効果的なストーリーテリングをするスキルが必要だと考えています。私はストーリーテリングに関して詳しくありませんが、仕事を通じて以下の二つのフレームワークを知りましたので軽く紹介します。世の中には他にもいろいろあると思いますが、基本的な考え方は近いのかなと想像しています。 空・雨・傘 STARフレームワーク 空・雨・傘 EMの方と会話する中で「空・雨・傘」というフレーズを何度
趣味プログラミングのたのしみ - Hatena Developer Blog
こんにちは。CTOのid:motemenです。みなさん趣味プログラム書いてますか？ このエントリは Backyard Hatena #4 のフォローアップ記事です。エピソードの最後のほうで、「motemenが作って公開しているツール、どんなことを考えて作ってる？」という話になりました。そのときは時間の関係もあってあまりちゃんと話せなかったな、という感覚があったので、ここであらためて考えてみようと思います。 治具のようにつくる ウェブ上で読める自分が好きな記事のひとつに、Go Is a Shop-built Jig（抄訳）というものがあります。一言でいうと、「Goは現実的な問題を解くための治具である」ということをいっています。治具とは何かを達成することを補助する小さな目的のために作られた道具、という感じかな。fujiwaraさんの隙間家具のたとえからも近いニュアンスを感じます。 自分がツール
コラム53：迷惑はかけてもいい｜運営委員・相談員のコラム｜学習相談室｜東京大学大学院法学政治学研究科・法学部
コラム53：迷惑はかけてもいい 日本人ならたいてい子どものころから、親や学校の先生などから、「他人に迷惑をかけてはいけません」と言われて育ってきたのではないだろうか。そのため、「他人に迷惑をかけてはいけない」というのは、普遍的な道徳律だと思っている人も多いのではないかと思う。私も数年前までそう思っていた一人だった。しかし、どうやらこの教えはそれほど普遍的な規範とは言えないようだ。日本語教師をしている私の知人によれば、中国ではこのような規範を子どもに教える親はほとんどいない代わりに、「困っている人を助けなさい」と教える親が多いという。私の友人の韓国人によれば、韓国でも「他人に迷惑をかけるな」という人はいるものの、日本ほど多くはないという。むろん、日本でも「困っている人を助けなさい」と教える親もいるだろうが、「他人様に迷惑をかけてはいけない」と教える親に比べると、圧倒的に少数派だろう。 新約聖
フロントエンドエンジニアをやめました。 - まいはにっき
フロントエンドエンジニアとして働くのを2022年いっぱいで終わりにしました。今までフロントエンドエンジニアとしての私と関わってくださった方、元上司、元同僚、友人・知人の皆様、本当にありがとうございました。 コーダーから始めて、約7年間ウェブのクライアントサイドのコードを書く業務をしました。 2023年からは大好きなアクセシビリティに向き合う仕事をやります。夢のよう！ なぜやめたのか 寝る時間も惜しむほど熱中できることを仕事にするのがいいなと思ったからです。いわゆる現代のフロントエンドエンジニアに求められるスキルの向上に対して、それほどの情熱を持っていたかというとそうではなく。ずっと情熱的な人に囲まれて働いてきて、愛がある人には勝てんな。と痛感し、私も愛する分野で生きていかなければと思いました。 誰もが求めるものにたどりつけるインターネットであってほしい 私を突き動かすのは「ウェブで快適を手
自分を必要以上に過小評価することは、あなたを認めてくれている人にとっても失礼だよって話 - そーだいなるらくがき帳
クライアント先の社内ポエムだけど必要になることがあったので転記した。 @nekoya さんにお願いしたらそちらも公開してくれた。:圧倒的感謝: @nekoya さんの話がとても良かったので僕もポエムを書いてみる。 zenn.dev 僕もその昔はもちろん駆け出しのエンジニアで自信が無くて自分を低く見積もったり、ある程度自信があっても 謙虚であることが美徳 と思って自分を敢えて卑下するなんてことをよくやっていた。 脳ある鷹は爪を隠す、なんていうけど確かに周囲に低能力だと思われていたほうが便利なシーンもあるにはある。 しかし少なくとも社会で働く上で 自分の能力を適切に評価する ことは自分にとっても会社にとっても重要なことだ。 その前提の上で、自分を過小に評価することは、あなたの仕事の成果に対して高評価し、認めてくれている人たちにとっては裏切り行為と言える。 例えばとても良い仕事をしたのにも関わら
低すぎる自己評価は実際の評価も下げてしまうという話
自己評価が高すぎると困るのは想像がつきやすいと思いますが、一方で低すぎるのも困りものです。むしろ、そっちの方がより深刻な問題を引き起こしやすかったりします。 自己評価が過度に低い状態というのは、謙虚さではなく自己否定につながる場合がままあります。 それはやがて自分の携わる仕事やチームに対する否定に発展していきます。これが本当に良くない。本人のみならず周りにも悪影響を与えるので、仕事によるプラスのアウトプットを打ち消すマイナスのアウトプットを生み出してしまう。 仕事をすると同時にそれを削る方向の動きもしてしまうので、成果を上げても十分な評価ができなくなってしまいます。そして、また下がる自己評価という負の循環が完成する。 そこまで極端でなかったとしても、自己評価が低い人がシニアエンジニアとかリーダーみたいなポジションについてしまうと、それもまた不幸を招きがちです。 「自分に厳しい」と言えば聞こ
チームでのソフトウェア開発で100点を目指すための簡単な近道は存在しない - stefafafan の fa は3つです
ソフトウェア開発に限らないと思うけど、結局「人間」も「チーム」も「プロダクト」も性質は十人十色なので「これさえパクれば開発速度10倍！利益10倍！顧客満足度1000%！」というものはありません、という前提がある気がする。 大学でCSの学位を取ったとしても、本を沢山読んだとしても、資格をとったとしても、この次働くチームで全てが最高に上手く回るとは限らない。以前いたチームでのプラクティスが全てそのまま当てはまるわけではない。じゃあなんで世の中で流行っているフレームワークやプラクティスがあるかというとそれはあくまで70点、80点を取りたいときに適しているというだけであって、100点を取るには正解は自分たちで見つけないといけないということ。 「人間」は様々な性格があるし、モチベーションの有無とか、スキルの有無とか、経験の有無とか、いろいろある。なので仮に自分に後輩ができたときに「こうすれば100%
おっぱいのブログ 第1章「おっぱいと私」 - 原田ひとみの語り場
いつか、このテーマをしっかり書きたいと思っていました。 大きな胸は果たして本当に得なのか、どういった事を経験し、どんな事があったのか。大きな胸の方にも、そうじゃない方にも、男性にも女性にも、色んな角度から深く知って頂きたいと思ったのです。 第1章…おっぱいと私 お人形さん遊び（意味深） 実は男疑惑が自分の中で急浮上 オタク街道とおっぱい 温泉施設での私 その心、修行僧の如し 声優としておっぱいキャラへ この記事のさいごに 第1章…おっぱいと私 物心ついた頃には、既におっぱいが大好きでした。 一番古い記憶は、枕カバーのおっぱい。真っ先にアニメの女の子２人、大きなおっぱいがどーんとプリントされたものを選び、寝る時はおっぱいに埋もれて寝ている感覚で悦に浸っていました。今考えると変な女の子ですが、その頃は周囲に悟られてはいなかったと思います。女の子が女性キャラクターグッズに没頭するのは当然の事です
プログラミングに必要なブレイクスルー
Yoyo Code (Matyáš Racek's blog)より。 ソフトウェアの開発方法を劇的に変えるには、いくつかのブレイクスルーが必要だと感じています。ブレイクスルーといった場合、それは大きなブレイクスルーを意味します。例えば、「構造化プログラミング」のブレイクスルーのようなもので、プログラミングに対する私たちの考え方を完全に変えてしまうようなものです。ここでは、それに関するいくつかの見解とアイデアを紹介します。 グルーコードや定型文を書くのは無駄だ 私が書くコードのほとんどは、面白いことはするわけではなく、定型文か、サブシステム同士を繋ぐための糊のようなものです。この種のコードは、すでに何度も書かれていて、これからも何度も書かれるような気がします。それなのに、なぜまた書かなければならないのでしょうか? 問題は、コードがかなり異なっていることで、通常は既存のコードをそのまま使うこと
エンジニアはもっと図を書こう - 生涯未熟
たまには軽い話題をば。 自分の中で信頼できるエンジニアかどうか？を見極めるひとつの指標で「込み入った議論の時に図を書くかどうか」というのがあります。 今までの経験上、図を書く派のエンジニアは割と良い感じの人が多かったので採用している指標なのですが、何故これが機能しているかというのを改めて考えてみた。 他者の認知負荷を理解している コンテクストを合わせることにコストをかけられる意識がある 自分の思考の整理するツールとして図を扱えている ザッと挙げましたが、この３つが機能している要因なのかなという気がしています. 他者の認知負荷を理解している あれやこれやエンジニア間で技術議論している中で、「Aさんはこの領域に詳しいけどBさんはこの領域にはほどほど詳しいくらいだな」という個々のレベル差に応じて認知の負荷がかかります。ただでさえ議論していると結構なスピードで話が展開されていくので、認知負荷が更に
課題にとにかく向き合い続けるのが良いのだろうと思っている - 下林明正のブログ
最近、様々な面で課題にとにかく向き合い続けるのが良いのだろうと明に思っている。 問題 vs 私たち - shimobayashiパブリックなどと一般的によく言われている 組織変革系の本をいくつか読んでみたけど組織変革の進め方 - shimobayashiパブリックに書いた通り結局課題に向き合うしかなさそうだった 開発プロセスの変遷モデル - shimobayashiパブリックも結局目の前の問題に向き合い続けることでしか状況は変わっていかないのだろうという考え 感情的な面でも、自分は割りと傷つきやすい性格だけど自分と課題を切り離すことでダメージコントロールできるのでは、と思う だいくしー on Twitter: "結局問題を解決しないといけないのはその人自身なので、感情や事情をこちらが受け止める必要はないですよね。もちろん傾聴はします。そして問題解決に構造的な手助けが必要ならそれはマネージメ
他人がやっていない事こそ強みになる。テキストエディタに人生を全振りしたエンジニアのキャリア戦略とは - Findy Engineer Lab
はじめまして。Shougo(@ShougoMatsu) という者です。私は現在、日中ソフトウェアエンジニアとして働く傍ら、GitHub Sponsorsで支援を頂いてテキストエディタ（Vim、neovim）本体を改善する活動やテキストエディタプラグイン開発を行っています。 今回「自分自身のキャリアを振り返り、スキルを向上させるために取り組んできたこと」について解説してほしいという依頼がありました。自分がプラグイン開発を始めてから、もう15年という長い月日が経っていて、世間ではテキストエディタの大ベテランと思われているようです。もうそこまで来てしまったのかと思うと同時に、時間さえかければ誰でもここに到達できると私は考えています。 私をはじめ誰しも最初は初心者です。右も左も分からない状態から始まるのです。私の経験が「自分はこれからどうすればよいのか分からない」「何か強みを持ちたい」と思っている
テックリードとしてシステムの未来を示して品質の期待を合わせる - yigarashiのブログ
最近チームのテックリードを拝命して、テクノロジーマネジメント領域もリードすることになりました。興味の中心は開発プロセスやデリバリーで、エンジニアリングはまだまだひよっこなので苦労の日々が続いています。この記事では新米テックリードとしての取り組みをひとつ紹介します。 私のチームでは10個近いコンポーネントのオーナーシップを持っています。それらの品質の期待度は大きく異なり、変更頻度、採用技術、システムに占める重要度といったパラメータから決定されます。この期待を見誤ると、変更頻度が極めて低いコンポーネントを頑張ってリファクタリングしたり、モダンな技術が採用され寿命の長いシステムを雑に拡張したりと、成果の小さいアクションを取ってしまいます。逆にこの期待を適切に捉えられると、チームのリソースがコスパが高いアクションに向かっていくことが期待できます。変更頻度の高いコンポーネントのCI/CDを改善し、重
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
やる気の出るアドバイス
お客さんに説明できるの？ 【仕事の姿勢】
人はなぜ大きなグループを作って、それに入らない人をいじめるの？｜読むらじる。｜NHKラジオ らじる★らじる
