The question of how to measure software developers’ productivity has long been a subject of debate in the tech industry. New versions of old misguided approaches, such as counting the “number of lines of code” written, resurface, over and over again, despite not reflecting value creation or performace.

In fact, setting incentives based on such metrics can lead to counterproductive behaviors, as explored in “Reinventing Organizations” by Frederic Laloux. The book highlights how traditional incentive systems often undermine intrinsic motivation and foster a culture of gaming the system rather than pursuing genuine excellence.

Resilience is the ability to bounce back from setbacks. It is definitely a critical skill to have, especially during difficult times; although it is often overlooked.

Personally, I have always considered myself quite resilient. However, 2023 has really made me prove it. And, to be honest, it has been a very challenging year. That is why I figured that writing about it would be the best idea for my end-of-year article.

The Covid pandemic forced many companies to unwillingly transition to remote work, thinking of it as a temporary necessity. However, at least in tech, remote work has become the new normal.

But… Is switching to remote work just a matter of working from home and using Zoom? Simply replacing the physical meeting room in the office with a virtual one? Or is it deeper than that?

In late 2015, based on all the lessons learned from my startup experience, I decided to create a representation of the different choices startups encounter through their lives, as a map; and then assigned some values and scores to them, so that Genetic Algorithms could be used as a way to learn to navigate those choices.

Originally this was implemented as a dektop application, but I have recently built a web application to let users experiment with Genetic Startups. Here is a quick demo video:

As a developer, you work on software projects, right? …Or are they software products?

Like many others in the software industry, you might think those two concepts are synonyms; but they aren’t. In fact, whether the software being developed is considered a project or a product may have critical and non-trivial ramifications, in many aspects.

The not-so-subtle differences between software projects and software products actually have a huge impact on our behavior, both from a business as well as from an engineering perspective.

If you are in the software industry, and specially if you are in the DevOps space, you are probably familiar with the concepts of “Infrastructure as code” and “Configuration as code”, which are very popular lately. But, what if that same idea could be applied to everything else in a software company? Aren’t documentation and training great candidates for becoming “as-code” as well?

During 2019 I’ve been intensively working on this idea at CloudBees University, along with my colleagues. Nowadays, for our training platform and courses everything is done “as code”.

Sounds interesting? Keep reading to learn more about it and/or watch the “Training As Code” talk my colleague Mark Waite and I delivered at DevOps World | Jenkins World in December 2019.

The software industry has been growing significantly for the last few decades, and this trend seems to only be accelerating.

Due to this fast growth, there has been an ever-increasing demand for software engineers and, since there are not enough developers to meet the demand, many companies often fail to cover their open positions. But, is it also possible that we are looking at the wrong skills when hiring?

Most job descriptions simply list a set of technologies as the necessary “profile” for the open position. However… Aren’t there other skills that could have a higher impact on developer’s success?

Are we looking at the right skills?

Continuous Integration, Continuous Delivery, and Continuous Deployment are key modern practices in software development. These techniques help us reduce integration problems, automate quality assessment and make deployments much more predictable and less error prone, allowing us to deploy easily and frequently. But… Do you really know the differences between the three?

The aim of this article is to help clarify what do these techniques mean and highlight the benefits each one provides. We will also analyze which one should be chosen depending on the circumstances.

10 years ago, Jeff Atwood wrote an article he titled The Programmer Bill of Rights. In that article he described 6 fundamentals that companies should provide for programmers to be successful and work to their full potential, thus maximizing their productivity.

Sadly, ten years later, many companies still deny these basics to their developers, even though the business case for these six points is absolutely proved.

In this article, not only would I like to update the original 6 principles, providing further evidence of their importance; but also I would like to extend the list. Based on my experience during the last 10 years, I will propose 4 new fundamentals that I consider absolutelly necessary for the daily work of any programmer, developer or software engineer. Let’s get started:

I have worked in many software projects and have been lucky to be in the initial team of several software products. Besides, having acted both as a Developer and as a Product Manager has allowed me to have a wider view of what usually causes most friction between business and engineering: time estimates.

It usually starts with managers or customers asking “when will <this idea> be ready?” and it is usually followed by developers racking their brains to give a specific date… Needless to say, that date is likely to be dreadfully wrong, as it is the norm in the industry. There is a near-total inability of developers to predict how long a project will take, so time estimates are usually worthless.

However, applying Scrum along with some XP practices we can avoid the uncomfortable tension of asking developers for time estimates. Instead, we can calculate release dates automatically, getting infinitely more accurate time estimates, while saving all the arguments and keeping team morale high. How? Keep reading!