Source: Codeguida.com

Is it possible to be a pro at one thing while working with different technologies? No correct answer so far, but developers who have experienced that can share their thoughts on the question.

In AMC Bridge, teams work on engineering projects, which means that specialists should be well up in programming as well as in math disciplines. There are not so many specialists of that type; hence they are cross-functional and change technology stacks from time to time to study new things. Does it increase demand for their services? What are the advantages and disadvantages of such technological versatility? You can find the answers below.

Oleh Spodynets, Software Developer. 14-year experience in development, 6 years with AMC Bridge. Dnipro

When I came to AMC Bridge, I worked on a project where we developed a user interface (UI) with C++. The UI had to connect plug-ins of graphic editors that worked with geometry.

In a year, the project launched a sub-project related to virtual reality (VR) devices. It came like a bolt from the blue! Firstly, I became a Team Leader. Secondly, I started working with a technology I had never worked with before—VR. AMC Bridge Team Leaders usually go through research projects, but I got in the external one right away. For me, it was like learning to swim in deep water.

About the project

Automobile manufacturers used to create true-size prototypes, from glue at first, later—from plastic. Now they have virtual reality. Our task is to ensure that designers can quickly analyze an automobile design concept. The car body data should be transmitted to a plug-in, and the body should be displayed in the VR headset. That way, one can examine the model, change the color, open and close the door by just pushing buttons on a clicker. We had to play around with the project. Also, we had a client’s prototype for testing.

To work on such a project, we moved to a room where the real-size automobile would fit in. We assembled base stations in the room corners, made the initial setting, and started experimenting.

Reluctance versus curiosity

At first, I was pretty reluctant to such a vector change, but the interest took over. In my opinion, only that sort of challenge helps us to improve ourselves and make us stronger. And such extreme turned out to be quite positive: it unveiled additional resources that helped process information faster.

Surely, the first month was not easy. What does VR stand for? How does VR headset tracking work in cyberspace? How to build a user interface? Unlike the usual one, the VR UI has an additional dimension and causes additional problems.

After carrying out the first experiments, it became clear why our code should generate no less than 90 frames per second and what motion sickness is. And you got how you can feel sick when wearing a VR headset, and something is glitching, or the horizon is suddenly getting skewed. However, the sphere inspired me greatly as it touches entertainment and games. I should confess that we were discovering VR not from the technical side for the first several days, but from the emotional, we were just having fun.

Our task was to create a project prototype on a browser and then—on a game engine. I did not work with 3D graphics and shaders before. Thus, I just opened OpenGL lessons and started studying. Just as now, then there was plenty of information. You only have to search and use it.

Not everything worked out, and it bugged me. But on the other hand, it stimulated to go on. Another motivation was responsibility: it was the first time when I directly communicated with a customer and approved architectural decisions.

Horizontal or vertical development?

I am convinced that professionals should be unbeatable in their fields. They should be asked for advice. But at the same time, it’s important to try your hand at the related sectors to get new experience.

During the last three years of rough switching to VR, I gained a lot. It was interesting to create a new architecture, write solutions from scratch, and invent a good many. It was similar to a workshop with freedom of artistic creativity and experimenting—a valuable experience. Now, when I look at other projects’ architecture, I understand them much better.

It might seem trite but leaving a comfort zone means growing. And now, I am open to new proposals that would teach me new things. It’s cool to work on a project where all is clear, organized, and outlined. But everything is good in its season.

Roman Kamantsev, Software Developer. 13 years in development and with AMC Bridge. Dnipro

In my career, I had many switches between technologies. At first, I worked with C# and ASP.NET, then—with Java, and after that, I returned again to C#, where I had a lot of desktop developments. I also worked as a DevOps Engineer on a project where there was almost no programming—I took care of servers and deployed.

My last transfer was to the mailing-related web project. Almost all client code was written in JavaScript, but I had never worked with it and didn’t know much. I still remember how I have been looking for an odd comma in the code for almost a week.

It was not easy, and I traveled through all the stages: from denial to acceptance. I understood that there were only two ways out of the situation: reach the moment when I would start to succeed or quit. I chose the first option. Although JS was not that cool as now—there were no Angular- or React-level libraries, development environments did not properly support JS, browsers and a limited number of libraries did not have high performance capabilities—but still, there was enough material. That’s why I just studied it step by step.

All languages are alike

When transferring, it’s important to understand that you won’t be able to demonstrate results at once. Certainly, everybody has their own story, but according to my observation, independent work starts not earlier than in two weeks.

