I'm so happy to share with you some simple tools and practices which helped me become a developer.

‍

In July 2017, I joined a company as a junior developer which develops mobile apps. I was super excited to be there as it was my really first job in programming.

Indeed, when I finished studying I decided to give a shot at consulting. I was part of a large project as project manager officer. I was making sure to have the performance indicator up to date and that the right people were meeting together. It was interesting for sure, but I was feeling that I was not producing materials myself, getting my hands dirty in a sense. I had always been attracted to programming, so I decided to give it a shot.

Long story short: I finally was a developer. The only problem: I had very few developing skills.

That is why I would like to share with you some of the most important tools that made me progress quickly:

• Asking for help the proper way
• Ghost-programming
• Pair-programming
• Reading the doc
• Test driven development

I believe they will be useful for a young developer starting to learn or an experienced one looking to have his team progressing.

Ask for help

Doing it properly will make you learn

Even though you'd know exactly how to do a feature, as a young developer you will encounter situations that you will not understand: debugging, unexpected behavior, new library... And sometimes, you might end up spending half your day on these issues, doing some coincidental coding. You are also likely to spend your afternoon on Google trying to find the solution although you did not understand the cause.

And maybe you will finally figure out it required a two-minutes job to fix this issue.

There is one thing that is to prevent this kind of situation: asking for help.

It might seem obvious, but some inexperienced developers in this case either do not want to stop looking by themselves or do not dare asking to more experienced colleagues.

Oh well you're right, you will probably argue that there is nothing like a good day of searching to learn a lot.

Sure, it is indeed a good thing to start looking by yourself and if the solution is given too quickly one might learn nothing.

That is why you need to teach people in your team asking for help the right way, this way young developers in your team will learn how to:

• Explain the context: how to explain the context of the feature they are developing to someone who is not familiar with it
• Synthesize the issue: how to rephrase the issues, explaining the errors they get and the behavior they were expecting at first
• Describe the hypothesis: how to explain their hypothesis regarding the issue they get and their leads on how to fix it as well as what they already tried

On the other hand, experienced developers will strengthen their skills on how to explain the good patterns. They will take time to make an intelligible sketch or explain how to look properly on the Internet to find the answer by looking for the issue on Github or by reading the documentation carefully. (after having looked at the error message on Google).

Now that we know how to ask for help, what can one do on a day-to-day basis that will speed-up the learning process of new developers?

Ghost programming

Split your tasks into very small chunks

Developing a feature requires going through some important steps to say the least. One have to imagine the user experience, the design, the edge cases and the technical solution to implement it. For the last one, as a young developer, you could have been told precisely what you need to do in order to get it right:

"We'll need to create a service that returns this kind of object and use it in this other part of the code where once you get the results from the API call you can display it to the user"

In my first months in programming I was able to spend more than one day to implement this feature. When I was asked where I encountered issue, I was struggling to give a proper answer: it was very confused on how I made it through.

That was the issue. I only had in mind the final results and I did not have a clear plan at the beginning. I did not realize I was spending too much time on some simple aspect of the implementation. Then I was feeling stressed not to succeed in doing it the right way, very confused when it came to ask for help and probably producing poor lines of code. I was then told to do ghost programming.

Ghost programming consists in splitting the instructions above in very small steps and giving to each of these steps an estimated time for completion (between 5 and 10 minutes). It forces you to:

• Prepare upstream: Write the technical solution for every step. Estimate how long it will take you. You will then be able to anticipate any issue you might have: you can peacefully ask for advice before starting!
• Identify blocking points: Spot during the development where you are losing time because you are already above your estimation ? This is where you can ask for help! ??

Ghost programming was really a relief. By giving you very short-term objectives, it allows you to start producing your feature with as many keys as you can have!

Pair-programming

Get the most from experienced developers in your team

If you are starting your journey as a developer, there will be time when you will need the help of a more experienced developer to go through a technical implementation. If you are dealing with a language/framework/pattern that you've never heard of, it is most likely that he will have to do the implementation with you.

Most of the time, you will sit down next to him and be very focus on what he's doing. You'll probably be asking some questions and you will understand the whole process.

In theory of course, since chances are high that you will skip a question or two on some foggy implementation that your co-worker will perform. And in my case, I ended up, when I needed to implement the same, either to go back to my instructor or to copy-paste the code he wrote.

One approach very common on my company which I believe softens the issue above is the peer-programming. You are surely familiar with the principle which is very simple:

• Start a 5-minutes timer
• Start developing
• When the time is up, leave the keyboard to your peer and start the timer again.

The key point in this exercise is to be very strict about getting the hand off the keyboard, or you will easily be back on the previous situation. It is also essential that both of the developers are describing how they go through the implementation.

Experienced developer will learn how to:

• Explain the pattern that they are using.
• Point out the reasons why this pattern is useful in this particular situation
• Describe potential pitfalls

They might then realize that they are not completely familiar with the ins and outs of the pattern and go themself deeper into it ?

• For young developers, doing it by themself will make them understand way more! They will realize what they are doing and by describing out loud what they are about to do, they will understand the reasons why their first approach might be error-prone.

Peer-programming is a real good practice when it comes to help a developer progress. Make sure to use it as often as possible!

Read the documentation

Understand how to get the proper knowledge

Ironically, I have been told the most obvious and useful learning to progress quickly a couple of months after I started my journey as a young developer. And that will be to read the documentation when you are using a new language/framework/library.

Of course, you quickly realize when you start programming that a lot of the answers to your questions are in the documentation. It's probably the first thing one will check if you ask for help. But in my case, I was looking for the extract of code that seems to be in my interest, copy it and use it in my code.

?This is not reading the documentation.

Take the time to start the documentation from the beginning, understand the core principles and basic examples and then go deeper. It will surely take you longer than only having a look at the part of interest but it will totally be worth it.

You will learn to:

• Plan more precisely the next features to come as you know how to use this language/framework/library
• Explain to your co-workers the reasons why your team is using it this particular way
• Train yourself to read code: starting from easy examples you might want to take a look to the repository and understand more

Add the documentation of your next unknown library to your Pocket and read it in your morning commute. This will take you to a whole new level ?

Test driven development

Start by writing what you want to obtain

I will conclude this series of approaches by a well-known software development process: the test-driven development. This is not my intention to explain deeply the concept and the different best practices (I leave it to this tutorial ?) but I would like to quickly underline how useful it was on my progress.

Very quickly, the core principle of TDD is to write the test cases with the appropriate results and then to write the code. I feel that it is so much easier to write functions following this pattern:

• You will understand objects you are dealing with very easily
• You will debug your code into your terminal without having to run it
• You will develop steps by steps with the construction of your function and that will make it much less intimidating.

This is it! ?

Well, please do not take me wrong as you are finishing this article: these five points above did and still do help me a lot build and strengthen my programming skills. It does not change the fact that it takes time, practice and a lot of unexpected problems to become an experienced developer.

Feel free to start discussions on the relevance of each of them on the comments! ?