<?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>Forem: Devarshi Kansara</title>
    <description>The latest articles on Forem by Devarshi Kansara (@devarshikansara).</description>
    <link>https://forem.com/devarshikansara</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%2F1028466%2F129451e0-6eee-4f26-9817-5e87d1a38d9d.jpeg</url>
      <title>Forem: Devarshi Kansara</title>
      <link>https://forem.com/devarshikansara</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://forem.com/feed/devarshikansara"/>
    <language>en</language>
    <item>
      <title>97 Things Every Programmer should know part 5</title>
      <dc:creator>Devarshi Kansara</dc:creator>
      <pubDate>Fri, 24 Feb 2023 04:20:26 +0000</pubDate>
      <link>https://forem.com/devarshikansara/97-things-every-programmer-should-know-part-5-1pp2</link>
      <guid>https://forem.com/devarshikansara/97-things-every-programmer-should-know-part-5-1pp2</guid>
      <description>&lt;p&gt;Beauty Is in Simplicity&lt;/p&gt;

&lt;p&gt;by Jorn Olmheim&lt;/p&gt;

&lt;p&gt;THERE IS ONE QUOTE, from Plato, that I think is particularly good for all software developers to know and keep close to their hearts:&lt;/p&gt;

&lt;p&gt;⚡The beauty of style and harmony and grace and good rhythm depends on simplicity.&lt;/p&gt;

&lt;p&gt;In one sentence, this sums up the values that we as software developers should aspire to. There are several things we strive for in our code:&lt;/p&gt;

&lt;p&gt;• Readability&lt;/p&gt;

&lt;p&gt;• Maintainability&lt;/p&gt;

&lt;p&gt;• Speed of development&lt;/p&gt;

&lt;p&gt;• The elusive quality of beauty&lt;/p&gt;

&lt;p&gt;The bottom line is that beautiful code is simple. Each part is kept simple with simple responsibilities and simple relationships with the other parts of the system. This is the way we can keep our systems maintainable over time, with clean, simple, testable code, ensuring a high speed of development throughout the lifetime of the system.&lt;/p&gt;

&lt;p&gt;Beauty is born of and found in simplicity.&lt;/p&gt;

</description>
      <category>career</category>
      <category>posts</category>
      <category>devto</category>
    </item>
    <item>
      <title>⚡97 Things Every Programmer should know part 4.</title>
      <dc:creator>Devarshi Kansara</dc:creator>
      <pubDate>Thu, 23 Feb 2023 05:19:22 +0000</pubDate>
      <link>https://forem.com/devarshikansara/97-things-every-programmer-should-know-part-4-24f</link>
      <guid>https://forem.com/devarshikansara/97-things-every-programmer-should-know-part-4-24f</guid>
      <description>&lt;p&gt;Automate Your Coding Standard — by Filip van Laenen&lt;/p&gt;

&lt;p&gt;Coding standards should make it easier to work on a project, and maintain development speed from the beginning to the end.&lt;/p&gt;

&lt;p&gt;It follows, then, that everybody should agree on the coding standard, too — it does not help if one developer uses three spaces to indent code, and another uses four.&lt;/p&gt;

&lt;p&gt;There exists a wealth of tools that can be used to produce code quality reports and to document and maintain the coding standards, but that is not the whole solution. It should be automated and enforced by possible. Here are a few examples.&lt;/p&gt;

&lt;p&gt;✅Make sure code formatting is part of the build process so that everybody runs it automatically every time they compile the code.&lt;/p&gt;

&lt;p&gt;✅Use a static code analysis tool to scan the code for unwanted anti-patterns. If any are found breaking the build.&lt;/p&gt;

&lt;p&gt;✅Learn to configure those tools so that you can scan for your own, project-specific anti-pattern.&lt;/p&gt;

&lt;p&gt;✅Do not only measure test coverage but automatically check the results, too. Again, break the build if the test coverage is too low.&lt;/p&gt;

&lt;p&gt;Try to do this for everything you consider important. Finally, the coding standards should be dynamic, rather than static. As the project evolves, the needs of the project change, and what has seemed smart in the beginning is not necessarily smart a few months later.&lt;/p&gt;

&lt;p&gt;Do you agree with this statement? Which automated tools do you use in your projects? Let me know in the comments👉&lt;/p&gt;

&lt;p&gt;Happy Coding!&lt;/p&gt;

