Learn To Develop The Code: My Way

Logo by karpenko_ilia/Shutterstock.com

8 YEARS ago I got my first job and it was a full stack position in some small outsource company. I knew almost nothing and I was spending much time understanding what was going on on both ends frontend and backend. Since that time, I have put my focus on frontend development, and now I know different kinds of development from Angular and React to “how does that simple Javascript thingy work exactly”. But I am still way too far from knowing everything. So I keep digging into the frontend world and, what is the most important, I keep trying to find the best way to educate myself. In this article, I’d love to explain my current approach to learn to develop the code.

I suppose that experienced developers might find my text obvious. Let’s say this article is for beginners and students, for developers who don’t know how to start their own projects. To be honest, I would love to use a time machine and tell myself all these things back in the days.

This article is not rocket science and doesn’t contain terrific secrets, it simply describes well-known things, which are grouped in one place. It’s an abstract framework that comes in handy when I want to create something new.

Learning is a project. So handle it accordingly. Consider it as a real project and your effort is an investment. You should have a plan: what result do you expect to achieve and what steps will bring you there. If you don’t have any plan, you will end up spreading your attention on everything but the real goal.

Compare:

I want to learn Svelte

With this one:

I want to learn Svelte, I am going to implement a simple web application Address Book. I need to do these 10 tasks to achieve the result. I want to host it on the service A to see if I did everything right and to see if it is available for everyone

Have you spotted the difference? The last one has much more meaning and also includes our expectations of what we want to implement. In the end, you will be able to say that you can write a real application on Svelte and you can clearly see the steps you are going to realize.

So far so good, we have a plan. Now what?

Let’s think of the project overall. What does it look like? What tools are you going to use? Think of it before you start writing the code. You might want to use some of these key features during the development:

• Git repository — stores and documents code, keeps changes history, remembers your success and failures
• CICD — automates routine processes (for instance, running tests, building docker images, deploying a new version, and so forth)
• Registry — this is optional but most likely you’d rather have one. For frontend libraries, it happens to be an npm registry, for Docker images we want to have a docker registry, maven registry for Java. There are many registry providers, so imagine your project and try to figure out which ones are required for you
• Deployment server — to see the result! You definitely want to see how everything comes together and want to see your work pays off
• Project management features — this is important to keep track of the project. Backlog, Tasks, Bugs, Pull-Requests, Time tracking, etc. We take it seriously, right? Big boys build adult processes around themselves as real companies do (we at Setronica use JIRA boards linked with BitBucket plus time tracking plugin — to manage everything in one place)

So many tools and services for developers nowadays

There should be two or three services. Don’t spread your attention on more than three! Stay focused, learn one thing, and then you would be able to start a new project to learn the other ones. I can imagine that it is not enough to stay within a single service. For example, for backend, you could use some platform like Heroku as it allows you to deploy complicated applications for free. On the other hand, it does not have any version control features. So select three services at max and don’t make too much effort trying to cover everything.

Depending on the idea you have in mind, one service can fit you better than others. Start from the real application — how many features does it have? Does it have a DB? Do you want to use Kubernetes to ship it? I don't have answers to all these questions, but I have some handy tips:

• In most cases, Heroku offers as many features for free as you can get
• For small static frontend projects, it might be enough to use GitHub Pages or a similar thing
• If you want to learn and deploy your application using the Kubernetes, try Kubesail out, it has a free account plan
• GitHub Packages is an awesome feature for different registries, like npm, maven, docker, etc

Once you have selected a service where to host your “production” version, select a git service. In 2020 they are all turned into combines packed with features. I love Github. It provides almost everything I need when writing pet projects: git, ci, docker and npm registries, project management — everything out of the box. Ah yea, private repositories, if you want to be a ninja. But you can take a look at alternatives like BitBucket, GitLab, and others.

Okay, following the 80/20 rule we did 80% of the progress and spend 20% of the time. Sweet! We did not write a line of code yet, but we know what to do, and we know where to do it.

Every application starts with a task. The task contains the requirements you want to implement. It documents the code you are going to write. And it answers the question “Why did I do it that way back in the days?”. Task is fuel. You pick a task and transform it into code. So create a list of tasks you are going to complete, thus you form the project backlog.

