タグ

programmingとworkに関するastk_fのブックマーク (18)

  • 「プログラマの三大美徳」と「HRT」を使い分ける - 「コードを憎んで人を憎まず」 - TechとPoemeの間

    TL; DR 「プログラマの三大美徳」はソフトウェアに向けるものであり,人に向けるものではない. 「HRT」は人に向けるものであり,ソフトウェアに向けるものではない. プログラマの三大美徳 プログラマの三大美徳というものがある.Perl を開発した Larry Wall が提唱したもので,「怠慢」「短気」「傲慢」からなる. 詳しくは上述のリンクにある各解説記事に譲るのだけど,例えば「怠慢」とは,「エンジニアとして手間を省くために最大限の努力をする気質」を指す.元の Larry Wall の記述では当たり前過ぎて省略されているのだけど,「最大限の努力」とは「仕事をしないために交渉する努力」ではなく「技術で手間を解決する努力」を指すものだと思われる (勿論,場合によっては前者が大事になるケースも有るのだけれど) . 「プログラマの三大美徳は "怠慢", "短気", "傲慢" である」というワー

    「プログラマの三大美徳」と「HRT」を使い分ける - 「コードを憎んで人を憎まず」 - TechとPoemeの間
  • SIer→社内エンジニア→リモートワーク、3つの職場を経て見えてきた、プログラマにとっての幸せな働き方 - GeekOutコラム

    みなさん、こんにちは。 普段は「give IT a try」というブログを書いている、プログラマの伊藤淳一(@jnchito)です。今回は縁あって、GeekOutでコラムを書かせてもらいます。 僕はプログラマとして働き始めてもうすぐ15年になります。最初に入った会社は大阪にあるSIerでした。そこで4年ほど働いた後、次は外資系企業の社内エンジニアとして働き始めました。社内エンジニア仕事は5年ほど続け、それから株式会社ソニックガーデンへ転職して現在に至ります。 これまでに働いてきた3つの職場は三社三様です。それぞれの職場で良かったことやしんどかったことをあらためて見つめ直してみると、プログラマにとっての幸せな働き方が浮かび上がってきます。もちろん何を幸せと感じるかは人によって異なりますが、同じ「IT業界」といってもいろんな職場があることは知っておいても損はないでしょう。 また、幸せは突然空

    SIer→社内エンジニア→リモートワーク、3つの職場を経て見えてきた、プログラマにとっての幸せな働き方 - GeekOutコラム
  • Amazonのソフトウェアエンジニア面接 | POSTD

    最近、Amazonエンジニア採用担当者から連絡を受けました。Amazonは、ベルリンオフィスのチームのソフトウェアエンジニアの採用面接をしていたのです。 連絡を受けてから契約書にサインするまでのプロセス全体は、2カ月でした。採用プロセスで経験したことと、私が合格できた理由として思い当たることをお知らせしたいと思います。 この記事で、もし私が何か重要なことに触れ忘れていたら、ぜひコメント欄に書いてください。出来る限りの詳細を回答に書きます。 4月27日:最初の連絡 採用担当者からの連絡は、 LinkedIn 経由でした。ベルリンオフィスのチームのソフトウェアエンジニアを募集しているので、もし興味があれば、最新のレジュメを送って欲しいとのことでした。私は、常にレジュメを最新にしていたので、翌日、Eメールに添付して送りました。 彼女からの返信には、募集しているソフトウェアエンジニアの役割と面接

    Amazonのソフトウェアエンジニア面接 | POSTD
  • 日本人プログラマーについての記事が Hacker News で話題になった

    東京住まいの外国人プログラマーが日人のプログラミング世界について記事を書いて (Jawaad Mahmood 氏のブログ記事)、その記事が Hacker News で取り上げられて、話題になった。 "My hypothesis is that a lot of Japanese companies produce little new because they have people solving solved problems over and over again." 以下、拙訳。(*) がついているところは訳していて意味がくみ取れなかった部分なのでコメント頂ければ幸い。誰か Hacker News へのコメントも要約してくれると助かる。 昨日、コーヒーを飲みながらアール氏とアキバに関する話題やらボードゲームやビジネスについて話していた。まじめな話題としてはプログラミングについて、

    日本人プログラマーについての記事が Hacker News で話題になった
  • 「少人数のチームの方がソフトウェアの品質は高い」実証的ソフトウェア工学の研究会が開催

    統計や実証を通してソフトウェア工学を研究していく、それが「エンピリカルソフトウェア工学」(Empirical Software Engineering、実証的ソフトウェア工学)です。「第一回エンピリカルソフトウェア工学研究会」が、12月10日に都内で開催されました。 基調講演では、マイクロソフトリサーチで研究をしているDr. Thomas Zimmermann氏が登壇。開発組織の構造がソフトウェアにどう影響するのか、バグ報告書やバグ報告者と修正されるバグの優先順位の関係、そしてエンピリカルソフトウェア工学という「データ指向のソフトウェア工学」を、どのようにソフトウェア開発における意志決定に役立ていくのか、といった内容の講演でした。 開発組織の構造がソフトウェア品質に及ぼす影響は? マイクロソフトリサーチのDr. Thomas Zimmermann氏。 今日はいくつかのテーマについて紹介した

    「少人数のチームの方がソフトウェアの品質は高い」実証的ソフトウェア工学の研究会が開催
  • 新人プログラマ向け・スキル向上のための具体的なアプローチと考え方 - give IT a try

    はじめに:「僕にもそんな頃があった」 先日、西脇.rb&神戸.rbの合同勉強会として「RailsプログラマのためのSQL勉強会」を開催しました。 この勉強会は出題者(=僕)が出したSQL問題を他の参加者が解く、というスタイルの勉強会です。 参加者の方の中には最近プログラミングを始めた、という人も何人かいました。 そういう人にとっては問題がちょっと難しかったので、ときどき僕がサポートに回って質問に答えたり、解き方をある程度教えたりしていました。 また、話がちょっと脱線して「僕が作ったこれぐらいのWebアプリは、伊藤さんなら何時間ぐらいで作れますか?」みたいな質問を受けたりもしました。 その中で言われたのが、 「説明されたらわかるけど、自分一人でこの答えにたどり着くのは無理です」 「えっ、そんな短い時間で作れるんですか」 といったようなコメントです。 そういったコメントを聞くと、「あー、僕にも

    新人プログラマ向け・スキル向上のための具体的なアプローチと考え方 - give IT a try
  • Stack Overflow Developer Survey 2016 Results

    Overview Developer Profile I. Geography II. Developer Occupations III. Programmers, Engineers, and Developers IV. Age V. Experience VI. Gender VII. Diversity VIII. Education Technology I. Most Popular Technologies II. Most Loved, Dreaded, and Wanted III. Top Tech on Stack Overflow IV. Trending Tech on Stack Overflow V. Top Paying Tech VI. Correlated Technologies VII. Development Environments VIII.

    Stack Overflow Developer Survey 2016 Results
  • こんなコーディングは退屈だ! | Yakst

    Enkiのco-founderで最高技術責任者(CTO)であるBruno Marnetteが、エンジニア仕事に飽きて転職してしまわないよう、社内文化をどのように構築しているのかを紹介します。 開発者として、私は2年以上同じ仕事を続けた事がありません。 転職することは私にとって良いキャリアとなりました。私達の業界では転職を繰り返す事はごく一般的なことです。ところが、以前私が働いていた会社は、私の離職に難色をしめしました。中には、私を必死で引きとめようとする人もいました。しかし、私は仕事に飽きてしまっていたため、残ることはできませんでした。 (免責事項:私は多くのプログラマーよりも楽しいプログラミングの仕事をしていたと思います。仕事を変えることが常に最善の選択とは限りません。) 現在私はEnkiのco-founderで最高技術責任者(CTO)です。会社ではエンジニア文化の構築も行っています。

    こんなコーディングは退屈だ! | Yakst
  • [翻訳] コードレビューについて

    この記事は::..: glen.nu :.: ramblings :.: on code review :.::の意訳記事です。@9len氏の許可を受けて投稿しています。 This article originally appeared in English at :..:: GLEN D SANFORD :.: RAMBLINGS :.: ON CODE REVIEW ::..: and has been translated with @9len’s permission for posting to this blog in Japanese. この記事は2014年3月に書いている。Twitterでユーザ検索チームを私が率いていたころの話だ。この記事は、コードレビューに関するセオリー・アプローチを体系化することを狙いとしていて、いくつかの基的なプラクティスの確立を狙っている。あな

  • ソフトウェアのプロとしての態度 - ちなみに

    Clean Coder プロフェッショナルプログラマへの道 作者: Robert C. Martin,角征典出版社/メーカー: アスキー・メディアワークス発売日: 2012/01/27メディア: 大型購入: 12人 クリック: 645回この商品を含むブログ (36件) を見る Clean Coder を読みました。 日語版は2012年発売で、去年2014年の誕生日に頂いたものだったのですが、やっとこさ読み終わりました。 貰ってすぐに前半を読んでいたのですが、途中で止まってしまっていて、今期の目標を技術書を読むことに設定したのを機に、通勤時間に少しずつ読み進めて2ヶ月くらいで読みました。 さらに読み終わってから1ヶ月ほど経過していて、とにかく怠惰。 ボブおじさんことRobert C Martinの著書で、ソフトウェアのプロとしての考え方や振る舞いについて、豊富な実体験を元に解説されている

    ソフトウェアのプロとしての態度 - ちなみに
  • [翻訳]プログラマの生産性の壊し方 - Qiita

    George Stockerの「How to destroy Programmer Productivity」の翻訳です(Georgeさんには報告済み)。 間違いがございましたら、ご指摘お願いします。 プログラマの生産性に関する次の画像は、インターネット中を徘徊しています。 ザ・シンプソンズが出てきそうだけれども、「真実だから面白い」。 私は、今まで生産的になる秘密について解明してきませんでした。それは、主には、私が一貫して生産的ではなかったからです。Joel on Softwareのジョエル・スポルスキは、ブログの記事でこのことについて話しています: 時々私は何も終わらせることができなくなります 確かに、私はオフィスに入って、10秒ごとにe-mailをチェックして、ウェブを読んで、アメリカン·エキスプレスでの支払いのようないくつかの頭を使わないタスクを処理します。しかし、コードを書くフロ

    [翻訳]プログラマの生産性の壊し方 - Qiita
  • プログラマが独立・起業する時によくするミスと対策 まとめ - Qiita

    自分がプログラマから起業して沢山失敗したので、同じミスをプログラマ、エンジニアの方にして欲しくないという想いから、よくある失敗をまとめました。(常に追加中) プログラマでなくても、フリーランス起業する方に役立つでしょう。 特に技術分野の経験だけしかない人は、気をつけましょう。 技術以外の大量の会社関連の知識、実行能力、実行する時間、経験が必要になります。 従業員との最も大きな違いはリスクかと思います。 従業員は金銭的なマイナスリスクは非常に少ないですが、フリーランスや取締役は数百万円以上のリスク負うことが非常に多いので、リスクヘッジをするための知識と経験が(嫌でも)多く必要になります。 技術も持っているのでプロダクトを作りたい方も多いと思いますが、会社の場合プロダクトを作るだけではなく、市場で勝てるプロダクトを作る会社組織も同時に作らなくてはなりません。どのような人材をどの順番でどのよう

    プログラマが独立・起業する時によくするミスと対策 まとめ - Qiita
  • Gitを使ったデザイナーとプログラマの協業について話してきた #P4D #phpcon2013 - 納豆には卵を入れる派です。

    常連プログラマがほぼ Rubyist しかいないP4Dなのですが、なぜかPHPカンファレンスで枠をいただいたとのことで、デザイナーとGitについて話し合ってみようという企画に参加してきました。 「生煮えぷるり」をプログラマとデザイナーの間で行ったり来たりさせる話 Pull Request 4 Designers - GitHubを使ったプログラマとデザイナーのイテレーティブな開発フロー// Speaker Deck GitHubを使った、実際のプログラマとデザイナーの協業の様子を見てもらおうということで、私がお手伝いさせていただいている、[https://forkwell.com:title=Forkwell] と [https://jobs.forkwell.com:title=Forkwell Jobs] での開発の様子を例にお話させていただきました。 補足とか 「生煮えぷるり」という

    Gitを使ったデザイナーとプログラマの協業について話してきた #P4D #phpcon2013 - 納豆には卵を入れる派です。
  • 俺の考えるプログラマー35歳定年説 - komagataのブログ

    おはようございます。高熱を出したまま35歳、アスキーコードで言えば#歳になりましたkomagataです。 間違えてて去年書くはずだったプログラマー35歳定年説について。(その来年がきたよ~、見てる〜? > 俺) パッピーバースデートゥーミーフロム俺 - komagata 「フィジカル、メンタルで衰えてくる」とか「マネジメントへの参加要求が強まり自然にプログラミングから遠ざかる」とか「求められる成果の総量が上昇するのでしかたなく」という面も確かにあると思います。 しかし、 「平均的なキャリアプランなんぞ知ったことか。こっちは大手町辺りに派遣されてスーツで一生デスマ案件でJavaを書き続ける覚悟は完了してるんだよ!」 という我々にとっては関係ありません。にも関わらず我々が長文を書いてしまうのはなぜでしょう? それは「誰も見てなくても関係ない」「真理鉱山に篭って一生続けられる」はずのプログラミン

  • プログラマーは皆、常に秘密や嘘を抱えている - totopon114689の日記

    プログラマーは皆、常に秘密や嘘を抱えている。 これは間違いない。 基的には誰にも話さないが、 (家族や友人などプログラムを知っていない人間に話しても分からない、という事もある) プログラマー同士の飲みの席などで、過去の笑い話として酒の肴になる事はある。 秘密や嘘の傾向には幾つかのパターンがある。 1) 仕様があいまいな場合の適当なコーディング 仕様があいまいな機能を実装する場合、想定していたものよりもプログラム量が膨大になる事はよくある。 また、細かいパターンや想定外のケースに対し、どのようにプログラム的対処を行うべきか? 洗い出しているとキリがない場合もある。 仮に事前に洗い出していたとしても、 「ケース自体は洗い出せているが、具体的にどのようなエラーメッセージを表示すべきか?」 などといった、その先がまたあいまいになっている場合もある。 このような場合、来であれば決裁権のある人間に

    プログラマーは皆、常に秘密や嘘を抱えている - totopon114689の日記
  • 同僚の外国人プログラマ観察記録 - rinu's blog

    概要 1ヶ月くらい一緒にお仕事している外国人プログラマさんを観察した記録です。 スペック 性別: 男性 仕事内容: うちの会社のプログラマは、ざっくり JS 等のフロントエンドと、 Java 等のバックエンドエンジニアにわかれているのですが、彼はどちらもやっているようです。 好きなべ物: はちみつ たまに、くまさんのようにはちみつを舐めていました。 性格 彼はめんどくさがり屋です。 同僚の Windows ユーザの手伝いをしている時、 "C:¥Program Files¥..." みたいなパスを打ちながら、「めんどくさい。 ああ めんどくさい」 と 100回くらいつぶやいていました。 (普段の彼の環境は mac なので /usr/local/bin) パスワードを覚えるのもめんどくさいので 1Password で管理しているようです。 PC スペック マシン: Macbook Pro メ

    同僚の外国人プログラマ観察記録 - rinu's blog
  • Loading...

  • プログラマと付き合う

    サービス終了のお知らせ いつもYahoo! JAPANのサービスをご利用いただき誠にありがとうございます。 お客様がアクセスされたサービスは日までにサービスを終了いたしました。 今後ともYahoo! JAPANのサービスをご愛顧くださいますよう、よろしくお願いいたします。

  • 1