@__timakin__です。エンジニアとかのジョブチェンジの話です。 書類選考におけるミスマッチ要因エンジニアの書類選考において、ミスマッチという結論を出すに至る要因はいくつかありますね。 文章から滲み出る性格、在籍してきた企業の文化が弊社と合わなそう、職歴があまりに短期に途切れている、などなど。。。 どれも判断に迷うのですが、個人的に一番迷うのはスキルのミスマッチによってNGと結論づけることです。 個人的にはスキルミスマッチは若手なら許容可能で、年次が上がってくるにつれ非常に厳しくなるという認識です。 加えて、たとえ若手でもミスマッチを生まないようにプライベートで何をやっているか、などなんらかの実績が必要となる、という感じです。 どれくらいだと「ミスマッチ」なのかそもそもミスマッチと書くのはあんまり好きではなくて、今までの経歴を棄損する印象があるからです。 例えば自分は、前職C++でゲ

tl;dr勉強会で寿司とピザ出すの極力やめませんか 餌としての寿司とピザ先日雑にこのようなことを呟いた。 これは、某社のエンジニア求人イベントの広告だったのだけれど、見た瞬間は餌で釣ろうとしてるような魂胆が透けて見え、それに対する嫌悪感を抱いた。 だけどその直後、「まあそうはいってもエンジニアの勉強会って寿司かピザしか頼まないし、それさえあれば人が集まると思われてもしょうがないくらいにワンパターン化してる主催側も悪いよな」と思ったりした。 念の為書いておくけど、自分が勉強会の担当になった時、ピザはサルバトーレクオモのうまいやつを少なめで注文したりして、結局ピザを注文してて、完全にブーメランである。とにかくピザに罪はない。 勉強会テロリスト寿司とピザが毎回出るとわかってると、テロリストみたいなやつがくる。 ・懇親会の直前だけきて台風みたいに寿司をかっさらって行くやつ ・寿司のネタだけ食ってシ

皆様、ChatGPTでCode Interpreterの機能がリリースされましたがお使いになりましたか？ 僕は大変有りがたーく日常使いさせて頂いており、活用方法について各方面のご意見を伺いたいですが、その話はさておき… こうした劇的な開発体験の変化が予感されると、度々繰り返される議題の１つが「エンジニアやコードの不要論」かと思います。 私自身がローコードツールを提供している会社の経営者なのですが（ヒューマンエラーを減らせる管理画面構築SaaS「ベースマキナ」をよろしくお願いします！）、この類の議論の盛り上がりと日頃情報を追っている最新のツール群との間を照らすと、ギャップを感じます。 端的に言うと、少なくともここ１年くらいで新しく登場するデベロッパー向けのツールを見ていると、コードが不要になる場面が増えると思いきや、逆にコードをしっかり書くツールが増えてきたな、という印象を持っています。 D

つまり・組織で情報の不透明性が問題になる時、必ずしもその不透明性は悪意や信頼性の無さから生まれるわけじゃなく、よかれと思ってやった結果生まれるかも知れない ・フルオープンにできなくても、情報の確定度合は可能な限りオープンにすべき 1on1で明らかになった不透明性この間1on1をチームメンバーとやっている時、情報の不透明性が問題になった。具体的にいうと、仕様議論が途中の機能について、「あの機能はいつから開発開始なんだろう」「開発スコープは？」という、疑問の声が上がっていた。 この不透明性が生まれたのは、例えば「外部企業と内密なやり取りがあって、隠しておきたい深刻な事情があった」とか、そういう背景からではない。 むしろ逆に、情報の不透明性の話になるたびに比較的僕の所属するチームは性善説で「できる限り共有しましょう」という議論が起こるので、上下の人間関係が悪いとかではない。教えてと言えばだいたい