You can create a board for the project, for instance, in Trello, Jira, or GitHub. The board doesn't need to have Kanban features or automation hooks, it can be a simple layout with columns “Todo”, “In Progress”, “Done”. You can imagine your super board with columns I haven’t mentioned, it is up to you. Put your backlog task in the “Todo” column and be ready to start!

Managing the board gives you a strong experience and good practice of how to set up the work on the project. It gives transparency for the process, gives you moments of satisfaction when you see how many tasks you have done already! (That warm feeling, yes). If the company pays for your education, the board will give managers an update regarding your progress and about milestones you have passed.

Typical board for one of my projects

One thing about tasks. Make them as detailed as possible, as small as possible. Tasks with the text “Implement web-site” or “Write user settings page” do not make any sense. Such tasks are hard to complete, and they don't contain any historical info on what you did exactly. Try to split them and add more context about what you expect to do. Tasks like “allow a user to change email from the account settings page” or “add Typescript into the project” are small and meaningful.

And yes, use labels! Mark tasks with labels. Feature, bug, high priority, need to think about it — you can imagine yours. Discuss it with your mentor (if you have one) about it. Labels will give you feedback about task status and will draw your attention to the thing you worked on the other day. Keep your board in good shape.

Okay then, we are ready to write some code, huh? Let’s finish a few tasks. A few simple things to see some results. Let’s say, hello world on the browser page or health check API if you are working on a backend application. Why should we implement a few of them? We don't want to waste time deploying the application, running tests, building docker image, and other routine steps before diving into code wrap. Spend some time at the start of the project and play a DevOps role. I do believe developers have to know the basics of the continuous integration process. You don't have to learn to write terraform code for AWS services, but you should be able to write simple CI scripts for CircleCI, Github actions, or another CI service. Imagine you’ve just merged another great pull request into the main branch and then seat back and relax watching it build and deliver to the real environment.

Automate as much as possible, do not waste your time on routine actions

Finally, you can start writing the code, learning framework you have selected, reading tons of manuals and documentation, finding the solution in the StackOverflow, ironizing “why this example does not work on my machine?!”. Sounds cool, right? Not so fast, one last thing. Learn Git. Seriously, learn it. Learn to merge and rebase, create branches, open pull-requests, or merge requests (hey GitLab) or whatever-it-called requests in your version control platform. Ask for a review. Ask somebody to look at your code. We never write perfect code, but we can get better at it, and requesting a review is a way to learn and do better. Get used to it, it’s a typical development process in almost every company.

Code review is a perfect way to learn, share ideas, and discuss current implementation

And write the code. The more you write, the more you learn, the better you get. Read about the language you have selected, about common patterns, about testing, imagine how is it applicable in every task you are going to implement.

To conclude, let’s overview what we’ve talked about:

• Create a board for your project — boards are used almost everywhere and allow you to keep the process transparent and manageable. (GitHub Projects, Trello, Jira)
• Fulfill the board with tasks — learn to describe what you expect to achieve exactly and split big tasks into simple pieces so you would be able to see real progress
• Learn Git — it is a must-know tool for every developer. Learn about branches, forks, merging, rebasing, and all that stuff. Get used to writing detailed commit messages that answer the “why?” question
• Learn to automate — avoid doing routine things for every task. Set up CI scripts and learn CI providers (CircleCI, Github Actions, TravisCI, BitBucket Pipelines)
• Deploy current results — to see how much you have already done. Show it to your colleagues, friends, your mentor: you are transforming time into working application (Heroku, KubeSail, GitHub Pages)
• Write the code. Open pull requests, find people to discuss your changes. Think of your code if it can be done in a better way (But don't rewrite the same task again and again. You need to move on)

It seems to contain too many steps to accomplish. No worries, I promise you that next time you will do most of the things automatically like they are nothing.

This is a simple framework that brings good habits that, in my opinion, developers should have in their skillset. It helps to organize yourself. It might seem to take forever in the beginning, but it will allow you to move faster in general. Give it a try.