Project you develop is the best growth facilitator

According to our research 40% of programmers declares, that professional development is the most important factor when they choose their employer. To facilitate programmers growth employers provide conference passes, books, days dedicated to side projects, hackathons.

During the Top Tech Employer certification process in Consult Red I interviewed engineers from the company. I asked - what is the source of their professional development. All of them told me that they grow as programmers, because of their everyday projects. To be fair, they read some books from time to time, but they didn’t feel the need for code kata exercises or learning on side projects - which is common in many software houses.

I can see two main reasons why. One, interviewed engineers had +10 years experience, so they already wrote a lot of code in their careers. Secondly, main projects, developed in the day job are the best opportunity for learning. In the end they allow you to solve real-world problems for several hours a day.

Of course this is not always the case, as my own experience shows. I took part in a few projects that changed how I see coding and even being a programmer. On the other hand, there were projects where it was really hard to learn anything new from my perspective.

When a project facilitates professional development and when it offers little to none stimulation? Let’s consider main factors.

Repeatability

Doing very similar things over and over is the number one enemy of growth. Repeating similar tasks a few times helps to master a certain technique or skill - making the work fast and efficient. After that, it may become monotonous. From the business perspective it’s not a bad deal, as many of the uncertainties are eliminated. But for a programmer, that want to develop his or her skills, it is a problem.

Ever heard of “yet another CRUD app”? In such a project most tasks boil down to adding a new set of the same actions over and over again. CRUD is nothing bad in itself, but when application requires only basic logic it can be a bit boring after a while.

On the other end of the spectrum we have apps, where everything is custom and it’s hard to reuse any popular approach. This means either a truly cutting-edge, scientific project, or reinventing the wheel. More likely the latter. It’s not optimal either. Such a development consumes a lot of time and it’s hard to learn properly.

Project complexity

More complex projects can be great for learning new things. There is one condition though. Complexity has to be controlled with documented design pattern usage and clear abstractions. If the high-level architecture and data-flow are not clear, working on complex projects can resemble archeological excavations more than programming. Yes, you’ll learn a lot about debugging, but in the end there’ll be frustration caused by a lack of progress.

Task difficulty

My own experiences are similar to desirable difficulty theory. This theory states that learning is faster and more efficient when learning task requires a considerable but desirable amount of effort. Such a task has to be accomplishable, so it has to correspond to solver skill. Too easy tasks can create an illusion of learning. This concept applies to education, but it translates nicely into professional world as well. Challenging tasks facilitate growth and acquiring new skills.

Tech diversity

We can think of old school bank systems written in COBOL. Some of them are still in production use, and they process a lot of transactions every minute. It would be hard to learn anything new working on them, because they are obsolete from the technology perspective and by now pretty much everything is figured out. The best projects often combine different technologies and are updated regularly. It allows programmer’s knowledge to be updated as well and assures they won’t be left behind in the fast changing tech landscape.

Team

People on the team are extremely important in this context. People create an environment where you can grow or not. If all team members are on the same level and have similar background it would be hard to learn from each other. On the other hand, if team members have mixed skills and experiences it’s more likely they will learn and challenge each other. Of course, they need cooperation, like designing new feature together or code review. They also need some common ground - otherwise it’s more likely they’ll spend most of their time fighting over everything.

Time pressure

This is a key piece of the puzzle. A project can be a masterpiece from a technical point of view, with the best team. But it won’t give you a lot of opportunities to develop professionally, if there’s no room for proper research, finding appropriate solutions, discussing ideas with the team or thorough code review. In the face of constant crunch it’s easy to use only what you know, even though it might not be the best fit for the specific problem.

Conclusion

Creating an environment where programmers can continuously learn new things is not easy. There are many factors that can affect it.

But working in such projects is a great source of satisfaction for developers. This corresponds not only with my personal experience. During the interviews in Red Embedded, I’ve heard the same thing - learning new things and growing on a professional level are one of the most important ingredients of the work satisfaction.