当社の規定により満60歳で定年退職をした。長いようで短かった会社員生活も一区切りだ。自分のプログラマとしての会社員生活を振り返ってみる。無駄に長いし結論はないのでお忙しい人は飛ばして欲しい。 9月末なのでブログ界隈では退職エントリーがそこかしこに書かれると思うが、その中で自分の退職エントリーを連ねることにどれほどの意味があろうか。もちろんないのだが、それでも多くの書き手の年齢を考えると満60歳定年退職というところに若干の希少価値を見出せなくもない。 1984年に大学院修了して以来、プログラマとしてのキャリアを重ねてきた。大学時代の同期でプログラマとして就職したものは皆無だ。当時、工学部の同期はメーカーに就職するのがほとんどで、大手家電メーカー、自動車メーカー、電力会社などなど、当時の誰でも名前を知っている人気企業に就職するものが大半だった。 その中で、日本ディジタルイクイップメント（DEC

前口上 アメリカで就職できなかった。華々しい成功譚は見かけるが、夢と散った話はあまり表に出てこない。 なんというか「三振したバッターが相手ピッチャーのことを語る」みたいでまるっきり時間の無駄かもしれないが、もしかしたら参考になる人もいるかも知れないし、実際に就職した人に「お前のアプローチはまったく的外れだ」と言われるかも知れない。僕も何が悪かったのか教えてもらいたい気持ちもあるし、迷ったがこのエントリを公開する。 ちなみにめっっっっちゃ長いので、要点だけ知りたい人は、アメリカで就職するにはとにかく 就労ビザ＞技術力＞学歴＞＞＞＞＞＞＞＞＞＞＞＞（越えられない壁）＞英語力 だというのだけお伝えできればと思う。 アメリカで働くために英語を頑張るぐらいなら、それより大学（院）に入り直してコンピュータサイエンスの学位をとり*1、同時に技術力を磨くほうがよほど近道だと感じた。 それから、現職の同僚は

お勧めの記事がありましたらコメントなどで教えて頂けると幸いです。 Guidelines プログラマが知るべき97のこと 技術的負債 不慣れなコードベースで短期間に生産性を高めるための7つの方法 何も知らない人を育てるために(新人教育情報キュレーション) 保守開発に開発者として入って困ることのまとめ(実体験) 技術系の名言まとめ++ 真似をする前にバッドプラクティスかどうかを調べてみよう 読まれない名著「人月の神話」を本気で読み込んでみた（まとめ） 技術的負債とどうやって戦うか Coding Style モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう 関数名や変数名に使えそうな動詞・名詞・形容詞のメモ Naming -名前付け- DRY原則をもう一度 -コンカレント・エンジニアリング- レガシーコードのメンテナンス担当になったら新人はどうすればいい クソコードに対する怒りとコー

GitHub上の実際のコミットメッセージやIssueのやりとりをみて、チートシート作りました。 共通的なこと コミットメッセージやIssueのタイトルは、主語省略し、1文で書き行末ピリオドは付けない 動詞は現在形・過去形のどちらも同じくらいの頻度で見られるが、どちらかに揃える。 コミットメッセージを書く Japanese English

- はじめに - 本日9/30を持ってSansan株式会社を退職しました。 来週月曜日から別の会社で働くことになりました。 疾風怒濤の結婚エントリからの転職エントリです。 - Sansanの思い出 - 今まで転職エントリを見てよく「転職するのに昔話する必要ないやろ先を見ろや」と思っていましたが、書きたくなる不思議な気持ちに今包まれています。 端的に書きますが、Sansanでは新卒エンジニアとしてR&Dをやっていました。 専門である機械学習関係のプロジェクトに色々足を突っ込んでいました。 Python、Rの力はもちろん向上しましたが、C#やC++、Go、GAS辺りがﾁｮｯﾄﾃﾞｷﾙようになり、AWSの各サービスがある程度触れるようになりました。 加えて学会や勉強会への登壇、インターンの受け入れなども経験しました。 これとか vaaaaaanquish.hatenablog.com Sansa

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

機械学習とif文が地続きであることを解説しました。 ver.2 質問への回答を追加し、顧客価値の小問に図を追加してわかりやすくかみ砕きました。Read less

もう見た？GitHub最新人気リポジトリTop25総覧【2017年9月版】 GitHubで直近1年に作成されたリポジトリの中から、スター数が多いリポジトリ上位25個を収集！読み物からソースコードまで、皆さんの開発に役立つ要素満載です！ 世界中の開発トレンドはGitHubにあり。 今回は直近1年に作成されたリポジトリの中から、スター数が多いリポジトリ上位25個を収集し、ジャンル別に整理しました。また、より内容を把握しやすくするため、各リポジトリの概要も記載しています。 上位にはソースコードだけでなく、開発に役立つ読み物系のリポジトリも多数。ぜひ参考にして、あなたの開発をブラッシュアップしてください。 読み物 Roadmap to becoming a web developer in 2017 Best websites a programmer should visit The Syste

