ITエンジニアの業務時間外の学習 - 勘と経験と読経
時間外学習に関するブログ記事をタイムラインで目にして考えたこと。ちなみに業務時間外に学習するかどうかは趣味の問題だと思っている。 業務時間外で勉強をしなければいけない理由：101回死んだエンジニア：エンジニアライフ 業務時間外の勉強が必須なんてことはない IT業界は技術の流れに置いていかれるとしんどい思いをする。業務時間外の勉強は必須だ。しかし、おかしな話ではないだろうか。なんで時間外に仕事のための技術を勉強しなければならないのだろうか。 本来であれば、業務に必要なことは業務時間内で教えるべきだと思う。だが、今時そんな余裕のある会社なんて無い。やって当然という雰囲気はあるが、やるだけの理由を説明できる人は少ない。大半が「仕事に必要だからやるんだよ！」としか言わない。 業務時間外で勉強をしなければいけない理由：101回死んだエンジニア：エンジニアライフ 業務時間外の勉強が必須なんてことはない
業務時間外で勉強をしなければいけない理由：101回死んだエンジニア：エンジニアライフ
いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。 ▪️業務時間外の勉強を新人にどう説明しているか IT業界は技術の流れに置いていかれるとしんどい思いをする。業務時間外の勉強は必須だ。しかし、おかしな話ではないだろうか。なんで時間外に仕事のための技術を勉強しなければならないのだろうか。 本来であれば、業務に必要なことは業務時間内で教えるべきだと思う。だが、今時そんな余裕のある会社なんて無い。やって当然という雰囲気はあるが、やるだけの理由を説明できる人は少ない。大半が「仕事に必要だからやるんだよ！」としか言わない。 IT系に勤めているからそれが当然だと思うかもしれない。だが、「仕事で必要だから」では理由が弱い。しんどい仕事をした後に、更に勉強というのはなかなかしんどい。相応の理由でも無い限り、モチベーションは保てない。
「学習コスト」という言葉について、自分の感じ方が変わってたなど - アナログ金木犀
ある日、TwitterのTLがある勉強会の内容で埋まった。 自分はその勉強会には出ていなかったのだけれど、隙をみては追っていた。 その中でちらほら「学習コスト」というキーワードが目に入った。 「学習コストが高すぎて導入できない」 その通りなんだろうなと思う。 ただ、なんだろう、違和感を感じた。 その方たちが言ってることに対する違和感じゃなく、自分の中に閉じた違和感のようなもの。 少し考えてみるとすぐに気づいた。 自分は「学習コスト」って言葉に対する現実が薄くなっている。 「なっている」と書いているのは、少し前までは明確に自分がリアルに感じて持っていたもので、よく使っていた言葉でもあったからだ。 どうして僕は「学習コスト」という言葉にリアルを感じなくなってしまっているんだろう。 原因 実は原因は明確だった。 一つしか思いつかない。僕に起こった変化はただ一つ。 転職 だ。 転職前はとあるスター
プログラミングの「抽象化」ってどういう意味で、なぜ必要なのか - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
＜追記＞いろいろ反応あってたしかになーって思いましたが、ここで説明されてるのは「汎化」とか「パラメタライズ」としたほうが正しいですね。抽象化というと、一塊の手続きをブラックボックスにして、実装を隠蔽する面のほうが正解に近いです。でもまあそこを差し引いて読んでいただければ、それなりに有用ではある記事だと思うので、このまま残しておきます＜/追記＞ プログラミングに限らない話かもしれませんが、ふだんの生活で触れないような概念というのは、一度わかってしまえば便利なんだけど、どうしてもとらえどころがない、というようなことが多いと思います。プログラミングにもそういう概念はたくさんあって、わたしのような凡人は新しい概念にぶち当たるたびに苦労しています。今日はそんな中で「抽象化」という言葉について、「昔の自分にこうやって説明してあげたかったな〜」という説明をします。 プログラミングを学んでいく中で、「とり
意識を低くするという成長戦略 - ジーズアカデミー戦記
2015-08-03 意識を低くするという成長戦略 自分語り Tweet ＊『エンジニアとしてコモディティ化しないよう一生勉強してサバイブします！』 IT系エンジニアによる勇ましい態度が苦手だ。曰く「近い将来エンジニアはコモディティ化する」「10年後に生き残るためには必死で勉強しなければならない」「一生コードを書いていたい…」、強い言葉で自身を奮い立たせている分には構わないが、その意識の高さが他人への攻撃へ転化されるとやっかいだ。かつてのSIer ディス、技術力が高くないエンジニアを無能だなどと強い口調で否定するのには辟易したものだ。 最近は攻撃的な物言いはいくぶん落ち着いたように思うが、それでも意識の高い言説は以前にもまして盛り上がっているように見える。エンジニア系メディアには毎日のようにTech企業のCTOや海外で活躍する日本人なんかが立ちかわり登場し、これから学ぶべき技術領域、考える
なぜJava以外のプログラミング言語でAndroidアプリを作ろうとするのか - Shoichi Matsuda's diary
こにふぁーさんのツイッターでこんな発言を発見しました。 AndroidをGoやRubyやHaskellやKotlinで書いたよって話、どうしたらそういう情熱がわき上がるのかわからないし本当すごいと思う— こにふぁーあぁぁん？ (@konifar) 2015, 7月 24 自分もたまに「Java以外のプログラミング言語でAndroidアプリを作る」ということをするクチです。 （Androidに限らずいろんな環境でいろんな言語を使おうしますね。） 具体的には、最近だとKotlinで瞬間タイマーというアプリを作ったりしてます。 なぜ自分が他の言語で書こうとするのかを今ぱっと思いついた範囲でまとめてみます。 新しい言語を学ぶ機会として"ついでに"アプリを作っている 真っ先に思いついたのはこちらです。 一番の目的は「新しい言語を学ぶこと」で、その手段として「アプリ(などなど)を作りきってみる」という
エンジニアからみた良いプロダクトマネージャとは？ - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
エンジニアからみた良いプロダクトマネージャ（以下PM）とは。rebuildfm #98で id:naoya さん(@naoya_ito)から PM についての話があったので便乗して書いてみる。※プロダクト（製品）マネージャはプロジェクトマネージャとは全然違う職種なので注意。 結論から先に。エンジニアから見た良い PM とは「つねにユーザーのことを考えた上でプロダクトに信念を持っている人」だと思う。それは当たり前じゃないか？と思った人は正しい。でも常にそれをできる PM は多くはない。幸いにも僕は多くの優秀な PM と仕事をさせてもらったのでそこから学んだことをまとめてみよう。 PM の役割 まずは PM の役割から見ていこう。スタートアップの CEO の役割からエンジニア、デザイナーをマイナスした感じと言ったら伝わるだろうか。 もう少し具体的に PM がやっていることを挙げてみよう。 自分
元Google社員、社内での給与額の公開運動について語る
Ex-Googler says she exposed company-wide pay inequality with crowdsourced spreadsheet | Fusion EricaJoy on Twitter: "a thing bothered me yesterday and it's still bothering me today and so now i want to tell a story." 元Google社員で今はSlack社員の黒人の女であるErica Bakerが、Googleが公民権運動で有名なIda B. Wellsを取り上げたことをきっかけに、Google社内に蔓延する差別について語っている。 昔不満であることは、今もってなお不満である。そこで、ひとつ話をしようと思う。 ある日曜日、元同僚の何人かと私は退屈で、給料について社内SNSで話して
目標は「小さく」「たくさん」設定しよう | サイボウズ式
【サイボウズ式編集部より】この「ブロガーズ・コラム」は、サイボウズの外部から招いたブロガーに、チームワークに関するコラムを執筆いただいています。今回ははせおやさいさんが考える「正しい目標設定の仕方」について。 こんにちは、はせ おやさいです。 今年も約半分が終わりますね。設定した目標の振り返り時期が近づいている人も多いのではないでしょうか。今回は、正しい目標設定とその運用について考えてみたいと思います！ その目標、本当に正しく設定されていますか？ 「目標設定」と聞いて、どんなものを思い浮かべますか？ サボらないよう管理されるもの？ それとも未達を責められるための嫌な基準？ さまざまな粒度の「目標」「目標設定」があると思いますが、本来的な「目標設定」というのは、まず会社が目指す方向と数値があり、それを各部署、各担当者までブレイクダウンした上で、達成のために作成される「ゴールまでの地図」なので
ウェブカツ運営者が語る！WEBサービスで起業したい人に読んで欲しい２０のコト - Qiita
プログラミング学習サービスやら、ペットサロン予約サービス、風俗予約サービスなど色々とやっている「かずきち」です。 ◾️その他Qiita記事 エンジニアで稼ぐために大切な２０のコト ウェブカツ生を雇わない？転職できない？著作権無断使用の炎上から１年を経て思うところをぶっちゃける。 テックキャンプをウェブカツ!! 顧問が徹底レビューしてぶった切ってみた ■運営サービス一部 http://crazy-wp.com/ フリーランスエンジニアを育成するオンライン最大級のプログラミングスクール「ウェブカツ」 http://webukatu.com/ ■プログラミングスクール「ウェブカツ」の出版本 「小学生からでもプログラミングを楽しく学べる漫画作りたいなー」と思い立ち、外注してウェブカツで漫画本を作りました。KADOKAWAさんより出版しています。 はたらくプログラミング 完全版 (コミックエッセイ)
シンプルの心理学 ― 心地良いデザインのために | POSTD
私たちの誰もが理解する”シンプル”という概念の正体を突き止めることは、難しそうに見えますが、実はそうでもありません。 私たちが製品やWebサイトをシンプルと感じるかどうかの背景には、”見れば分かる”ということだけではなく、単なる直観的な反応にとどまらない何かがあります。 Steve Jobs は次のように述べています。 シンプルであることは、複雑であることより難しい場合がある。物事をシンプルにするためには、思考を整理して懸命に考えなくてはならない。しかし、努力する価値はある。ひとたび達成すれば、山をも動かすことができるのだから。 シンプルにものを作ることにそんなに力があるのであれば、なぜ私たちはそうできないのでしょうか。 なぜシンプルであることは、こうも複雑なのでしょうか。 人生における多くの事柄と同じように、シンプルさには表面的に見えている以上の何かがあります。ここでは、私たちの脳が新し
プレゼンの技術
プレゼンテーションのためのプレゼンテーション！ Acroquest社内で行った若手向け勉強会での発表資料です！ Read less
残業とプログラミングの効率について
プログラマーの残業についての質問です。 人月の神話などの教訓もあると思うのですが、どのくらいやるとどのくらい一人のプログラマーのアウトプットが落ちるのかなどのグラフやデータはあるのでしょうか。 コーディングする文字数の低下や、工数などの単位で示されているグラフはあるのでしょうか。 この辺について、自分を実験台にするのは悲しいので、参考に知りたいです。 例えば、ちょっと違いますが睡眠時間はこういうのがありました。 http://laugh-raku.com/wp-content/uploads/2013/05/7ae61a6d2298f57c5a19f9a46b49e7531.png こういうデータや考え方についてなにか知っている人いましたら、教えてください。 よろしくお願いします。
コードレビューのベストプラクティス | POSTD
Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上
エンジニアの「できない」という言葉の裏側 - Konifar's WIP
「ここ、こんな感じにできませんかね？」と言われたエンジニアが、「うーん、それはちょっと厳しいですね。できないです」と返すみたいなやりとりは結構見かけます。 この「できますか？」⇒「できない」というやりとりなんですが、「できない」という言葉にはいくつか裏が考えられます。言葉足らずだっただけでちょっとした調整をすればできるよね、というケースもあるので、「できない」という言葉の裏側をまとめておこうと思います。 先に補足しておくと、「エンジニアの人の言葉が足りなすぎるでしょ」という意見ももちろんあると思います。こういうコミュニケーションは、お互いの信頼度によっても変わってくるので難しいところです。お互いが相手に伝わるように意識すべきだと思うんですが、 エンジニアから「できない」と言われた時にどういう意味で言ってるのか想像しやすくなればいいなという思いで書いておきます。 ちなみに、「（できるけどやり
イタリア人｢日本人は堂々と翻訳アプリで会話してくれ｣
あの佐々岡 @anosasaoka フランスで出会った日本語ぺらっぺらのイタリア人に何で日本語覚えたの？って聞いたら｢俺はイタリアとスペインと英語とフランスと中国語が喋れる。どこの言葉も楽勝に覚えれて俺は天才だと思ってた。だけど日本語に出会って俺のプライドが粉砕した。あんな言語普通に使ってるお前らは化物だよ。｣ あの佐々岡 @anosasaoka ｢よく日本人は英語が喋れなくて申し訳なさそうにするだろう。本当に馬鹿げてる。生まれてひとつの言語だけを覚えそれだけで生活出来る事が他の国から見てどれだけ羨ましいと思ってる。もっと堂々としてくれ。堂々と翻訳アプリ使って会話して来い。日本語しか使えない事にプライドを持って欲しい。｣ あの佐々岡 @anosasaoka ｢申し訳なさそうにしてるから舐められるんだ。攻撃しないって姿勢を出せば誰も攻撃してこないと思ったら大間違いだ。抵抗しないと思ったらどん
情報共有ができないチームの人間関係は破綻する | サイボウズ式
【サイボウズ式編集部より】「ブロガーズ・コラム」は、著名ブロガーをサイボウズの外部から招いて、チームワークに関するコラムを執筆いただいています。今回は日野瑛太郎さんによる「情報共有ができないチームのもろさ」について。 チームで働く場合、情報共有はとても重要です。仮に情報共有を一切しないのだとしたら、それは一人で働いていることとほとんど何も変わりません。チームで情報が共有されることではじめて、他人を手伝ったり意見を言ったりすることができるようになります。情報共有はチームワークの基本中の基本だと言ってもよいでしょう。 しかし、そんな基本中の基本であるはずの情報共有が、あまりうまくできていないというチームを結構よく見かけます。人数が少ないうちはある程度うまくまわっていても、チームの人数が増えるにつれて情報共有がいい加減になってしまうということも少なくありません。 僕がまだ会社員をしていたころに一
2年以上勉強会の運営をしてて - 水まんじゅう2
工夫しようは使う必要がない。工夫したなら、使ってもいいッ！ ※このエントリはどこかの組織を代表して言うものではありません。個人的な意見なのでご注意ください。 忙しい人のために3行で。 東京ではドタキャンが3割ぐらいいる。リマインダすることでドタキャン率は明確に変化する。 ドタキャンしなければいけない側にもそれなりの理由があると思うのでdisるのはやめよう。 有償の勉強会はどんな理由があろうとも勉強会という形式ではやらない方がよいです。 日本Javaユーザーグループで活動をはじめて2年がたちました 日本Javaユーザーグループ(以下JJUG)の幹事をやっています。月一回ナイトセミナーという形で勉強会を運営しています。 なんだかんだで勉強会運営の元締めみたいな感じになっていてノウハウがたまってるので共有します。 通常の勉強会について 勉強会は大体無償の形でやってます。たいていOracleさんの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
笑われるプレゼン
bwin·必赢(中国)唯一官方网站