「コーディング」を含む日記 RSS

はてなキーワード: コーディングとは

2021-07-29

自分が開発を始めたソフトウェアイスラエル企業の目に留まってそのまま現地に行っちゃった人のお話を読んでいた。

すごいなー→仕事心底楽しそうやなー→自分の実現したいことが周囲から認められて幸せそうやなーまでは思った。

けれども、こーなりたいなーとか自分もいつかのために勉学に励まなくちゃ!って気概まで全く至らなくて

プロ野球選手目指しますとはちゃうんだからと思っても、自分にはもう踏み出す足がないことにため息をついてしまった。

プログラミング嫌い、特にgo言語なにそれおいしいの?原始的で野蛮書くの辛いって口悪しくぶっちゃけたら転職面接で落ちたばかりだ。

実際に似たような業界だけど、プログラマーとしての才能まじでないし、寿司打は一回り年下の後輩にぼろ負けするくらいタイピング遅いし、

正直コーディングよりも、yamlファイル、tomlファイルという設定ファイルもっちり整えてる時間の方が好き。

マネージャー職もリーダーも無理。自分はこのポジむいてないなっていうのはよく知ってる。ソフトバンク行った同僚の残した資料を見てるとこれと同じレベルドキュメント作る自信も皆無で。

...そんなワイでも、もっとお金もらえる仕事いかな。さすがに禿が気になる年頃だし、600万円ほしいな。無理かな。

anond:20210729082724

まともなコーディングも出来ないSIerではなくて、最新技術を抑えたエンジニアとしてWeb業界で生まれ変わりたいって事でしょう。

何も出来んSIerからじゃ、Web屋くらいしか採用してくれないだけで、行けるなら別の業界の方がいいんでないの

2021-07-27

anond:20210727111807

静的型付けを「大規模に向いてる」とか言う人よく見るけど、数十行とか数百行レベルコードでも静的型のほうがコーディング楽だよな。

2021-07-16

国が半導体技術者の育成はできるのか

仮に予算を十分につけたとする。

半導体エンジニアも、様々な分野があり、

  1. CPUGPUSoCなどのアーキテクチャを作るアーキテクト、
  2. Verilog、SystemVerilogVHDLなどのハードウェア記述言語でRTLコーディング検証する論理設計
  3. レイアウトタイミング検証、電源検証をする物理設計
  4. PLL、アナログ回路設計者、
  5. 光プロセス設計するプロセスエンジニア
  6. ウェーハのダイシング、パッケージ組み立てなど後工程

など多岐に渡る。

問題なのが書籍電子書籍がない分野であり、国が本気になったとして、教科書作りから始めるわけで、出来るのか?

2021-07-11

VAT

新型コロナ感染症は、血栓形成が特異な病態として知られている。そのウィルス粒子のガワをコーディングするmRNAを筋注し、人体内でガワを作らせ認識させ忠和抗体を作る過程で同様なことが起こる可能性はある。んで体質(凝固因子等のsnp)や元々の冠動脈疾患リスクファクター状態によって Vaccine related Acute

Thrombosis とでもいうべき病態が起こって稀には接種翌日に発症するのかも。頻度がすごく低いのはその発生自体まれなのか、発生しても無症状で経過する事が多いなどの理由が考えられる(症状のない小さな動脈血栓・深部静脈血栓日常診療でもしばしば経験されること)。

なので、接種後数日以内に亡くなった方々については発症経過や血清・血算等データの保存・集積をできる限り行って後々の検討に使えるようにしておいた方がいいんじゃないか。

2021-07-05

今週も、エクセルスクショぺたぺた・関数リスト丸写し作業がはじまる

先週金曜日は久しぶりにコーディングした

クソコードの引き継ぎで不快まりなかったがな

今週はまた、エクセル

する作業

先方の秘伝のエクセル方眼紙の体裁に合わせなきゃならん

無駄に罫線の使い方とかが細かく決まってる

