コードに書かれたSQLが動くかどうかが問題になっている場面での派遣PGさんとの遣り取り。
コードの「コンパイルは通りましたけど」と真顔で言われた事があります。
勿論そのSQLは動きませんでした...

プログラマーなのにブラインドタッチが出来ない

これ、わりと珍しくないと思います
私の職場に前に居たSEの方はブラインドタッチできませんでしたし
スクール等でも珍しくないです
（それすらできない人でもスクールから斡旋されたSES等では
「○○エンジニア」としてプロジェクトにアサインしているんでしょうね…）

書いたコードがどれもレガシーコードだった
英語が出来ない

変数名が半角英数字なだけマシに見えてしまいます
弊社の既存のVBAツールには2バイト文字の関数や変数がぞろぞろあります
それとも意味は通じるだけ、2バイト文字の方がマシなんでしょうか？
他にもUPDBI（UPDATE BI(日)の略らしい）＝更新日のような
前任者はルー〇柴だったのかと思うような変数名も盛りだくさんです

Gitが使えない、ソースコード管理が出来ない

SQLを書いていたり長い長いif文がまるごとコメントアウトされて

'YYYY/MM/DD 関数fooを修正

みたいなソース、弊社にいっぱいあります
3桁行のコメントアウトや関数まるごとコメントアウトで修正もザラです

…ここで実務経験（？）積んだ私もスライムの仲間入りな感がすごいですが
会社単位でスライムな場所もあるという実例でした

@c-ari47 さん、私の想像を超えるエピソードありがとうございます！コンパイルが通ればOKと考えたPGさん。SQL単体で確認したのかな。きっとそんな事も考えないのでしょうね。
いやはや、世の中広いものです

@parrot_s さん、エピソードありがとうございます！経験豊富なことにびっくりしています。
ブラインドタッチが出来ないのは別に珍しくないんですね。私がエンジニアに求める期待値が大きすぎる？のかも。

弊社の既存のVBAツールには2バイト文字の関数や変数がぞろぞろあります

言語仕様が2バイト文字を許容しているんですね。VBA経験がない私としては違和感しか無いのですが、それって便利なんだろうか。どこかに落とし穴がありそうな気がします。

他にもUPDBI（UPDATE BI(日)の略らしい）＝更新日のような

まさにこれと同様の命名を見ました。あちこちにあるんですね。

いやはや、開発現場の闇は深いです。

最近は、大学まで（なんなら、大学卒業まで）、ブラインドタッチができない若者が増殖中のようですね･･･。

これは恐ろしい、、、！copilotを採用がいいですね！
といいつつ僕も１０年以上未経験エンジニアばかりしか採用しない現場にいましたので、
共感しかありません、、汗
３年ぐらい育ててやっとという時に、いつもバイバイですｗ

なんかもう大体当てはまってる気がしてきた🤣

コーディングルールやテストやレビューの方法を決めて守らせソース管理にgitを使わせたいなら操作方法を簡単にでもまとめて示せば問題のかなりの部分は解決するのでは?
記事を読んだ限りではされることをしないで愚痴を垂れてる印象です。
ブラインドタッチは割とどうでも良いことだと思います。

@fujitanozomu さんのコメント支援
この記事読んだ最初の印象は「なんか窮屈そうだし、この人の理想に叶っていないとこういうふうに記事とかで愚痴られたりするんだろうなあ」でした
しかしもちろん、記事にあるトンデモエピソードに笑ったり学ぶところもありましたので、
今後はプログラム内のコメントにはこういったチクチク言葉ではなく、誰もが涙する感動的で雅なポエムを心を込めて書こうと思いました

プログラマーなのにブラインドタッチが出来ない

異業種から転職したての5年ほど前の私はまさにそうでした。
その時に一週間で覚えてこいって言われて、必死にやって覚えましたね。
その一週間は、仕事以外の時間は基本的にブラインドタッチの練習やイメトレをしていました。笑
それでなんとか一週間後のテスト（笑）に合格できました。
地味に辛かったですが、今となってはその時に必死にやって良かったと思っています。

