<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Justin Vos</title>
    <description>The latest articles on DEV Community by Justin Vos (@justinvos).</description>
    <link>https://dev.to/justinvos</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F11933%2F6b80a5d7-befb-41e0-ad61-4167c22d8bcf.jpg</url>
      <title>DEV Community: Justin Vos</title>
      <link>https://dev.to/justinvos</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/justinvos"/>
    <language>en</language>
    <item>
      <title>Colocation is still underrated</title>
      <dc:creator>Justin Vos</dc:creator>
      <pubDate>Thu, 26 Sep 2019 11:49:11 +0000</pubDate>
      <link>https://dev.to/justinvos/colocation-is-still-underrated-5dfl</link>
      <guid>https://dev.to/justinvos/colocation-is-still-underrated-5dfl</guid>
      <description>&lt;p&gt;Colocation has been a thing in the Web space for quite a while now. React, Vue.js and others have been pushing it for a couple of years with their Component-based frameworks.&lt;/p&gt;

&lt;p&gt;The traditional approach of separating HTML, CSS and JavaScript code doesn't make a whole lot of sense. Each of these is a different technology but they need to work together. Most features would have some code split across three different files.&lt;/p&gt;

&lt;p&gt;Everyone seems to be on board with putting their HTML and JavaScript in the same component file, however many developers I talk with have different ideas when it comes to CSS.&lt;/p&gt;

&lt;p&gt;Either because it's just not simple and easy to implement or because it hasn't been popularised as much. For some reason, a lot of developers are against writing CSS in their component files.&lt;/p&gt;

&lt;p&gt;Regardless of implementation or style, here's why colocation is great:&lt;/p&gt;

&lt;p&gt;Isolated from other features means less intertwining bugs. One section of CSS code can be isolated from others making sure it's not unknowingly depending on or being depended on other code.&lt;/p&gt;

&lt;p&gt;It's harder to let one technology become out-of-line with the others. If the structure of the markup changes, the styling is right there in front of you and so you'll naturally keep this up-to-date as well. This isn't the case when the styles are hidden away in another file.&lt;/p&gt;

&lt;p&gt;Removal of dead or obselete features are much simpler. Since there are no hidden ties to any other code, once a feature is no longer needed, it can be just removed.&lt;/p&gt;

&lt;p&gt;All the details of how a feature is implemented can be hidden away inside a single file. If someone is new to the code or doesn't need to understand it just yet, they don't have to.&lt;/p&gt;

&lt;p&gt;This all enables a team to move faster, reduce bugs and keep the amount of code down.&lt;/p&gt;

</description>
      <category>web</category>
      <category>components</category>
    </item>
    <item>
      <title>Reading code is the best skill a developer can have</title>
      <dc:creator>Justin Vos</dc:creator>
      <pubDate>Wed, 04 Sep 2019 10:25:47 +0000</pubDate>
      <link>https://dev.to/justinvos/reading-code-is-the-best-skill-a-developer-can-have-j9o</link>
      <guid>https://dev.to/justinvos/reading-code-is-the-best-skill-a-developer-can-have-j9o</guid>
      <description>&lt;p&gt;&lt;strong&gt;The best skill a developer can have is being able to read code well.&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Reading and understanding code is the most important skill because you spend most of your time doing it already and you need to understand not only your own code but also others' code.&lt;/p&gt;

&lt;p&gt;As Robert C. Martin has famously said &lt;em&gt;"the ratio of time spent reading versus writing is well over 10 to 1"&lt;/em&gt;. While I completely agree with his observation, Martin uses this fact to recommend making your own code as understandable as possible which I would also agree with too. However even more important is being able to proficiently read code.&lt;/p&gt;

&lt;p&gt;You can't write all the code you will use or keep the rest of the world up to your high standard. In order to build anything, make modifications to code or even just discuss it requires understanding others' code. Learning how to understand bad code is the only way through this challenge.&lt;/p&gt;

&lt;p&gt;Writing good code only goes so far, you'll still have to read your teammates' code, your framework's and library's code.&lt;/p&gt;

&lt;h2&gt;
  
  
  How can I get better at reading (bad) code?
&lt;/h2&gt;

&lt;p&gt;Reading code is a muscle that needs to be trained. So far your brain is pretty well trained on reading mostly your own codebase. Like only listening to only one news source, you can fall into limiting yourself in thinking in only one way.&lt;/p&gt;

&lt;p&gt;Mixing up what read allows you to get different inputs and see different solutions.&lt;/p&gt;

&lt;p&gt;I'd recommend:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Read how your framework (e.g. React, Vue.js, Rails, etc) is built to understand what you've already got to work with and how you can take advantage of it.&lt;/li&gt;
&lt;li&gt;Read how the libraries you use (e.g. Redux, lodash, Rake) are structured and modularised.&lt;/li&gt;
&lt;li&gt;Read how similar applications are built and how they are solving a lot of the same problems you have in different ways (e.g. Sound-Redux, vue-hackernews).&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;&lt;strong&gt;What codebases would you recommend reading?&lt;/strong&gt;&lt;/p&gt;

</description>
      <category>junior</category>
      <category>upskill</category>
    </item>
  </channel>
</rss>