誰がやっても70時間はかかる

氏ね

2021-07-03

anond:20210702212831

ガチで頑張ったことを聞いてるんじゃなくて、ある程度でっち上げても良いから話に一貫性論理性を持たせられるか試されてるんだろうな

プログラマーならコーディングインタビューとかでそれを見るけど、総合職はこういう質問論理構築力を見るんだろう

2021-07-02

どーしても在宅でコーディング系の仕事で雇われたいんだけど、どうやったら仕事にありつけるだろうか。

休み4日手取り15万円のいまの仕事しんどいから転職したい。

今の仕事ブルーカラー。2年間働いたけれど、昇給ボーナス退職金もない。がまんすれば定年まで居られるだろうけど、経済面だけでなく肉体的にもきつい仕事なので続けられるかどうか……。

過去に、IT系っぽい会社で働いていたことがある。そこでは、実務としてコーディング経験はないが、デジタルデータ作成ディレクターのようなこともやっていた。

いま40歳をこえているが、趣味程度にウェブサイト作成したりしていたことがあり、PHP , MySQL , JavaScript , HTML , CSS などWeb系の知識は少しはある。

2021-06-30

anond:20210629214345

NSAバイトで社内システムを見たラリー・ペイジが「これ商用化していい?」つったのが当たったのがGoogleからな、本質的には払い下げの金塊をタダで貰って高額転売する嗅覚に特化した商社で、キラキラ社内で楽しく天才コーディングしてるのはダミー。そこが自分で金を精錬してるMSとは違う

2021-06-17

CTOだけど、一ヶ月Web就職レビューしてみた。

https://anond.hatelabo.jp/20210617075257

0. 温度感

基本的現在では、バックエンドフロントエンド運用保守全てができないエンジニア価値は無い。

経験者でも、これらができない/わからないのは、相当恥ずかしいことだと思った方がいい。

典型的はてなー意識の高さ。

上がってるような基本(元増田に上がってるやつの倍ぐらい)が全部立ち上げからできて

2〜3個プロジェクト経験したらテックリード素養が既に身についてそう。

まり、ただのエンジニアにはそこまで要求されない。

プロジェクト的にもどっちかが弱いと

Rails/DjangojQuery+Bootstrapみたいな構成

Amplify/FirebaseにVue/Reactみたいな構成全然あるので

フロントバックエンドも一旦はどっちかでいい。

面接はなんとか抜けてもらうとして、

チーム開発での最低限の目標としては、

成果物から指導学習コストレビューコスト技術負債マネジメントコストを引いた分が正になっていれば

ひとまず「チームに居ていい人」と見なされそう。

チーム的に良くても、経営層にそれで許されるかはわからんのでその辺の立ち回りも上手いことやるとして、

一旦は、正の生産性を目指してほしい。

以後、ブコメで誰一人一ヶ月でできるって言ってなくて笑うので、

一ヶ月というのは無視して、三〜六ヶ月程度をイメージしつつ書いていく。

1. 言語: PythonJavascript

これだけで一ヶ月経つ気がするが正気か。

似たような言語なのでどっちからやってもいいし、両方同時にやってもいい。

どっちかしかやらないならJavascriptおすすめ。後ででてくる、Flaskは適当Expressかに置き換える

現場だとほぼTypescriptなので、Javascriptはある程度慣れたらTypescriptに移行したほうがいい。

どちらも、Python2とES2015以前の記法というレガシーネット上に転がってるので参考にしないように注意。

パッケージ管理単体テストタスクランナー

この辺は6のフロントフレームワークと同時にやる。

コードは断片的なサンプルではなく

一貫性があって

・正しい書き方がされた

お手本プロジェクトをなにか(github書籍など)で手に入れて読むべき。

おそらくフレームワークに乗っかっているので並行して進めることになる。

6. フロントエンドフレームワーク: Vue.js

話の流れで先にこっち