愚痴ぐらい言ったっていいじゃない
だってQiitaなんだもの
（いいのか？）

@fujitanozomu さん、コメントありがとうございます～
今読み返すと、愚痴っぽい記事でしたね。猛省しています。もっと皆さんの役に立つ記事が書けるようがんばります。

コーディングルールやテストやレビューの方法を決めて守らせソース管理にgitを使わせたいなら操作方法を簡単にでもまとめて示せば問題のかなりの部分は解決するのでは?

はい。操作方法の指導はします。しかしそれでも解決しないこともあるんです。

記事を読んだ限りではされることをしないで愚痴を垂れてる印象です。

他に改善するために取り組むべきことが有りましたら、コメント欄でご教示いただけると嬉しいです。

ブラインドタッチは割とどうでも良いことだと思います。
これだけは言えます。ブラインドタッチが出来ない、タイプが遅い人は、生産性が全然違います。それに指数関数的に経験値も違ってきます。要件を見て試算した工数に対して、１０倍も工数が膨らんだことも中にはあります。経験が多いほど考慮スべきことが考慮できているのでバグも少なくコードの見通しも良いです。反対は考慮が漏れている、テストも不完全、コードは難解で、というスライムなんです。見たことないですか？

@error_401 さん。愚痴っぽい記事にお付き合いいただきありがとうございます。共感いただけるところが少しでもあれば嬉しいです。

他人のコードを借りる時は概ね完コピしてますね。
テストした上で動作上に問題なさそうならそのまま使いますが大体は取っ払って書き直したくなります。
中途半端にコードへ混ぜ込むと他人が書いたプログラムが何処に行ったか分からなくて苦労した覚えがあるのでURLまでコメントに含めて残したりします。

コピペだと会社的にはライセンス汚染（著作権侵害）リスクが気になる。

大変に、うなづける内容でした。

見てないとサボる

大変に申し訳ございませんすべての社会人様

コメントに不適切文字が

やろうとしたことはありますが、
上司がバリバリのエンジニアのため、思いとどまっていますｗ

@error_401 さん

最近は、大学まで（なんなら、大学卒業まで）、ブラインドタッチができない若者が増殖中のようですね･･･

システムを使う現場では問題になっています。職種によっては現場オペレータの採用時にはキーボードが使えることが条件になるのですが、スキルの差は当然あり、人によってパフォーマンスが大きく差が生じます。フリック入力のUIがあれば解決するのかと考え真剣に検討したこともあります。

@matsuyoro さん
共感いただき嬉しいです。

３年ぐらい育ててやっとという時に、いつもバイバイですｗ

より処遇の良いところに行っちゃんたんでしょうかね。長く働ける環境を作るのも課題の一つだと考えていたところです。

@SMwww さん
このようなエピソードはどこにでもあるんですね。
お仲間がいて安心（？）しました

@A-Kira さん

地味に辛かったですが、今となってはその時に必死にやって良かったと思っています。

私もブラインドタッチが出来ることで良かったなぁっと思いますし、同じですね。
コードを書くことはもちろん、資料作成、メールの作成も、頭に思いついたことが
スラスラと書けることで、ITのメリットを生かしていると実感します。

ノートに手書きすることもするのですが、なんでスラスラ書けないんだと我にかえって、ノートPCを引っ張り出すこともあります。

@maemae さん

他人のコードを借りる時は概ね完コピしてますね。

私もネットで見つけたコードをコピーすることもあります。あとで引用元を参照する可能性がある場合は、ブロックのコメントにURLを残しておいたりします。同じですね。

コードを借りる時、社内の他のプロジェクトで似たような処理をしているコードが無いか調査して、次にエンジニアに聞いてみて、それでもでてこないときはネット検索するという順序です。

@tenmyo さん

コピペだと会社的にはライセンス汚染（著作権侵害）リスクが気になる。

ネットニュースでコピペの著作権問題になったのを思い出しました。
たしかそれは担当したエンジニアが他社に持ち出したんでしたっけ

@miyabi_takatsuk さん

見てないとサボる
大変に申し訳ございませんすべての社会人様

