How do you learn?

Continuous learning – old phrase but increasingly important in the software development industry. It is crucial to recognize best practices how you are going to stay on top of technology development. And when you face a new technology challenge, the learning skill is the most important survival tool. So be prepared.

In this post, I highlight some learnings that can help project managers, product owners, or other stakeholders to understand obstacles in software development better. I also reflect on some of my learnings from software development to the project management perspective. All this should boil down to how important role learning skill of the individuals plays in software development and how it impacts to the development projects.

Learning a new tech

After leading software teams for over a decade, I decided to refresh and improve my software development skills. Ruby on Rails was given as a learning environment by my tutor in my future employer-to-be-company. Everything I knew about Rails was Rails Girls (http://railsgirls.com/), an international movement that provides guidelines and materials for workshops that teach women how to code using Ruby on Rails. Ok, maybe also more seasoned male practitioners can also learn this I thought. I got a bit more excited when I learned that there exists actually quite a large ecosystem and pretty famous companies like Airbnb, Shopify, and Kickstarter providing their service on this platform. So let’s GO, I am ready to learn!

As a project manager, I remember seeing people get excited when they are asked to assign a new task that requires building up a new skill. A new programming language, web framework, or tool. Excitement is connected to the strong belief that they can learn anything and that they will be excellent at that. This excitement tends to make people forget that learning takes time and patience. Also, your project may or may not have that luxury… It is easy to forget until the next sprint review.

Starting from the void

Turned out that there is a lot of information available to learn Ruby on Rails – a swamp of information where you can easily get lost and distracted. I realized that I needed a learning plan, a focused one and I need to stick to that. Luckily I had a good mentor to support me.

From the project management perspective the senior team members, solid practitioners, are worth of gold. Not that they will solve your most difficult problems, they can also use their experience to help the junior members to remove impediments faster.

Tabula rasa

The problem at the beginning of the learning curve is that you don’t have the skills to evaluate the content, so it is hard to know where to start. You can start by implementing the examples from blog posts and get things to work – or then not. Errors in the examples provide frustration but also a good learning experiment: how to debug the problems that you run into and interpret the error messages that are all greek to you in the beginning. When googling these error messages you quickly see that someone somewhere has earlier ran into this very same problem and there are a lot of ways to recover. It takes time to test all proposed solutions to find out the right one for you. If any.

From the project management perspective, you may have tasks in your project that just seem to take forever for no particular reason. If the team is not familiar with the tools and technologies they are using, the solving of the unknown takes unpredictable time.

High-quality code from day one

One of the modern software development paradigms is Test Driven Development. I have had a lot of discussions around this topic – shall we write also the tests when doing the code, what if we do the tests later as this is now just a quick prototype, will we be faster if we don’t? I’d say that if you want your execution machine to be at least somehow predictable, need an ability for quick release cycles and emergency patches, and want to concentrate on your business instead of unstable software and team, it is better to do the tests from the beginning. It will help you to have better software faster. And senior developers that master TDD also say that it won’t even be faster to skip tests. The time spent on developing tests comes back in many ways. The test cycle is shorter because of a decreased amount of bugs and software is actually build to be tested. If the software structure does not support testing, it will make adding tests later time-consuming if not next to impossible.

DevOps – Why building a development environment is time-consuming?

I want to stress one aspect that may be descriptive for the whole SW industry; the developer toolchain components may be good for the exact purpose that they are created as the stand-alone tool but the integration is not straightforward all the time. Seamless integration is needed to build an efficient software development environment since that will fasten your development. You may have the illusion of the working development operations and it may very well be … after some debugging and googling.

Everyone knows this already – who cares if open source documentation is a bit outdated…
Open source is a brilliant thing – you just integrate the components and you are ready to go. Sometimes you just need to read some documentation. Some comprehensive documentation, some not so detailed, some outdated, some… CODE. There is always self-explaining source code available. Obviously reading code is slower than learning from good up-to-date documentation.

Good tooling for documenting your software

I followed the best practices to write my tests. After I had my tests up and running, I start the discussion with the team about the documentation. Swagger / Open API tools were recommended. It means a nice way to combine the test code and documentation on the same file. Easier to keep also documentation updated. The downside in my case was that OpenAPI tool for Rails, rswag, integrates with a bit different integration type of tests that I already had, so I needed to learn new syntax and convert my tests accordingly. This is a good example of the schedule impact of the wrong tech selections.

The summary, the conclusion, the point

The key takeaway from the project management perspective? Schedule risk that is hard to estimate. There are some “industry standard” multiplicators for this type of “unknowns”. Still, it is better to get the risks visible so the whole organization can be prepared instead of being surprised and then executing emergency maneuvers.

In short, the team shall know their technology stack. Ideally. In practice, you should minimize the amount of needed learning and then give the team the needed time to learn. In addition, make sure that the team is ready for the challenge, ready to learn, and most importantly, make sure that stakeholders understand the consequence.

Learning is not simple even at the age of the internet. You have to be committed, shall not give up, shall not retreat. There is one question I am going to stress in the future on the job interviews and when building the team: “How do you learn new things?”. If people have difficulties articulating this, I would proceed with caution. Prepared to support their learning.