タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

programmingとProgrammingとworkに関するwindishのブックマーク (6)

  • 失敗したエンジニア組織施策としくじりの反省|nottegra@EM

    前回、成功したエンジニア組織の施策について書きましたが、今回は失敗編です。失敗のほうが多いのでどうしても文量が多いのですがご勘弁下さい。 説明用に前職の関係記事がガンガン出てきますが、貶めたり咎める意図は全くありません。あくまで僕が責任持って実施した施策で失敗したことについてのノウハウ共有と反省についての記事です。 組織施策プレゼン大会 ※元記事がお亡くなりになっているのでWayback Machineより [概要] 組織施策についてチームごとにプレゼン。プレゼン毎に担当役員+組織責任者(僕)が点数評価。点数が一定以上の場合施策実行をその場で採択。 内容は、課題提起→施策内容→実行体制→スケジュール→予算→まとめ。 [導入背景] エンジニア組織の人数が増えて組織硬直が進んでいたこと、全員の目線を合わせる機会があまり無かったことから、メンバーの不満が見えないレベルでたまり続けていました。 メ

    失敗したエンジニア組織施策としくじりの反省|nottegra@EM
    windish
    windish 2020/08/01
    “失敗を認めて施策を止める事や、失敗を分析して公表する事に対して周りがもっと寛大になってくれたら良いなぁ” ですねえ。。
  • 習得したいプログラミング言語、したくない言語 | 日経 xTECH(クロステック)

    ITエンジニアは 数百種類ともいわれるプログラミング言語のなかで、今後どの言語を習得したいと考えているのだろうか。日経 xTECHが実施した「プログラミング言語実態調査」の結果を見ていこう。 ITエンジニアは今後、どんなプログラミング言語を学びたいのか。またもう要らないと感じているプログラミング言語は何か。これらを明らかにするために、日経 xTECHでは「プログラミング言語実態調査 2018」を実施。その結果、ITエンジニアが今後有望視するプログラミング言語が浮かび上がった。 調査では、今後スキルを磨きたいプログラミング言語を複数回答で聞いた。すると、スキルを磨きたい言語の第1位は「Python」だった。回答者1000人中、実に670人がPythonを選んだ。ITエンジニアのおよそ3人に2人がPythonを推す状況だ。 Pythonは最近のAI人工知能)関連のシステムで欠かせないプログラ

    習得したいプログラミング言語、したくない言語 | 日経 xTECH(クロステック)
    windish
    windish 2018/11/16
    途中までしか読めてないが、JSよりPythonが多いのかー。それだけ習得してる人が少ないってことかな。
  • 勉強の仕方がわからない 追記あり その2

    ここ5,6年の悩みで最近はっきりわかってきたんだけど、俺いつのころからかどうやって勉強していいのかわからなくなった。 IT系の仕事だから、新しいソフトウェアとか技術とか勉強してマスターしたいって思っているんだけど、空き時間に勉強してもぜんっぜん頭に入ってこないのよね。 仕事は幸いにもそこまでブラックじゃないのよ。こうやって増田に愚痴ブログかける時間もあるし、残業もたまにあるぐらい。仕事のストレスでどうって話じゃない。 一番大きいのは結婚して子供できて自由な時間が減ったことなんだろうけど、でもそれ以前から勉強ぜんぜんできなくなったの。 参考書とかチュートリアル動画とかに数十万円くらい費やしてきたけど、それの1割も満足に読めてない。 とにかく勉強して何か成長したって実感がここ10年ぜんぜん持ててないから勉強することへのモチベが全然あがらない。 何をしないよりもなんかしたほうがマシだろうとチュー

    勉強の仕方がわからない 追記あり その2
    windish
    windish 2017/11/08
    色々と身につまされる。/ 趣味のゲームにからめて簡単なスクリプトを新しい言語で書いたりしてる。でももっと抽象度が高いレベルでのキャッチアップが遅れがち。
  • VB.netの今後とは?その需要と将来性/エンジニア | アサインナビ マガジン

    windish
    windish 2016/09/09
    懐かしいなVB.NET。VB6からのコンバートコードしか扱えなかった人たちは元気にしてるかなあ。。
  • Google Java Style Guide (非公式和訳)

    Tip: ただ何かのプログラムが非ASCII文字を正しく処理しないという危惧だけでコードを読みにくくしてはならない。もしそのような事が起こる場合はそのプログラムが 壊れている のであってそちらが 修正 されるべきである。 3 ソースファイル構造 ソースファイルの内容は 以下の順序 であること。 1. ライセンスあるいはコピーライトの情報(もしあるならば) 2. package文 3. import文 4. ただ1個のトップレベルクラス。 ソースに書かれている内容それぞれの分離には ただ1行の空行 を使うこと。 3.1 ライセンスあるいはコピーライトの情報(もしあるならば) もしファイルにライセンスあるいはコピーライトの情報があるならばここに入る。 3.2 パッケージ文 パッケージ文は 改行してはならない。 文字数制限(4.4節 文字数制限は100文字 )はパッケージ文には適用されない。 3

  • あるエンジニアの緩慢な死、あるいはエンジニア35歳定年説。 - Qiita

    エンジニア35歳定年説」が許されるのは小学生までだよねーとか思っていたら、実際にはそんな感じになってしまったあるエンジニアの半生を振り返ります。ご参考まで。 第一期 サービスリリース前 自分でサービスをガリガリ作っている というかサービスを作ることしかしていない 1日16時間くらい仕事をしても、プログラミングしかしていないので疲れない 仕様の検討をしながら作るので、基全ての時間は開発をしているという認識 フルスタックエンジニアというある種の全能感を満喫する 第二期 サービスリリース後 運用(ユーザーサポートなども含む)が入ってくるのでサービス開発のスピードが落ちる エンジニアを採用(業務委託含む)する 仕様の調整やコードレビューなど、開発以外の仕事が少しずつ増えてくる でもまだまだ自分が圧倒的にメイン開発者 コードレビューやマージ、リリースは自分が全てやる システムの全体からディテール

    あるエンジニアの緩慢な死、あるいはエンジニア35歳定年説。 - Qiita
    windish
    windish 2016/01/06
    岩田さんの「経営もプログラミングと同じ」という言葉をなぜか思い出した
  • 1