「コード書いてる人って話しかけても無視するよね」と言われるけど悪気はないらしい
俺はGAFA@年収3000万(目標) @GafaOreha @nazomizusouti @s_takv 完全に同意です。 私は非エンジニアの方に説明するときは「囲碁とか将棋で先の先をひたすら読んでる最中に話しかけられるのと同じ感覚なんです。」というとスンナリ納得してもらえます。 2020-04-29 04:18:06 けい@ソフトウェアで応援 @benri_tools @nazomizusouti はじめまして。 全くおっしゃる通りです。 それと30秒しかたっていないと思って戻ってみると、何分も経過していたなんてこともあります。 あと聞こえていないこともあります。 全く悪気はないのです。 2020-04-28 23:35:34
システムの作り逃げはなぜ起こるのか - novtanの日常
流石にイラッとしたので殴り書いておこう。 xtech.nikkei.com あのね、こういうのって発注側に責任があることがほとんどですよ。「要件を満たすクソコード」を生むのは発注側ですよ。早く安く＝クソコードリスク極大なんですよ。をーたーほーるで設計をちゃんと検収するとかすればよかったんじゃないですかね？あるいは、「正しい見積を出してきたベンダーに任せる」のですよ。それを判断できない？じゃあ、高いITベンダーに「食い物にされている」と思わずに依存してください（その方が絶対品質上がるので。金はかかるけど）。 あくまで筆者の経験を基にした主観的な見解だが、「作り逃げ」は「なんちゃってアジャイル」（雑に手早く構築することがアジャイル開発だと勘違いしている）なベンダーやエンジニアに目立つ。 この話も、現象として捉えると確かにそのとおりだと思うけど、これ絶対ろくなRFPを振り出してないし、コンペにな
顧客のBurning needsを解決する
こんにちは、@chikathreesixです。エンジニア起業家としてAutifyというAIを用いたソフトウェアテストの自動化製品を開発するスタートアップのCEOをやっています。 この記事では、BtoBスタートアップがProduct Market Fitするために必須である「顧客のBurning needsを解決する」ことについて、アメリカのアクセラレーターAlchemist Acceleratorにて学んだ経験を元に書きました。 僕らがどのように顧客のBurning needsを見つけ、Autifyという製品にたどり着いたのか、その過程と失敗について共有することで、エンジニア起業家やBtoB SaaS起業家の方々の参考となれば幸いです。 ※BtoCには当てはまらないケースもあるかもしれませんが、僕はBtoCの事は全くわからないのでご容赦ください。 弊社は2019年の1月にアメリカのトップス
【Google re:Work】マネジメントで悩むすべてのエンジニアが見るべき完全無料テキスト | DevelopersIO
エンジニアにとって、正解が分かりづらいマネジメント業務ってとっつきづらいんですが、その良き羅針盤となってくれるテキスト「re:Work」の紹介です。 「エンジニア天国な会社にしたい。したくない？」 「したい。けど、どうやって？わっしょい的な雰囲気で？」 今年の6月あたり、クラスメソッドAWS事業本部コンサル部で合宿を予定しているんですが、その合宿でやるネタを考えているときに知ったのが、この「Google re:Work」。 正解が見えづらい組織運営において、「良いチームとはなにか？」「採用で気をつけるべき点」「ビジョンがもたらす効果」など、マネジメントの頻出課題をギュッと凝縮して詰め込んだこのコンテンツがむっちゃ有用だったので、紹介します。 Webコンテンツとして完全無料なので、今マネジメントで悩んでいる人も、これからマネージャー目指そうとしている人にも参考になる点多いと思うので、一度気軽
底辺IT企業は『書けない』プログラマとどう向き合ってきたか - megamouthの葬列
新年から夢のない話で申し訳ないのだが、表題のとおりのテーマである。 note.mu という記事があって、むやみに長いので飛ばし飛ばし読んだ。 大意としては、世の中には「書けない」プログラマというのがいて（元エントリでは学生さんのようである。さもありなん）そういう人はどうやったって書けるようにならないんだから、諦めろ、という話のようである。 で、じっと手を見て、下請け底辺のIT企業にいる私たちは、このような人々をどうしてきたろうか、と考えると、「放ったらかし」にしたなあ、と思うのである。 最初のほうは優しく教えていたと思う。話したりハンズオンしている時に、あっこの子、変数のことわかってないな、と感じたら、ホワイトボードを持ち出してきて、例の"x"と書いた箱の絵に矢印を引いて、値が入っている図を書いて、「わかった？」「あ、はい」みたいなやり取りをして終わり、という程度の「教育」である。 だが、
値付けできないエンジニアは搾取される｜門屋 亮
もう20年以上前になりますが、わたしの就職して初めての仕事はAccessで動く簡単なプログラムを書くことでした。Accessってもう知らない人もいると思いますが Excel がもうちょっと高機能になったようなものです。わたしはそのプログラムを２週間くらいで書き上げて、上司にこれいくらで売るんですかと尋ねました。上司は100万だと答えました。わたしは素人みたいな新人が作ったプログラムがそんな値段で売れるということにびっくりしましたし、そもそもアクセスで作ったただのファイルを売っていいということも知りませんでした。なんてボロい商売だと思いました。 わたしが当時務めていたのはシステムを開発して納品する会社でした。システムの開発では、作る前にお客様にだいたいいくらかかりますよという見積もりを出します。金額を納得していただけるように、その根拠としてこの機能に何日くらいの作業が必要ですと、細かくタスク
フロントエンドエンジニアから、デザイナーさんに意識してほしい10のこと｜Pittan｜note
フロントエンドエンジニアとデザイナーさんは日々協力してプロダクトを作っていく関係にあります。デザイナーさんが作ってくれたものをエンジニアが素早く実現できるよう、いくつかエンジニアから意識してほしいことをまとめました。 なんでこんな話になったのか（前置きなので次の章まで飛ばしてOKです） デザイナーさんから「この画面をこんな風に作ってください」とXDやSketch、PSDなどいろいろな形で渡されることがあると思います。 僕の個人的な意見・経験ですが、いざ実装するぞとなったときに 「あれ…ここってどうしたらいいんだろう？」 と迷って作業のスピードが落ちてしまうことがとてもストレスに感じていました。できればノンストップでいきたいなあと思うわけです。 手が止まるたび、デザイナーさんに「ここってどうしたらいいですか？」と質問するのが何か新しい画面を作るときに必ず発生していました。 「（いつも聞いてる
ジュニアを採用しない連中はシニアに値しない - portal shit!
Twitter で DHH が共有していた記事が面白かったので著者の許可を得て翻訳します。 "If you don't hire juniors, you don't deserve seniors", spot on! We've had phenomenal success hiring junior developers at Basecamp. @jasonfried first tech hire was particularly junior at the time 😂https://t.co/QczMtsou4J — DHH (@dhh) September 21, 2018 ジュニアを採用しない連中はシニアに値しない、というもの。 If you don't hire juniors, you don't deserve seniors (2023) • Isaac Lym
先進的プログラマが微妙技術を勧めるという吐き気を催す邪悪 - フロイドの狂気日記
はてブで時折ホッテントリする技術系スライドなりトピックがある。 僕はいつも職業柄それを見るが「何だこの技術」というのも少なくない。 ディファクトスタンダードになっている技術の紹介なら参考になる。だがほんとに聞いたこともない技術でアプリを作りましたみたいなことが度々散見される。 2-3年前からAngular 2.X以降を勉強している人は今でも幸いであるが、もしBackborn.jsをpushする記事に目を止めて、一生懸命勉強していたとしたら今は別のスキルを勉強していることだろう。 2-3年前は勢力を2分する勢いだったgulpやgrantも今や先端技術とは言えない。今はwebpackがそれらに取って代わったらしい。 このようにたった2年で使っている技術が微妙になることはよくある やはり4-5年前はLaravelとPhalconというPHPフレームワークが話題になったが、Phalconの方はもは
凄腕エンジニアの「錯覚資産」の使い方 - ゆとりずむ
こんにちは、らくからちゃです。 プーアール茶を片手にのんびり仕事をしていることが多いんですけど、中国茶はお湯を注いで最初の一杯目は捨て、いわば二番煎じから頂くんのが美味しいんだそうな。なんでも最初の一杯で茶葉を開かせ、コップを温めておくことが目的だそうなんですけど、物事によっては二番煎じ、三番煎じのほうが丁度よいくらいの頃合いになるものもあるでしょう。 人によっては「もう何杯目やねん」と思われるひとも居るかと思いませんが、ここ最近話題の「エンジニアはプライベートの時間でも勉強をすべきか」問題について、個人的に考えたことを整理しておきたいと思います。 axia.co.jp まずは結論を申し上げますと「プライベートでも勉強するかどうかより、業務時間中に上手に勉強時間を確保できるかどうかが重要なんじゃないの」と思うんですね。 つーか、エンジニアなら ・上司の目を盗んで ・上司を上手に騙して ・上
エンジニアを育てる環境と、コミュニティのありかたについて - blog.8-p.info
エンジニアを育てるはなしが、たぶん以下の Takuto Kihira さんの tweet をきっかけに盛り上がっていた。 昨日の飲みで、某CTOが「エンジニアを育てるって言うけど、紀平さん誰かに育てられました？自分で育ったでしょ？だからエンジニアに対しては、頑張れ、としか言いようがないと思うんですよね」って話をしていて、まあ確かにそうだと思った。自分はしかし親に環境を用意してもらったな。本とかPCとか。 私の立場は、Dai MIKURUBE さんの tweet に近い。 エンジニアの成長について「自分は自力で育った」「今まで見てきた人は誰かに育てられたというより自力で育ってきてた」は観察としてたぶん真なんだけど、「だからこれからもそれでいい」は明確に偽だと思うんだよなー。それって各種の職人業が次々廃れてるのと同じことを再現するだけのような気がする 私自身も大学で情報工学を学ぶまえに多少はプ
身に着けた技術をいかに捨てられるか。エンジニア歴39年、今でもエンジニアで居続ける理由。
サイバーエージェントのゲーム・エンターテイメント事業に携わる10社以上の子会社が所属する事業部SGE（Smartphone Games & Entertainment）では、さまざまなメンバーが活躍しています。 初めてプログラミングに触れたのは39年前。新しい技術がどんどん出てくる環境は、新しいことが好きな自分には合っていると語る平松。現在は、特定のプロジェクトには所属せず、事業部横断でネイティブアプリの品質チェックやパフォーマンス改善を担当。事業部にいなくてはならない存在となっている。そんな平松の今までのキャリアとこれからどんなことをしていきたいのかをききました。 初めてプログラムに触れたのは1979年 エンジニアをはじめたきっかけを教えてください。 高校の進路をどうしようかと考えている時に、ちょうど地元の高校で、日本で2番目に情報処理科が開設されました。元々、新しいものが好きだったので
不健康エンジニアが3ヶ月だけ食事に気をつけたら心も体も健康になれた話 - paiza times
Photo by Marco Verch 長田です。 エンジニアの皆さん、健康に気を使っていますか？ 先日オライリーからヘルシープログラマーという書籍が出て話題になりましたが、ITエンジニアのなかには朝遅く夜も遅い、腰痛い、肩凝った、目が疲れた、残業しんどいなど、不健康な人も多い印象があります。 ヘルシープログラマ ―プログラミングを楽しく続けるための健康Hack 作者:Joe KutnerオライリージャパンAmazon 私ももともと超不健康な生活を送っていたのですが、一転してここ3ヶ月で社内のみんなから「健康エンジニア」と呼ばれるようになってきました。 今では「エンジニアが健康を意識しないのはもったいない」と思っています。なぜなら「健康こそが開発の生産性を向上させるのに最も重要な要因」だからです。力こそパワー、健康こそヘルシー。 というわけで今回は、私がなぜそんなに健康を意識するようにな
エンジニアは業務時間外でも勉強するべきなのか | 株式会社アクシア
エンジニアがスキルアップするための勉強を業務時間外でもするべきかどうかについて、「教育してエンジニアを育てるのは企業側の責任だ」「エンジニアであればスキルアップのために当然自分で勉強すべきだ」といったような議論を度々見かけます。 この問題についてはどちらが正解というわけでもないかもしれませんし、企業やエンジニアのポリシーによるところも大きいかもしれません。 いずれにしても今後うちの会社の求人に応募してきてくれる方に向けて、企業として、または会社トップとしての私の考えを明確にしておくことはやっておいた方が良いなと思いましたので、この記事に私の考えをまとめてみたいと思います。 プライベートで勉強しなくても何とかなります 仕事をこなしていくという観点から言えばプライベートでの勉強を一切やらなくても何とかなります。たとえ未経験で入社してきた人であってもそれくらいの教育は行っています。 でも最初にこ
Web サービス開発に必要な技能について - ボクココ
ども、@kimihom です。 先日とある雑誌の記者さんから取材を受けて、自分のスキルについて色々と聞かれた。私自身は何かに特化したスペシャリストというよりも、あらゆることが一人でできるジェネラリストの部類である。前回の記事では web サービスのアイディアについて必要なことを書いたが、今回はそのアイディアを実現するためのジェネラリストとして必要な技能について紹介する。 www.bokukoko.info 俗にいう"有名エンジニア"の方々は何かの技術に特化したスペシャリストである場合が多いので下記の事項には当てはまらない。あくまでこれは1人のエンジニアとしての参考情報にすぎないことに注意していただきたい。 一人でサービスを作りきる能力を磨く 何かに特化したスペシャリストの人が、 CSS でデザインを整えたりすることとサーバーの負荷監視などをすることを同時に行うことは困難だ。だけども、ジェネ
不思議の国のSE用語 - Qiita
不思議の国 SEが住んでいるところ、そこは不思議な不思議なお国柄です。 新たな国民として移住してきた人、特産物のシステムを買いに来た人など色々な人がこの国には存在します。 しかしこの国で話される言葉は 独特 です。 ぱっと聞いただけでは意味がわからなかったり、よく似た表現であっても微妙にニュアンスが違っていたり。 似たような表現を使い分けるその裏に、その人の意図や省略された文脈が隠されていたりもします。 どこの国でもコミュニケーションを間違うと非常に厄介ですが、そんなことにならぬよう、 お国言葉らしきもの をまとめてみました。 SEを代表例として、このお国言葉を話す人も、話される人も、改めて言葉の意味合いを見つめなおしてみると新たな気付きが得られるかもしれません。 なお、そんなことから 「絶対にSEしか使わない用語」を集めたわけではない のでその点ご了承くださいませ。 他言語版 @micr
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアのための情報設計入門
【パソナキャリア】転職エージェントが支援する求人・転職サイト
焼きそば - hiroki-uemuraのブログ
エンジニアからデザイナーに向けて、デザインカンプを作るときにしておいて欲しいこと。
