できないエンジニアの特徴 - Qiita
エンジニア単価表の記事はこちら！ はじめに 社会人になってから数年。数々の失敗を目撃 & 体験をしてきました。 その教訓で、改善すればより仕事も人間関係も円滑に進み、エンジニアとしても成長できるだろうなというネガティブな点をまとめてみました。 僕も過去できていなかったり、今もできていないところはありますが、反面教師として伝えられたらと思います。 特徴 1.納期に間に合わない時、自分から報告してこない 明確に期日が共有できているのにも関わらず、直前もしくは遅れる旨を報告してこないパターンです。 責任感がない人に多い気がします。実力不足であったり、実装していくうちにタスクの見積もりがずれることもあるので勇気を持って報告しましょう！ 2.タスク分解しないで、仕事し始める 機能実装のような中規模以上のタスクは、DB変更など下のレイヤーが間違っているとその上位の実装も全て修正しなくてはいけなくなりま
プログラミングスクールの講師を2年間続けて限界が来て辞めた話 - Qiita
はじめに 某プログラミングスクールで二年間講師をしてました。 受講生の方からの評価点は平均より高く、最終的には全インストラクターの中から代表に選ばれる立場にまでなりました。 始めた経緯 もともと、プログラミングスクールをいつか開きたいと思っていたこともあり、業務委託契約で経験が積めそうなところに応募。 即採用していただき、正社員で働く傍、副業としてプログラミング講師に。 エンジニア歴は当時は5年 得意な言語はPHPのみでした。 コロナ禍で全てが変わった 特定を避ける為に細かな時期は記述しませんが、この復業を始めてから今も尚世界を苦しめているウイルスの流行で事が大きく変貌していきました。 というのも、私が請け負っていたプログラミングスクールでは生徒様が作成したいと言う物をベースにプログラミングを教えるスクールでした。 その中で、コロナ禍前までの生徒様達は明確に、 「ECサイトが作りたい」 「
エンジニア200人に聞いて、業務委託単価表を作りました - Qiita
ISSUEへ移動しました 診断機能の結果も元に単価表の精度をアップデートしています。購読してお待ちいただければと思います。 2022年度最新版はこちら こちらの単価表を元に単価診断機能を作りました 様々なご要望を受け、新たに単価診断機能を作成しました！質問形式で現時点での単価目安を診断することができます。改良に改良を重ねていくのでぜひ一度受けてもらえると嬉しいです！ はじめに 私は「ISSUE」という副業プラットフォームを運営しているのですが、プラットフォームを構築する際にエンジニアの方々約200人とお話しました。そのヒアリング内容からエンジニア業務委託単価表を作成してみました。単価はこれから副業やフリーランスとして活動しようという方々がよく悩むところだと思います。私もそうでした。またすでに業務委託をしている方もどのタイミングで単価を上げる交渉をすればいいかとても悩むものだと思います。そん
「あれ、プログラミングが楽しくない…」【すべてのエンジニアへ】 - Qiita
経緯 ストーリー形式で長々と書いているため、結論だけ知りたい人は「僕はここに居てもいいんだ！！！」へどうぞ。 プログラミングが楽しくなくなった日 ある日、Javaの勉強中にふと思った 「これ、なんの役に立つんだ？」 私は、三年間Cをやっていて、PythonとJavaScriptをかじったことがある。 今までに「Twitter神絵師探索」や「トイレットペーパー管理システム」、「クソ雑魚AI付きオセロ」に「ブロック崩し（PICマイコン）」などを作ってきた。 お世辞にもプログラマーと言えるレベルではないが、ちょっとしたミニアプリくらいなら作れる程度だ。 しかし、私の技術不足と人脈不足で「これは誰かに貢献したぞ！」というものはない。 そこで、ひとつの疑問が浮かぶのだ 「あれ？プログラミングしても意味なくない？」 幼い日の僕 私が最初にプログラミングのようなものを始めたのは「部員成績記録Excelシ
エンジニア夫婦が自分たちの結婚式用にプロフィールサイトとウェブアプリを作った話 - Qiita
はじめに 私事ですが今年の6/27に結婚式を挙げました。 私も奥さんもエンジニアなので何か二人らしいおもてなしができないかと思い、よくある席次表プロフィール代わりのプロフィールサイトと披露宴のレクリエーション用にクイズウェブアプリを作成しました。 作ったもの 分担は、奥さん（@tasopi）が主にプロフィールサイトのコーディングとデザイン作成を担当し、私（@danishi）はアプリのフロントエンドとバックエンド、AWSインフラ周りを担当しました。 結婚式の準備の合間を縫って工期は２ヵ月くらい。 実際作ったものの当日の写真が以下です。 席次表に印刷しておいたQRコードから遷移して見てもらうようにしました。 トップページとプロフィール紹介、自分年表のようなページで構成されています。 クイズアプリ（出題側） 予めURLを伝えたスタッフさんに操作してもらうPC用画面で、順番に問題を出題、最後に問題
新人の方によく展開している有益な情報 - Qiita
新人の方によく展開させていただいている有益な情報をまとめておきます。今後も展開することがあるかもしれないため情報をまとめております。 あらたな、有益な情報がありましたら、随時追加してまいります。 有益な記事・論文・書籍等を執筆・紹介していただいた皆様に感謝申し上げます。 ちなみに、本記事に記載されている情報は、お困りごと・お悩みごとをお聞きしたとき・気づいたときに、そのお困りごとに対して参考になりそうなものだけを展開していました。この情報を一気に展開していたわけではございません。 コードリーディングについて [1]ソースコードを読むための技術 https://i.loveruby.net/ja/misc/readingcode.html [2]派生開発推進協議会 関西部会 スペックアウトチーム，「派生開発におけるスペックアウト手法の提案」，派生開発カンファレンス2015，2015 http
「正直９年経ったいまでもfor文ググってる」 - Qiita
「正直９年経ったいまでもfor文ググってる」 という議論記事があった。正直なところ私もググる方の人だ。私の感想: ポンとテキストエディタだけ渡された時に書けるか自信ないぞ...IDEがあればまあ大丈夫かなあ。 JavaScriptだけじゃない。言語色々扱うしという言い訳。正規表現とか毎度調べる。 だから世の中にチートシートというものがあるのだ。お気に入りチートシート多数。 実戦でどうしているか？結局周りのソースを見て馴染む書き方にしていますよ多分。 暗記するかしないかは受験勉強みたいなもので、コーディング面接に受かるなら必要。暗記そのものには意味はないとは思う。 競技プログラミングが使えないとかいう論もあったな。 ググり力も大事。 でも「最低限」もできないのはやはり恥ずかしい気持ちはある。 なんかこれ英語できるできないと似てるな。英語なんてGoogle翻訳、DeepL翻訳あればいいけど、実
技術的なハマりパターンを分類・オサレに命名し、パターン毎に解決策(エンジニアのググり方・質問の仕方)を明示してみた - Qiita
技術的なハマりパターンを分類・オサレに命名し、パターン毎に解決策(エンジニアのググり方・質問の仕方)を明示してみたtips ※ 2021年1月22日(金)更新 2021-01-22 10:55 @zeatan さんからの編集リクエストを受け付けました。: not reflect(ed)について ・ "-" について ※ 2021年1月23日(土)更新 2021-01-23 13:25 Googleability を高める Cheat Sheet に語彙を追加しました。 : custom ・ pass について ※ 2021年1月24日(日)更新 2021-01-24 19:36 Googleability を高める Cheat Sheet に語彙を追加しました。 : not smooth について ※ 2021年1月25日(月)更新 2021-01-25 11:32 Googleabili
伸びるエンジニア、伸びないエンジニア - Qiita
はじめに 同じぐらいの年齢で、同じような環境でも、エンジニアとして1年も働いていると差が出てくる。 それは プログラミングのセンスだとか、 論理的思考力だとか、 やる気の問題とか、 そういった言葉で片付けられてしまうケースもあるけれど、個人の性格・思考によることも多い。 今日は伸びる/伸びないの一因のひとつである、 『コーチャブル』 『謙虚さ』 『現状維持バイアス』 について解説してみる。 ティーチングとコーチング コーチャブルについて語る前に、コーチングについて触れておく。 コーチングは、「ティーチングとコーチングの違い」という文脈で語られることが多い。 この違いを知るまでは混同しがちな言葉だが、大きな違いがある。 ティーチング(Teaching)とは、答え・ゴールを教える方法。 コーチング(Coaching)は、答えやゴールを考えさせる方法。 プログラミングをしていると、後輩から 「な
なぜ我々はアウトプットをするべきなのか - Qiita
はじめに エンジニアには、アウトプットの文化があります。 僕自身、社外でLTメインの勉強会を２年近く運営していました。 みなさんも日頃から大小さまざまな形でアウトプットをされていると思います。 ですがそのアウトプット、「エンジニアだから」「みんながやっているから」「なんか良さそうだから」といった、なんとなくの理由でやってはいませんか？ どんなことにも言えることですが、目的意識があるかないかで得られる成果は大きく変わってきます。 アウトプットの目的、つまりはメリットを理解することで、アウトプットから得られる成果はより大きくなります。 今回はその「アウトプットで得られるメリット」について、経験を少し交えつつ、お話ししていきます。 なぜアウトプットするべきか それはアウトプットに多くのメリットがあるからに他なりません。 その中でも、僕が特に大きいと感じるメリットはこの４つです。 インプットの質を
SQL記述者全員が理解すべきSELECT文の論理的な処理順序のお話 - Qiita
2020/9/30追記 本記事は元々、「SQL記述者全員が理解すべきSELECT文の実行順序のお話」というタイトルで投稿しておりました。 しかし、知見のある方からのコメントと自分でも調べてみた結果、今回紹介している順序はあくまで論理的な処理順序であり、実行順序とは別物ということがわかりました。 誤った知識を布教してしまい申し訳ございません。 2020/9/30のタイミングで、本記事のタイトルを「SQL記述者全員が理解すべきSELECT文の論理的な処理順序のお話」に変更させていただきました。 はじめに 「SQLといえば、エンジニアが扱うスキル」と思われがちですが、最近はマーケターや営業など、非エンジニアの方もSQLを使って、自らデータを抽出し分析する方が増えてきています。 またエンジニアの方でも、ORM任せでなんとなく理解している状態の方もいるのではないでしょうか？ 今回は、そんな方々にこそ
糞コードは直すな。 - Qiita
とりあえず落ち着け。 みなさん、毎日なにかしらのコードを読み、開発する日々を送っていると思います。そんな中で、 糞コードは死ぬべきである！！絶対に直すべき！！ という感情に取りつかれてしまうことがあると思います。自分の技術力に自信のある人ほど、無理やりにでも直そうと試みると思います。それがどんな修羅の道か。そして、糞コード修正がどんな道を歩むのか。この記事では糞コード修正の罠とありがちなストーリーについて書きたいと思います。 ビジネスとしてのプログラムは本質的に糞である 例えば、「携帯電話の利用料金」のプログラムがあります。 「携帯電話 透明性高め料金値下げを」という記事もあるように世の中の携帯電話の料金プランはかなり複雑です。例えば、auだと「auでんき」といった電気料金とパックされた電話料金プランがあります。また、「auスマートバリュー」といったプランもあり、家のインターネット回線をa
【Google Apps Script, Slack】彼女にバレずにワクワクメールのメッセージに気付くために夜な夜な怪しげなスクリプトを組んだ話 - Qiita
次に、Google Apps Script にて 1 分おきに動くスクリプトを用意する スクリプトでは、まず Gmail の内容をチェックし、該当のタイトルのメールを抽出する 抽出したメールの中で、スター（★）がついていないメールにおいて、メール本文から、ユーザ情報およびメッセージ本文を抽出する ユーザ情報を隠蔽した文字列を、Slack に用意した"通知あり"のチャンネル（#tsuchi）に飛ばす ユーザ情報およびメッセージ本文を、Slack に用意した"通知なし"のチャンネル（#hitsuchi）に飛ばす もちろん、処理が終わったメールについては、スター（★）をつけることを忘れない 前提事項 Slack にて、"通知あり"のチャンネル（#tsuchi）および"通知なし"のチャンネル（#hitsuchi）は作成済み 上記チャンネルに対応する Webhook URL は、Slack にログイ
ZOZOTOWN作り手のマインドセット（エンジニア編/マネージャー編） - Qiita
はじめに 弊社では、大きな1つのサービス（ECサイト）をたくさんの部署が協力しながら運営しています。 2012年4月に新卒入社して以来ずっと同じサービスに携わっている自分が、開発チーム内でサーバーサイドエンジニアとして意識してきたこと、そして今はマネージャーとして意識していることを簡単にまとめてみました。 エンジニアとして意識していたこと 1.1/3の法則 1/3の法則とはスケジュールを立てる際に、全体の時間の過ごし方を「設計」「開発」「テスト」それぞれ1/3ずつで分配するという方法です。 ただし、順序は問わずです。 全体の開発の中で、まずモックアップ的に実装することをフェーズ1、プロダクトとして出せるレベルまでクオリティを高める実装をフェーズ2とすると、それぞれのフェーズ内で1/3の法則を適用させます。 入社後しばらくは、コードを書くことが楽しくて「とにかく手を動かして作りまくるぞ！」と
終：どこまでショボいアプリがAppleの審査に通るのか試してみた - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? どこまでショボいアプリがAppleの審査に通るのか試してみた の記事の続編です。 何の話かわからない方は前回の記事も併せて読んで頂ければと思います。 背景 オーケー、しょぼいアプリでも審査に通ることはわかった。 でも、アップデートで全く違うアプリに生まれ変わるとしたらどうなんだい？ そう・・・二つ名アプリがソーシャルゲームになるとしたら・・・ 作ってみる まず最初の課題。 そもそも二つ名を表示するだけのアプリがソーシャルゲームになるって、どういうことだってばよ？ いきなりの難問。 そもそも私はソシャゲーしない。仕事もお堅い開発のSI。
私たちはどうして公式ドキュメントが読めないのか？ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 少しプログラミングを覚えてきた初学者が、さらに力をつけるために必要なのが公式ドキュメントを読むことだと思います。 公式ドキュメントには、日本語の記事には書かれていないような詳細な説明や、APIの使用方法、そしてリリースノートなど、実装には不可欠な情報が掲載されています。 しかし、公式ドキュメントが上手く読めずにつまづく人も多いのではないでしょうか？慣れていない人にとっては、技術について書かれたドキュメントを読むのは難しいものです。 この記事では、つまづいてしまう人が少しでも減るように、公式ドキュメントが読めない原因と対策をいくつか書いて
Webエンジニアが知るべき低レイヤーの技術とその学習方法 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 初めまして NewsPicks Advent Calendar 2018の 20日目を担当させていただきます、NewsPicks の @takugi です。 弊社 CTO 杉浦が2年程前に書いた 普通のやつらの下を行け！ NewsPicks CTOが新人エンジニアに伝えたい3つのこと という記事を読み、 低レイヤーの技術を身につけるべき という考えに共感しました。その後、目の前の仕事に関する技術のキャッチアップに時間を取られる日々が続いていましたが、今年の半ば頃から低レイヤーの技術を身につけることに少しずつ取り組み始めました。この記事に
エンジニアが情報収集とトレンドを追うのに読むと良いサイト - Qiita
背景 自分が普段電車や会社で読んでいるIT系のサイトと学習などで使用しているサイトのまとめ。 ニュース系 ■ CNET Japan ■ @IT ■ ITmedia ■ はてなブックマーク(テクノロジーカテゴリ) ■ Menthas ■ Publickey ニュース(ガジェット系) ■ PC Watch ■ GIZMODO ■ Engadget 技術系ブログ(企業系) ■ Developers.IO ■ はてなブログ開発ブログ ■ サイボウズのエンジニアブログ ■ クックパッド開発者ブログ ■ Google Developers ■ Yahoo! JAPAN Tech Blog ■ Mercari Engineering Blog ■ Webnaut ■ バズ部 ■ SOUM/misc ■ LINE Engineering 技術系ブログ(個人) ■ ネットワークエンジニアのメモ ■ プログラ
新人エンジニアの私が圧倒的成長するためにやっていること
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 私はエンジニアになってまだ4ヶ月のいわゆる新人枠。それでもこの4ヶ月、どのようなマインドや仕組みを用意して進めていけば圧倒的成長に繋がるのかを自分なりに試行錯誤し、実行してきました。 そこで、私の失敗談やそこから得た経験が、新人エンジニア同志の方の参考になればという思いで今回の記事を書きました。 周りのエンジニアとのレベルの違いを感じすぎて「自分なんて...」「こんなことを言ったら」と引っ込みがちだった私が圧倒的成長を目指してやったことが、エンジニアになりたての誰かのところに届けられたらうれしいです。一緒に圧倒的成長しましょう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
個人的に超絶為になったので新人エンジニアに勧めたい記事まとめ - Qiita