現在コーディングのグッドプラクティスデザインパターンフレームワークの形をしている。

なので、ReactとVueをその思想から理解しきれれば、プログラミング言語の潮流の最先端に追いつけるはずだ。

とはいえ最低限としては使い方が分かるところまで。

TypescriptVue.jsも書き方をどこまで取り入れるかが使用者裁量に任されてるし、

開発でVueとReactのどっちを使うかはチーム次第なので、

一旦React+Typescriptガチガチに書かれたコードプロジェクトを拾ってきて、必死で解読するのがいいと思うなー。

2割ぐらいわかった気になればチーム入ってから(React, Vueどちらだったとしても)動けそう。

パッケージとかテストタスクデプロイ辺りもこのタイミングで拾ってきたプロジェクトを使って学ぶ。

2, 4. ツール: gitDocker

バージョン管理コンテナ思想が優れているのは自明なので、これらはツールと見ていい。

そして、後からプロジェクトに入った人がプロジェクト流儀に沿って使う分には難しいことはなさそう。

採用に来た人がgitとかわかってるとチーム開発経験者だなーって思うし、知らないと未経験者なんだなーって思うし、

そういう意味ではチーム開発の経験があるかどうかの試金石にはされてそう。

構築できる、ではなく、触れる程度で良さそう。

gitプロジェクト流儀によると書いたが、git-flowイメージ図を理解して運用できるのがよい。

https://qiita.com/KosukeSone/items/514dd24828b485c69a05

3. OS: Linux

これは「パソコンの使い方わかってますか」ぐらいの温度感

ファイルパーミッションユーザープロセスのような基本概念理解する

一冊読めば済むだろうし、概念系はさらっておいてほしい。

grepやfindやxargsなどのコマンドを組み合わせて簡単な処理を自動化する

こういうのができるんだなーって言うのを知っておいて、調べつつ書ければ十分。

sedとか正規表現も。

あとはシェルスクリプトとかって思ったけど同様のことはPythonでもできそう。

IPアドレスを調べたり、SSHリモートマシンログインする

地味にSSHログインした先の環境だと、vimが主要なテキストエディタになるので

vimを最低限触ることだけ要りそう。もういらないかもって思ってたんだけどなー。

ファイル開いて入力モードに切り替えて書き込んで保存して終了

チュートリアルする。拡張とかはいらない。

細かく書いたが、LPIC-1の範囲がほどよくまとまっているのでそっちを参照するとよい。

5. サーバーフレームワーク: Flask

フレームワークを覚えること自体重要なのではなく、Web開発の基本を習得することが重要

これが意図なら

HTTPルーティングデータベースSQL認証セッション管理などは当然すべて覚える。

この辺の機能を持った小規模Webアプリを作ってHerokuデプロイすれば一旦完成とみなしてよさそう。

コード書き写しただけにならないようには注意しつつだけど、長く見て5人日ぐらい?

慣れると1日あればいけると思う。

フレームワークもなんでもいい。

軽量である必要もなくて、

Djangoとかでも各コンポーネントがどんな働き方してるか程度はわかるだろうしそれで十分。

余力があれば複数個触ってみたり、人から勧められたらそっちでも。

最近サーバーレス&NoSQL流行ってるのでFirebaseとかもやればいいと思う。

7. アルゴリズム

コメントリーが荒れててウケる

実務プログラミングで最低限必要アルゴリズム力は

「書いてるコード計算量オーダーを把握していること」

に尽きる。

計算量を気にしなかったせいで線形検索メソッドとfor文を組み合わせて

O(n^2)やO(n^3)のロジックを書いてしまって

データ量が万〜十万の本番データで遅延するとか

それらに対して分散や非同期処理で解消しようとするとか、

ちょっとでもアルゴリズムを触った人ならアホらしいなって思うような行為

アルゴリズム不要勢は平気でやるぐらい、両者は溝が深い。

