Q&A
要るものを取り入れ要らないものを切り捨てるその境界線を決める判断力と、僕が何をしたいかじゃなく相手（客だったり市場だったり世界中だったり）のために何が出来るかで考えられる視点とが必要、という風に理解しました。ありがとうございます。
###前提・実現したいこと
スキルアップを好循環でしたい
###環境
- プログラミング歴36年。
- 現在フリー。
- 時々仕事が来てPHPを使ったWebアプリや簡単なスマホアプリを作る程度。
- 自宅で１人でやっている。
###今までやった分野
BASIC, C, C++, java, html, javascript, css, UNIX, bash, VB, ExcelVBA, SQL, PHP, Objective-C, swift
どれをとっても初級者レベルです。
###頼みの綱
- teratail
- 高い書籍
何かを始めようと思ったときにはWebで調べるか3,000円級の書籍を買うかで迷います。大抵はWebでしばらく頑張って、時間と労力を考えて本に走るパターンが多いです。
###エラーメッセージ
Emergency: You are under construction FOREVER.
と言うのはジョークですが。
###該当のソースコード
txt
1とある人：「コンピュータは自分の言うことを聞いてくれるから好きだ」 2僕：「コンピュータが自分の言うことを聞いてくれないから苦手」
###よくやる過ち
- 細部にこだわりすぎて全体を見失う
- 1人でやっているので声をかけてくれる人もいなくて、集中してて気づいたら時間だけが経っている
- 聞ける人がいないので、簡単なアドバイスで分かることに丸1日かけたり
###淡い期待
- コワーキングスペースがあるのでそこに通ったら色々情報が入ってくるかも
- MANABIYAで何かつかめるのではないか
###アドバイスをお願いします
色々手を出してきたのですが、実務に耐えるスキルはごく一部です。使えないから仕事にならない、仕事がないからスキルが上がらないの負のスパイラルです。
もっとスキルを付けたい気持ちでいっぱいなのですが、どうやったら、もしくは何を意識したら出来るのか、アドバイスを頂けますでしょうか。
よろしくお願いします。
###補足 2017.12.24 14:26
補足させていただきます。
「スキルアップのコツを教えてください」と言うのは、出来るエンジニアさんが普段どんな事を考え、どんな事を実践しているのかということをお聞きしたかったのです。
例えばですが「プログラマの三大美徳」ってありますよね。得たスキルをアウトプットすると身につくという話を聞いたこともあります。
駄目なエンジニアに共通する点というのも恐らくあるんだろうと思っています。自分は長時間集中してるつもりで行き詰まり、我慢していたトイレに行ったらすぐに分かったとかはあるあるだと思います。
駄目なエンジニアが出来るエンジニアになるためのアイデアがあったらブレイン・ストーミング的にぽんぽん挙げていただきたいというのが質問の主旨です。
回答11件
0
36年で「どれも初心者レベル」という質問文をみてぎょっとなりましたが、
質問文や回答の履歴を見たところ、初心者というには懐が深く、謙遜しているだけとお見受けしました。
もしくは、比較する対象の人間が居ないので自信があまりないだけかもしれません。
フリーランスで仕事がぼちぼちくる時点でエンジニアとしての絶対経験値量では
そこらのエンジニアの平均よりは確実に上でしょう。
そこで、最も基本的な所から一度見返してみましょう。
エンジニアリングやプログラミングに限らず、上達する要素として以下が上げられます。
- 自分が出来る精一杯の事を頑張って行う
- 数をこなす
- 自分の行いを振り返り反省する
- 物事の本質や根幹に触れて理解する
これは自分のスキルレベルによりフェイズがあります。
一段抜かしにすることは出来ません。
自分に足りないのはどれかを知っているのは自分だけなので、胸に手を当てて考えてみてください。
1は脳科学の内部モデルの話です。
人間は新しい事にチャレンジして試行錯誤すると脳にストレスが溜まり、疲弊・損傷します。
その状態で睡眠をとると、身体の動き、頭の考え方をアップデートさせます。
ただし、このサイクルは非常に疲れます。
人は一人前になると同じことや慣れた事を好みますが、疲れるのを嫌がる人間の深層心理に基づくもので、
歳を重ねても継続的に新しい物を吸収し続ける気概のある人間は多くありません。
ですが、頑張って新しい事にチャレンジし、ヘトヘトになったら寝たら翌日出来る様になる。
このメカニズムを知っていれば「自分はこんなに時間を掛けたのに出来るようにならない…向いていない事に時間を掛けて損した……」とは思わずに済むので気が楽になります。
プログラミングの世界でも同じ事ですし、例を上げるまでもありませんね、次。
2はよほど普段何も考えずに生きている人間でない限り、
ある程度数をこなすことで、自然に身体が慣れ、必勝パターンを編み出して楽勝になります。
生まれてきて数度しかバットを振ったことの無い人間が、
プロ野球選手と対峙してホームランを打てるわけがないので数をこなしましょう。
これもプログラミングの世界でも同じです、次。
3は内部モデルの再強化を測ります。
例えば将棋道場等に行けば将棋歴うん10年のおじいちゃん連中が毎日集まって将棋を指したりしています。
どんどん上達していく人も居ますが、さっぱり上達しない人も居ます。
両者の違いはなんでしょうか？才能？…ですが才能の一言で片付けるには早計すぎます。
人は数をこなす事で自然と身体や頭の使い方を最適化してアップデートしますが、
機械学習に於ける「局所解」というべき現象に簡単に陥る欠陥があります。
これを癖と呼びます。
この癖を取り払うのに、自分の行動を客観的に見直し、
頭に「この方法じゃダメなんだ」と思い知らせて再度内部モデルのアップデートを促します。
将棋では棋譜、麻雀では牌譜、対戦格闘ゲームではキーディスプレイ付きの動画、
スポーツなんかでも自分のフォームを録画して…という風に客観的な視点から見つめ直すということをしない限り、一定ラインの実力で停止します。
プログラミングの世界では以下の3つが助けになるでしょう。
- GitHubやブログ等に自分のコードや設計等の思考プロセスを載せる
- 設計しきる事を諦めてコピペやゴリ押しに頼って完了させた仕事の見直し
- 勉強会での発表
オススメは勉強会での発表です。
人に聞かせるということは、あまりにも馬鹿げたものは見せられませんし、仕事ではないとはいえ納期もあります。
その中である程度しっかりした結論を作り上げる事は力にもなります。
また、発表を通じてマサカリが飛んできたり、自分であれは失敗だったな…と思う点も多々存在します。
結果として反省のプロセスにダイレクトにぶつかるから、成長しやすいと言えるのです。
4、物事の本質ってなんでしょうか？そしてそれの理解は必要なのでしょうか？
私は質の安定化の為には必要不可欠だと考えます。
子供のなんでなんで？攻撃がありますが、
それを大人になって得た技術力を駆使して掘り下げて行くと見えてくる世界があります。
その場の気分でAかBかを決めていた事が、
このケースではA、このケースではBと明確に見えるようになってきます。
隣接知識も貪欲に追い求めるようになり、どんどん行動の意味に深みがましてきます。
これは言語化出来ないジャンルで、言葉にすると陳腐な事しか言えません。
私のプログラミングに対する姿勢はこんな感じですね。
同意できるものは是非持っていってください。
- 動けばいいやな考えは捨てる
- コードのコピペはしない(プログラミング言語が持つ強力なループ文や抽象化の設計力で事足りる)
- 次が楽になるように宿題を潰して品質を安定化させる
- 数をこなすためにタイピング速度が遅ければ速くする、Typing.ioでWPM50以上の人はCLIでの操作をメインにしたほうが数をこなせるようになる
- リファレンスを見るだけではなく、自分の手でコードを打ち込んで結果を見る
- 英語の一次情報に触れる、英語が苦手ならQiita等で事前情報を仕入れても良いけど、必ず一次情報のサイトが正であり、他は一定ライン以上信じてはいけないという認識を持つ
- リーダブルコードはいいぞ、コード全体の品質が良い方向で安定化する
- オブジェクト指向プログラミングはいいぞ、比喩を用いた平易な文章でコードを表現する能力が鍛えられる
- 関数型プログラミングはいいぞ、関数の切り出しの抽象化のセンスがよくなる
- あらゆる物をコード化しよう、その為には覚える事はまだまだ星の数ほどある
例えばExcelの試験項目表じゃなくてプログラムの自動コードならパソコンが裏で勝手にテストしてくれるでしょ？
インフラの構築をWordの手順書じゃなくてAnsibleのPlaybookとかにしておけば新しくジョインした人に渡して読ませたり実行して環境作ったり出来るでしょ？
投稿2017/12/24 15:44
総合スコア21158
0
プログラミング歴36年
大ベテランの質問者の方に対して、アドバイスなどというとおこがましいので、
業績がある人の思考に対する、私自身の解釈を書いていきます。参考になれば。
どれをとっても初級者レベルです
バフェットという世界的大富豪の投資家がいます。
資産で彼にかなう人はteratailにいないと思うので（笑）、
ビジネスについての話なら、素直に聞けると思います。
重要なのは、
自分の能力の輪をどれだけ大きくするかではなく、
その輪の境界をどこまで厳密に決められるか
こう言ったバフェットは、コカコーラの株を買っています。
誰でも知ってる会社の株を、早い時期に買って成功したんですね。
そして、グーグルといえば、まず検索エンジンですよね？
アマゾンといえば、まず通販サービスですよね？
両企業は、今なら誰でも知ってるサービスを、
早い時期から始めていたので成功しました。
だから、勝負するドメインを決めることが重要だと思います。
「選択と集中」とか言えばよくあるフレーズですが、
実際に成功したバフェットが言うと重みがあります。
そのときそのとき流行する技術に何でも飛びつくと、
どんどん能力の輪が薄く広がります。
そうではなく、境界を見極める必要があります。
ネットで人気のちょっとしたTIPSみたいなものは誤差の範囲で、
本当に差が付く部分は、こういう絞り込みが大きいと思います。
たとえばもし、本当に必要な技術だけに絞れれば、
言語などの技術の数を半分にするかわり、
倍の深さで技術を学ぶことができます。
何をやらないかが戦略です。一日24時間は人間みな同じなので、
優先順位をつけて、リソースを配分するしかありません。
だからこれは一例ですが、開発の話でいえば、技術の取捨選択が可能です。
Webアプリだけやる、スマホアプリだけやる、あるいは、Androidだけやる、iOSだけやる、
逆に、あえてデスクトップだけやるとか、ハイブリッドでマルチプラットフォームに展開するが、
そのかわりDBもサーバも使わず簡略化するとか、いろいろな絞り込み方があります。
さらに、場合によっては、それらすらもいらないかもしれません。
たとえば、成功するかどうかはともかく、プログラムは一切外部に公開しなくても、
株の自動売買ボットを作って収益化できるかもしれません。やり方はいくらでもあるでしょう。
そして、分野を絞り込む代わりに、機械学習なのか、仮想通貨なのか、
何らかの競争力のある技術を持ち込んで、付加価値を生み出していくわけです。
何が成功するかは分かりません。しかしいずれにせよ、すでに長い経験があるなら、
細かいスキルアップよりも、自分のビジネスを組み立てる方が大きい気がします。
細部にこだわりすぎて全体を見失う
今度はプログラミングの分野での有名人を参考にしましょう。
ケント・ベックは**XP（エクストリーム・プログラミング）**やTDDなどの先駆者です。
TDD（テスト駆動開発）などの開発手法が普及した一方で、
思想的な部分が広く理解されているとは言いがたいです。
XPでは、価値、それも顧客（や市場）の価値に、
フォーカスすることを重視しています。
テストやリファクタリング（で変更しやすくする）とか、
プロトタイピングとかコミュニケーションとかは、そのための手段です。
開発を反復するたびに、本当に必要な価値に迫っていくのが本筋で、
そうでなければ、行き当たりばったりのやり方になってしまいます。
ここで、話が飛躍するように見えるかもしれませんが、
**DDD（ドメイン駆動開発）**でユビキタス言語を使うことも、
結局、顧客の関心事（＝ドメイン）にフォーカスすることで、
ドメインに注力したい、問題を絞り込みたいわけです。
要するに、業務の問題と技術の問題がバラバラになってしまうと、
非効率なので、なるべく対応させようという点では同じです。
開発を反復するとか、ドメイン層を作るとか、やり方が別なだけです。
そして、グーグルのページランクだったり、アマゾンのリコメンドだったりは、
ユーザの需要に応えるものだったから、ビジネス的に成功したわけです。
あるいは、マイクロソフトやアップルは、GUIのOSを作りましたし、
成功した企業は共通して、ユーザの問題を解決する技術を提供しています。
その逆に、歴代ゲームハードは、市場で負けた方がスペックが高い、なんていう例もあります。
だから、ユーザ視点で最終成果物をイメージして、
そこから逆算して必要な技術、あるいは工程を考えると、絞り込みやすいです。
これが技術者視点だと、手段が目的化しやすいです。
たとえば、ソフトを使う体感速度で差が出ないなら、高速化しなくていいです。
経験を詰むと凡ミスは減っていきますが、その代わり、顧客や市場の声を聞いて、
慣れたやり方を捨てる勇気を持つ方がだんだん難しくなってきます。
ベテランになるほど、プログラムを書くのが慣れて早くなっていくでしょうが、
しかし、（不要な部分を）書かないのが一番早いので、
要件や仕様の見極めが重要になり、それは顧客や市場の価値が決める、というわけです。
長く続けてればプログラミングは自然と上手くなるでしょうが、
ユーザ視点とかビジネス的なスキルは意識しないと身につかないので、
たとえベテランの人でもそこが弱い、ということはよくあります。
私自身もわりと器用貧乏で苦しんだので、
ここで書いたような視点の転換は、
とても新鮮でしたし、今でも重要だと考えています。
投稿2017/12/24 13:10
編集2017/12/24 14:01
総合スコア5592
0
こんにちは。
私もプログラミング歴だけで考えたら似たような感じです。ワンボード・マイコンの時代からですし、現在個人事業で一人でやってます。
よくやる過ち
・細部にこだわりすぎて全体を見失う
・1人でやっているので声をかけてくれる人もいなくて、集中してて気づいたら時間だけが経っている
・聞ける人がいないので、簡単なアドバイスで分かることに丸1日かけたり
う～～ん、私はこの３つは良くやるのですが必ずしも「過ち」とは考えないです。
「細部にこだわりすぎて全体を見失う」拘った結果、スキルが身についていることも少なくありません。
「時間だけが経っている」悲しい事実かも。何かを得るための投資と割り切ってます。
「簡単なアドバイスで分かることに丸1日」最後はteratailや専門家の方へ質問して解決することもありますが、そこに至るまでに結構時間かけてます。もう少し早く質問した方がよいのですが、ついつい拘ってしまいます。その分、力がついているとも感じますが。
要するに「こだわりを過ち」と考えることを止めると技術が身に付きやすくなるかもです。
あと、細部にこだわり過ぎたと感じた時「自分はこれで何を得たのか」を振り返えると良いかもしれません。
ただ、ビジネス的には細部にこだわりすぎるとまずいんですよね。悩ましいです。
技術者として力がついてもビジネスに繋がらなければ役に立たないし。結局バランスですね。（自省を込めて）
投稿2017/12/24 06:36
総合スコア23272
なるほど。捉え方次第で悪も善に変わるんですね。
それと感じたのは自分がどういう状態なのかを把握してらっしゃる。「ここは時間をかけてでも」と客観視している。自分をモニターできてるかどうかは大きいですよね。
アドバイスありがとうございました。
0
36年やってきたなら自分に合ったやりかたくらい見つけておるぢゃろ。
投稿2017/12/24 01:48
総合スコア16614
ご指摘、もっともです。
そして、自分に合ったやりかたが拙いのでスキルも拙い現状となってます。
まぁ、今あなた「見つけておるぢゃろ」という言葉をお使いになったけどもね、私は自分の歳の分だけ生きてきたので初対面の方とのやりとりでの言葉の選び方くらいは知っています。
あなたとは違うんです。
そんなところも鑑みていただいてご回答をいただければ幸いかと思います。
> 自分に合ったやりかたが拙いので
なのでもっといい方法がないだろうか、との相談でしょうか。
「一人でコツコツ」がうまく回らんなら、どこぞのコミュニティに参加するのも手ではないかしら。
あと、僕だったら「コレだったら誰にも負けない」をひとつ育てますね。
あちこち手を伸ばしてどれも初心者レベルだと自分の腕を売り込めない。
0
ベストアンサー
私はmiyabi-sunさんの回答に大変共感していて、そのような行動指針を私自身持っています。
新しいアドバイスがあるわけではありません。
ただ、その上でtaroさんの場合チームで仕事をしてみるのが良いのではと思いました。
taroさん自身も1人であることを問題に上げていますし、テーマが「好循環」でしたので。
「動けばいい」と「こうでなければダメ」という匙加減はとても難しいもので、私は仮の作業はよくても本番となると結構「こうでなければダメ」が邪魔して作業が遅延する方です。
とりあえず動かす事と正しいデザインを追い求める事は常に相反する性質だと思っています。
私のチームにも「まず動かす」ことがモットーの人がいます。
私はどんなものが欲しいか考えた後、初期の作業の大半をその人に振ってます。
私は相手の作業中にリサーチし、依頼した仕事を評価できる状態になることを目指します。
そうして振った作業の結果をレビュー、改善します。
この両方を１人で良い塩梅で、というのは大変なことです。
私はガタガタだろうと動作する完成品（たたき台）を受け取ることで、「迷う」というネガティブなプロセスを省いて仕事を始動させ、改善に取り組み、「このようにすればいい」というアドバイスを理由と共に作業者に伝えています。
作業者も私もスキルがアップしていく実感があります。
フリーでは難しいかもしれませんが、ペアで作業する相手を探してみるのはどうでしょうか。
投稿2017/12/29 18:20
総合スコア1591
> その上でtaroさんの場合チームで仕事をしてみるのが良いのではと思いました。
僕もそうだと思います。そしてその方向で動こうとしています。
コワーキングスペースに足を運ぼうとか、クラウドソーシングサイトを活用しようとか、具体的な行動を起こし始めています。
今回この質問をしてみて色んな方からアドバイスや考えを頂きました。正直、全ての方からの回答を消化できてはいません。でも質問してよかったと思ってます。
恐らくteratailの意向とは違うタイプの質問だと思いますが、それでも皆さんマイナス評価をつけることもほぼなく、真っ直ぐ考えて回答をして頂きました。本当にありがたいことだと思います。
回答を頂いて数日で血や肉になるテーマではないと思います。なので、この質問はずっと自分の中でキープして皆さんの回答を何度も読み返していこうと思ってます。
残念ながら今のteratailではベストアンサーを決めなければいけないというある意味非情なシステムになっています。
（いや、僕がteratailの指針に沿った質問をすればこういう事にならないことは分かってるのですが。）
僕が「この回答が一番勇気づけられた」と思った回答をベストアンサーとするというのも一つの方法だと思いますが、他の方に申し訳なくて決められません。ですので、代表として現時点で一番最後にお答えいただいたharuさんに、回答いただいた全ての皆さんへのありったけの感謝の意を込めてベストアンサーを付けてこの質問を閉じようと思います。
0
・言語・ライブラリ・フレームワークの利用スキルを身に付けるのであれば、
自分が使っているOSS開発者のTwitterアカウントをフォローするなどして、最新情報を取得して、気になったら即試してみるとかそう言うフットワークの軽さがあるとキャッチアップ早くなるかもしれません。
・プロダクトを高速に作りたいと言うことであれば
プロダクトとして成立する最小まで機能を削った物をプロトタイピングして、どんどん改築していくという手もあると思います。この場合は技術は手段となるので、別に最新の技術が必要となるわけではなく、作るものの価値の分離・統合を考えるような試行錯誤を高速で繰り返せるか、ユーザーに評価されるレベルまで練り込めるかといった経験こそがスキルとなるかと思います。
投稿2017/12/25 05:46
総合スコア138
これは他の質問で書いたことがあるのですがこの質問でも早めに書いておくべきだったかもしれません。今Laravelに興味があるのは僕の下手の横好きの囲碁のQ&Aサイトを作りたいという夢があるからです。サイト作成、運営を自分でやるとすると、挙げていただいた２つの選択肢の両方に関わってくるのかなと思いました。まずは、Taylor OtwellさんとLaravelのツイッターアカウントをフォローしてみました。
ありがとうございます。
0
36年プログラミングをやってこられているだけでもすごいスキルだと思います。スキルにもいろいろあるので、とにかく違う言語でなにか書いてみる、他の人がどんなのを作っているか調べて自分ならどんな方法を採用するか落とし込んでいるなどいろいろと方法論はあるかと思います。
書籍を読んだから急にスキルアップしたという話はあまり聞いたことがありません。たぶん少し脱線して違うものを作ってみることが大切なのではないでしょうか。
投稿2017/12/24 08:52
総合スコア1161
多分何かしらの組織にいれば人の書いたコードが読めて個人でやってるよりずっと「脱線」しやすいんでしょうね。個人、というか僕で言うと入り口はWeb、そこでどうにもならなくなったら書籍にすがるしかないです。
例えば全く知らなかったLaravelを何の拍子か忘れましたがやってみたくなり、ver5.4をインストールしたのですが、webのドキュメントではよく分からず、Laracastで訛った早口の英語に必死になりながら長い動画を何本も何回か繰り返し見た覚えがあります。こうなってくると精神的に参ってきて、あまり読みやすい内容ではない本を買うことで苦しみから逃れるしかないのです。結局その本はほとんど読まず、Laravelは挫折に終わりました。また近いうちに再開しようと思ってますが。
本を買えばスキルが上がる、というのはないかもしれないですが、本がないととっかかりすらつかめない事もあるという本音はやはりあります。
回答の趣旨とは違うコメントになってる感があって申し訳ないのですが。「脱線」、心がけてみます。
0
がると申します。
興味深いお話だったので。私見で恐縮ですが。
拝見していると「何をもってスキルと呼称していて」「どんな方向にアップさせたいのか」が、もしかしたら当人は明確に何かがあるのかもしれないのですが、文章を読んでいる限りだと、不明瞭な感じでした。
端的には
・プログラミングそのもののスキルを上げたいのか
・「ビジネスとして行う」実務的なスキルを上げたいのか
が、まず不明でした。
また、プログラミングだと仮定しても
・より深く基礎を学びたいのか
・より早く最新の技術をキャッチアップしたいのか
・より広く技術の応用が出来るようになりたいのか
等。
実務だとしますと
・いかに「仕様や要求」を素早くコードであらわすか
・「後での改修が容易」な書き方
・「必要な実装」と「不要な実装」を見極めて「不要な実装」をしないようにする
・チームでの開発がしやすいようにする
等。
色々な観点があるか、と思うので。
そのあたりをまず整理してみる、というのは如何でしょうか？
投稿2017/12/24 07:57
総合スコア506
こんにちは、がるさん。
そうですね、僕が抱いてるイメージと文面から皆さんが読み取れるイメージとは具体性が一致しないかもしれませんね。もしそうだとしたら逆にその方が良いのかもしれません。僕が狭い視野で「スキル」と言ったのに対してこうして何人もの方から僕の想像し得なかった「スキル」観が返って来てる。その結果、例えば「そっか、もっと具体的に自分は何を向上させたいのか考えてみよう」という発想が浮かんできます。
ちなみにがるさんの分岐で言うと、僕の思ってたのは
> ・プログラミングそのもののスキルを上げたい
の
> ・より早く最新の技術をキャッチアップしたい
が一番近いと思います。
でもその土台として実務や基礎は必要ですのでそこだけを磨きたいというわけではないです。欲張りですかね。
・論理的思考能力
・効率的な物の組み立て方
なるほど、課題が明確になった時にそれをプログラミングする能力はスキルアップの一環としてとても大切だと思います。
競技プログラミングという存在も知りませんでした。
ありがとうございます。
補足しますと、特定の言語についてある程度理解した段階で課題として出されたらそれを解くのはそれほど苦手意識はないです。
質問文の「よくやる過ち」に書いた部分が一番苦手です。
「出来るエンジニア」になれるにはどうしたらいいのかというのが質問の主旨です。
0
まぁひとりで出来て、実益もあるような課題が必要ですね。
仮想通貨トレードのBotとか触ってみるのもいいかもですね。
為替などのFXとは違いマイナスになることが無いですし少額で試せます。
投稿2018/05/08 00:40
総合スコア23
マイナス評価が付いてる理由がわからないのですが、
「ひとりで出来て実益もある」という課題は実用的だと感じました。
安全性等確認して大丈夫そうであればやってみたいと思います。
まぁ仮想通貨・FXっていう言葉だけに反応した人でしょうね。
0
プログラミング歴36年。
おおっ！私より2～4年くらい長いかな（笑）。
私は、本格的なのは会社に入ってからですが、学生時代のお遊びも含めると同じくらいですね。始めた頃ってパソコンの黎明期ですよね。懐かしいなぁ。
どれをとっても初級者レベルです。
ああ、これが残念ですよね。どれか一つでもやり込んだものがあればと思うんですが。手広くやるのは悪くはないとは思うのですが。
ある域に達すると、言語は道具に過ぎず、考え方が大事だというのがわかるようになってくるはずです。（この初級者というのは謙遜であって、例えばC/C++はその中でも長いです、ということじゃないのでしょうか？）
昔は、プログラマ限界説みたいなのがあって、30歳前半までなんて言われたことも有りましたが、あれは都市伝説みたいなもので、そんなことは無いと思います。ただ、30歳せめて40歳前半までにやり込んで、色々と経験しておくのが良いと思います。（フリーだとそれも難しいかもしれませんが・・・）
今更、という感じがするかもしれませんが、今から10年間いや5年、死ぬ気でやり込めばコツが掴めるかもしれません。
釈迦に説法でしたよね。失礼なことを言ってたら謝ります。
まあ、人間に限界など無いのでがんばってください！
投稿2017/12/25 09:54
総合スコア3579
そうですね、Cは出たての頃興味でちょっとかじったり卒論で使ったり就職して３年位は使ってたので得意でなければいけない言語ですね。錆びついちゃってて「Cなら書けます（読めます）！」と自信を持って言えないです。まぁ今後Cをメインに何かをするだろうという気はしないのですが。自分の中ではPHPが一番マシかなと思っていて、Webとスマホアプリが華やかなのかなと思ってるので今はそのあたりのスキルを固める（始める）ことに気持ちが行ってます。後は別のコメントで囲碁好きといいましたが、近年の囲碁といえばAIなのでPythonで機械学習も知りたいなとか。って気が多いのが良くないのかな？死ぬ気でこれらをやってちゃんと消化できればいいんでしょうね。頑張ります。
ありがとうございます。
別に言語はなんでも良いと思います。機械学習ならPythonみたいな感じになってますが、これはライブラリがあることの相乗効果で、その言語が使われているということだと思います。別にその他の言語で機械学習ができないわけではありません。（言語の特色みたいなものあるとは思いますが）
プログラミングは、やってないと簡単に錆びついてしまいます。私も、学生時代はCOBOLやFORTRANをやってましたが、今は一切触ってないので、プログラムは一から勉強しないと組めないでしょう。perl, awk, rubyなどのスクリプト言語も触りましたが、本来業務では使わないので錆びついています。javaはC++やC#に近いので何とかなりますが逆引きとかリファレンス片手でないと組めません。C/C++はメインでやってるので基本は全部わかりますが、ライブラリ関係となると(例えばboost)そのマニュアルや逆引きなどを常に確認しながら組んでいます。そういう詳細なことはネット環境であれば検索すればなんとかなるので、その場所さえ知っていれば良いわけです。
まあ、36年もやられているので論理的な思考や仕様書などプログラムドキュメント関係は整えてらっしゃると思いますので、敢えてコツと言えば、自分な得意な言語で論理構築して、それを使う言語に翻訳するのが一番確実で近道ではないでしょうか。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/12/25 11:51
2017/12/25 14:25