Sapan Parikh

Co-founder and Software Craftsperson at Incubyte

A tech evangelist and mentor, Sapan has been fuelled by two things in his 15+ year professional career; coffee and his love of designing self-motivated, high-performing and passionate software engineering teams. Being a software craftsperson at heart, he has created and coached teams of over 500 software developers spread across the US and India with the sole objective of forging exceptional software products with an unfettered focus on quality.

Posts

Your daily productivity test

Playbook

Are you a software developer? How can you be more effective on this journey of being a craftsman?

Project Kickstart Checklist

Playbook

The Checklist Manifesto by Atul Gawande, walks us through the benefits of the humble checklist. He talks about how checklists of “dumb stuff” can save us from disasters in life and death situations.

Understanding Technical debt!

Software Craftsmanship Best Practices SDLC

The term “Technical Debt” was coined by Ward Cunningham (one of the authors of Agile Manifesto).

Pair Programming — How it works!

Software Craftsmanship Best Practices SDLC

Have you ever come across a bug that had complex logic, and was incredibly hard to fix?

12 Books Developers Must Read

Careers Software Craftsmanship

Books are a massive source of knowledge. Before we list all the books here, we want to discuss why we think it’s essential for programmers to read them.

Benefits and Challenges of Open-Source Development

Open Source

Open-source software (OSS) is the holy grail for developers. It is a hub of innovation through intense collaboration in this era of agile software development.

Do not assume that technical debt is a problem with your code

97 Things Not To Do Software Craftsmanship

Ever saw SonarQube laden with thousands of maintainability and security issues? Looking at those dashboards, we often believe we’re looking at the code’s state, but there is more to it.

Not All Tests are the Same

Software Craftsmanship

On multiple occasions, I have worked on projects where I learned how critical testing is and that not all tests are the same.

Do not Release Code Without Automated Tests

97 Things Not To Do

Most projects that I see facing serious problems lack tests. You should write tests for two things

Do not Get so busy that you stop learning

97 Things Not To Do

Learning is the most vital part of a software developer’s life. Being so busy that one stops learning is neither desirable nor helpful to one’s career.

Do not Optimize Prematurely

97 Things Not To Do

Once again, you would think that the software development community has moved past this point, but I still get many teammates who want to “save memory” using HashMaps instead of POJOs.

Do not Show Separate Estimate for Unit Testing

97 Things Not To Do

Once I was asked in an interview (I was the interviewer!) What do you do in situations where the customers don’t want you to write test cases, or they want you to deprioritize the activity of writing test cases.

Do not Copy and paste code to minimize the impact:

97 Things Not To Do

Have you ever seen code in your module, which was so complex that you decided to copy and paste it entirely rather than changing it to accommodate your requirement?

Do not Fall for faux agile

97 Things Not To Do

Enough ink is already spilled on this topic, nevertheless talking about it once again may not hurt.