計算量を意識するだけなら、AtCoderABCのC〜D問題辺りが解ければ十分。

8. セキュリティ

有名な脆弱性攻撃手法は、ほとんどフレームワーク等で解決手段が用意されている

(XSS対策自動エスケープなど)

のでアドリブをせずに正しい書き方でやれば良い。

開発現場でもセキュリティリスクがある箇所を1から自前で実装することを経験が浅い者にはやらせないので、

ただただ、フレームワークが正しいとしているやり方をなぞるのが良い。

最後

開発の勉強のやり方としては、

・正しいコード見本を手に入れること

公式リファレンスを読むこと

エラーメッセージを読むこと(そしてググること)

この辺りの習慣があればやってけんのかな、

その他、チーム開発って面では

アジャイルサムライプロジェクト管理)とか

TeamGeek(人間性)とかインプットしておくと共通言語が増えて嬉しい。

この方向で進めてけば、その途中で正の生産性≒足引っ張らないぐらいになれるので、

そしたらやってけるんちゃうーって感じ。

エンジニア()所詮この程度の視座の低さなんだよね

anond:20210617075257

私は一流SIer上級管理職をやってるけど、こんな要素技術なんて結局意味がないんだって何回いったらわかるんだろうね日本エンジニア()は。この程度を勉強したところで結局派遣SES関の山なんだけど本当にそういうのを目指したいのか?本当の意味エンジニアになりたいのならとにかく顧客とのコミュニケーション要件定義の仕方、そして進捗管理の報告、ちゃんとした開発プロセスを学び、次に機能設計、詳細設計をもれなく記載する技術を学ぶべきで、Docker()なんてどうでもいい。

不勉強な人ほどウォーターフォール馬鹿にするけど、結局すべての開発プロセスというのはウォーターフォールが基本だし、その中で要件定義機能設計重要性を勉強する。こういう正統な成長の道があるのに最も価値の低いコーディングから入るのは愚の骨頂。

2021-06-15

anond:20210615203714

業界によるよね

IT系ナウい手法も次々出てきてるし

インターネット情報あるし無料コーディングできるしで

若い人のほうがすっきりした知識持ってるすらある

2021-06-12

ちょっとプログラミングできる奴が一番うざい

上司しろ同僚にしろ部下にしろ

ちょっとプログラミングできる、っていうレベルの人が一番うざい

というか害悪だしデジタライズするとき障壁

上司に多いのが「所詮コーダー仕事」的思考の人

設計が全てでコーディング作業っていう考え

アジャイル手法理解していても考え方を理解していない

結局彼らの設計したモノは当初の目的からはかなり外れてしま

長い月日をかけて誰にも使われないソフトウェアが完成する

完成する頃にはもう居ない

同僚に多いのは「その言語ちょっとね」とか言う人

自分サーバサイドだからフロントエンドからAIから、とか言ってその分野ばっかりやる人

ぶっちゃけその分野もこっちでやった方が早いしできるんだけど

そうしたら彼らの仕事が無くなるからやらないだけ

自分で蒔いたバグ自分で改修することを毎日やってる

まぁそれはみんな一緒かもしれんけど同じことばっかやってて成長しない

部下に多いのは「動いたからいいでしょ」的な人

最近Qiitaにも多いけど「こうしたら動きました」って言って内容理解してない人

これってどういう意味?って効いたら「コピペしてきました」って言う(意味を聞いてるんだが)

大抵は冗長かつ不十分な実装になっててしばらくして動かなくなる

もしくは自分で考えたであろうスパゲッティになってて

リファクタリングとかの作業でほぼフルスクラッチする

まぁ誰しも通る道だとは思うので丁寧に指導はするけれど

何年もそんな感じだとちょっとイラッとくる

2021-06-10

日本の古き良きIT企業退職して3年がたった

3年前、世間一般にはメーカーSIerとして知られている会社退職した。ただ俺のポジションパッケージソフト開発であり純粋SIerとは異なる。

