クソコードと呼ばない - ppworks.jp
新しい現場にはいったときに心がけていること、クソコードと呼ばないこと。 誰かのコードを読んでいるとそりゃまあクソコードを見つけることがある。その時どう立ち向かうかという精神論の話。 例えソレがそうであってもソレを口にするとネガティブが蔓延する。思ってもイイ、でも言ってしまってはならない。あるフェーズに置いては必要だった し、現に動いていて価値を提供している のだ。あるべき姿を叫ぶの簡単だ。あるべき姿を見ているなら行動しないといけない。見つけたらリファクタだ。出来るところからやるんだ。 Shut the fuck up and write some code & 許可を求めるな Pull Request せよ— 🌈KOSHIKAWA (@ppworks) 2014年5月23日 クソはクソと言える空気や文化は大事。良くないものを指摘できるようにはしたい。口の前に手を動かそう。プログラマーなら
RE: クソコードと呼ばない - id:bash0C7の進捗 過去アーカイブ[〜2019-02-23]
例えソレがそうであってもソレを口にするとネガティブが蔓延する。思ってもイイ、でも言ってしまってはならない。 ホントそれ。びっくりするほど簡単に場を汚染してしまうので、意識的に避けている。 さて、昨年末に公開されたこの記事 2ページ目で自分に言及があり、 「悪いことを言わない」という前向きな思想が彼にはあるんだろうね。ネガティブなことを口に出してしまうと「言霊（ことだま）」となって固定されてしまうと考えているんだね。 という評価をいただいた。 「悪いこと」ワードを発する事によって、雰囲気を悪くしてしまうのを恐れている。場を悪い方に倒してしまうことを強く恐れている。 どんなものであれ物事は放っておくと悪化して行く。滅び方向に向かっていく。 それを食い止めて自分たちの望む方向に持っていく活動を環境面であれ技術面であれ行っているわけだが、わざわざ悪化させる必要なんて無い。非常にシンプルなことだ。
![RE: クソコードと呼ばない - id:bash0C7の進捗 過去アーカイブ[〜2019-02-23]](https://cdn-ak-scissors.b.st-hatena.com/image/square/e3dd50d5c40beac87f94057029c23cc173eb8425/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F12921228815714508769%2F8454420450080544583%2F1421500760)
ソフトウェア開発の生産性を阻害する「気軽に聞けない」ことの考察と対策 - メソッド屋のブログ
マイクロソフトの DevOps テクニカルエバンジェリストになる前から、ずっと不思議だったことがあります。 それは、「アメリカのエンジニアの生産性の高さ」です。素晴らしいサービスは大抵彼らから生まれていますし、彼らを見ているとアウトカムも生産性も非常に高く感じます。 私は個人的にこの秘密を解く旅の途中にいます。私はインターナショナルチームに所属しているのですが、同僚と一緒に働いたり、ハッカソンをしたりして気づいた１つの仮説について共有したいと思います。 気軽に「聞けないこと」が生産性を阻害しているのでは？ 以前私は「米国のエンジニアはコンピュータサイエンスを専攻している人が多くすごく優秀で、さらに英語が出来るので、技術収集するのも楽だから相当アドバンテージがある」と思っていました。 英語に関してはそうだと思いますが、彼らの個々の人がそんなに優秀かというとそうでもないことに気づきました。それ
【決定版】アプリ事業のKPIツリー！ | Growth Hack Journal
はじめに アプリによってビジネスモデルは異なりますが、大多数のアプリがゴール（KGI）にしているのは売上増かと思います。 では、あなたは売上増に向けた指標の把握と整理ができているでしょうか？ この記事ではKPIツリーを使ってアプリの売上に貢献する指標を洗い出し、各指標について説明したいと思います。 1.KPIツリーの重要性 ◆そもそもKPIツリーとは？ KPIツリーとは、例えばアプリのKGIを売上とした場合、売上を構成する要素を分解して施策が実行可能になるレベルまで落とし込まれた指標（KPI）の一覧です。 ◆KPIツリーを作らない場合の問題点 ①ボトルネックとなっている問題がわからない 売上を構成する要素を洗い出さないと、売上増の妨げになっている問題に気づかないことがあります。 ②具体的な施策を考えるのが難しい 売上やアクティブユーザー数など上位の指標を分解しないままでは、「じゃあその指標
CTOより 第3回 「Quipperの開発体制の今」
quipper-cto-3.md 今回はQuipperの開発体制と進め方について書いてみようと思う。 開発チームの規模 第一回で紹介したように、Quipperは、ロンドン、東京、マニラ、ジャカルタ、メキシコシティにオフィスがあり、そのうちロンドン、東京、マニラが開発拠点になっている。 内訳としては、以下の様な状況だ。 Web iOS/Android Engineering Design Total London 3 0 0 1 4 Tokyo 5 4 3 1 13 Manila 7 1 0 2 10 Total 15 5 3 4 27 30人弱。この規模から、今年中に3拠点合計で10人くらいの増強を考えている。拠点毎、職種毎の大まかな計画はあるが、いい人がいたら拠点/職種毎の採用の増減はある感じで、3拠点全職種トータルで考えて一番強いチームにしたい。 Engineeringは、Quippe
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - edumentab/cqrs-starter-kit: A starter kit for working with CQRS and intentful testing.
CQRS
Luigi vs Airflow vs Pinball