この流れです。 前提基本的に自分はGoのサーバーサイドが主戦場で、カンファレンスにはよく顔を出します。最近はOSSを公開すればいい感じにGithub Trendsの上の方にきて目立つような、芸人っぽいムーブができるようになりました。 ですが、直近プライベートではGo以外にTypeScript(Next.js) でGraphQLのクライアント書いたり、仕事だと前はSwiftやらC++やらPerlやら色々使っていたので、他の方と比べると広く浅い経歴です。 また、大学に入ってから学習を始めましたし、当時はドットインストールが出始めたくらいで、基本的には書籍で勉強していました。大学では授業でFORTRANの授業を取りました。内容は意味わからなかったので同級生に寄生してました。 Progateとかプログラミングスクールとかには頼ってませんでした。無かったので...。なので、「幼少期からBASICを触

基本忙しいな〜と思いつつ、幸いにも仲良く仕事ができてることが多い。その理由を考えてた時に気づいたことをまとめたのがこの文章になる。ここで言いたいことはつまり、「機能を削ることはユーザーと開発チーム双方にとって、恐らく各位が考えている以上に良いことだ」ということだ。 なお、サムネは「機能を削ぎ落としていく過程はまるで彫刻製作のようだ...」と一瞬考えた時に程よい画像をとってきたのだけれど、単純にキモいなと思ったのと、的を射ているようで射てない気がしたし、プロダクト開発も彫刻もそんな知らないので、可及的速やかに忘れることにした。 いかにしてチームは殺伐となるかリリース間際やプロダクト開発が長期化すると、えてしてチームは殺伐としがち。自分が関わったチームでのプロダクト開発では、半々で殺伐なシーンと平和なシーンだった。 殺伐な開発は、その後チームの人間関係に消しがたい遺恨を残し、結果退職や倒産とい

個人的に技術選定について想いを馳せた記事です。 技術選定と妥協最近とても技術選定について悩んでいます。技術選定とは常にジレンマを伴い、各エンジニアの感情がぶつかり合うセンシティブなトピックです。 技術選定が「悩む価値のある問題」であるのは明確で、サービスそのものの市場領域を選ぶときほどではないけど、開発組織が長期に渡って健全にワークするか、というのを決める、非常に重要かつ長期にわたる問題だからです。 加えてこれは個人的な話ですが、僕は自分のエンジニアとしての性格なのか、「ビジネスとしてうまくいくスピード感があるのか、明確な課題があってそれを解決しているのか」という意見は前提にしつつ、ある程度技術的新規性に重きを置きがちなタイプという自覚があります。 なので、僕個人は技術選定となると、新規技術の導入に逸る気持ちを意識して抑えなくてはならないことが多いです。ただ別にそこまでネガティブな感情を覚

開発者向けのドメイン、「.dev」の登録受付が開始された。timakin.devはちゃんと俺が取った。みなさんも取りましょう。 で、昨日vim.devのドメインが個人によって取得され、そのリダイレクト先がEmacsのサイトになっていたことで、物議を醸した。HackerNewsにも載ってた。 この行為に対し、観測範囲では ・「やりすぎだ、同じデベロッパーとして辟易する」という人 ・単に"エディター間の宗教戦争"に関するユーモアあるネタだと受け取る人 の二極化が見られた。ちなみに僕はそこまでエディタ戦争に関心はないし、結構あとあと迷惑になる行為かなーと思うので、どちらかといえば前者寄り。 僕の話は置いておいて、前者はOSS開発者やカンファレンス主催者などが多い印象を持った。だから前者の意見が偉いとかそういうわけではないのだけれど、おそらく以下の２つのポイントで認識が大きくズレているから、二極化

tl;dr・Goの依存性注入は普通に行われるが、DIツールはまだ観測範囲では浸透していない。 ・直近出たGoogle製Go向けDIツール「Wire」はシンプルなAPIやツール作成で有用だが、依存オブジェクトの設定が複雑化すると表現性に限界がくる ・Goにおいて、DIツールはある種のフレームワークと認識して慎重に採用すべき前提：Goの依存性注入と課題Goのコードを書く際、特に一定規模を超えたAPIを書く際は、依存するオブジェクトというのが増える。DBクライアントやロガーや各種ビジネスロジックを呼び出すサービス層などがそれに該当する。 レイヤー化されたパッケージ構成の下、こうした依存オブジェクトをトップダウンに注入していくやり方は見通しがよく、テスト時にモックのAPIクライアントを差し込みやすかったりと、テスタビリティを向上させる。ざっくり依存性注入が行われるようなレイヤー化された構成で、なん