客ともSEとも会話せず、ひたすらドキュメントプログラムを書く部署だ。といっても別にペーペーではなく主任クラスであり、

会社の業績がとてもよかったこともあり年収1000万弱はあった。35歳。

これだけ見るととてもいい待遇に見えるだろう。でも耐えられないことがいっぱいあった。

Linuxで動くアプリなのにVMを動かすのも苦労する8GBしかメモリのないWindows PC、紙にコード印刷して説明しないと納得しない品質保証部、

作業実施Excelにチェックを付けていくテストjquery一つ使うのに3ヶ月かかる承認フロー、開発中にバグを一つ出すごとに

ひたすら反省文を求める品質保証部と一緒になって詰めてくるマネージャー、常にコンパイルできないtrunk、

Java 5の時代から進化しないコード、使いにくい社内ミドルウェアの利用を強制される設計、開発期間の半分以上を占める最上設計

一旦書いたコードは消してはならずコメントアウトしないといけないコーディング規約など、数を上げればきりがない。

色々改善活動を頑張ったものの、結局Subversionの導入も品質保証部がついていけないから、ということでClearCaseといわれる

今ではほぼ誰も使ってないであろうバージョン管理ツールが使われ続けることになった。使いにくい社内ミドルウェア

研究所がその道のプロと聞いたので一緒に改善を図った。そしたらRubyしかいたことがない文系新卒の子が出てきた。

一応研究所の人だし…と思って新バージョンプロトの開発を依頼したら、1分以上稼働できない状態になって出てきた。

研究開発は準委任相当なのでそれ以上修正を依頼できずに期間が終わった。

また前の会社独特の文化として、大きなバグを出した開発者反省会(社内ではとある固有名詞で呼ばれている)があった。

この反省会のターゲットになった開発チームはその資料準備で開発が1〜3ヶ月ほど止まるほど大掛かりなイベントだ。

このとき担当品質保証部は「連帯責任から」という理由資料レビューに大変な精を出す。余計なお世話だ。

このため1020ページほどの資料を毎週レビューにかけて最高のものにしていく。でも結局本番では幹部からの怒号が飛んで終わりである

連帯責任かいっていた品質保証部は幹部と一緒になって詰めてくる。連帯責任ではなかったのか。

幹部によると、この反省会があるから今の会社があるんだそう。これを経験して一人前らしい。

こんな感じで開発の体制はひどかったが、世間一般ではホワイト企業と見られている通り有休は取りやすかった。

そのため、転職活動を始めた。そしたらなんと「メモリ32GBのマシン」「mavenが気兼ねなく使える回線」「自動テスト

GitHub」「CI/CD」 という発言ポンポン出てくる。メルカリだのGoogleだのといったイケイWeb系ではなく、

いわゆるSIerでもだ。最初は何だこの格差はと思ったが、まぁ営業トークなんだろうな、と思い直した。というわけで

ケイWeb系も内定は出たものの、つい安定をとってしまい某大企業のDX系の部署転職した。

そしたら何だこれは。最高スペックMacBook ProからGitHubpushするだけで自動デプロイで即サービスイン、

問題が発生したら社用携帯に通知が飛んできて、クラウド監視サービスログをチェック、即修正デプロイ

社内の連絡はSlackで、スタンプを押せばIssueがたち即関連部署対応に走る。OfficeツールGoogle Docsで、

計算表はちゃんと表として使っている。開発者ちゃんと開発をしており、反省会の準備や品質保証部の接待なんて業務はなく

純粋エンドユーザーだけを見ている。ここはなんて最高の環境なんだと歓喜した。また個人的にはおまけ程度であるが、

年収は30万ほど増えて大台に乗った。

さて、それから3年がたった。人間というのはい環境になれると対して喜びを感じなくなる、というのはそうだと思う。

今では別にdeployブランチマージされたらCIが走って自動テストが走りデプロイされるのも、だから何?