たまに息抜きは良いと思います。度が過ぎるとね～です。

コメントに不適切文字が

やろうとしたことはありますが、
上司がバリバリのエンジニアのため、思いとどまっていますｗ

上司の褒め言葉を書いておけば査定も良くなる？

@tennis99jpさん、

愚痴だから悪いということではなくて、されるべきは問題解決の筈で、されるべきことをされてないよう見える記事で愚痴を垂れられても「問題解決能力のない人だな」「建設的でないな」「下で働く人も不幸だな」等思うだけです。

コーディングルールやテストやレビューの方法を決めて守らせソース管理にgitを使わせたいなら操作方法を簡単にでもまとめて示せば問題のかなりの部分は解決するのでは?

はい。操作方法の指導はします。しかしそれでも解決しないこともあるんです。

記事を読んだ限りではされることをしないで愚痴を垂れてる印象です。

他に改善するために取り組むべきことが有りましたら、コメント欄でご教示いただけると嬉しいです。

コーディングルールやテストやレビューの方法を決めて守らせることは是非にされるべきと思っています。この辺り上の引用部から話が伝わってる気がしません。記事中で

一度命名のルールを決めてしまえば楽なんだろうと思います。

と書かれていることからコーディングルールを決めていない、あるいは「コーディングルール」の概念に齟齬がある気がします。同様に、

書いたコードがどれもレガシーコードだった

※レガシーコードの意味的定義には諸説あります

ここでされるべきは「レガシーコード」の解釈は複数あることの注記ではなく、この記事の中ではどのような意味で使っているかの説明でしょう。自分で思っていることを他者へ伝えることは自分の責任だと思いますが、その辺りの認識がない方と伺えます。認識し改めない限り他者とのコミュニケーションギャップの解消は難しいと思います。

ブラインドタッチは割とどうでも良いことだと思います。

これだけは言えます。ブラインドタッチが出来ない、タイプが遅い人は、生産性が全然違います。

問題はタイピングが遅いことでありブラインドタッチができないことではないのでは? ブラインドタッチができなくとも業務に支障のない程度の速度でタピングできる人は珍しくもないという認識ですが必用なのはブラインドタッチですか?
生産性が全然違うということですが、教本等用意して少し練習させれば身につく程度のことが実施できない環境ということであれば根は深いですがちょっと自分の想像が及ばない世界ですね。

タイトルは秀逸ですがクソコード自慢なんて腐るほどあるので諦めて育てるか切り捨てるかすることをおすすめします。愚痴ってる暇はないはずですよ

@fujitanozomu さん。私の駄文、ダメコメントにお付き合いいただき本当にありがとうございます。参考になるところ多々あり、頭が下がる思いです。

「問題解決能力のない人だな」「建設的でないな」「下で働く人も不幸だな」等思うだけです。

ほんとそうですよね。こんな私と一緒に働く人には、本当に感謝しか有りません。

コーディングルールやテストやレビューの方法を決めて守らせることは是非にされるべきと思っています。

なるほど、そうですよねー。ルールは決めているのですが、なかなかそのルールを守ってくれない場合どうしたら良いですか？ね。

自分で思っていることを他者へ伝えることは自分の責任だと思いますが、その辺りの認識がない方と伺えます。認識し改めない限り他者とのコミュニケーションギャップの解消は難しいと思います。

はい、おっしゃるとおりです。コミニュケーションは本当に難しいと思っています。業務指示を的確に伝えることもそうですよね。 @fujitanozomu さんは経験が豊富のようにうかがえました。なにかコツとか、普段気をつけていることとかありますか。そのへんのことをもし記事にでもしていただければ参考にしたいと思っています。よろしくお願いします

@szcan97 さん
コメントありがとうございます。

タイトルは秀逸ですがクソコード自慢なんて腐るほどあるので諦めて育てるか切り捨てるかすることをおすすめします。

はい。気を取り直して、自分の業務に戻ります。

問題はタイピングが遅いことでありブラインドタッチができないことではないのでは? ブラインドタッチができなくとも