マネジメント 新しいチームのあり方を探求 就活 就活生必見！サイボウズの疑問 ティール組織 会社の「あたりまえ」が変わる 多様性 100人100通りの個性 ワークスタイル 働き方、生き方、もっと自由に 青野慶久 サイボウズ社長の想いと覚悟 キャリア 人生の「積み上げ方」を見直す 複業 複数の「本業」をもつ働き方 人事制度 多様な働き方を支える仕組み マンガ サクッと手軽に読める！

【まつもとゆきひろ氏 特別講演】若手エンジニアの生存戦略 - connpassに参加してきました。若手エンジニアないしはエンジニアを目指す学生向けに、生存戦略を説く主旨の講演でした。まつもとゆきひろ氏とは、プログラミング言語・Rubyを作った人です。 全体的な内容はこちらのブログで非常にコンパクトに紹介されているのでご参照ください。 zuckey17.hatenablog.com 私のブログではまつもとゆきひろ氏もといMatz氏が語ったことを前半に紹介しつつ、後半に主観感想もまとめたいと思います。 ■生き残るには？ -死ななければいい。 「エンジニアの生存戦略、つまり生き残るには？」 その問いに「単純ながら、死ななければいい。」という皮切りでスタートした。 じゃあこの"死なない"ためにはどうするか。 そもそも生き残るとはどのような戦略を取ればいいのか？ Matz氏は「背景や環境など当然違う

日本では「プログラマー35歳(40歳)定年説」が存在しますが、アメリカでも同じように、いつまでも「イチ開発者」として生涯を過ごすのは困難と見なされています。40歳を超えたプログラマーはやがて「管理職」になることを促されるのですが、マネージャーになることを拒否して「生涯現役開発者」を貫いている40代～60代のソフトウェア開発者にインタビューが行われています。 Software Developers After 40, 50 and 60 Who Hate Being A Manager https://belitsoft.com/php-development-services/top-software-developers-after-40-50-and-60#2 ◆45歳でシニア・ソフトウェアエンジニアのロブ・フレッッチャーさん 得意分野：ウェブ開発、テスト駆動開発、アジャイルソフトウェ

2017 - 04 - 21 株式会社ラブグラフを退職しました 4月21日を以て株式会社ラブグラフを退職した．最後のわがままで，今まで使ったことのない有給休暇を消化させてもらえることになったので，5月半ばまでは在籍することになっているが，ともかく今日が最終出社日だった．2015年3月頃から手伝っていたので，およそ2年に渡って関わり続けてきたことになる．長い間，様々な人たちから「やめろやめろ」と言われていながら，ようやく退職を決意することにしたわけであるが，以下に主たる理由を3つ挙げる． 第一に，今の組織に留まり続けても，今後自分にとって成長がないだろうと感じた． 初めの頃は，メンバーもごく少なかったこともあり，自分でサービスを作っているという実感があったが，ビジネスサイドの人間が増え，力を持つようになると，単に彼らの注文をこなすだけの作業が格段に増えた．「社内外注」とは言い得て妙なり，他人

表題の通り、数年勤めたソニー株式会社を退職しました。 個別具体の退職理由はいろいろあってそれらは後述しますが、退職を決めた基本的な理由は、個人的なキャリアパスの設計と会社の方針のミスマッチ、労働観のミスマッチ、技術投資の考え方のミスマッチの三点に集約できると思っています。 キャリアパスの設計と会社の方針のミスマッチ私はソニーでソフトウェアエンジニアとして働いていました。 ソフトウェアエンジニア(を目指す人間)にとってソニーと言えば、"自由闊達な理想工場"、エンジニアが自由に活躍できる会社、日本のメーカーなのにソフトウェアもちゃんとつくれる会社、などのイメージがあるかと思います。私もそう思っていました。 実際会社は説明会などでそういった説明をしましたし、そういったイメージを前提に私はソニーを選び、「エンジニアとしてプロフェッショナルになる。品質が高く、お客の求める体験を作り出せる人間になる」

以前 ゴールを決め目標を決める・解決案ではなく質問する - コーチングの学習で学んだこと - $shibayu36->blog; で、「ゴールを決め、現在位置とのギャップを考え、目標を決める」と良いということをまとめた。イメージとしては以下の図の通り。 しかし、前回の記事だと具体的にどのようにエンジニアの目標設定を行うかイメージが湧かない。そこで、もう少し具体的に最近どのようにやっていたかを書いてみたいと思う。 僕がメンティーと目標設定を行うときは、以下のフローを辿っている。 なんでも良いのでゴールのイメージを明確にする 現在の自分とゴールのイメージのギャップを考える ギャップを埋める目標を考え、アクションを定める ちなみに今回は、チームの成果達成のために個人の目標を決めるのではなく、エンジニアのスキル向上の目標を立てるという前提で書いていく。 なんでも良いのでゴールのイメージを明確にする