って感じだしま普通仕事として淡々とやっている感じはする。待遇面で悪化した点もちらほらあるし

(例えば年間休日が5日ぐらい減った、残業が月5時間ぐらい増えたなど)などもある。

ただ一つ言えることは前の会社には戻れないな…ということである人間一度生活レベルを上げてしまうと下げるのは

とても苦痛に感じてしまものである

ただ、一つだけ今の会社転職してよかったと感じ続けられることが一つある。それは人だ。

前の会社では家でプログラムを書いているなんていった日にはおちょくられたり、人生楽しいの的な目で見られたりした。

芸能人ゴルフの話ができないとコミュ障扱いされた。そのため仕事の話はしても、飲み会にはできるだけ行きたくなかった。

でも今の会社では雑談としてFastlyが落ちても大丈夫CDN構想とか、AtCoderの話をして盛り上がることができる。

ダイバーシティなんていうが、人間所詮同質な人間同士で集まったほうが快適なんだな・・・という複雑な思いを抱いている。

追記

皆さん読んでくれてありがとうございます。いくつか質問が出ているので答えられる範囲で答えます

真面目な疑問なんだけど、Java5のコード書いてる人を1000万で雇う会社があるの?どういうモチベーション??

製品自体90年代から脈々とバージョンアップしている企業向けのソフトウェアなので、コードベースが古いというのがあります

またユーザーからすると中身がJava17だろうがJava5だろうが関係ないわけで、要は業務が滞りなく進めばよいわけです。

そのため昔から受け継がれたスパゲッティコードを地道に解き明かし、新しく出てきた要件を今までのコードベースを壊さずにバグなしで追加していく、

もとからあったバグについては、その他の数百万行のユニットテストもないコードに影響なしで修正を施す、といった技能必要になります

こう考えると意外と希少なスキルなんだな・・・と思えるかもしれません。

clearcaseよりもsubversionの方が100億倍導入も運用簡単だと思うんだけど品管どうなってんの?

ClearCaseご存知な方がいるんですね!一から作る製品だとSubversionのほうが簡単かもしれません。ただ、ClearCase専用の

社内ツールがいくつかあり、そのツールで出力した情報を社内資産として持っているという理由があったりします。

例えばお客さんから「この機能バグってるっぽい」というクレームを受けた際、その機能周辺の情報をそのツールから検索し、

コードレベルで再発防止策を関係部署総出で練った上でお客さんに回答する、という運用フローになっています

そのため、Subversionに変えるためには開発陣の一存では無理で、品質保証部やマネージャー層など全ての知識アップデート

必要になり、そこまでコストをかけて説得して回る必要はあるのか・・・という話になってしまうわけです。

ただ、社内の生産性を向上させるのが目的部署としてはSubversionGitを社内に浸透させたがっているのも事実で、

新規プロダクトなんかはGitを使っていました。ただしGitHubプロキシでアク禁されているだけでなく、サービス名名指しで使用禁止

になっているので、相当の理由がない限り使えないかと思います

主任クラスでも1000万円近くもらえるのか。すごい。

1000万という数字に興味のある方が多かったので参考までに書いておくと、等級ランクというもの存在して管理職を除く最上位のランク

なると2人の子持ち、賃貸住まい、標準評価で大体900万になるという感じです。年功序列だが部署ごとに違うというイメージで、

研究所だと20代で到達する一方、利益を上げていない事業部や間接部署だと定年間際まで到達しない人も多い、ぐらいの感じです。

平均では30代中盤ぐらいでしょうか。

ちなみに私の場合は基本給は33万程度ですが、そこに裁量労働手当と住宅手当、家族手当がついて月給で50万を超えるぐらいでした。

ボーナス個人評価よりも部門業績に大きく左右されるのですが、部署が最高評価場合は夏冬とも150万以上でした。

最後最後ダイバーシティについては、ダイバーシティ勘違いしているように思う

