【中編】プログラミングとデザイン、やっていることはわりと同じ〜「デザインは感覚じゃない」 2015年01月20日 中編では「エンジニアから見たデザインの謎」について引き続き現場のエンジニアと、一緒にお仕事をさせて頂いているデザイナーの方をお迎えして、お話を伺いました。デザインにもあるという理論や理由についても詳しく語ってもらいました。
![【中編】プログラミングとデザイン、やっていることはわりと同じ〜「デザインは感覚じゃない」](https://cdn-ak-scissors.b.st-hatena.com/image/square/1814163073fa1d0bedbc9e2b8a35ea730ac89a8f/height=288;version=1;width=512/https%3A%2F%2Fsonicgarden.imgix.net%2Fuploads%2Fimage%2Ffile%2F1576%2Foriginal.jpg%3Fixlib%3Drails-4.3.1%26fit%3Dcrop%26crop%3Dfaces%26ar%3D1.91%253A1%26w%3D1200%26auto%3Dformat)
なんか難しく考え過ぎなんじゃないかな〜、と思ったり、思わなかったり。 こちらの記事を読みました。 主さんの意見としては以下のようですね。 1.独学では妥協をいくらでもできる 2.興味の範囲内のことしかやらない。 3.自分の実力に合わせた実装しかしなくなる この意見への批判とかではないですが、私の見解では大分異なります。 treeが思う独学が実務に通用しにくい理由 何故通用するのか 皆どうやってプログラムを学んだのか 現場の人間はそんなに有能なのか ではプログラム以外で通用しにくい部分はあるか? 雑感 treeが思う独学が実務に通用しにくい理由 通用しますよ。余裕で。 これでは話がこれで終わってしまうので、もう少し詳しく書きます。 何故通用するのか 皆どうやってプログラムを学んだのか 日本は他の教育先進国と違ってITはゴミ扱いされ、義務教育の間は実践で使えるレベルのIT教育は行われません。従
独学でプログラミングを勉強してIT業界に就職したけど、やはり独学で得た技術だけだと通用しないと思う局面が幾たびもあった。 今は本はたくさん出てるし、動画もあるし、生のコードを読みたければGitでいくらでも読めるし、独学で勉強する土台はかなりできていると思う。 それでもなかなか実務に通用しない。 その理由はいろいろあるんだけど、自分が強く感じた3つの理由をこの記事では挙げたい。 1.独学では妥協をいくらでもできる 独学で作っているプログラムだと、使い勝手が悪い機能を見つけたとしても「ま、ええか」で済ませてられてしまう。 誰に命令されて作っているわけでもないから。極端な話、バグがあっても放置できる。「小さいバグだしいいでしょ」と。実務でそれをやったら殺される。 「ま、めんどくさそうだしこれでええか」で済ませてしまうと、めんどくさい実装をすることで得られる技術の向上がなくなる。 実際、現場だと仕
この前id:hitode909くんからピープルウェアを貰ったので読んだ。非常に面白くて、興味深い話が多かった。 ピープルウエア 第3版 作者: トム・デマルコ,ティモシー・リスター,松原友夫,山浦恒央出版社/メーカー: 日経BP社発売日: 2013/12/18メディア: 単行本(ソフトカバー)この商品を含むブログ (6件) を見る この本は、作者のトム・デマルコさんとティモシー・リスターさんが10年に及んだ調査と、自身のソフトウェア開発の経験をもとに、ソフトウェア開発における人に関する問題をたくさんのコラムを通じて教えてくれる。冒頭には以下のようにある。 実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである。 いろんなレイヤにおける人の問題についてそれぞれ章がわかれていて、個人からオフィスやチーム、さらには会社組織のはなしへと続く。結構マネージャー視点ぽいコ
この前id:hitode909くんからピープルウェアを貰ったので読んだ。非常に面白くて、興味深い話が多かった。 ピープルウエア 第3版 作者:トム デマルコ;ティモシー リスター日経BPAmazon この本はソフトウェアのプロジェクトが失敗する時は、原因が単なる技術的問題だけである場合は少なく、その前段階の人とのコミュニケーションレベルにも問題があるときが多いという話をしている。それでプロジェクトを進める上での人に関する問題をテーマにしている。 最近は個人で作業をするというよりも、チームで仕事を進めるということが多くなりつつあるので、非常に参考になる事が多かった。印象に残った点を書いていく。 早くヤレとせかされると 早くヤレとせかされれば、雑な仕事をするだけで、質の高い仕事はしない 耳が痛い。でも自分自身が言われても直感的にはそうなりそうという感じだと思った。 またこの本の関連する内容に「
今までパッケージソフトとかWebサービスの開発をしてきた中で、ビジネス上の納期や要求を満たすためにひどいコードを書くっていうのは自分の経験ではあまりなかった気がします。なにかひどいバグがあって、とりあえずのパッチを当てて間に合わす、ということはたまにあるけれど。SIの世界は知りませんよ。 そもそもコードを汚くかけば納期に間に合うということもないし、ビジネス上の近道になるということもない。コードをきれいに書こうが汚く書こうが無理なものは無理。第一汚いコードを意図的に書くというのも意外に難しいということは、普段まあまあきれいなコードを書いている人ならわかってくれるんじゃないかと思います。 仕様変更に設計がついていけてなくておかしいとかならともかく、関数が1000行あるとか、newした瞬間全てが終わるとか、変数のスコープがびっくりするくらい広い、みたいなコードについてははビジネス上の要求ではなく
2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。本件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 本件に関する詳細は、プレスリリースをご確認ください。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く