ブラインドタッチが出来ないということは、手元と画面の視線移動が頻繁に行われ時間ロスが発生します。タイプしているつもりがエディターやフォーム等に反映できていなかった、IMEI切り替えが思ったとおりでなかったなど意図しない文字が入力されていたなど、手戻りの要因も起こりえます。タイピングを効率的にそしてタイプ量を多くしようとすると必然的にブラインドタッチに行き着くと思います。

ブラインドタッチに関して、
私はブラインドタッチができるかどうかはプログラマの力量とは直接関係ないかなと思ってます。
例えば以下のサイトを見ると、プログラマが1ヶ月に書くコードはだいたい500～2000Stepぐらいみたいです。
20日稼働しているとして、大体一日に25～100行ぐらい書けばいいってことですね

よく、1人月1000stepみたいな話を聞くが、これを見る感じ統計的に間違った数字じゃないことが分かる。このデータだと1000step/1人月はむしろパフォーマンスが高い方だ。

これぐらいの行数であればブラインドタッチなんてできなくても余裕で書けますね。
もちろん開発の際に試行錯誤してたりすると実際にはもっと書くことになりますが、モダンな言語ではたいていエディタの強力な補完機能などがあるので、タイピングが遅すぎてプログラミングできない！みたいになることは一般的な現場では無いと思います。

それよりも支配的なのは、仕様を理解する時間、コードを読む時間、設計を考える時間、書いたコードを動かす時間、うまく動かなくて「はまる」時間です。ここらへんの時間がどれだけ短いか、あるいは短くしていく能力があるかがプログラマの力量に直結するという印象です。

もちろんブラインドタッチできるに越したことは無いと思いますが、そんな些細なことよりももっと見るべき点があるんじゃないでしょうか

@KuwaK さん、コメントありがとうございます。

紹介のリンク先記事を見ました。ソースとしている「ソフトウェア開発分析データ集2020独立行政法人情報処理推進機構 (IPA)」も確認しました。
P80 SLOC 生産性では開発５工程の実績工数（人時）に対する成果物SLOCの相関を求めています。開発５工程は基本設計～総合テストを対象としています。
開発規模（SLOC)によって、開発５工程の合計工数がどのように変化するかを調査したものと読み取ります。コーディング以外の工数および人間も含まれています。このデータからエンジニアのタイプ量の実績値を判断することは難しいと判断します。

大体一日に25～100行ぐらい書けばいいってことですね

最終的に成果物として残る行数としてはそれ位かもしれませんね。
各工程で必要なドキュメント作成、検討調査書、テスト打鍵、エビデンス作成など、キータイプが発生する場面は多くあります。１日に１００行のコード成果物が出来たとして、そこに至るためのプロセスで発生する成果物はどうしてもキータイプが必要ですから。タイピングは仕事の効率、生産性を計る人るのバロメーターだと思っています。タイピングがすべてというわけでは有りません。

それよりも支配的なのは、仕様を理解する時間、コードを読む時間、設計を考える時間、書いたコードを動かす時間、うまく動かなくて「はまる」時間です。ここらへんの時間がどれだけ短いか、あるいは短くしていく能力があるかがプログラマの力量に直結するという印象です。

全く同意します。漠然とですが、ここで言っているプログラマの力量とタイピング能力にはある程度の相関があるんではないかと感じています。

モダンな言語ではたいていエディタの強力な補完機能などがあるので、タイピングが遅すぎてプログラミングできない！みたいになることは一般的な現場では無いと思います。

はい、おっしゃるとおりです。もし目の前に補完機能を使わないエンジニアがいたらどうします？キャリア豊富なエンジニアでも実際に居るんですね。もしかするとキャリア豊富だからかえって、最新のツールに親しんでいないだけかもしれませんね。

@KuwaK さん

私はブラインドタッチができるかどうかはプログラマの力量とは直接関係ないかなと思ってます。

そうでしょうか。
できるプログラマでタッチタイプできない人はほぼいないでしょうし、逆にタッチタイプできない族のなかではできるプログラマは少ないと思います。(もちろん例外あり)

もちろんブラインドタッチできるに越したことは無いと思いますが、そんな些細なこと