なるほど、たしかに。ちょっと言葉の選びが悪かったかもしれないですね。

2021-06-06

プログラマはなるべくコードを書くな」という言説

経験豊富プログラマほどこの言説をすっと理解して、経験の浅い人ほど理解できないらしい。

よくある誤解に「学習のためには車輪の再発明をした方がいい」というものがある。

これは間違っている。学習のためであっても、既製品劣化コピーを作るよりも、既製品を利用した方が学ぶものは多い。

たとえば、初心者データを保存するしくみを試行錯誤して実装したところで、既存リレーショナルデータベースよりも良いものができるはずがない。

一方、最初からデータベースを使っていれば、単にデータを保存すると言う目的を達成するだけではなく、主キーや外部キーインデックストランザクションSQLなどの重要概念を学ぶことができる。

プログラミング初心者車輪の再発明をするのは将棋で言えば、駒の動かし方を覚えただけの初心者が「一手目は76歩がいいのか26歩がいいのか」なんてことを延々と考えているようなものである。そんなことに意味はない。そんなことをするより、さっさと定跡を覚えた方がよい。

さて、経験豊富プログラマほど「コードを書くな」というのがすっと腑に落ちるのは、それがどういうことなのかを理解しているからだ。

たとえば彼らは、「設定より規約」という概念について、具体的な実例とともによく理解している。

一方、経験の浅いプログラマは、設計コーディング能力も低いし、複数パラダイムや良いフレームワークにも触れたことが無いから、「コードを書かない」というのが何を意味するのか理解できない。だから、「コードを書くな」という主張も理解できない。

2021-06-01

python場合組織コーディングスタイルを制定するより「PEPに従え」と言ったほうが効率よいと思ってて、オープンソースコードを使う場合も大抵PEP使っとけば整合性取れる。

ただ、なんでGoogleがインデントでスペース4ではなく、スペース2を採用しているか謎でめんどいのだけど。

追記

いっとくが、俺は「Googleに勤めてる」なんて一言も言ってないからな某JO。エンジニアしてりゃGoogleの公開したコードを使うことぐらいあるんだよ。

2021-05-27

職場での挨拶問題

職場での挨拶について定期的にはてブ話題になるが

そのたびに自称プログラマーくんの

コーディングに集中しているとき挨拶されると集中力きれるからやめてほしい

みたいなコメントがあってうぜえ

あのなあ、職場はお前の子供部屋じゃねえんだよ

所詮仕事なんてコミュニケーションが一番大事なの。てめえのせいで職場雰囲気が乱れて全体の出力が下がったらおまえ責任とれんの?

あー、いま「そんな古臭い職場は糞だ」と言おうとしただろ。わかるよ。

でもお前が現に働いてるのはそのクソの職場なんだよ。いいかげん自覚しろ。お前もそのレベルなんだよ

つーか、どーせ挨拶しないのがカッコいいとか思ってんだろ?集中してる俺カッコいいとか思ってるんだろ?

その気持わかるよ、俺もそう思ってた時期があったからな

早くお前が大人になってくれるのを願ってるぜ

あと、コーディングなんて集中力不要単純作業だろ。

ちゃん設計しろ設計設計とき集中しろ。頭を使わずに手を動かしちゃうタイプなの?

anond:20210527102458

CLIプログラミング環境って話があまり一般的な話ではないから誤解した。

というのも、Androidアプリとかを作りたい場合環境GUIになるのは必然だが、インフラ側で動作するスクリプトを書く場合は、GUIのない環境CLIだけでコーディングする場合があるからCLIを使う場合も多い。

からプログラミング環境の話で言えば、それは単に文脈依存して切り替えるのが良いってだけの話になる。

ちなみにCUIって言葉を好むのは極東人だけ。

完璧主義を克服したい

https://blog.tinect.jp/?p=70708

巧拙速という言葉があるらしい。

