ITエンジニアの開発トレンドやキャリア情報・技術勉強会のレポート記事を紹介するメディアです。| 株式会社grooves 運営
![ITエンジニア向けのトレンド情報 | Forkwell Press (フォークウェルプレス)](https://cdn-ak-scissors.b.st-hatena.com/image/square/c3156253c25f63328d7dfaf11079aff89ddb8627/height=288;version=1;width=512/https%3A%2F%2Fpr.forkwell.com%2Fwp-content%2Fuploads%2F2022%2F05%2F0525_Fwpr.png)
新年から夢のない話で申し訳ないのだが、表題のとおりのテーマである。 note.mu という記事があって、むやみに長いので飛ばし飛ばし読んだ。 大意としては、世の中には「書けない」プログラマというのがいて(元エントリでは学生さんのようである。さもありなん)そういう人はどうやったって書けるようにならないんだから、諦めろ、という話のようである。 で、じっと手を見て、下請け底辺のIT企業にいる私たちは、このような人々をどうしてきたろうか、と考えると、「放ったらかし」にしたなあ、と思うのである。 最初のほうは優しく教えていたと思う。話したりハンズオンしている時に、あっこの子、変数のことわかってないな、と感じたら、ホワイトボードを持ち出してきて、例の"x"と書いた箱の絵に矢印を引いて、値が入っている図を書いて、「わかった?」「あ、はい」みたいなやり取りをして終わり、という程度の「教育」である。 だが、
アプリ開発等で有名なフェンリル社にお招きいただき、「エンジニアという仕事を楽しみ続けるためのキャリア戦略」というテーマで講演させていただきました。フェンリルさんに許可をいただいたので、その講演内でつかった約60ページのスライド資料を全ページ公開します。 エンジニアを楽しみ「続ける」というところがポイントで、世の中の変化も激しいし自分も飽きたり慣れたり状況や心境が変わったりする中でどうやって楽しみ「続ける」よう工夫しているのか、というのを実体験を多く交えつつ話しています。 エンジニア、昔は楽しかったんだけど最近はどうも惰性でやってるかも、とか、若くて優秀な人にはもうかなわないなぁ、という感じの方々には共感していただける部分があるかもしれないのでぜひ見てみてください。
~~ 2018/6/26 22:33 更新 ~~ 500以上のいいね、また読んでくださった皆さまありがとうございました!!! この記事はMatz氏の講演を聴き、何か感じたところを中心にメモしてます。 (特に後半は疲れてメモしてないとこも多く。。) 参考になる箇所は人それぞれ異なると思います。 ↓のリンクからまだ見れるようなので、約2時間の長い動画となりますがお時間のある方はぜひご覧になってください(^ ^) \生配信中!/ 【まつもとゆきひろ氏 特別講演】 若手エンジニアの生存戦略 #エンジニア生存戦略 https://t.co/Taf9eQ9k73 — サトアズ(佐藤アズサ) (@satoazu_sp) 2018年6月23日 ~~ 2018/6/25 22:21 更新 ~~ 200以上のいいね、ありがとうございました!!! 200いいね! | 【まつもとゆきひろ氏 特別講演】若手エンジニ
フロントエンドエンジニア / バックエンドエンジニア / DevOpsエンジニア@poly_soft 先日2018年の最先端フロントエンドエンジニアになろうという記事を訳したのですが、そのリポジトリにはバックエンドとDevOpsのロードマップ画像も置いてあります。 しかしバックエンドのテキストにはTODOの1行だけで、動きがありませんでした。 解説が追加されないかなー、と思ってたら別の人がやってたのを見付けました。 ということで以下はModern Backend Developer in 2018の日本語訳です。 Modern Backend Developer in 2018 こんにちのWeb開発の様相は、数年前とは全く別物です。 Web開発には多すぎる選択肢があって何をすればいいのか迷います。 それが、これらのステップを視覚的に表し、段階的にWeb開発を行っていくためのガイドラインを作
〜〜が知っておくべきサイト20選とか、エンジニアなら今すぐフォローすべき有名人とか、いつも釣られてみにいくと全く興味なかったり拍子抜けしたりするわけだが、こういうのが並んでいたらあまりの格の違いに絶望してしまうだろうというものを適当に並べてみた。私が見ているわけではなくて、こうありたいと思っている私の願望である。どちらかというとインフラ系とか基盤系のものに偏っているが、あくまで私が興味ある一連の例だと思ってください。「これが入ってない!」というクレームは受け付けますので、是非教えてください。一緒に成層圏まで意識を高めましょう。 情報サイト、有名ブログ Software Engineering Radio : IEEEが主催しているソフトウェアエンジニア向けのPodCast。データベースからフロントエンド、暗号、ハードウェア、マイクロサービス、などなどとにかく多様なジャンルの最新のトピックの
5の「振り返り」は以下の項目を検討しておくと良いです。 Idea:アイデア。コンセプト。テーマ。元ネタ What went right:やってみて良かったこと。うまくいったところ。成功したところ。次回に生かせそうなこと What went wrong:ダメだったところ。うまく機能しなかったところ。問題点。改善すべき点 What I learned:学んだこと。効果的なゲームデザインの方法やツールの使い方、獲得したテクニックなど ちなみに最初にリンクを貼った、作ったゲームの各ページの下の方には、振り返りや作成にかかった時間などを記載しています(以下はノンフィールドRPG「OneWay RPG」を作った時の振り返り) Game A Weekで得たもの ということで「Game A Week」を行った結果、私が得たものです。 ゲームを作りながら技術検証できる ゲームを完成させたときの達成感を繰り返
はじめに 今期より、自分のいる会社で社内報を発行することとなり、 その中で現役エンジニアからリアルな声を収集しています! そのうちのひとつとして掲載したのが「エンジニアが選ぶ良書まとめ」。 今回は、社内だけで公開していた良書の情報をこちらでも備忘録としてまとめておきます。 2017/09/4 追記: 本投稿を公開したことで予想以上に反響があり、良書とは?を改めて考えさせられました。 社内のアンケートでは、新人に読んでほしい本、手元にあると便利だと思う本、という趣旨で 集計したので、「良書」という意味では人それぞれ捉え方が違うのかな、と思いタイトルを変更しました。 ヒアリング対象 エンジニア向けの書籍はたくさんあるものの、技術書をはじめ、どれも比較的高価ですよね・・・。 バージョンupしたら使い物にならない書籍もあるし、学習にはお金も時間もかかる! なので、書籍購入を失敗しないように、要領よ
CEDEC2017「優れたエンジニアが集まり継続的に成長する会社にする方法 ~組織を急拡大させる採用育成評価ガイド~」講演資料です。
若手エンジニアを不幸にしないための開発の「べからず」集を書いてみました。 「若手エンジニアを不幸にしないため」とは書いていますが、若手に限った内容ではありません。 いろんな開発の「べからず」のために不幸になるのは、とりわけ若手が多いということを意識したためだと思ったからです。 ・若手には、方針の決定権がない。 ・若手は、組織の中で道具のように扱われてしまう場合がある。 ・(今の)若手は、将来も働き続けるための力を付けるための組織内での教育が、(昔ほど)なされなくなってきている。 ・コスト意識が乏しいので必要性が乏しいことについてまで残業前提の仕事のスケジュールを組織がたてることが多い。(その分野の理論を知っていれば自明のことを実験で証明することを要求されるのは苦痛である。) 設計指針の「べからず」 何ができれば十分かを明確にしない 開発目標は、何ができれば十分なのかを明確にしないまま、追加
上杉周作シリコンバレーのエンジニアが語る、誰にも悪気はなかった話2017/02/22 貧困の連鎖を止めようとしたら、子どもの学力が下がりました。働き方から変えよう、地方から変えようとしたら、何も変わりませんでした。 自己紹介こんにちは。上杉周作と申します。教育について考えるのが好きな、シリコンバレー在住のエンジニアです。 88年生まれで、中学1年まで日本で暮らし、それからはアメリカ在住です。カーネギーメロン大でコンピュータサイエンスを学び、AppleとFacebookでエンジニアインターンをし、その後シリコンバレーのベンチャーを転々とし、2012年9月よりシリコンバレーの教育ベンチャー・EdSurgeに就職しました。2017年1月にはNHK「クローズアップ現代+」の教育特集に「教育×IT」の専門家としてお呼びいただき、教育評論家の尾木ママさんと共演しました。 そしてこのたび、4年とすこし働
こんにちは、アプリケーションエンジニアのid:shiba_yu36です。今回ははてなで毎週開催している社内技術勉強会で発表した「技術ブログを書くことについて」という発表資料を公開します。 speakerdeck.com 今回の発表をなぜ行ったかというと、もっと気軽に自分のやったことをブログに書くといいのではという考え方を社内に伝えたかったからです。エンジニアをしていると、ブログを書くときは他の人が書いていないことしか書いてはいけない、しかも完璧に書かなければならない、というような気持ちになることもあります。しかし、ブログを書くことで自分の学習をより深め、加速することもできるので、あまり気負いせずにブログを継続して書いて欲しいという思いを発表しました。これがエンジニアのブログに関する正しい考え方と言い張るつもりはなくて、一つのブログに対する考え方として、参考になれば良いなと思います。 発表で
今年、いわゆるデータサイエンティスト的なスキルの後輩が入ってきて、私がメンターの役割を任されました(正確にはメンターになるはずのメンバーが抜けてしまい、早いタイミングで私が引き継ぎました)。 彼は、今時珍しく(?)、数学的な能力と、その手法を実世界に結びつけるセンスを兼ね備えて持っています。 ただし、プログラミングやエンジニアとしてのスキルは、入社時にはあまり持っていませんでした。 せっかくメンターになったので、ナントカっていう分析手法の話を「わかんねえなあ」って思いながら聞いてたり、「こういうこと勉強したらいいんじゃない?」とか唆したり、自分や同期がつらいと思っていたところを取り除いてたりしてました。その甲斐あったのかは分かりませんが、割と楽しんで仕事しているようだし、エンジニアとしてのスキルも順調につけていっています。 そこで、メンターの立場で心がけたことや、スムーズに業務できている要
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く