Another point I came across was related to JS itself. Unlike with C# and Visual Studio, in JS, it was not possible to debug and understand where an error was: you had missed a comma, and you got an error in the other place in the library! And then, there were no options to find it quickly; you had to search manually.

However, after several switches, you begin to understand that all languages are alike: usually a very similar syntax, just different constraints. Software development principles are also commonly used for all technologies. And an experienced person can easily make turnarounds between them. Besides, after a while, you start to differentiate the general software development principles, such as ‘Keep it simple’ or ‘Don’t repeat yourself’, for instance. Therefore, sometimes you spend only 20% of your effort and time on technologies themselves.

Surely, it also depends on tasks. You can easily fix something having a minimal base. If you are a .NET developer, and you have to create a web project from scratch, it will take a lot of time.

For me, the transition to JS was the right decision. It gave me a great bonus for the further work as a full-stack developer, though, in AMC Bridge, it presupposes the back end mostly.

Horizontal or vertical development?

I do not have a hard and fast answer to this question. When developers are geared towards something specific, they can cope with any task, even if only in that technology, but well and truly. At the same time, versatile developers can independently solve lots of general questions in a wide range. If specific tasks occur—from my own experience, it doesn’t happen often—they can always seek advice from subject matter experts.

In my opinion, a much more important thing is to have full-scale knowledge, for instance, in mathematical disciplines. It can take a month to gain insight into new technology. But you’ll not get onto geometry, trigonometry, higher mathematics that quickly.

Pavlo Bidenko, Project Manager at AMC Bridge. 10 years in development. Dnipro

I worked with .NET when my teammate and I were suggested to switch to pure JS and work on a web application for visualization. There were no ready-made solutions at the project, and it meant that we had to learn everything from scratch. We had lots of mistakes and problems. I thought that I knew how to write in C# and .NET, and JS seemed to be simpler. But I was wrong. After the first critical feedback, I had to redo everything and consult literature in the end.

Read instructions at the start

It happens that when buying something, we seldom read instructions. Most often, we do something, and only when it goes wrong or breaks, we open a user guide. The same is in programming: you find a ready-made solution on Stack Overflow, implement it, and only when you see it doesn’t work, you pick up a book. When I read a number of books about JS, things got much better. And to thoroughly get onto something, you need to read more than one book. It is possible to get a solid theoretical background only in this way.

Invest in knowledge, especially when this is about studying a new programming language. And also, do not neglect your associates’ experience who have already made that way. It will help you minimize the number of taken knocks.

It is necessary to use various tools to avoid creating duct tapes

A language should help in writing code but not create constraints. That’s why it is necessary to use various tools to avoid creating duct tapes and reinventing the wheel. If you always do something time-consuming in Java, you may not know that it is possible to do the same but with less effort in JS, for example.

I am happy that I had that experience. I recommend everybody to study essentially different languages. For example, .NET, C#, and Java are almost the same, so knowing all of them does not give extra benefits for growth. But if you study C# and low-level C++ or C# and JS, Scala, or something from functional programming and OOP, you see different approaches. At least, it is worth feeling familiar with basic concepts of different languages and frameworks. Then, you’ll be able to find a particular solution to each specific task, even if the solution is from a different technology stack.

A new language helps to see your major language from the outside

Is there no possibility of suggesting a new tool or technology for a project? Then try something new in your spare time. It is a must for maintaining your market value. Sign up for thematic newsletters or follow top experts on Twitter. This way, you will keep abreast of the news spending little time on that: you can read 3-4 blogs. When studying something new, I always save best practices in a separate folder. Probably, I won’t use them in a current project, but maybe I will be able to do it in the next one.

Why do I consider it important? Firstly, a new language helps to see your major language from the outside: by understanding the principles of JS, for instance, you get a more profound comprehension of C#. You can always add a trick from one language to another. Secondly, such full-stack developers get leading positions more easily as they can propose ultimate solutions, and that’s exactly what the clients need.

Horizontal or vertical development?

Together with teammates, we often argue that it is better to know a little of everything or be a subject matter expert. I suppose that the more solid knowledge in a particular sphere you have and the more new technologies you embrace—the better. A large-scale outlook, or a T-shaped development, provides lots of opportunities, as T-shaped developers can cope with issues that are beyond the I-shaped developers’ depth.

At some point in time, T-shaped becomes the only way for growth. When? How to understand that you are already up in one thing? Answer the question: can you already solve any task without Google, and do teammates ask for your advice? Then, that’s it!