自分の成果物を「ゴミ」「クズ」「底辺」と表現して卑下する人がいるが、よくない。具体的には以下。ちなみに作っている物自体はとても良いなあ、と思っていて、僕なんかプログラミング勉強して２ヶ月の頃、おそらくphpMyAdminを起動させて「わかんねえな」って画面の前で呆然としていただけだったはず。 自分にも「初心者の〜」とかそういう接頭句つけた時期があったのでわかるけど、こういった卑下をするのは大体、「自信がないけど成果物をオープンにしたくて、上級者から何か言われた時の免罪符にしたい」から。 なんだけど、大体意味がないし、自分にとって良くない影響がある。 こういう言葉を使って自分の成果物を世に出す経験を繰り返してしまうと、「この程度のクオリティでも"劣ってる可能性があるのはわかってます"って姿勢さえ表明しておけば良いだろう」って心理がうっすらと働いてしまい、無意識に自分の成果物に限界を作ってしま

「誰かエンジニアで暇な人いませんか？」個人的にカンファレンスとかでエンジニアの知り合いの数が多くなったせいか、優秀なエンジニアの知り合いを紹介して欲しいと相談されることが非常に多いです。 「本当に優秀な人」以外を繋ぐならすぐ紹介できます。しかし、本気で生産性が高い人に声をかける場合、他のリファラル案件にも負けない条件を提示しないと絶対に来てくれないし、下手な紹介なんかしたら「僕と対象者の関係」「対象者の人生」「会社のプロダクトの成功」の全ての面で不幸が生じます。誰でもわかることだと思いますが、その割に結構雑に依頼を投げる人が多いな、という印象があります。優秀なエンジニアで仲良くしてもらってる人は、雑に紹介できるほど半端な友好関係ではないので、適当に繋いだりはしないです。 紹介可否の格差ある一定の基準をクリアしていると、すぐに紹介できます。紹介できない場合はよほど事情が変わらない限り良い報告

反省文。 tl;dr・「後から改善すれば良い」のスタンスは、返済コストを甘く見積もっている結果 ・負債の返済にはコーディング以外の工数が大きくかかってくる ・技術的負債を"徐々に"返済することは様々な面で良い 出社即リファクタリング最近出社した直後に、こっそりリファクタリングの時間を一定程度取るようにしている。朝のウォーミングアップがてら改善作業をしていると、瞑想みたいな効果があって大変気分がよくなるし、その後のコーディングも生産性が上がる。大体こういう気分。 具体的な作業は、アーキテクチャの方針が固まってなかった時代のコードの１つのエンドポイントだけ、適切なレイヤ化を施したり、単体テストが可能なメソッドとして切り出しつつ実際にテストを書いたり、テストに必要な共通処理を定義したり、だ。 初期から機能追加を重点的に行ってきたプロダクトでは、スピード優先の名目で多くの負債が生まれる。こうした負

ポエム。 つまり？予算やチームのリテラシーに合わせて最速で作れて、チーム内で「俺ら高凝集低結合だなー」と思えるなら、アーキテクチャはなんでもいいと思えてきました。 前提・まだ割と収益が安定してないプロジェクトでの話です。お金があるなら好きにやりましょう。Go Bold。 ・DDDやクリーンアーキテクチャがダメとは言ってないです。むしろ自分は直近そこまで厳格ではないクリーンアーキテクチャでAPI書いてます。 ・以前こういうポスト書くくらいにはアーキテクチャのこと試行錯誤してました。 アーキテクチャ導入議論への疲労以前僕は、DDDやクリーンアーキテクチャを導入するという話が出ると積極的に顔を出すようにしていました。でも、最近は「導入しましょう」「既に適用してあるのでキャッチアップしてください」などの議論をするのに少し疲れてしまい、足が重くなったように感じます。もうおじいちゃんなので体力がないん