CodeGym /Courses /Python SELF EN /Creating Products

Creating Products

Python SELF EN
Level 64 , Lesson 0
Available

1.1 "People Aren't Born Anymore, They're Grown"

Alright, since you're still here, let's keep going. "And I'll show you how deep the rabbit hole goes" ©

Let me tell you how the product development process works — we'll walk through the steps from the topmost global level down to the very bottom — writing code. I think you're in for a few interesting discoveries…

Modern IT products aren't written anymore, they're created. They're assembled piece by piece from libraries, frameworks, third-party programs and products, or they're even using remote paid or free internet services.

A modern product is a whole zoo of technologies, services, solutions, and processes. Some work is done by people, some is automated, and the other 90% is done by cloud services in data centers. The world ain't what it used to be.

But the first thing you'll notice is constant changes. You're no longer writing programs, you're making changes to them.

1.2 Constant Changes

You'll join a team of 20 people who have been working on a product for 5 years, and the 7th version is currently available to users. Your task will be to make changes to this product. Small ones, so as not to scare off current active users.

And it won't be easy, because the product is already up and running. It has clients, and they pay money. So, breaking anything is not an option. Making changes to an already working product is several times more challenging than to a new one. There are special standards, migration protocols, and utilities for this. It reminds me of a joke:

Two old friends meet: one became a mechanic, the other a surgeon... Each has their own life, worries, joys... They tell each other everything, and then the conversation turns to salaries. The auto mechanic says, "Well, I earn 30k a month and I'm quite content with that, how about you?" The heart surgeon says, "Well, I make about 100k per operation...". The mechanic gets curious, "Strange, why such a big difference? We do the same thing - change parts." And the surgeon says, "Well, let's go to the car, start it up...". The mechanic starts the car, the surgeon opens the hood and tells the mechanic, "See, the engine is running? Change it! :)"

Even if a miracle happens, and your team has been writing the product from scratch for a whole year, only to release it later, do you know what will happen next?

If your product becomes successful, the product owner will want to develop it. Release a new version, add some functionality. Or at least conduct a few experiments. And do you know what's coming? Changes.

1.3 Product Value

From a modern development perspective, only code that has been released and a feature that users are using has value. If you've written code, it's stored somewhere, it works, but people don't use it, its value is close to zero. Therefore, all code should get to production as soon as possible.

Your code should go through the following stages:

  • You wrote it and made sure it works.
  • Your TeamLead reviewed it and added it to the main branch in Git.
  • Tests during the program build showed that you didn't break anything important.
  • Integration tests showed that the product works as it should.
  • The QA tester checked this code and gave the go-ahead for release.
  • Then the new version of the product needs to be built and released on the server.
  • The new version of the product needs to be packed into Docker Images and released.
  • You may need to run migration scripts and make changes to the database and/or other third-party solutions.
  • Then you need to gather logs on the server to make sure everything works as expected.
  • In case of an emergency situation, if you broke something, you need to roll back the build, restore the previous state of the database, and not lose the actions users did while working with the unstable version of the product.

In most companies, these tasks are now solved: new processes are set up, special people are hired, special security protocols and quality control standards are introduced.

The larger the company, the less time passes from writing code to the moment it hits production and becomes valuable — starts providing benefit to people.

In most companies, code goes through this path in two weeks. However, there are companies that release every week or even every day. Some rare exceptions even do it several times a day.

Written code is worthless. Only code running in production brings value.

Comments
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION