理想の技術選定 | timakin（ちまきん）
個人的に技術選定について想いを馳せた記事です。 技術選定と妥協最近とても技術選定について悩んでいます。技術選定とは常にジレンマを伴い、各エンジニアの感情がぶつかり合うセンシティブなトピックです。 技術選定が「悩む価値のある問題」であるのは明確で、サービスそのものの市場領域を選ぶときほどではないけど、開発組織が長期に渡って健全にワークするか、というのを決める、非常に重要かつ長期にわたる問題だからです。 加えてこれは個人的な話ですが、僕は自分のエンジニアとしての性格なのか、「ビジネスとしてうまくいくスピード感があるのか、明確な課題があってそれを解決しているのか」という意見は前提にしつつ、ある程度技術的新規性に重きを置きがちなタイプという自覚があります。 なので、僕個人は技術選定となると、新規技術の導入に逸る気持ちを意識して抑えなくてはならないことが多いです。ただ別にそこまでネガティブな感情を覚
さよならアーキテクチャ議論｜Seiji Takahashi@ベースマキナ
ポエム。 つまり？予算やチームのリテラシーに合わせて最速で作れて、チーム内で「俺ら高凝集低結合だなー」と思えるなら、アーキテクチャはなんでもいいと思えてきました。 前提・まだ割と収益が安定してないプロジェクトでの話です。お金があるなら好きにやりましょう。Go Bold。 ・DDDやクリーンアーキテクチャがダメとは言ってないです。むしろ自分は直近そこまで厳格ではないクリーンアーキテクチャでAPI書いてます。 ・以前こういうポスト書くくらいにはアーキテクチャのこと試行錯誤してました。 アーキテクチャ導入議論への疲労以前僕は、DDDやクリーンアーキテクチャを導入するという話が出ると積極的に顔を出すようにしていました。でも、最近は「導入しましょう」「既に適用してあるのでキャッチアップしてください」などの議論をするのに少し疲れてしまい、足が重くなったように感じます。もうおじいちゃんなので体力がないん
優秀なエンジニアを紹介する条件｜Seiji Takahashi@ベースマキナ
「誰かエンジニアで暇な人いませんか？」個人的にカンファレンスとかでエンジニアの知り合いの数が多くなったせいか、優秀なエンジニアの知り合いを紹介して欲しいと相談されることが非常に多いです。 「本当に優秀な人」以外を繋ぐならすぐ紹介できます。しかし、本気で生産性が高い人に声をかける場合、他のリファラル案件にも負けない条件を提示しないと絶対に来てくれないし、下手な紹介なんかしたら「僕と対象者の関係」「対象者の人生」「会社のプロダクトの成功」の全ての面で不幸が生じます。誰でもわかることだと思いますが、その割に結構雑に依頼を投げる人が多いな、という印象があります。優秀なエンジニアで仲良くしてもらってる人は、雑に紹介できるほど半端な友好関係ではないので、適当に繋いだりはしないです。 紹介可否の格差ある一定の基準をクリアしていると、すぐに紹介できます。紹介できない場合はよほど事情が変わらない限り良い報告
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
