“I have always imagined that paradise will be a kind of library.”


The lips of wisdom are closed, except to the ears of Understanding--The Kybalion

Posted by: lrrp | June 25, 2017

To Quit is not a Option…..


Posted by: lrrp | June 16, 2017




Code quality and development speed are two essential – and sometimes conflicting – factors for software development teams.

Proper development requires careful design, solid implementation, and testing. Tight deadlines may compromise this process. On the other hand, applying the best overall solution may stand in the way of delivering speedily.

At Codementor, we believe that both code quality and shipping speed are important. Shorter ‘time to market’ makes us more agile as a startup, while good code quality makes future development easier, faster, and more stable.

Here’s what we do to achieve these goals:

  • Make sure all team members from our dev, design, and product teams know why we are building features
  • Identify which features are essential for each release

If there is one thing worse than shipping a feature slowly, it’s definitely to ship the wrong feature. Most of the times, a few lines of description on a Github issue are far from enough in order to explain the context of a feature.

Not knowing and understanding the “why”, developers will build features like they’d construct a house with only part of the plan. They might be able to build something that meets the immediate needs, but they will not structure the code taking into account future changes. After several iterations, things will become slower and slower, it’ll take more and more time to release features that could otherwise have been shipped fast.

If developers are aware of the context of a feature, they can build it while keeping possible future changes in mind. If the project falls behind schedule, they’ll be able make the necessary adjustments only if they know the “why”.

There are always unknown unknowns in the development process. This may delay the shipping. When this happens, we always ask ourselves:
Are all these features essential to test the market? If not, what are the features that can be cut?

Most of the times, we can find features that can be cut or built in a “reduced” form.
Sometimes, the same business goal can be achieved with a simpler technical approach or by introducing a tolerable amount of technical debt into the system. But only when developers know the context of features can they make the acceptable and reasonable trade-offs.

How do you (or your team) balance code quality and development speed?

Posted by: lrrp | May 1, 2017

Doing things Right


Posted by: lrrp | May 1, 2017

Programmer Dad


Posted by: lrrp | May 1, 2017

Your Vision is Your Limit


Posted by: lrrp | May 1, 2017

Everyone Brings Joy to this office….


« Newer Posts - Older Posts »