以下はMadza( Twitter / GitHub / LinkedIn / Webサイト )による記事、65 Things I wish I knew when I started to Code 🌱🚀の日本語訳です。
65 Things I wish I knew when I started to Code 🌱🚀
1.Coding is about problem-solving.
コーディングは、問題解決の手段である。
コンピュータの前に座って適当にキーボードのボタンを押しまくることだけがプログラマの仕事ではありません。
それは現実世界の様々な問題を解決し、人々の生活をより快適にするための強力な手段なのです。
あなたにその力があるかぎり、あなたは守られるでしょう。
2.The golden rule is planning.
最優先すべきは計画である。
プロジェクトの成功は、計画を立てることから始まります。
誰に向けたプロジェクトなのかを認識し、ゴールを明確にし、タスクを立てましょう。
紙とペンでも、オンラインのワイヤフレームツールでも何でもいいので、あなたのソリューションがどのような姿になりたいのかを明確に描きましょう。
3.The content is king.
コンテンツは王様である。
コンテンツがないかぎり、あなたのサイトは空です。
静的コンテンツを扱っているのであれば、それが適切に表示されることを確認しましょう。
動的コンテンツであれば、コンテンツをどのように作成するか、もしくは受け取るかを想定し、コンテンツに基づいたデザインとコードとデータベース構造を作りましょう。
4.Coding should be the last phase of a project.
コーディングはプロジェクトの最終段階。
初心者の人は、全てのプロジェクトはコーディングから始まると考えているかもしれません。
本当は、問題を解決するためにそれ以前に行われた全てのプランを技術的に実装するだけのフェーズにすぎません。
5.You have everything at your fingertips.
指先ひとつでなんでも手に入る。
勉強するためには図書館に行かなければならなかった、1950年代や60年代のような時代ではありません。
必要な情報は全て手に届く範囲にあります。
インターネットとあなたの頭脳を駆使しましょう。
6.You don't need extreme hardware to code.
高性能なハードウェアは必要ない。
最先端のプロセッサ、大量のメモリ、そして5枚のディスプレイはまだ要りません。
始めるのにはミッドレンジのノートパソコンでも十分です。
7.You don't need to be great at math.
数学に強い必要はない。
映画ではしばしばIQ200の天才がコーディングしています。
AI、ロボット工学、暗号などのトピックでは数学も重要になってきますが、まず始めるだけなら基本的なことさえ知っていれば十分です。
8.Finding the right workflow is not easy.
正しいワークフローを見つけることは困難。
開発者の好みは一人ひとり異なります。
様々な設定や拡張機能を試してみましょう。
どんな環境があなたにぴったりであるかを見つけ出すには多くの時間がかかるでしょう。
しかし、その時間は後からあなたの生産性という形で返ってきます。
9.The perfect timing is now.
今が最高のタイミングだ！
ブックマークに登録するのは、ただの先延ばしです。
プロダクトを始める最善の策は、今始めることです。
10.Syncing makes you mobile.
同期化こそがモバイル化だ。
ブラウザやIDE/エディタの拡張機能や設定を、全てのマシンで同期しましょう。
これによって、どこにいても同じ環境で仕事できるようになります。
11.There are multiple ways of achieving.
道のりはいくらでもある。
コーディングを始めるまで、ロジックは非常に厳密なものであり、決められたパターンに従ったコーディングを行わなければならないと思っていました。
しかし実際は、厳密なのは言語の構文だけでした。
12.Naming things is hard.
名付けは難しい。
一見簡単なことに思えるかもしれませんが、プロジェクトが大規模になるほど、それがどれほど難しいことなのかがわかるようになるでしょう。
13.Take mistakes as lessons.
失敗は教訓である。
どんな成功体験も、トライ&エラーの果てにあることに気が付くでしょう。
好奇心としつこさこそが鍵です。
14.Recreating is 10X easier than writing ground-up.
作り直しは10倍楽。
既存のアプリを作り直すときには、プロジェクトの構造やレイアウトをおおまかに理解しています。
そしてその理解こそが、しばしば最も困難なところです。
15.It's important to find your niche.
自分のニッチを見つけることが重要。
ニッチからニッチを彷徨っても、その先は何処にも通じていません。
興味のある分野をはっきりさせておいて、そこに飛び込む前に十分に調査しておきましょう。
16.Be curious about why things work.
物事が働いている理由に興味を持とう。
それがどうしてそうなっているのか、常に深く観察しましょう。
魔法のように動いているところを見るだけで満足しないでください。
17.Tools are your keys to productivity.
ツールは生産性の要。
人の良し悪しは道具の良し悪しで決まります。
適切なツールスタックを作ることに相応の時間をかけることで、その後に大きな利益を得ることができます。
18.Passionate projects keep you going.
情熱こそが継続の鍵。
趣味のプロジェクトは、本当に興味のあるものを選んでください。
その選択が、最終結果に対するモチベーションに多大に影響するでしょう。
19.It's a marathon, not a sprint.
プログラミングはスプリントではなくマラソンである。
プログラミング開発は常に進化し続けています。
継続的に学習を続けていく準備をしましょう。
一気に駆け抜けようとすると、すぐに疲れてしまいます。
20.People you follow are the information you consume.
フォローは情報の質に直結する。
ソーシャルメディアではフォローする相手に注意を払いましょう。
あなたが目に入れる情報の質、身体に取り入れる情報の質に直結します。
21.Do not reinvent the wheel.
車輪の再発明は不要。
プロジェクトを始める前に、同じような課題に対して他の開発者が使ったツールを探してみましょう。
大抵の物事には解決策が既に存在しているはずです。
22.It's easy to get carried away.
我を忘れるのは簡単。
コミュニティに参加するのはとてもよいことで、より優れた技術や、よりモダンなUIを知ることにしばしば繋がります。
しかし、だからといって現在使っている技術スタックは古臭くて悪いものではありませんし、新しくてモダンな技術に必ず乗り換えなければならないということでもありません。
23.Tutorials often mislead you.
チュートリアルはしばしばミスリードする。
チュートリアルは、大抵は最初から最適化された形でコーディングされています。
そのコードと、あなたが自分で書いたコードを見比べると、あなたは途端にやる気を失うことでしょう。
あなたのコードは、時間をかけて作ったわりにクリーンでもないつぎはぎコードだからです。
チュートリアルはあくまでコードの明るい面だけを取り出したものであり、実のところ裏では多くの開発者も苦労しているものです。
24.Tutorials won't make you independent.
チュートリアルだけでは独り立ちできない。
チュートリアルを見たり読んだりすることは、技術の概要を知るためにはよいことです。
しかし、それだけのものであってその先に進むことはできません。
公式ドキュメントを読んだりして分析力を養い、自分なりのソリューションを見つけ出す必要があります。
25.No tech is perfect.
完璧な技術はない。
あらゆる技術は、それぞれ長所と短所を持っています。
現在のタスクに迷った場合は、選択肢を並べて、それぞれのタスクへの取り組み方を調査してみてください。
26.Your ability to pick up stuff matters.
選定眼が大事。
企業に応募する際は、その企業がメインとする技術スタックに精通していない可能性が高いでしょう。
重要なことは、どれだけ多くの技術を知っているかではなく、出会った技術をどれだけ早く取り込めるか、ということです。
27.Version control is a must.
バージョン管理は必須技能。
クライアントはしばしば変更前のデザインを求めてきたり、要求が二転三転したりします。
バージョン管理は多くの手間を省き、そして過去のコードがバックアップされていることを保証します。
28.Bugs can be really intimidating.
バグは本当に恐ろしいものだ。
修正に何時間も、あるいは何日もかかる困難なバグに備えておきましょう。
その間は他に何もできなくなりますが、そこを乗り越えさえすればきっと大きく成長できるはずです。
29.Learn what not to learn.
不要なものを見抜こう。
我々は皆、膨大な技術情報の海で溺れています。
現代におけるもっとも優秀なスキルのひとつが、何を学ぶ必要が無いかを学ぶことです。
30.Reading code makes you better, too.
成長にはコードリーディングも不可欠だ。
コードを書くことは、自分が知っていることを振り返ることです。
同じように他の開発者のコードを読むことも重要で、様々なデザインパターンやベストプラクティスを知ることができます。
31.Be humble and others will respect you.
謙虚こそがリスペクトの鍵。
内面では図に乗っていたとしても、外面は謙虚にいきましょう。
自慢話にはみんなうんざりしています。
32.Being a perfectionist will slow you down.
完璧主義より完了主義。
量より質を目指すことはよいことです。
しかし、それを目指しすぎると、半端に投げ出されたプロジェクトの山に埋もれることになります。
33.Open source is awesome.
オープンソースはすごい。
個人から大企業まで、オープンソースのコミュニティは大きく広がっています。
それはすばらしいことで、そしてよりよくなっていると私は信じています。
他者が使っているベストプラクティスやデザインパターンをぜひとも学びましょう。
34.The diploma is optional.
学位は必須ではない。
クライアントは多くの場合、問題を解決するために卒業証書ではなく能力を必要としています。
35.Break it down when you get stuck.
行き詰ったときは、物事を分解せよ。
問題が大きすぎるため、解決することが難しく感じることがよくあります。
そんな場合は、問題を小さな部品に分けて、それぞれに少しづつ取り組んでみましょう。
36.Corporate companies need you for CRUD apps.
企業はCRUDを必要としている。
企業の中心は、CRUD業務です。
就職を考えている人は、日々勉強し、CRUDに備えておきましょう。
37.The project is never fully finished.
プロジェクトが完璧になることはない。
あらゆるプロジェクトはさらに改善することができ、さらに最適化することができます。
プロジェクトが要件を満たしているのであれば、それが提出のしどきです
38.Good code is easy to read and maintain.
良いコードとは、読みやすくメンテしやすいコードである。
一人で作っているかどうかにかかわらず、常に他の誰かが触ることを前提としてコードを書きましょう。
難しいところには処理内容を記載したコメントを残してください。
39.The first language is always the hardest.
最初の言語が一番難しい言語だ。
どの言語が一番難しいかはよく話題に上がりますが、実際のところ、言語の学習難易度はそれまでのあなたの経験に依存します。
40.Googling and using Stack Overflow is acceptable.
ググるのもStack Overflowるのも仕事のうちだ。
それらのリソースは、あなたを助けるために存在します。
GoogleやStack Overflowを使うことを恥じる必要はありません。
みんな使っています。
41.Communication skills are underrated.
コミュニケーション能力は過小評価されている。
コードだけでプロジェクトの成功が決まるとは限りません。
他者とコミュニケーションを取り続けることは重要です。
42.Sharpen your negotiation skills.
交渉力を磨こう。
いくら最先端の技術を知っていても、交渉の仕方を知らなければただの持ち腐れです。
43.Having an online presence is important.
オンラインでの存在感は重要です。
いくらローカルで大量のプロジェクトを回していたとしても、誰も知らなければ存在しないのと同じです。
うまくプロモーションして、オンラインでの存在感を高めましょう。
44.Always be aware of the 20/80 rule.
20/80ルールを常に意識しましょう。
プロジェクトの最後の20%が、プロジェクトにかかる時間の80%を占めることを心得てください。
クライアントに進捗を報告する前に、このことを思い出してください。
45.Don't over-engineer without a cause.
理由もないオーバースペックは害悪。
追加する機能がなくなる状態を目指すのではなく、削除する機能がなくなる状態を目指すことが最良の手段です。
46.Frameworks come and go.
フレームワークは常に入れ替わる。
フレームワークのベースとなる技術を学び、必要に応じて特定のフレームワークを選択できるようになることのほうが、より価値があります。
47.Knowing something well is better than pretend to know a bit of everything.
全てのことを少しずつ知っているよりも、とあることを詳しく知っている方がいい。
あらゆる物事を知ろうとするのではなく、興味のある分野について調べ、ひとつの技術を深く学びましょう。
何でも屋になろうとすると、何も知らない人になってしまいます。
48.Testing is there for a reason.
テストが存在するのには理由がある。
テストを書く習慣をつけましょう。
最初は不要な作業をしているように思えるかもしれません。
しかし、特に大規模なコードにおいては、テストを書くことで多くの時間を節約できるようになります。
49.Achievements boost your motivation best.
成果がモチベーションを加速する。
閃きを得たとき、新たな概念を自分のものとしたとき、ユーザが驚くのを見たとき、自分の仕事に価値を感じたとき。
それらはあなたのモチベーションの燃料となることでしょう。
50.Do not put up more than you can carry.
持てる以上の荷物は持たないようにする。
新しいことを学ぶために十分に挑戦的であり、しかし手に負えないほど巨大すぎはしない、そんな課題を見つけましょう。
51.Do not compare yourself to others.
他者と自分を比較しないこと。
他の開発者の成果と比較してしまうと、自分に苛立ってしまうかもしれません。
自分のペースで学習すればよいのです。
52.Do not take criticism personally.
アプリへの批判と個人への批判を混同しない。
建設的な批判は貴重なフィードバックであり、自分だけでは気付かなかったミスや改善点を指摘してくれるものです。
最終的にはより良い製品を作り出すために役立ちます。
53.Everyone has written a bad code.
みんなもだめなコードを書いている。
数年前に書いたコードを見直して、信じられなかったり恥ずかしいと思うかもしれません。
しかし、それはあなたが確実に進歩しているという明白な証拠です。
54.One finished project is better than 10 half-finished ones.
10の断片よりも1の完成品。
一度に取り組むプロジェクトはひとつかふたつにして、アイデアと実行のサイクルを回すようにしましょう。
最後までやり遂げることが大事です。
55.The best way to learn is by teaching others.
最も効率の良い学習法は、人に教えること。
何かを他人に教えるためには、自分はそれ以上に詳しくなければなりません。
それはあなたが本質を知ることを意味しており、そして知識を共有することで皆がハッピーになります。
56.You are never ready to apply for a job.
求人に応募する準備が完成するときは来ない。
コードを学ぶことは道程であり、決して目的地ではありません。
従って、あなたは常に何かをやり切っておらず、中途半端だという思いを抱くことはないでしょう。
そんなことは気にせずとにかく応募しましょう。
57.The hype train is real.
トレンドを乗りこなせ。
トレンドには注意を払いますが、深くは入り込まず主要なユースケースと動作原理を理解するにとどめましょう。
そうすれば、必要に迫られて実際にツールを選ぶことになったときに、どのツールがどの問題を解くのに適切かを判断できるようになります。
58.Practice leads to mastery.
練習こそが早道。
繰り返しは全ての知識の母であり、何かをマスターするための最も安全な道のひとつが、それを粘り強く練習し続けることです。
59.Focus on the indexes, not the content.
注目すべきはインデックスであり、コンテンツではない。
こんにち重要なのは、情報を早く見つけることです。
何が必要か、そして何処を見ればいいのかが一度わかってしまえば、あとは時間をかければどうにかなります。
60.Be a sponge for knowledge.
知識を吸収するスポンジになれ。
知識と競争力を維持するために、日々学び続ける習慣を身につけましょう。
誰に学ぶかには細心の注意を払い、量より質を求めましょう。
61.Learn to say no.
NOと断ってやることだ。
何事も断らないでいると、遅かれ早かれ他人がそれを利用し始め、必要以上の仕事に埋もれてしまうことでしょう。
62.Note-taking is your rescue for writing block.
メモはアイデアの救済である。
何をしているときでも、どこにいるときでも、常にアイデアを追い求めましょう。
それでもインスピレーションがわいてこないときのために、記録を残しておきましょう。
63.Schedule the week and prioritize.
スケジュールを立て、優先順位を決める。
計画を立てるためにいくばくかの時間を割きましょう。
しなければならないタスクを特定し、実行する順番を決めることが容易になります。
64.Taking breaks make wonders.
休憩には不思議な効果がある。
行き詰ったら、しばらくコーディングとは全く関係ないことをしましょう。
家族と一緒に過ごしたり、趣味に時間を費やしたり、ジョギングしたりしましょう。
再度プロジェクトに向かい合ったとき、不思議と簡単に解決策を思いつくことがよくあります。
65.Sports and proper sleep boost productivity.
適度な運動と睡眠が大事。
8時間の睡眠と4時間の仕事は、4時間の睡眠と8時間の仕事よりも多くの仕事をこなすことができます。
さらに定期的な運動も行い、最適なコンディションを保ちましょう。
文章を書くことは私のパッションであり、あなたの助けになることを嬉しく思います。
質問があれば気軽に尋ねてください！
Twitter、LinkedIn、GitHub、そしてDEVのフォローもよろしく！
他の記事も読みたかったらブログもチェックしてね。
コメント欄
「よい記事。みんなにシェアする。」
「初心者だけど学ぶべき情報やスキルの量に圧倒されてしまうから65番を守る。」
「『People you follow are the information you consume』『It's a marathon, not a sprint』まことに真実なり！」
「『Learn what not to learn』が心に響いた。」
「29番すき」
「『The golden rule is planning』だいじ。自分の経験から言うと、プロジェクト設計と、自分を管理できる開発者さえあればプロジェクトは成功する。」
「planningとは、時間割のことではなく、カレンダーのことでもない。何をすべきか、どのような順序で行うかを考えること。」
「4番はウォーターフォール前提だから同意できない。ほとんどのユーザは自分が何を求めているかわからないからね。」
感想
開発に関する心構えを説いた、参考になるテキストです。
ただ、全部いっきにこなそうとすると却って疲れるのは間違いないので、気になった幾つかをピックアップして心にとどめるとよいでしょう。
私は特に64番と65番を重点的に守っていこうと思います。
あと20番「People you follow are the information you consume」も大事だよねーと自分のフォローを見てみたところ、技術関連のユーザがほぼ全くいなかった。
海の向こうでも声が上がるということは決して日本だけの問題ではないということですが、日本では特に41番「Communication skills are underrated」42番「Sharpen your negotiation skills」あたりは軽視されているような気がしますね。
給与がとか労働時間がとか文句を言うのはいいけれど、文句を言う前にやることをやったのかと。
誰もが「誰かが何とかしろ」と言うばかりで誰も自分で何とかしようとしないという。
私？私はべつに誰かが何とかしろとか言ってませんし。