マイクロソフトの仕事日記11/20/19

バスでは、日記を書くこと。

マイクロソフトに約3ヶ月、そして実際に伝説的な企業年金のため、作業時間よりも簡単亜麻。リラックスした男のダウンは、私は幸せな、幸せな気分を取得し、学ぶための動機があります。ここで、私は最終的に私のフロントエンド開発のキャリアを開きました。周りのフロントエンド開発のような非常に少数の人々は、私は完璧になるまでゆっくりのようにさまざまなコンポーネントの試運転、例外だっただけということがあります。私はシムズを再生するように、それぞれの時間は、合計がデバッグ服、靴、髪、顔体とその上に多くの時間を費やしています。共通の基本コンポーネントは、専門の管理時間を標準化し、コンポーネントグループによって公開されているので、少しコンポーネントのほとんどが開発されていないことに失望し、データで満たされ、他のグループは、行に直接入力します。しかし、数千マイルは一歩、複雑なステップによって、深さのステップを除いて最初にする簡単な組立作業から始まります。

弟メンターインドは特に深刻と責任があります。私は、どのようにデバッグのために、どのようにリリース、新たに随時書き込みにバグが到着したが、弟は非常に辛抱強くどのように正しい教えてくれました。ブラザーときに非常に患者、私はPRや改訂を参照するには、時間に彼を送信します、娘の酒があるかもしれない、冗談を言って、つついに行くような何もありません。このメンターでは、気持ちはとてもクールでした。

今日はそれを本番環境にリリースされた、私が先週書いた、バグを発見しました。この関数は、実際には間接的な効果は、私は文字列で観測可能な変数を変更しますすることです タイプが、使用があったが修正されていない、割り当ての失敗につながる、それがテストで問題を見つけられませんでしたとき、空です。メンター顧客への影響、その修理アウトタイムリーにリリースするので、発見後に私を知らせました。問題の発見から、修理の解決策を見つけるし、その後2時間の円で回って、リリースを承認しました。不思議は、ソフトウェアの開発は非常に厳格なプロセスであり、小さな見落としが悪いユーザーエクスペリエンスにつながる可能性があると述べていません。実際には、昨日は、内部エラーの問題の増加を示したと報告しoncall、グループは、その理由を述べたが、このバグアップにリンクされていません。そのため、修理の問題の後、次のステップは、このバグを発見していなかったのはなぜoncall議論と分析の下で、あなたはより速く、トラブルシューティングのプロセスをより直感的にする方法を向上させることができます。

ホームは、ので、今日は修理のバグはとても新しいデフォルトのページを達成するためにどのように今夜を参照して、いくつかの時間を遅らせました。さあ！