Through my career as a software developer, I worked with multiple languages, environments, and frameworks. Also, I was teaching many people how to code, cooperating with a lot of junior developers.
There are several things that junior developers need to learn. Nowadays, it is effortless to learn fundamentals having all these books, video tutorials, bootcamps, webinars, and training.
But still, some things are not taught well enough. The reason for this is mainly because some concepts are hard to explain theoritically.
One such concept is the art of the experiment. Especially now, when young adepts of programming learn to write correct, formalized code, it is something that is left behind — something that becomes easy to forget. Don’t get me wrong here thus. Formalized programming is something significant. But it’s not something you need to do all the time.
Let’s take an example. There is a ticket to solve. But what solution to choose? What will work? Now, two approaches appear. I have observed that there is a significant difference between junior developers and more experienced one’s decisions.
Junior developers will start to work on the ticket. Choose a solution he/she thinks can work. And try the approach in a formalized way.
It means the developer writes the code using all standards that apply to write quality code. It seems nice until the first approach gives expected results. You end up with a nicely written system. There is nothing left than to test the solution and commit it to the repository.
But it rarely happens. The fact is that the first approach is rarely an excellent solution if you are a junior developer. Most of the time, you will need to roll back and choose another solution and another. It will take some time until you find the right one. If you are a junior developer, you can think this is the way programming works. But you can also feel frustrated by how long it takes to solve a problem.
And in fact, you should be frustrated, because it’s wrong!
What you will learn while becoming a better software developer is that you should minimize time spent on testing approaches. And that NO ONE expects you to write cute code during the experiment phase of writing code. No one will come by and say: “You are writing the proof of concept not aligned with _WHATEVER_STANDARD_ you should use.”. It never happens.
What you can hear is more likely: “Why it takes so long?”. And there is something to take from such a question because it should not take long to validate an approach.
Minimize the time needed to experiment with the code, with the framework, language etc. Forget about all standard for the time of this phase. Leave standardization for the next stage of software development. Because when you have the right approach, it will be easy to standardize the code.
To give some examples. Let’s say you need to test 3 approaches, and approach number 3 is the proper one. Each approach test takes 8 hours. 2 hours to use the method, 4 hours to connect it with the project you want to apply it to, 2 hours to apply all standards necessary. It’s simple math. For three approaches, you spend:
3x8h = 24h
Now, let’s assume you will create a test project next to the main one. It compiles faster. It allows you to debug the code more quickly. You don’t connect the approach proof of concept to the codebase yet. You don’t apply any standards to the source. You spend 2 hours on two first solutions, and 8 hours for the last one (more or less).
2+2+8 = 12h
As you can see, you will spend 50% less time to finish the task!
What a relief! Your code will be as good as it is in the first approach. It will become less frustrating to solve the actual problem. Programming will be much more satisfying this way!
The math is simple, but it’s not math that can help you become a better software developer. It is a change in the way you think about programming. The art of the experiment is one of the major concepts to use to accomplish it.
But how to experiment with the code? There are various ways to do so. Here are some tips that can help you with that:
- Divide uncertain tasks into “experimentation” and “integration and standardization” phases
- Test solutions you are not sure of in the “experimentation” phase without integrating and standardizing them.
- Use git branches, commits and stashes to save work-in-the-middle versions of the code that work correctly (create safe harbors to go back to, if you have to remove a lot of systems)
- Create a side project that compiles faster than the main one, where you can test concepts
- Keep a document with a list of hard fixes and descriptions of how you solved them. It will help you next time you will face the same issue (memory is volatile!)
- When an experiment gives the proper result, write the final solution in your central system.
To sum it up, create a space and time for experimenting. It is not only more satisfying but also is more effective. Your code will be better because you won’t leave any junk from experiments. It will be integrated and standardized better because you will have an individual phase for this task. You will finish jobs faster and boost your learning abilities.
Ps. Join the Programming Deck waiting list! A printed deck project for people who want to learn about programming. We need 6 000 people on the list to be able to publish the deck!