求職者が「フルスタック」という言葉を「標準的なもの」と軽く扱うのを目撃した著者は、このバズワードが技術スタックに焦点を当てることで、開発者としての幅広いスキルを適切に評価できなくなる危険性を指摘する。代わりに「ジェネラリスト」という表現の方が、学習能力や適応力をより正確に伝えられると提案している。
tomrenner-com
tomrenner-com から 25 件
著者は、利用可能なドメインを購入したことから自分のサイトを持つことになり、開発の楽しさと実用的な目的を兼ねて自ら構築することにしました。Ruby、Sinatra、jQuery、HTML、CSSを使用してサイトを作成し、ソフトウェア関連の意見や読書、イベントのレビューなどを投稿する予定です。執筆を通じて学習し、思考を明確化することを目指しています。
顧客は常に正しい
2.0開発者はユーザーテストの重要性を理解しているが、実際のユーザーからのフィードバックやサポート依頼を煩わしい中断と捉えがちだ。しかし、顧客サポートは大規模なユーザーテストであり、ユーザーが抱える問題はUX上の課題を示している。開発者の専門はソフトウェアだが、ユーザーは問題領域の専門家であり、そのフィードバックから学ぶべきだ。
一生懸命働いても生産的でないことはよくある。この記事では、価値に基づいた優先順位付け、主要要件への集中、チーム全体での価値測定など、生産的な開発を実現するための実践的なアプローチを提案している。複雑さではなく価値で時間を割り当てることが重要だ。
適切な規模を把握する
1.0アジャイル開発では、事前設計よりも早期のフィードバックが重要ですが、大規模プロジェクトではスコープクリープのリスクがあります。高等教育セクターでの6-12ヶ月プロジェクトでは、過度な事前設計とスコープ拡大のバランスを見つけることが課題です。最適な解決策の範囲を見極めるには、コードを一度だけ書き、最小時間で作成し、将来再利用可能にすることを心がけることが重要です。
著者は190ポンドのASUS Chromebook C201を購入し、Chromebrewを使ってVim、Python、Gitをインストールして開発環境を構築しました。1キロ未満の軽量さと低価格のおかげで常に持ち歩き、隙間時間を有効活用できるようになりましたが、開発者モードの制約や基本的なコマンドラインツールの欠如などの課題も残っています。
チームにおいて知識が個人の頭の中だけにあることは危険だ。人間は忘れやすく創造的だが、コンピューターは忘れず創造的ではない。重要なのは、コンピューターに記憶させ、人間が創造的な部分に集中できるシステムを作ること。個人の文書化とタスク管理の原則は、効果的な生産性向上に不可欠である。
著者はかつて時間の「効率性」にこだわり、隙間時間を埋めようとしていましたが、その結果として期待したような生産性の向上は得られませんでした。現在は、仕事と生活のバランスを重視し、本当に興味のあることだけに取り組むことで、より幸せで効果的な学習ができると気づきました。技術業界では長時間労働が推奨されがちですが、小さな効率性にこだわるよりも、本当に重要なことに集中する方が良い結果をもたらすと主張しています。
「失敗の神殿」は、チームが毎週のレトロスペクティブで自分のミスを共有し、そこから学ぶための定期的なセッションです。軽い儀式と非難しない雰囲気の中で、チーム全体が同じ過ちを繰り返さないようにすることを目的としています。これは学習環境を育み、チームの成長を促進する貴重な取り組みです。
XTC(eXtreme Tuesday Club)でBasecampの新製品開発フレームワーク「Shape Up」についてのセッションが開催されました。議論では、Shape Upの長所(チームの責任と所有権、信頼関係の構築、バックログ概念の排除など)と懸念点(固定されたスコープ、長い開発サイクル、チームの二分化など)が検討され、参加者は「太いペン」デザインや「ベッティング」といった特定の手法を自社で試してみたいと述べました。
GephiとTwitterStreamerプラグインを使用してTwitterデータからネットワークグラフを作成する初心者向けガイド。トランプ関連のツイートを例に、データ収集から可視化、エクスポートまでの手順を解説しています。
仕事の受信箱は通常ストレスの源ですが、「Nice :-)」というフォルダーを作り、称賛や感謝、ポジティブなメールを保存することで、自分だけの幸せな場所を作ることができます。このシンプルなマインドフルネスの実践は、困難な日々を乗り越える助けとなり、仕事の価値を思い出させてくれます。
この記事では、同じ職場や場所に留まりながらも、個人的な成長やスキル向上を続けることの重要性について論じています。Codebar Festivalでの講演内容を基に、キャリアの進歩は必ずしも転職や場所の移動を意味するわけではないという視点を提供します。
DevOpsのパフォーマンスを測定するDORAメトリクスについて、各指標(デプロイ頻度、平均デプロイ時間、変更失敗率、サービス復旧時間)を実際に追跡するために必要な「一次」データと、Git、Jira、Sentryなどの既存ツールから自動的に抽出する方法を探ります。
Facebookが新たに参入するメタバースについて、The Spectatorのキット・ウィルソンが論じています。ソフトウェアエンジニアのトム・レナーとともに、この新たなデジタル現実への道筋について探ります。
ソフトウェア業界は常に新しい技術を学ぶことに長けているが、過去の経験を積み重ねた「業界知識」の蓄積は十分ではない。COBOLやPrologなどの過去の言語や技術から学び、現在のReactやGoのトレンドを歴史的文脈で理解する視点が必要とされている。
依存関係を整理せよ
2.02021年のLog4J脆弱性を例に、依存パッケージの過剰な追加がもたらすセキュリティリスクとコード品質の問題を指摘。開発者は「車輪の再発明を避ける」原則に従いがちだが、これにより未知の品質の外部コードが蓄積され、脆弱性が潜在する。依存関係の最小化と追加時の厳格な正当化プロセスを提案する。
「沈黙の部分を声に出して言う」とは、チーム内での実践について合意を形成する方法で、なぜ特定の方法で物事を行うのかを、それが明らかだと思われる場合でも明言する習慣を指します。これにより、期待や信念を明確にすることでリーダーシップを発揮し、チームが異議を唱えたり、意見の相違を明確にしたりする機会を提供します。
必然性の響き
2.0テック業界の著名人たちは、AIの未来を「必然的」なものとして語り、私たちに適応を迫る。しかし、LLMが本当に望ましい未来なのか、私たちには選択肢がある。必然主義に議論を支配させず、自分たちが望む未来を考え、戦うべきだ。
この記事では、AIスロップや製品のエンシット化、テック業界における構造的な多様性の障壁、インターネットの劣化に対する個人の責任など、現代のテクノロジーと社会が直面する重要な問題について考察しています。著者は、消費者の受動的な受け入れに抵抗し、質の高いコンテンツを支持し、多様性を促進する行動を取るよう読者に呼びかけています。
信頼を最適化する
2.0ソフトウェア開発におけるチームプロセスや方法論を評価する際のヒューリスティックとして「信頼を最適化する」ことを提案。コードレビュー、テスト、チームビルディング、アジャイル手法など、あらゆる活動は技術的・建築的・対人的・組織的な信頼構築に貢献しており、高パフォーマンスチームはこれら4つの領域で信頼を成功裏に構築するチームである。
この記事では、デジタルガーデニングの概念、ウェブの衰退に対する批判、そしてSpotifyが死者のアーティストから許可なくAI生成楽曲を公開するという倫理的問題など、現代のデジタル世界について考察しています。著者は、エンジニアとしての責任と個人の道徳的立場の重要性を強調しています。
著者は、AIツールが人間のように振る舞うように設計されていることについて論じています。この擬人化は、ツールの不正確さを許容させ、ユーザーとの感情的な絆を築かせることで、客観的な評価を妨げていると指摘します。結局のところ、AIは人間ではなく、単なるトースターのような道具に過ぎないと結論づけています。
この記事では、サイクルタイム測定の危険性、AIツール設計における学習理論の重要性、GitHub Actionsを介したNixエコシステムへのサプライチェーン攻撃の脅威について考察しています。各トピックは、ソフトウェア開発における測定、学習、セキュリティの実践的な課題を浮き彫りにしています。
著者は、大規模言語モデル(LLM)が400年にわたる信頼詐欺の最新形態であると主張する。機械計算機への信頼構築から始まり、恐怖と共感を利用した感情操作、そして「今すぐ適応せよ」という緊急行動の要求まで、古典的な詐欺の三段階がLLMの普及戦略に見られると指摘する。実際のビジネス成果は乏しいにもかかわらず、社会全体がこの「知性」の幻想に巻き込まれていると批判する。