プロとしての行為 Act as Proffesional
スーパーエンジニア達の習慣が大人気だったので、自戒の意も込めて、反面教師として成長しないエンジニアの悪習慣について僕の経験と視点からまとめてみる。 業務時間外での学びがない プロ野球選手は日々練習をして、試合という本番で勝敗の結果を出して評価されるこれをエンジニアに置き換えると、どこかで練習をして、仕事という試合をして、ソフトウェアという勝敗の結果をつくりだす。プロ野球選手が試合を練習だと思って取り組んでいたら、結果を出せるのだろうか？ 業務外で練習をして、本番で良い結果を出せるように努力しよう。練習大事!! 時間をかければよいものができると信じているいくら時間をかけたって、バグのないエレガントなコードのソフトウェアはできない。効率的に仕様を満たしていくことが求められている。むしろ、時間をかけるべき所は上記で指している練習!! 参考：集中力を発揮して、生産性を高めるために知っておくべきこと
ググるな危険：プログラマで、生きている：エンジニアライフ
だいぶ前の話になりますけど、「新人にデータ移行ツールのコーディングを任せるので、面倒をみてやってくれ」と頼まれたことがありました。 その新人はやたらとGoogle検索に頼る人で、とにかくわからないことがあると、わたしに聞かずにGoogle先生に尋ねるんですね。 検索サイトにはわたしもかなりお世話になっていますし、昔に比べるととても使い勝手がよくなっていますけれど、その人の技術レベルに対応して検索結果を出してくれるほど高機能なわけではありません。 そのため新人の書いてくるコードは、つぎはぎというかちぐはぐというか、身についてない知識に振り回されてる感が満載でした。 そういう弊害を気にしつつも、自分で調べようとする気持ちは尊重するべきなのかなあ、と思ってとりあえず黙認していたんですが、あるとき「ちょっと考えが甘かった」と思い知らされるトラブルが発生しました。 その新人が「Windowsのレジス
エンジニアの勉強法について
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは。 サービス統括部に所属しております、堀 邦明と申します。 普段はYahoo! JAPANトップページのフロントエンドエンジニアとして、JavaScriptやPHP,Perlといった言語を利用して開発しています。 この度、デベロッパーズサミット2009というイベントにおいてエンジニアの勉強法というテーマでJavaScriptの勉強法についてお話をさせていただきました。 今回は、そのときのお話について発表しきれなかった部分も含めてご紹介できればと思います。 勉強の分類 勉強には大きく分類して2つのステップがあると思います。 1. 情報収集 1つは情報収集です。 技術書やウェブサイト、ブログを読んだり、勉強会やセミナーに参加
SI業界を目指す君達へ贈る「何故システム開発はテンパるのか」 - novtan別館
先日学生に聞かれたんですよ。 「下流工程は大変って聞きますが、上流は楽なんですよね？」 よろしい、君はよく勉強している。でも根本的に間違っている。下流工程が辛いのは、上流工程でちゃんと仕事ができなかったからだ*1。 というわけで、主に学生向きに話を単純化して語ってみます。これが普通だとか、一般的だとか言うつもりはなく、違う視点もあるかと思いますが、一つの考え方として。 SIでのシステム開発は、建設業にたとえられます。が。 顧客の希望を聞き、設計し、施工し、引き渡す。こういった工程を踏む仕事ということで、システム開発はよく建設業にたとえられます。実際に工程管理の手法なども似通っています。ところが、大抵の場合、耐震偽造をした建築物よりもシステムのほうが脆弱に仕上がります。何故でしょうか。 一つには、建物の図面を引くには建築士の資格が必要ですが、システムの設計に資格は必要ありません。 もう一つ、
エンジニアとして生き残るための、たった１つの真実 - Fight the Future
エンジニアとして生き残るための、たった１つの真実。 「生き残る」という言葉には2つの意味を持たせている。 老害エンジニアにならずに生き残る プロジェクトにつぶされることなく生き残る ではどうすれば生き残れるのか？ 大きなヒントがInfoQの記事にあった。 原則4:自分の仕事の仕方を常に疑う InfoQ: トップスポーツチームの監督に教わる秘訣 老害エンジニアにならないために 先日テレビを見ていたら、水素自動車の特集をやっていた。 ホンダの社長がこんな感じのことを言っていた。 「技術はほしいと思ってもすぐにできるものじゃない。だから今のうちから研究する。」 クラサバからWebへシステム開発の主軸が移ったとき、多くのエンジニアが追いつけなかった。 それはほしいと思っても技術がすぐに身につかなかったからだ。 昔COBOLができれば一生食うに困らないと言われていたそうだ。 だが、現実は違った。 自
「ITは文系領域も多いからコンピュータサイエンスなんて知らなくていいんだよ」的な言説が蔓延ることが業界の現状を招いているのだが - novtan別館
今年最後の殴り書き。 ITに向いている人材が文系か理系かなんていう議論にはまったく意味がない。ものづくりには沢山のステップがあり、また各ステップの仕事には様々なタスクがあり、それぞれがいわゆる文系的タスクであったり理系的タスクであったりする。ITという名のつく職業における仕事は多くの部分で事務作業化が目指され、また、実現されてきているけれども、設計は決して事務作業ではない。設計がいらない建物はプレハブくらいだろう。プレハブを売るのがITの仕事の全てである、という話であれば、あるいは正しいのかもしれないが。 私がここで主に想定し、前提にしていた「ITのスキル」は、SEやプロジェクト・マネージャーのように対人スキルを要求される職務ではなく、純粋に「プログラミング」や「設計」のスキルだった。 ITエンジニアにコンピュータ・サイエンスは必須か - モジログ コンピュータ・サイエンスの知識は、もちろ
僕がプログラマーを応援したがるわけ - Attribute=51
ひとつ、昔話でも。 やたらプログラマーを応援したがるエントリーを書いたり、 ときどきプログラミングの話題を書いたりする関係で、 「SEの人なんだ」と思われたりするんですけど、SEではないんですよ。 まぎらわしくてごめんなさい。 でも、昔はSEでした。 3年間、割と大きな会社でJavaプログラマーやってました。 まあ、この際、「SEとプログラマーは違う」なんて話題は目をつむってくださいな。 デキル人になりたくて、土日もよく勉強してました。 資格の勉強をしたり、自宅でプログラミングばかりしてました。 まあ、友達いなかったんでね、それぐらいしかやることなかったってのもあるんだけどさ。 当時、自分のいた会社では、 請け負う案件をCOBOLなどのレガシーシステムから、Javaを使ったオープンシステムに移行し始めてました。 社内でCOBOLを知っている人は多数いたけど（あとVB）、Javaを知っている
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ふつうのシステム開発〜ゆるふわドンピシャ(ry