The Hard Thing About Software Development
Here&#x27;s the problem:<p>- Here&#x27;s a pool of knowledge about software development: hardware, operating systems, memory, disks, file formats, databases, networks, protocols, languages, debuggers, design patterns, security, accessibility, UI&#x2F;UX, distributed systems, paradigms, typical algorithms &amp; data structures, and CS problems<p>- There&#x27;s a pool of knowledge about whatever industry you get into as a developer: user demands, existing workflows, existing infrastructure, previous decisions, legal regulation &amp; compliance, physical laws, profitability, and practical limits.<p>Your software development skills should reach a point where you don&#x27;t write &quot;Bad Code&quot; -- anything that&#x27;s wrong like loading a entire database table that eats memory when you can read individual rows, storing passwords in cleartext, or not doing anything for accessibility (this is not design pattern, space&#x2F;tab debates). These have been done hundreds of times by new and &#x27;experienced&#x27; people.<p>It takes time to get to this point. More time than anyone likes to admit because the pool of knowledge grows and shrinks daily, but has undoubtedly had a net expansion since computers were a thing.<p>It takes time to get deep knowledge about whatever industry you get into. This is different for every industry. There&#x27;s a practical minimum that you need to work on solutions or do maintenance on software within this industry. This is to avoid &quot;Bad Code&quot; which will hurt you, other people, or your business.<p>You can gain industry knowledge by just being given problems and being shown. This is probably how most of us know our industries from the get-go. A minority of us came from those industries and transitioned to programming later, so we already had a base level of knowledge of our problems.<p>If I&#x27;ve got the definition of Deep Context right from this article, it means to get to that point, you have to spend a good amount of time within the industry. It&#x27;s not something you can gain completely by reading out of a book.<p>If you&#x27;re to gain deep context within an industry, you have to devote some time away from software. You can&#x27;t do both at the same instant (but certainly within a day). When you study an industry, there&#x27;s an opportunity cost to not learning something new about software and vice versa.<p>When you add more requirements to a single job, it increases the time we have to spend before we&#x27;re employable. Not every industry changes as fast as software does, but some certainly do, possibly catalyzed by software.<p>If you increase the time requirements, it&#x27;s going to reduce the available pool of engineers as long as all of the engineers are honest and don&#x27;t apply for jobs or remote contracts until they&#x27;re ready.<p>If you don&#x27;t want the time requirements to increase, you have pay the opportunity costs from one of your pools of knowledge.<p>So really, we need a much better &quot;good enough&quot; for employing developers and career development, including teaching software and industry knowledge. Because eventually the time requirements are going to become steeper and steeper. It can&#x27;t go up forever.