下手で良いからどんどんアウトプットしろという中国のなんか偉い人の格言だ。

冒頭に貼った記事で改めてその格言を思い出し、

「あ〜これ俺が未だに出来てないやつ、、こんな親が居たらもうちょっと楽に生きれたかな」とちょっと親のせいにした自分に気づいて凹んだ。

訳あってweb制作勉強を始めて、独学でどうにかこうにか学んでポートフォリオサイトを作るところまで来た。

勉強を始めてから自分完璧主義を改めて自覚し、修正を試みながら取り組んできたつもりだけど、それが中々上手くいかず、仕事に出来たとしてもこなせるのか不安要素になっている。

数をこなさないと速度も質も上がらない。

巧拙速を知ってからそれを散々頭に言い聞かせているのに、いざ制作が始まると、出来るだけ良いものにしたいという意識が段々強くなり、自分で立てた締め切りをぶっちぎる。

記事にもあるような「まずは試作品作るくらいの感覚で作って、見せたりフィードバック得ながら整えようぜ」理論完璧主義修正に一番必要視点だと言うのはよく分かる。

ただ、「試作品」のレベル感が全然からない。

デザインを見せたかったらデザインとして作り切ってないといけないと感じるし、コーディングを見せたかったらコーディングとして機能を作り切ってないとフィードバックをもらう意味がないのでは?と思ってしまう。

見る側も本気で作ったものレビューしたいはずだし、適当ものを出すのは失礼だと感じてしまう。

その辺のさじ加減ってみんなどうしてるんだ?全然分からん

自分が納得いっていないものを人に見せる、ということへの抵抗がやたら強いという要素もあるのだろう。

数こなしてない自分の納得感なんて大したものじゃないとこれを書いている今は思うけど、作ってる時はそういう客観性も吹っ飛んでしまう。

結局はバランスで、適当にやりすぎても何も残らないと思うし、良いものを作ろうという気持ち自体

悪いことでは無いとも思う。

ただ、その気持ちスケジュールという優先順位無視し始めることが問題

毎日継続することだけは出来ているだけに、このバランス感の無さが悔しくて悔しくて悔しくて悔しい。

この文章も1時間くらい費やしてしまってるやばい

その割には大したアウトプットにはなっていないのだろう。

有能なはてなの皆さん、お知恵をお貸しください。

2021-05-26

anond:20210526083319

PCの利点の一つは、コーディングすれば当該の作業などを自動化できることだと思うので、頭が良くなるかどうかはわからないけど生産性は上がる場合がある。

2021-05-23

休日勉強する正義か?

エンジニアは、「休みの日も勉強しないと行けない」「休み日もコーディングしてる」という話がある。

ビジネスサイドも同様に、休みの日でも勉強仕事をしてる。それに反意があるのも知ってる。

しかし、やっぱりやってる人とやってない人で大きく差が付く事は確かである

北欧の何処の国か忘れたが「日曜日はお店を閉める事」という法律が出来た。

その国の人々の多くは、法律に従って店を閉めた。そして、休み謳歌した。

が、アジアから移民の店は方を破った。日曜日一生懸命働いたのだ。

結果、その店は儲かり、他の店は衰退していった。

この場合無理やり法律で縛ったから、日曜日開けた店は違法であり、悪者だが法律がなければ勤勉な店である

何を言いたいかというと、休みの日に勉強禁止する法律を作ってくれないかな。

anond:20210522230533

なるほど、コーディング規約最初に作っとくべきだったね。リンター実行して、きれいにしとけばよかった感じか。

2021-05-18

機能につきひとりで設計コーディングテストをやる想定のプロジェクトに居るのだが

派遣おじさんが無能コーディングさせられん

そいつコーディングとお前のテストタスク交換して進めろってことになった

テストバグがあると俺に直せと飛んでくる

俺の負荷だけ倍になってないかこれ

ログイン ユーザー登録
ようこそ ゲスト さん