全く些細なことじゃないです。
メールやチャット、仕様書やBTS、報告書や議事録など文章を入力する機会も多々あります。
想像してみてください。タイプが速い人がチャットでレスするのに1分かかるなら、5倍タイプが遅い人は5分かかるんですよ？
タイプが速い人が年間100時間タイプに費やしてるとしたら、5倍遅い人は500時間必要なんです。

想像してみてください。日本語キーボードを使っているあなたが英語配列のキーボードを使わざるをえなくなったら。ほんの少しの間作業効率が落ちるでしょう。dvorak配列で入力するのを強制されたら。相当長い間作業効率は落ちると思います。
これでも些細なことだと思いますか？

キータイプで思わぬ反響を頂いてびっくりしています。
あくまでも想像ですがプログラマーの立場からキータイプのスピードやブラインドタッチの出来るできないだけで能力を評価して欲しくないと言っているような気がしています。一方でプロジェクトのスケジュールやコストを管理する側から見れば、効率と品質とか気にしているわけで、プロジェクトに投下するエンジニアの能力をどうやって測って、作業工程にどう反映するかを判断しなくてはなりません。効率よく振る舞ってくれれば日程に余裕が生まれますが、反対ですと。。。やはりキータイプが速い（ブラインドタッチが可能）方が安心材料になります。
管理側が作業担当者の効率の良さに期待を寄せているのであれば、担当者するプログラ―ま―はその期待に応えるように努力するのはいかがでしょうか。ブラインドタッチが出来ないことを棚に上げて、エクスキューズを並べるよりもずっと気持ちがよいです。効率よく仕事ができるようになれば、より多くの経験がつめて、その結果能力が上がっていくと思います。
さて、プログラマ向けのタイピング練習ツールが無いものか調べたところ、こんな良いサイトが有るのを見つけました。

言語別にページが用意され、課題のプログラムソースを見ながらタイプしていくものです。言語の習得にも少しは役立つかもしれませんね。

Gitが使えない、ソースコード管理が出来ない

そういえば、開発が間に合わないからサーバのコードを直接サーバ上の vim で編集して、リリースしたらサーバのコードを Git に取り込んでねという上司（プログラマ歴 30 年）が過去にいました。

記事の中ではおそらく贅沢な悩みなんだと思います。

記事を見て思ったのは、自分と同じ事を当たり前のように他人が出来ると思ってはいけないという事と役割に対して期待値が大きすぎないか？という所ですね。

がっつりコードを書く現場で3年くらい働いたエンジニアなら上記愚痴が出ても仕方ないと思いますが、独学で勉強した未経験の方だとおそらく、平文でパスワード保存しますし、gitもmainブランチしか使わないと思うのでなんやら手間取ると思いますし、テストも書かないと思いますし、要件も大分噛み砕いて細かく渡さないと無理だと思いますし、他業種から来たならタイピングも出来ないと思うし、英語も出来ない人いると思います。

コードを書いてないけどエンジニア3年くらいしてた人でも多分無理かなぁと思います。

私の見解的には未経験を雇っているなら期待値高すぎ、即戦力なら面接が甘すぎと感じました。

いやー、経験者の中途採用じゃないかなー

@lunalice さん、コメントありがとうございます

がっつりコードを書く現場で3年くらい働いたエンジニアなら上記愚痴が出ても仕方ないと思いますが

ですよねー。新卒からプログラミング一筋３０年のベテランのかたも、このエピソードに含まれているという事実を知ったらどう思いますか？これが現実なんですよね。有名企業なら優秀な人材も集まって着やすいのでしょうか。当方の属する会社は残念ながらそういう企業では無いようです。高給をお支払いすることも難しく、エンジニアの皆さんに提供できるものといえば、高い志くらいです。

@error_401 さん、コメントありがとうございます

いやー、経験者の中途採用じゃないかなー

お察しのとおりです。

standard****さんから頂いたコメントが消えていますが、せっかく書いていただいたので、お礼の気持で返信します。（読まれていない可能性は高いですが）

採用した方の責任っていうのがあるので

