Posted by: lrrp | October 7, 2017

Developers Love Development

We software developers are a fortunate lot. We love what we do, and a lot of the time, when we’re actually building software, we’re very happy people. Unfortunately, this isn’t universally true since so many software development projects require developers to do a lot of other things aside from writing code such as sitting through boring meetings and building documentation or other artifacts. This is not as enjoyable to us as facing the challenge of solving unknown problems, learning and discovering as we go. This is what attracts us to writing software.

Professional software development is fundamentally different than most people think. It has nothing to do with using software or networking or virtually anything else. Building software is an immensely creative activity.

One of the questions I ask almost every group of students I teach is do they think writing software is more art or science. The majority of developers say that although there are elements of both, that software development is more art than science. By this, they mean that there’s more creative and abstraction skills required to be a good software developer than there is an explicit process. Of course, it takes a tremendous amount of discipline to write even the simplest of programs but this is an area where we get addicted to growth. Developers love the challenge of building things that have never been built before, solving problems, and providing tools that improve people’s lives.

We really don’t conform to the typical stereotype of the antisocial nerd or geek who found friendship in silicone circuitry. Modern software developers come from all walks of life and all backgrounds.

Writing software is perhaps the most engaging and challenging profession of all. Software development requires a greatly diverse set of skills and we have to be good at all of them to be successful. To design software takes a tremendous amount of creative visualization-after all, we’re using our imagination to understand a problem and model its solution. To write software requires a great deal of tenacity-we must keep track of a large number of details and use a whole variety of techniques to manage the enormous complexity of even a relatively trivial program. To debug code takes exceptional analytical skills-completely different from the skills required to design software, but developers must be good at both. As a result, we tend to use both sides of our brain in the process of building software, and this can make for a highly satisfying experience, but also a highly challenging one.

I’ve asked a number of non-software developers what they think the process of writing software is and I’ve heard of lots of different answers, none of which are anywhere near what the process really is about. I supposed that’s true for other fields. Professional acting is much more than just pretending. Great actors become their characters and transform into another person. It’s a great skill to have and certainly very few people have it, but what they do is not anything like the title of their profession implies. They are not act-ors, they are “be-ors.”

I know people who have gone into the restaurant business because they love the process of sharing food with their friends. But preparing five hundred meals a day is very different from sitting down with your friends and enjoying a scrumptious dinner. Chefs are some of the hardest working people of any profession. It’s a highly intense environment, which is why a lot of people drop out of the profession. I think a lot of people in a lot of fields feel like they have to make compromises because that’s just the way life is, and perhaps it is for many of them, but software developers still find fulfillment in our work every day we actually get to build software.

Of course, it takes an enormous commitment and it’s certainly not easy to break into the profession. Most of the developers I know learned what they needed to on the job or through a lot of self-study. As such there’s a huge divergence in skill sets and knowledgeability in this industry. There is no set of clear standards so it can be challenging to work on teams when everyone has their own ideas on how to do things.

Writing software is a group activity. Most software development projects do not have coders siloed from each other just turning code out. Most of the code built for business today happens in a subdued environment that requires entire teams of individuals to work together. Of course, developers aren’t really known for their social skills, but a lot of that is changing as we realize the desperate need for communication among teammates.

How do you evaluate a design?

This is a question I often ask software developers in my senior advanced software design classes. I tend to get blank stares in response, not because they don’t know how to evaluate a design but they rarely have a common rubric to apply. This can be a challenge for teams, making it hard for us to communicate and collaborate when building software. So I spend a lot of time in my classes defining terms that will serve us in being able to evaluate what’s virtuous in software designs.

Developers love my classes because they immediately recognize the value of talking about and thinking about these things. I’ve had the chance to work with many senior software developers and I’ve made it my mission to find out why the successful ones are so successful then I share that with other developers I work with. It seems as if we each have a piece of the puzzle, and when we put it together we get the big picture. That’s precisely what I do in my work, which is amazingly satisfying.

Posted by: lrrp | September 17, 2017

Hates when you win….


“Don_t blame others as an excuse for your not working hard enough”

“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


« Newer Posts - Older Posts »