Full Stack Developer skills in API era – 2020

I called myself a Full-Stack Developer even before I became one. I see the same now from other young developers when I interview candidates for the Full-Stack Developer position. My goal was to become a Full-Stack Developer, so before it happened, I was faking it. 

Faking something before it happens is not a wrong approach, but not knowing the truth is terrible. 

There are some skills I was pretending I had before I had them. In this article, I write about them and other skills one needs to build to become a rockstar Full-Stack developer.

Here is the list of the skills that every Full-Stack Developer needs to have:

• Mental model
• Technical skills
• Universal standards
• Learning process
• Writing habits

Full-Stack Developer has a different meaning today than five years ago.

In the era of APIs and frameworks, we have to make sure we understand what Full-Stack means and what we need to learn today in the 2020s.

A Mental Model

Mental models are potent concepts when making decisions. Mental models are how we understand everything, in this case, how Full-Stack Developer understands different layers of application or system.

In the API era, understanding server-client communication is crucial. Also, the same as before, we need to know how our web server behaves in different conditions as well as final consumers – clients. Equally important is to understand request-response flow and structure.

Our conscious brain’s memory is limited. We can’t keep all the information in our conscious minds. Instead, we use different types of mental models to understand complicated systems.

In short, mental models are pieces of the picture we draw in our minds.

Technical skills

I met many developers that are focused on technical skills only. Technical skills are necessary, but not crucial, to become a relevant and authoritative Full-Stack Developer. 

Programming languages, design patterns, architecture, IDEs, deployment strategies are just tools to solve a particular problem.

Let’s compare the process of building a web application to building a house. 

When building a house, everything starts with an idea. Then, an architect prepares all necessary parts such as a blueprint, specification of materials, measurements, and others.

To make it short, you see that there must be detailed planning. Planning usually takes the same time as building a house itself, if not even more.

The process of building is one of the final steps. In API architecture, it’s the one-direction way. We iterate as much as needed on the design, and once when it’s finished, it becomes the contract. This contract goes to development as a final decision/blueprint.

From this, we can see that Full-Stack is not about using a hammer as a metaphor for programming languages and other tools, but more about visualization and execution.

“Vision without execution is hallucination.”

When it comes to execution, we need to have all those skills, such as programming languages, server management, deployment, and others.

In the API era, prevalent architectures like MVC are not exciting and useful anymore. Frameworks that promote tight coupling to the framework itself are useless in the long run.

Once when you understand all the points from this article, they aim to simplify the process of choosing the perfect framework and tools for your projects.

Calling yourself a Full-Stack developer just because of knowing JavaScript and HTML is too opportunistic.

Universal standards

I want to push this one on the top of the list of priorities for all developers, especially Full-Stack developers.

There are many reasons why standards matter. One of them is consistency.

Building systems by following universal standards helps us to develop long-lasting systems. It simplifies the recruitment process for business organizations and unifies the whole development process.

I worked without plans, design, without knowledge about designing software. Later, I started learning and practicing universal standards. In the beginning, partially.

Time by time, through repetition, I adopted more and more standardized practices, official standards, and standard recommendations in my workflow. 

It helped me to build quality long-lasting solutions and to simplify and speed up my workflow.

Building standardized APIs starts with API design. There was a need for standardization of API description.

Open API initiative recognized the immense value of standardizing APIs description. A consortium of industry experts has united to define Open API Standard (OAS 3.0). 

During the time, I used swagger to describe my REST APIs, but now OAS 3.0 is widely adopted, and we can call it The Standard.

In PHP community PHP-FIG (Framework Interoperability Group) works on PSRs (PHP Standard recommendations). The aim is to enable the interoperability of PHP components. Founders of The PHP-FIG are several PHP frameworks founders.

If you’re in Web development and SEO world than go to schema.org and keep on eye on structured data that I have written about.

Those are just the first ones that got out of my mind. There are many standards in the industry that can help us to become better developers, help businesses to achieve their goals and to improve the overall quality of life.

In our career, we all had at least one time that funny situation when we suggested to “start from scratch” instead of refining the existing app. 

By following universal standards, we can decrease the number of those situations and make our applications and systems last longer.

Learning process

Since you read this, you’re probably doing great. Reading, watching new stuff, and being open to different opinions is a fantastic habit and skill.

For me, the most potent subskill is reflecting all new things I read, watch, or do. I want everything I interact with, such as a book, video, conference, job, friendship to support my vision, or to raise the right questions.

Whatever I consume through my learning process and whichever medium I used, the new value needs to make a connection with my previous knowledge, experience, and vision in the first place.

An example of that, from my experience, is when I refused a few job offers. All of these offers were bigger than my current contract. They just didn’t match my core values.

So, there is no need for extra effort to improve your learning process. More important is to take time, think about all that you do, what you consume through your work and other media. Try to match it with your vision of your future. 

Does it match? 

If yes, perfect, do it! If not, why the hell do you do it? 

“If it doesn’t bring you income, inspiration, or plesure, it doesn’t belong in your life.”

Writing habits

Before I became a developer, I was working in NGOs in different positions. 

I led the youth organization that implemented projects in my local community. We worked on organizing workshops, conferences, and other activities to encourage and empower young people in our local community.

During that time, I went to workshops where I learned how to start, plan, implement, and finish the project.

Planning projects in detail was a mandatory thing. I had to elaborate on every aspect of the project in written form. The documentation had to meet a required format to get funded by the local government or foundations. Also, after implementation, all reports were written in a form that was required by sponsors.

This phase of my life taught me that all I do needs to have a scope, plan, and actions. Everything I do has more value if it’s written down in proper format than experience that never gets documented.

As a Full-Stack developer in the API era, documentation is the main attribute of a good project. Everyday communication with coworkers and superiors is fundamental. 

“Documentation is like sex. When it’s good, it’s perfect. When it’s bad, it’s better than nothing.”

The better I can communicate projects and everyday tasks, the better the developer I become. 

The more I write down about projects and everything I work on, the easier it becomes for everyone, company, new developers, and me.

Conclusion

Do not wait for somebody to ask you for some of these skills to learn. Start learning and practicing them today. Whatever you want to become, you must start, everything you are starting the first time is terrible in the beginning, but after a few months, you start liking it and incorporating it in your core skill set. 

Three months ago, when I started this blog again, I wasn’t focused on big goals, but small ones. The small ones are like “imaginatively, originally and freshly telling the story that I desperately want to tell.”

Am I perfect? Of course, not. Am I getting better, hell yeah!