はい、責任をもって指導教育をしていますので、ご安心ください。転職もとは皆さん別々のキャリアを歩んでこられていますので、それぞれの経験を持ち寄ることで、互いの知識を補完し合ったり新しいアイデアが生まれたりと、良いこともたくさんありますよ。

@tennis99jpさん
ちょっと、批判的かなと思ったので消してしまいました。
がんばってください。いい人をみつけるコツなども、たくさんの積み重ねで見つけていかれるといいですよね。

よくはしらんですが、日本の会社は社員をやめさせるということがかなり難しいので、試用期間とか設けてためすとか、いろいろ工夫がいるかもです。

JoelOnSoftwareで有名なJoel氏の「ソフトウェア開発者採用ガイド」なども面白いと思います。

自分は「強将の下に弱兵なし」と思って、自分の周りの人を強くするのは自分の責任でやらないとなーと思ったりします。
弱兵が弱兵のまま自分の周りにいるのは、自分の責任っすよね。

@tennis99jp さん

では面接が甘すぎのパターンですね。本来ギャップを埋める為の面接だと思いますので、相手の能力が期待値より低いというよりはギャップを埋められてない状態でミスマッチが起きてる感じに見えました。この記事を見て相手がよわよわスライムに見せかけてミスマッチさせてますというブーメランにしか見えないので、少なくても即戦力レベルの人がこの記事見て入社してみたいなぁとは思えないだろうと感じました。頑張って下さいね。

自分もこの記事の著者をスライムと見下してるのに気づかない人多すぎ。
不愉快。

ええなあ。みんな人を見る目があって

非ITエンジニアで、PHPとbootstrap使っていてほぼ非公開webページ作っています。
ここにない例として、「動作の理解・記憶ができずにjsファイルの4割がコメントアウト」
みたいなことをやりました（reactのチュートリアル）
あと、テスト資料のshift社のスキルテストのフォーマットをエクセル化して丸パクリしてたり…

アンチコメント。
変数名に関しては、素人状態だと（新卒者・未経験エンジニアとかも）
「サンプルから勝手に変えていいのかな？不安だなぁ。」と思って最初のころは変えずにやっていました。（エラーが増えて作り直したケド。）
他の記事も読んだ印象ですが、@tennis99jpさんは自分自身に課する責任や能力値の要求が非常に高く、かつ優秀であることから、他者への要求値が高くなっているのではないかと勝手ながら感じました。
非エンジニアである立場のため過剰な進言ではありますが、もし現在の状況の悪さに対して3年以上の中長期的な懸念をされているのであれば、ワークスアプリケーションズを創設された牧野社長の採用と成長戦略のように、あえて未経験者を雇って業務時間の半分を使ってQiitaの記事やスタートアップマニュアルを作らせる。マニュアルをフェーズごとに整え、どのレベルでもスキルアップを図れるようにする。などの社内的な取り組みも有効ではないかと思いました。

最後に・・・私がベビースライムよりは少々マシなスライムである、と勇気をいただきました。ありがとうございます。

問題はタイピングが遅いことでありブラインドタッチができないことではないのでは? ブラインドタッチができなくとも

ブラインドタッチが出来ないということは、手元と画面の視線移動が頻繁に行われ時間ロスが発生します。タイプしているつもりがエディターやフォーム等に反映できていなかった、IMEI切り替えが思ったとおりでなかったなど意図しない文字が入力されていたなど、手戻りの要因も起こりえます。タイピングを効率的にそしてタイプ量を多くしようとすると必然的にブラインドタッチに行き着くと思います。

だからこれ、ブラインドタッチできるかどうかじゃなくて、入力が遅いことが問題なんですよねっていうのがプログラマ的思考なんです。何を達成すべきなのかは早く正確に入力することであって、ブラインドタッチしていなくても早く正確に入力できたり、入力補完使いこなしてたりするんだったらいいでしょって意見が多いんだと思います。
また、システムの運用保守を行うプログラマであれば、別に早くタップする必要もなかったりします。

主語が大きすぎるのと根本原因の分析が甘いと思います。
典型的な手段と目的を取り違えている主張。