Programming on Pavan Yarahttps://pavanyara.com/tags/programming/Recent content in Programming on Pavan YaraHugo -- gohugo.ioen-USpavan.yara@gmail.com (Pavan Yara)pavan.yara@gmail.com (Pavan Yara)Pavan YaraThu, 17 Oct 2019 20:54:53 +0530Programming principles for early stage startupshttps://pavanyara.com/blog/programming-principles-startups/Thu, 17 Oct 2019 20:54:53 +0530pavan.yara@gmail.com (Pavan Yara)https://pavanyara.com/blog/programming-principles-startups/<ol> <li>Expect to re-write your code and do not over architecture.</li> <li>Use consistency and agree upon the rules.</li> <li>Solve system problems, not the immediate problem.</li> <li>Keep sprints short and features small.</li> <li>Focus on good database design.</li> <li>Avoid processes that add too much overhead.</li> <li>Document your code using 2 styles - self documenting or inline documentation</li> <li>Build microservices over large monethletic codebase</li> </ol> <p>Source: <a href="https://medium.com/helium-mvc/programming-principles-for-early-stage-startups-1215ad14bcb8">https://medium.com/helium-mvc/programming-principles-for-early-stage-startups-1215ad14bcb8</a></p>
  • Expect to re-write your code and do not over architecture.
  • Use consistency and agree upon the rules.
  • Solve system problems, not the immediate problem.
  • Keep sprints short and features small.
  • Focus on good database design.
  • Avoid processes that add too much overhead.
  • Document your code using 2 styles - self documenting or inline documentation
  • Build microservices over large monethletic codebase

    • Source: https://medium.com/helium-mvc/programming-principles-for-early-stage-startups-1215ad14bcb8

    ]]>    Things I Learnt The Hard Way (in 30 Years of Software Development)https://pavanyara.com/blog/things-learnt-the-hard-way-programming/Fri, 28 Jun 2019 19:39:07 +0530pavan.yara@gmail.com (Pavan Yara)https://pavanyara.com/blog/things-learnt-the-hard-way-programming/<p>This is a cynical, clinical collection of things Julia Biason learnt in 30 years working with software development.</p> <p>Again, some things are really cynical, others are long observations on different jobs.</p> <h2 id="before-you-start-writing-code">Before you start writing code&hellip;</h2> <ul> <li>Spec First, Then Code</li> <li>Write Steps as Comments</li> <li>Gherkin Is Your Friend to Understand Expectations</li> <li>Design Patters Are Used to Name Solution, Not Find Them</li> <li>Thinking Data Flow Beats Patterns</li> <li>The Magic Number Seven, Plus Or Minus Two</li> <li>Cognitive Cost Is The Readability Killer</li> <li>Learn The Basics of Functional Programming</li> </ul> <h2 id="testing-software">Testing Software</h2> <ul> <li>Unit Tests Are Good, Integration Tests Are Gooder</li> <li>Testing Every Function Creates Dead Code</li> <li>Tests Make Better APIs</li> <li>Make Tests That You Know How To Run On The Command Line</li> <li>Good Languages Come With Tests</li> </ul> <h2 id="documenting-your-code">Documenting your code</h2> <ul> <li>Documentation Is A Love Letter To Your Future Self</li> <li>The Function Documentation Is Its Contract</li> <li>If A Function Description Includes An &ldquo;And&rdquo;, It&rsquo;s Wrong</li> <li>Good Languages Come With Integrated Documentation</li> </ul> <h2 id="writing-code">Writing code</h2> <ul> <li>Be Ready To Throw Your Code Away</li> <li>Future Thinking Is Future Trashing</li> <li>Don&rsquo;t Use Booleans As Parameters</li> <li>Beware of Interface Changes</li> <li>It&rsquo;s Better To Let The Application Crash Than Do Nothing</li> <li>If You Know How To Handle It, Handle It</li> <li>Types Say What Your Data Is</li> <li>If Your Data Has a Schema, Use a Structure</li> <li>Don&rsquo;t Mess With Things Outside Your Project</li> </ul> <p>More:</p>This is a cynical, clinical collection of things Julia Biason learnt in 30 years working with software development.

    Again, some things are really cynical, others are long observations on different jobs.

    Before you start writing code…

    • Spec First, Then Code
    • Write Steps as Comments
    • Gherkin Is Your Friend to Understand Expectations
    • Design Patters Are Used to Name Solution, Not Find Them
    • Thinking Data Flow Beats Patterns
    • The Magic Number Seven, Plus Or Minus Two
    • Cognitive Cost Is The Readability Killer
    • Learn The Basics of Functional Programming

    Testing Software

    • Unit Tests Are Good, Integration Tests Are Gooder
    • Testing Every Function Creates Dead Code
    • Tests Make Better APIs
    • Make Tests That You Know How To Run On The Command Line
    • Good Languages Come With Tests

    Documenting your code

    • Documentation Is A Love Letter To Your Future Self
    • The Function Documentation Is Its Contract
    • If A Function Description Includes An “And”, It’s Wrong
    • Good Languages Come With Integrated Documentation

    Writing code

    • Be Ready To Throw Your Code Away
    • Future Thinking Is Future Trashing
    • Don’t Use Booleans As Parameters
    • Beware of Interface Changes
    • It’s Better To Let The Application Crash Than Do Nothing
    • If You Know How To Handle It, Handle It
    • Types Say What Your Data Is
    • If Your Data Has a Schema, Use a Structure
    • Don’t Mess With Things Outside Your Project

    More:

    ]]>