</description>
      <category>systemdesign</category>
      <category>cloudcomputing</category>
      <category>devops</category>
      <category>sre</category>
    </item>
    <item>
      <title>⚡97 Things Every Programmer should know Part 3.</title>
      <dc:creator>Devarshi Kansara</dc:creator>
      <pubDate>Wed, 22 Feb 2023 05:09:35 +0000</pubDate>
      <link>https://forem.com/devarshikansara/97-things-every-programmer-should-know-part-3-3j6p</link>
      <guid>https://forem.com/devarshikansara/97-things-every-programmer-should-know-part-3-3j6p</guid>
      <description>&lt;p&gt;Ask, “What Would the User Do?” (YouAre Not the User)&lt;/p&gt;

&lt;p&gt;by Giles Colborne&lt;/p&gt;

&lt;p&gt;⚡WE ALL TEND TO ASSUME THAT OTHER PEOPLE THINK LIKE US. But they don’t. Psychologists call this the fake consensus bias.&lt;/p&gt;

&lt;p&gt;⚡This bias explains why programmers have such a hard time putting themselves in the user’s position. Users don’t think like programmers. To start, they spend much less time using computers. They neither know nor care how a computer works.&lt;/p&gt;

&lt;p&gt;⚡The best way to find out how a user thinks is to watch one. Ask a user to complete a task using a similar piece of software to what you’re developing. Make sure the task is a real one: “Calculate your expenses for the last month” is better. Get the user to talk through his or her progress.&lt;/p&gt;

&lt;p&gt;⚡You’ll also find that there is a gap between what the users say they want and what they do. We should ask for users’ requirements. It’s why the best way to capture requirements is to watch users. Spending an hour watching users is more informative than spending a day guessing what they want.&lt;/p&gt;

&lt;p&gt;⚡Do you agree with this statement? Happy Coding!&lt;/p&gt;

</description>
      <category>c</category>
      <category>zig</category>
      <category>rust</category>
      <category>python</category>
    </item>
    <item>
      <title>⚡97 Things Every Programmer should know Part 2</title>
      <dc:creator>Devarshi Kansara</dc:creator>
      <pubDate>Tue, 21 Feb 2023 05:08:26 +0000</pubDate>
      <link>https://forem.com/devarshikansara/97-things-every-programmer-should-know-part-2-110l</link>
      <guid>https://forem.com/devarshikansara/97-things-every-programmer-should-know-part-2-110l</guid>
      <description>&lt;p&gt;⚡ 2. Apply Functional Programming Principles&lt;/p&gt;

&lt;p&gt;⚡ by Edward Garson&lt;/p&gt;

&lt;p&gt;⚡Mastery of the functional programming paradigm can greatly improve the quality of the code you write in other contexts. If you deeply understand and apply the functional paradigm, your designs will exhibit a much higher degree of referential transparency.&lt;/p&gt;

&lt;p&gt;⚡Referential transparency is a very desirable property: it implies that functions consistently yield the same results given the same input, irrespective of where and when they are invoked. That is, function evaluation depends less- ideally, not at all-on the side effects of mutable state.&lt;/p&gt;

&lt;p&gt;⚡Do you agree with this statement? Happy Coding!&lt;/p&gt;

</description>
      <category>codenewbie</category>
      <category>analyst</category>
      <category>python</category>
      <category>sql</category>
    </item>
    <item>
      <title>97 Things Every Programmer should know Part 1</title>
      <dc:creator>Devarshi Kansara</dc:creator>
      <pubDate>Fri, 17 Feb 2023 06:08:50 +0000</pubDate>
      <link>https://forem.com/devarshikansara/97-things-every-programmer-should-know-part-1-4207</link>
      <guid>https://forem.com/devarshikansara/97-things-every-programmer-should-know-part-1-4207</guid>
      <description>&lt;p&gt;Over the last few days, I have been reading O’Reilly’s 97 Things Every Programmer Should Know and I want to share a little bit about each topic shared by the experts who wrote the book.&lt;/p&gt;

&lt;p&gt;⚡1. Act with prudence: by Set Rose.&lt;/p&gt;

&lt;p&gt;⚡Where he refers to the importance of avoiding technical debt, as it is a trap because it can be ‘beneficial’ in the short term, but in the long term it can be detrimental.&lt;/p&gt;

&lt;p&gt;⚡He then recommends that even if technical debt is unavoidable, you should pay off debt as soon as possible. It would be imprudent to do otherwise.&lt;/p&gt;

&lt;p&gt;⚡What do you think of this advice?&lt;/p&gt;

&lt;p&gt;Stay tuned for the more blogs!!!😊&lt;/p&gt;

</description>
      <category>webdev</category>
      <category>programming</category>
      <category>productivity</category>
    </item>
  </channel>
</rss>
