<story><title>How I became a better programmer (2017)</title><url>https://jlongster.com/How-I-Became-Better-Programmer</url></story><parent_chain><item><author>MaxBarraclough</author><text>&amp;gt; then languages&lt;p&gt;Perhaps a slight digression, but: I think there are very few people who can really say they can &amp;#x27;see through&amp;#x27; the difference between languages.&lt;p&gt;C++, Erlang, Prolog, and Haskell, are very different languages, all the way from the shallow matter of syntax, through the type system, and even down to the fundamental model of computation. When I hear someone say &lt;i&gt;If you learn to program in one language, it&amp;#x27;s easy to learn another&lt;/i&gt;, I assume that person doesn&amp;#x27;t know much about programming.</text></item><item><author>kqr</author><text>The points on the fluff in particular resonate with me because idespite being a fairly good software engineer, I would say it was only recently I truly started seeing past the fluff.&lt;p&gt;However, typing this out, I realise I would have said the same thing 10 years ago, and 5 years ago, and I probably will again another 5 years from now.&lt;p&gt;I think the truth is that we&amp;#x27;re &lt;i&gt;always&lt;/i&gt; missing the forest for all the trees -- only at increasing levels of abstraction: at first, everything is foreign, then syntax becomes fluff, then APIs become fluff, then patterns, then languages, then compilers, then ... I look forward to learning what the next level of fluff will be.&lt;p&gt;&amp;gt; The majority of the stuff being released every day is just a rehash of the same ideas. Truly revolutionary stuff only happens every few years.&lt;p&gt;Maybe not even that often. I can recommend Old Is the New New by Kevlin Henney for a good, historical perspective on how little actually changes sometimes: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;youtube.com&amp;#x2F;watch?v=AbgsfeGvg3E&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;youtube.com&amp;#x2F;watch?v=AbgsfeGvg3E&lt;/a&gt;&lt;p&gt;Edit: now this was more interesting than I anticipated. What &lt;i&gt;is&lt;/i&gt; the next level of fluff? Concurrency? Advanced data structures? Phrasing problems for SMT solvers? Probabilistic modeling?&lt;p&gt;Or are the things I picture as fluff just specific techniques, because the next level of fluff is so meta I wouldn&amp;#x27;t even recognise it now?</text></item></parent_chain><comment><author>echelon</author><text>&amp;gt; If you learn to program in one language, it&amp;#x27;s easy to learn another, I assume that person doesn&amp;#x27;t know much about programming.&lt;p&gt;This is flat out wrong.&lt;p&gt;If you know Python, it&amp;#x27;ll be easier to learn Rust than having to learn Rust from zero. Engineering is about problem solving and formulating solutions with algorithms and data structures. If you don&amp;#x27;t know what those are yet, it&amp;#x27;ll take much longer to learn.&lt;p&gt;Learning one of &lt;i&gt;anything&lt;/i&gt; makes learning the next one easier. Programming languages, spoken languages, musical instruments, sports cars, martial arts, sports, weapons, drawing, etc. Your brain builds a rich scaffold you can hang new concepts from.</text></comment>
<story><title>How I became a better programmer (2017)</title><url>https://jlongster.com/How-I-Became-Better-Programmer</url></story><parent_chain><item><author>MaxBarraclough</author><text>&amp;gt; then languages&lt;p&gt;Perhaps a slight digression, but: I think there are very few people who can really say they can &amp;#x27;see through&amp;#x27; the difference between languages.&lt;p&gt;C++, Erlang, Prolog, and Haskell, are very different languages, all the way from the shallow matter of syntax, through the type system, and even down to the fundamental model of computation. When I hear someone say &lt;i&gt;If you learn to program in one language, it&amp;#x27;s easy to learn another&lt;/i&gt;, I assume that person doesn&amp;#x27;t know much about programming.</text></item><item><author>kqr</author><text>The points on the fluff in particular resonate with me because idespite being a fairly good software engineer, I would say it was only recently I truly started seeing past the fluff.&lt;p&gt;However, typing this out, I realise I would have said the same thing 10 years ago, and 5 years ago, and I probably will again another 5 years from now.&lt;p&gt;I think the truth is that we&amp;#x27;re &lt;i&gt;always&lt;/i&gt; missing the forest for all the trees -- only at increasing levels of abstraction: at first, everything is foreign, then syntax becomes fluff, then APIs become fluff, then patterns, then languages, then compilers, then ... I look forward to learning what the next level of fluff will be.&lt;p&gt;&amp;gt; The majority of the stuff being released every day is just a rehash of the same ideas. Truly revolutionary stuff only happens every few years.&lt;p&gt;Maybe not even that often. I can recommend Old Is the New New by Kevlin Henney for a good, historical perspective on how little actually changes sometimes: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;youtube.com&amp;#x2F;watch?v=AbgsfeGvg3E&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;youtube.com&amp;#x2F;watch?v=AbgsfeGvg3E&lt;/a&gt;&lt;p&gt;Edit: now this was more interesting than I anticipated. What &lt;i&gt;is&lt;/i&gt; the next level of fluff? Concurrency? Advanced data structures? Phrasing problems for SMT solvers? Probabilistic modeling?&lt;p&gt;Or are the things I picture as fluff just specific techniques, because the next level of fluff is so meta I wouldn&amp;#x27;t even recognise it now?</text></item></parent_chain><comment><author>battery_cowboy</author><text>I&amp;#x27;m one of those people, but there&amp;#x27;s more nuance than that to it. I&amp;#x27;ve learned about 20 different languages to some degree, from Python to brainfuck to Elixir currently. When I learn a new language, I go to the source material, so for elixir I used the tutorials at the elixir home page and their API documentation. I read the tutorials, writing each line of code into my editor, running each, modifying it to see how it works, etc. Then, everytime the tutorial links to or mentions an API, I&amp;#x27;ll go read that documentation page in full and experimenting. Then I&amp;#x27;ll make some projects with that language, look at how the more experienced Elixir (or whatever) developers code by exploring their repos, etc.&lt;p&gt;After doing that 10+ times, it becomes easier to see the patterns in languages, and easier to understand how their underlying structure will affect how you have to code. There&amp;#x27;s only so many ways to write a compiler or interpreter, and if you know how they work and you know that your language is, for example, optimized for tail recursion, then you get your experience from other similar languages as a bonus.&lt;p&gt;I see your point if you&amp;#x27;re saying, on a surface level, that, &amp;quot;you know one, you know them all,&amp;quot; is wrong, but if you dig deeper I think you&amp;#x27;ll see that, for the experienced (as in: someone who&amp;#x27;s been around a while) developer, you kinda can say that, with some reservations.&lt;p&gt;I think anyone can do the same thing, it just takes a decade or more to get there. I&amp;#x27;m kinda dumb, too, so if I can do it, anyone can.</text></comment>