質問：マネジャーを続けるかエンジニアに戻るかで葛藤しています
チームのリーダーとしてマネジメントを任されるようになりました。自分としては一エンジニアとして頑張りたいという思いもあり、このままマネジャーを続けるかエンジニアに戻るかで葛藤しています。藤本さんのご意見をいただければ幸いです。 まず最初に大事なことは、いわゆるチームマネジメントは決して片手間でできるようなものでも、やっていいものでもない、ということです。なので、結論を先に書いてしまうと、葛藤している暇があったら早めにどちらか決めてしまいましょう。まぁ言うのは簡単なんですけどね。 ものすごく単純な例えですが、エンジニアとして10台のサーバーで一つのタスクを分散処理したり一つのシステムを動かしたりするのと、マネジャーとして10人のチームメンバーを一つのゴールに向かってまとめ上げて走り続けることの、どちらが簡単でしょうか？ 前者を簡単と言うつもりは全くありませんが（前者も十分に難しいことが多いので
ソフトウェア開発時に気をつけてる振る舞い - futoase
他人と開発する多人数開発(2名以上)のお話。 なんとなく思ってること。 修正してください 仕様が変更になった上での変更であれば、修正ではない。 ので、「変更した理由」と「変更して欲しい意図」を説明する。 その前に一言、「修正」とかチケットで「修正」とつけてはいけない。 その人は「変更前の仕様」を充足した形で実装していたのだから。 バグを出した後の言葉かけ 僕は率直に、見つかってよかったと思うし、そう表現するのだけど、 人によって追い詰める言葉を発してしまう。 追い詰めると、次バグが見つかっても「気が付かなかったフリ」をされてしまう。 そうなると品質が下がる。意味が無い。 話を自己の経験100%で話してしまう 自分が得られた知見は重要なんだけど 働いてきた場所は10も無いだろう。というので 50%ぐらいに抑えて、後は他社の事例とか、 なんか優れたようなドキュメントとか開発の歴史事例とか それ
クライアントサイド JavaScript (AltJS) のテストを書くのは本当に難しいのか？ - @kyanny's blog
TL;DR - 最初の一人はつらいけど後続はそうでもないので先駆者は自覚と誇りを持ってオールグリーンを維持しよう このエントリはMarionette.js ベースで3ヶ月開発したアプリのカバレッジ推移をまとめてみた - @kyanny's blogというエントリの続きにあたります。未読の方は先にそちらを一読されることをおすすめします。 Marionette.js ベースで3ヶ月開発したアプリのカバレッジ推移をまとめてみた - @kyanny's blogの結論で触れたように、今回テストを書くことにこだわったのは、「クライアントサイド JavaScript (AltJS) のテストを書くのは本当に難しいのか？」という問いに対する自分なりの回答を実践して検証してみたかったという理由があったからだ。 以前から「クライアント JavaScript (CoffeeScript や他の AltJS を
プログラムは手段だけど、せっかく作るなら儲かって綺麗にこしたことはない。 - お前の血は何色だ!! 4
コードは綺麗だけど儲からないプロジェクトと、 コードは糞汚いけど儲かるプロジェクトのどっちがいいですか？ もちろん、コードは綺麗で儲かるプロジェクトがいいのは理想ですが、今回は、この2つです。 コードは糞汚いけど儲かるプロジェクトの場合、次期バージョンとかの予算を確保することができます。 そこで、汚い部分を捨てて書きなおすことだって出来ます。 コードは綺麗だけど儲からないプロジェクトは、次のバージョンの改修費用もでずにゴミ箱に送られる運命です。 プロジェクト解散、メンバーは散り散りです。 フリーソフトの場合は、儲かるをユーザに使ってもらえるソフトとか支持されるソフト、 ゲームの場合は、儲かるを面白いゲーム、支持されるゲームとかと適当に読み替えてください。 コードは綺麗に越したことはないです。 だけど、プロジェクトとして成立しないことには意味がありません。 コードは綺麗だけど、誰も遊んでくれ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Goの変数名が短い理由（あるいはGoがほかの言語と違う理由） - Qiita
