Notes on Distributed Systems for Young Bloods – Something Similar
I’ve been thinking about the lessons distributed systems engineers learn on the job. A great deal of our instruction is through scars made by mistakes made in production traffic. These scars are useful reminders, sure, but it’d be better to have more engineers with the full count of their fingers. New systems engineers will find the Fallacies of Distributed Computing and the CAP theorem as part of
どのようにエンジニアの目標設定を行うか - $shibayu36->blog;
以前 ゴールを決め目標を決める・解決案ではなく質問する - コーチングの学習で学んだこと - $shibayu36->blog; で、「ゴールを決め、現在位置とのギャップを考え、目標を決める」と良いということをまとめた。イメージとしては以下の図の通り。 しかし、前回の記事だと具体的にどのようにエンジニアの目標設定を行うかイメージが湧かない。そこで、もう少し具体的に最近どのようにやっていたかを書いてみたいと思う。 僕がメンティーと目標設定を行うときは、以下のフローを辿っている。 なんでも良いのでゴールのイメージを明確にする 現在の自分とゴールのイメージのギャップを考える ギャップを埋める目標を考え、アクションを定める ちなみに今回は、チームの成果達成のために個人の目標を決めるのではなく、エンジニアのスキル向上の目標を立てるという前提で書いていく。 なんでも良いのでゴールのイメージを明確にする
スクラムマスターとして僕がやっていること、あとバーンダウンチャートの話(ShanonAdventCalendar2016 - 17日目)
これは Shanon Advent Calendar 2016 の 17日目の記事になります。 こんばんは、開発の土田です。 僕は 2014年の1月から、約3年くらいスクラムマスターをやっています。そこで、これまでやっていたこと、普段やっていることなどについて、つらつらと書いていこうかと思います。 上記の通り、約3年くらいやってますが、ずっと開発と兼任でやっていて、自分のチーム1チームだけ見ています。スクラムマスターとしては研修とか受けたことはなくて、本などを読んで、「見よう見まね」でやっている感じです。 チーム編成について チームは大体プロジェクトごとに変わっています。基本的には大きく変えない方針なので、プロジェクトごとにチームは変わりますが、大きくは変わらない、といった感じです。(何人か入れ替わることはあるけど、全とっかえみたいな変更はあまりないです)。チームの規模は、一番大きなときは
マネジメントに悩める全てのエンジニアにささげる 伊藤直也の１人CTO Night
…というのに行ってきたのでメモを晒します。社内共有用に書いたんだけど、秘匿情報もないのでほぼそのまま公開します。乱文かつ文中敬称略にて失礼。 ～マネジメントに悩める全てのエンジニアにささげる～ 伊藤直也の１人CTO Night ｜転職ならDODA（デューダ） 開発組織マネジメントのコツ対象 : 50 – 100人ぐらいのWeb / 受託会社CTO or VP of Engineering海外ではCTO : テックリードのイメージが強いマネジメントをするのはVPofEが多いCTOがマネジメントしたくなければVPofEを雇うのもありスコープチームマネジメントヒューマンマネジメント基本姿勢「イシューから始めよ」解の質 x イシュー度 -> バリューのある仕事イシュー度 : 問題設定の正しさ問題解決ではなく問題発見にフォーカスマネージャーの仕事は問題設定あとはメンバーが解いてくれるチーム構造開発組
新卒の子にどこまで勉強すれば良いですかね？と聞かれた件 - Qiita
ちょっと、簡単に答えられなかったので、休み中にまとめました。 「どこまで勉強すれば良いか？」 という質問には、 自分の立ち位置や、今後の目標など関わるので、 それらを踏まえて考える必要があると思います。 職種によっても違いますが、質問された時の状況は、 Web系エンジニアが新卒の子に聞かれた形なので、 考慮いただきたいです。 また、そもそも、どんな背景をもったやつが書いてるんだ？と思う方も いらっしゃるかと思いましたので、簡単に自己紹介してから書きます。 書いている人の自己紹介 現在33歳で、エンジニアスタートしたのが、 2005年08月だったので、エンジニア歴は11年となります。 ほとんどの現場がデスマーチ状態だったので、2ヶ月くらい前に転職して、 現在はホワイトな会社のリクルート住まいカンパニーで、PHPを書いています。 言語歴としては、最初にJP1スクリプトを１年半くらいやって、次に
はてなのエンジニアに期待する「アウトプット」 - Hatena Developer Blog
id:stanaka です。はてなでは1月末と7月末に評価の時期を迎えます。毎回この時期になると評価プロセスや評価軸について議論になります。 はてなでのエンジニア評価として、コード品質などいくつかの項目がありますが、その中の一つとして「アウトプットする」ということを設定しています。 「アウトプットする」ということは直接的にはその本人と会社の社外におけるプレゼンスを向上させる、ということになりますが、それ以上の効果があると考えており、そのあたりの背景について社内向け文章を書いたのですが、せっかくですので社外にも公開します。 「アウトプットする」ことを期待する背景 はてなのエンジニアの評価基準として「アウトプットする」ということを軸の一つとしています。 アプトプットすることは、自身や会社の社外におけるプレゼンス向上だけではない価値があると考えています。 アウトプットすることで各エンジニアがより
サイボウズ・ラボを退職しました（ご挨拶） - 竹迫の近況報告
2015年8月末をもって竹迫はサイボウズ・ラボ株式会社を退職いたしました。勤続年数は長く9年10ヶ月でした。 在職中は様々な活動を通して多くの皆様よりご指導ご鞭撻をいただきまして誠にありがとうございました。 まだまだ未熟だった私もサイボウズの中では多くのことを学びまして、自分自身も人間として大きく成長することができました。 サイボウズ・ラボの設立背景（10年前） 思い起こせば、私がサイボウズ・ラボに入社したのは2005年11月で、当時はまだラボを設立したばかりの立ち上げ期の頃でした。 リージャス赤坂のレンタルオフィスの一室を借りて、畑さん、akkyさん、kazuhoさんと4人で机を並べて、仕事を開始したのは良い思い出です。 それまでのサイボウズは関西人のノリでダジャレのキャンペーンをよく実施していたためか、どちらかというと宣伝やマーケティングにうまい会社と思われており、なかなか技術の会社と
私、ScalaMatsuriで転職しました - ScalaMatsuri運営ブログ
今回ScalaMatsuri 2016のスポンサー企業を募集するにあたり、特別企画として ScalaMatsuri 2014を転職活動に活用され、実際に株式会社ドワンゴさまに2014年末に入社された中山裕貴(@pocketberserker)さんに、ScalaMatsuriを利用した転職活動について詳しくお話をお伺いしました。 スポンサーをご検討されている企業のみなさんにとっては「ScalaMatsuri参加者はどんなところを見ているのか？」について、 転職を検討している参加者にとっては「どんな風に転職に活用できるのか？」について、ご参考になれば幸いです。 普段、関数プログラミングに偏らせたScalaの勉強会を開催したりしています(笑) Q.それではよろしくお願いします。 まずはドワンゴ社内でのお仕事を含め、どのような活動をなさっているか、教えていただけますか？ A.仕事では、サーバーサイ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Software Engineering at Google