small_avatar_AdrianR3.png

thumbnail_avatar_AdrianR3.png

avatar_AdrianR3.png

Adrian

GET IN TOUCH

The existence of the technical debt in all IT projects is often an open secret that nobody involved wants to admit. The scale of the debt and the speed at which it grows depends on many variables. I’m gonna walk you through a few most important aspects of technical debt (in my opinion of course). With that knowledge, your daily developer work will be easier in the long run. Fewer bugs and the easier introduction of new features will surely be rewarding for the team and make the project itself better.

### 1. Keep up with SOLID
The first issue on our list is the fast pace of new features introduction. It often goes in combination with skipping some important design and architecture bits. The new feature is just glued into the project **without SOLID principles preserved**. If it works, it works, I guess it’s good enough, but this is only partially true. If you make these mistakes, they can get back at you in the future and interfere with the development of the project.

### 
2. Skipping Unit testing
The second problem on my list is **skipping Unit testing** of newly introduced features. If SOLID wise features can be placed between trash and garbage, we need at least add Unit Tests. Those can be reused when the feature will be rewritten or refactored. It is important to ensure that the functionality is redone in 100% and don’t introduce any regression bugs.


### 3. Omitted documentation
The third mistake is **forgetting about documentation**. Developers' brains don’t store unneeded information. We forget about feature-specific solutions and hacks implemented after a couple of weeks of the project lifespan. Sooner than later the project-specific elements will be overwritten by new features. And when you get back to the feature that you need to refactor it won't be there. And believe me, that time will finally come. You will spend many hours trying to figure out what the author had in mind. That’s embarrassing, especially when you were… the author.

### 4. Lack of the proper code review
The fourth well-known sin committed by development teams is the lack of **proper code review**. We accept the code that’s good enough. But in many cases good enough isn’t so good in the last place. Later on, we can’t focus and lose the bigger picture. For example, we concentrate on typos in comments instead of critical code failures and risky code structures.

The code review process is the most important point of your software production. With good code review you will:

- mentor junior developers how to code better,

- give feedback to experienced developers,

- show a better approach (if it is possible) and plan future refactoring if the deadline is tight.


Increase in the quality of software 

![ ](\uploads\eight_useful_advices_on_how_to_deal_with_technological_debt_372btLkvd3nXpq8jGV0TW2.jpg)
### 5. Procrastination
The fifth issue is the sight of surprise on the developer's face when he finds a technical debt that wasn't addressed before. All the time, each developer **should be on a technical debt hunt!** When you open a class after a while, and you see the mistakes, don’t procrastinate, address the problem, create a ticket and plan it. Refactor! Fulfill your duty to the project.

### 6. Losing the debt awareness
The sixth problem: losing track of your debt, each commit, each version you and your team released.  All the team members knew that some shortcuts were made. But they didn’t know how far the debt was forced into the project.  **There is a point of no return and believing it's still far away is irresponsible.**  Your team needs to act now!   Audit the project with a static analysis tool. Establish the desired level of debt in your project. Make a plan to refactor most debt-heavy classes. Introduce in your Continuous Integration a step that will run the static analysis tool, and bring you a detailed report for each commit. That will give the team situational awareness about the debt introduced or the debt reduced with this change. Furthermore, it can make the code review easier, because it can integrate nicely with GitHub or GitLab merge requests.

### 7. Skipping Unit testing… again
The Seventh Sin - Unit tests. Yes, we are all **guilty of skipping the unit tests!** It’s hard to write them when the time is crucial. Skipping these tests is risky in all situations. But when you plan a refactor and the features aren’t covered with tests, it can be a suicidal mission for the team, managers, and the dagger for the project.   You need to have the source of truth that will determine if the feature you just refactored is working as intended. Before refactoring, do yourself a favor and test the feature you're gonna work with. 

### 8. Refactoring the trouble-making solutions
The Eighth, final, and most important problem - in my op

inion - is **building a team awareness** that with any chosen approach we will always introduce some amount of technical debt into our project, simply because of a need of meeting business needs and given deadlines. But, having this in mind, we also need to be aware of the fact that in the next iteration we're gonna deal with that debt by refactoring the trouble-making solutions.

### Summary
That awareness is a key to keeping the debt at bay. When you can address the problems you created, prioritize and plan tickets to refactor parts of code that have the heaviest impact on debt and project.

**Tips and tricks to avoid the technical debt**

Don’t deny the existence of the technical debt in your project. Raise awareness about it among your management. Define weak spots and prioritize tasks. Plan the refactor in your development cycle (time-box the refactor tasks). Write the tests to ensure that refactoring won’t damage anything fragile. Do the refactor itself. Track the progress of the refactor with a static analysis tool. And keep your team sane and they won’t be afraid to work with your well-maintained project.



small_Blog_artykul_Adrian_Lukasz_Grzegorz_prediction_cover_high-1.png

thumbnail_Blog_artykul_Adrian_Lukasz_Grzegorz_prediction_cover_high-1.png

Blog_artykul_Adrian_Lukasz_Grzegorz_prediction_cover_high-1.png

How to keep your team sane while dealing with technical debt?

Frontend Engineering

UX/UI Design

Research & Discovery

AI For Your Business

Services

Case Studies

Career

About us

Blog

There comes a point in nearly everyone’s career where they feel that it’s time to make a switch. At times, the feeling comes out of the blue - completely unprompted. On the other hand, you could spend years considering whether to change your specialization without making a move.  Today, you’ll get some insight from Tomasz, who switched from Java to become a senior Node.js developer when he joined our team at [Bitnoise](https://www.bitnoise.pl/)
. The jump seemed risky at first, but in the end, Tomasz settled in beautifully. Here’s what he learned.

#### Tomasz, what is your technical and educational background?
My technical and educational background are quite intertwined. While I always wanted to work with computers, my story didn’t really start until I attended the Poznań University of Technology. I graduated from there with a Master’s degree in Computer Science. During this time, I completed a successful stint as an analyst and research programmer at the university, which helped me grow a lot as a programmer.

Most of my studies focused on C#, which was the programming language preferred by the majority of universities at this time. That said, I also took a course that covered Java. From that point onward, my career centered around Java development.

#### How did your career as a software developer start?
By the time I graduated University, I knew I wanted to be a software architect. However, I was still pretty naive. I didn’t realize that before becoming a software architect, you must spend significant time in the trenches as a developer first.

I scoured the internet for architect job postings. There were a few, but none that I was qualified for. Meanwhile, I found dozens of good job offers for Java developers. I quickly realized that I had no choice but to work as a developer first. I thought to myself “why not?” as I accepted my first job working for PayU.

#### What were your first steps in commercial software projects?
I took my first steps during my university years. PayU was also pretty active in hiring junior developers at my university. I cut my teeth on my first commercial software projects there.   These projects weren’t simple. If you weren’t aware, PayU is a major online payment platform. Nowadays, Naspers Corporation owns it. As employees, our project managers held us to a high standard. And the company was extremely well organized, which I appreciated.

In my three years working for PayU, I evolved into a full-fledged developer. I credit the company and the people who worked there for much of my growth as a developer.

#### But you still worked with Java, how did you switch to Node.js?
While working at PayU, I became a little restless and decided it was time for a change. I had a friend who worked at a small local company, so I decided to take my talents there. One of the advantages of working at this company was that they gave me a lot of freedom. My natural curiosity prompted me to learn Node.js. This was a boon to my growth as a developer.

Coincidentally, one of my tasks at this company was to build an API gateway. We decided to use Node.js for this purpose because it was far simpler and quicker to implement than Java.

#### So, two major factors influenced the change: opportunity and willingness to experiment.
No doubt. It’s one thing for you to play around with new programming languages all day, but necessity is the mother of all invention. If one of your higher-ups at your job has the open-mindedness to try a new technology, the world is your oyster. You can begin taking on bigger and bigger challenges with new approaches each time.

I think it’s always fun to challenge yourself. However, not everyone dares to leave their comfort zone. In this case, their tech stack. You could spend years using the same language and never truly grow as a programmer. In this industry, it’s important to constantly try new things and take the opportunities that present themselves. That’s how you get an edge both at your current job and when you’re trying to find a new one. 

#### What were the next steps in your journey toward Node.js?
After working for this smaller company, I transferred to a software development company named Espeo. Once again, I was happy that my superiors at Espeo were technologically agnostic. When we worked on projects, we wanted to use the right tool for the job, rather than choosing the same one because we always used it.

I worked with Java, Python, PHP, and Node.js. Not to mention, I did a bit of work with blockchain technology as well. Given that Node.js has one of the most extensive Ethereum libraries around, it only reinforced my positive impression of it.

At this point, I had built up 7 years of programming experience working with a variety of programming languages. I would say that Java still dominated my work, but Node.js was probably second. If you asked me what kind of developer I was back then, I would have told you I was a Java developer for sure.

#### And then Bitnoise called you…
Indeed. The pitch got me pretty excited. Most companies have clients, but they don’t get to be nearly as hands-on with projects as Bitnoise is. Not to mention, I appreciate that Bitnoise prizes experienced senior-level employees. As a result, they offered me a role as a senior Node.js developer. I thought this was quite a coup, considering that Node.js wasn’t even the main technology I worked with.

One of my first projects at Bitnoise involved an HR Tech startup called JOIN. Working with such a fast-growing firm is incredible. The best part was, JOIN’s CTO is extremely open-minded too. As a result, he accommodated the fact that I’m not a Node.js specialist.

I’ve already been working with JOIN for three years, and I’m still as passionate about the project today as I was the day I started, if not more! Growing alongside Join and my colleagues at Bitnoise has been extremely rewarding. Watching a startup evolve into a major player is a bit like watching your nephew or niece grow up.

#### Let’s focus on the challenge of switching from Java to Node.js - although it seems frictionless in hindsight, were there any initial fears or challenges?
As I mentioned before, I was now designated as a senior developer in a programming language I didn’t specialize in. I certainly had reservations about starting from a lower level. It felt a bit like I was back at square one, I lost a lot of the confidence I built up during my 7 years in the industry. It forced me to work harder than I ever did before to prove myself.

Imagine moving from Manchester United to Real Madrid. You already know you’re a good player, but you still need to impress the new fans. In this case, I knew I was a good developer, but I still needed to impress my colleagues and our clients. This type of competitive mentality is rewarding; I learned lots of new things and emerged with newfound confidence. Switching to a new environment also changes your perspective.

#### What would you tell a fellow senior backend developer considering a switch?
A good developer understands that the programming language you use is merely a tool. As you gain experience, you realize that the same problem-solving skills underlie each language you use. Eventually, these tools become interchangeable. And you don’t need to worry that Node.js is a newer language. You can use it for the same purposes that you would for Java. I promise any developer that switching to Node.js won’t make you feel inadequate.

Of course, Java and Node.js are quite different. However, the difference is more comparable to playing for two different football teams than it is to the difference between playing football to basketball. Any developer worth their salt can make the switch if they put in the effort.

#### Besides the tech stack, what are some important reasons for a senior developer to move to a different project?
I’ve already covered the technology part, that’s really just about adding a new tool to your arsenal. I actually think that work culture is by far the most important determinant of a project’s success, so I look at that. Above all, I prefer working in a Test-Driven Development environment (TDD). Essentially, it means that we prioritize product quality above all else. We run lots of tests before we write the code.

There are other elements that some might consider superficial, but which I find quite relevant. For instance, you need to have a degree of flexibility in all approaches, not just with coding. We recently switched from Scrum to Kanban to organize our JOIN project because we felt it would improve our efficiency in the long run.

I’ll share one last bit of philosophy with you. I’m not someone who thinks that software development is an art. Rather, it’s a means to an end. That end should be twofold: to increase your business’s value and to provide your users with the best possible experience when they use your products.  That’s the great part about working with Bitnoise, we don’t try to glorify our tools. Rather, we aim to elevate our clients and the users that they support. I think it takes humility for a company to recognize what’s truly important.

#### Thank you, Tomasz, for sharing your experience with us!
You’re welcome. The pleasure is entirely mine!

#### Tech summary
During our interview with Tomasz, we discussed Java and Node.js at length. Let’s dive into some of the specifications of these two backend technologies. They’re both quite popular, but Java is quite a bit older. Java’s initial release was in 1995 while Node.js didn’t come out until 2009.

Node.js is part of the JavaScript stack; it’s a JavaScript runtime environment. Meanwhile, Java is a full-fledged programming language that aims to have few dependencies. You can use both languages to build sophisticated backends for web and mobile applications. That said, these languages have substantial differences that we’ll investigate further.  

**Java** 

Java is one of the first languages that come to mind for any programmer. It’s been established as one of the best technologies for developing applications and is considered a heavyweight by almost everyone in the industry.

Originally, developers used Java to create desktop applications. However, Java has gained popularity for many other purposes. Many large and complex applications like social media platforms tend to appreciate Java. Not to mention, banking applications, metaverse games, ERP solutions, and CRM applications use the language for their backend too. Spotify, Twitter, and Minecraft are all examples of popular apps that were written in Java.   

**Node.js** 

While we can consider Java to be one of the heavy hitters among programming languages, Node.js is a more lightweight tool. Ryan Dahl created Node.js in 2009 to serve the community’s need for a friendlier, lighter backend technology. The platform is based on JavaScript and is open-source; there are several free Node.js libraries that can help with your use case.

Of course, since Node.js is based on Javascript, it’s extremely easy for Javascript developers to learn this technology. As a result, many startups have opted to use Node.js over similar options since the learning curve is quite minimal in comparison to other languages.   

**Advantages of Java** 

There’s a reason why Java has been widely trusted by developers since 1995. It has a rigid structure that stands the test of time. Consequently, Java helps you build extremely stable applications. Any software you create with Java will be durable and you’ll easily minimize the risk of errors.

Another advantage to Java is that it’s a statically-typed language. Once again, this reduces the chance of errors since every variable, object, and so on is well-defined. To achieve this level of definition in Node.js, you would need to use TypeScript in tandem with it, since TypeScript requires you to define the type of variable each time that you set one.

**Advantages of Node.js** 

Even with Java’s reliability, Node.js possesses several important advantages of its own. The main one is speed of development - writing Java code is quite a bit slower than most native languages because it uses compilers.

Furthermore, Node.js employs an event loop mechanism that allows servers to respond to requests without blocking input and output operations. As a result, Node.js is extremely scalable, which makes it perfect for startups that need room to grow.

Of course, with all these advantages, many developers are eager to learn Node.js. Some, like Tomasz, have already learned the language at work. There are others that have spent years working with the technology already. Due to its popularity, it shouldn’t be hard to find a quality developer willing to make the switch to Node.js.  

#### The start-up’s dilemma - Java or Node.js?
When you first found your startup, you have some serious decisions to make. Your initial choice of technology could be the most important of them all. Choosing between Java and Node.js will have a major impact on the success of your application or SaaS. Choose wisely.

You can rest assured that you will have no problems developing a stable backend with either of these technologies. However, since Node.js is a lightweight technology and draws heavily from JavaScript, it’s far easier for most developers to train in or switch to Node.js than it is for them to switch to Java. After all, Java has a pretty high barrier to entry. There are a lot of technical details you need to learn which makes switching to Java a rather uncommon event.

As a result, recruiting Java developers becomes a bit of a pain. The difficulty of the language means that there is a deficit of Java developers available on the job market. We mentioned that quite a few largescale applications use Java. Guess who you’ll be competing against when recruiting Java developers? The likes of Spotify and Twitter will be in on the action, as will be large banks and insurance companies. For most startups, this is a rather intimidating proposition.

Based on our experience at Bitnoise, we encourage founders and CTOs to use Node.js for their backend. Node.js will help you get the job done just as well as Java in 99.9% of cases. And even if you’re already a Java developer, building a solid team of Java developers around you will be arduous and expensive.

As Tomasz proved, it’s not too challenging for a Java developer to switch to Node.js. Many are eager to make the jump. Given an enticing opportunity at your startup, you’ll have few problems attracting Node.js developers, even at the senior level.

![ ](\uploads\Blog_artykul_TomekC_Java2NodeJS_blog_02_4u5EhT3eltrHOSjoUwieyy.png)
#### Why switch to Node.js as a developer?  
- It’s relatively easy to switch if you already know other backend technologies  

- Node.js is growing in popularity and many startups use it as their primary technology

- It can achieve almost the same results as other languages

- Using Node.js helps see results faster than Java, among others


![ ](\uploads\Blog_artykul_TomekC_Java2NodeJS_blog_01_50tuNqSJuA9HWdB0ty5tsl.png)


small_Blog_artykul_TomekC_Java2NodeJS_cover_high.png

thumbnail_Blog_artykul_TomekC_Java2NodeJS_cover_high.png

Blog_artykul_TomekC_Java2NodeJS_cover_high.png

Switching from Java to Node.js as a senior developer - Tomasz’s story

During my career, I worked with many React.js teams and was involved in some way in dozens of projects. Over the years I feel I witnessed enough to say with a degree of certainty what is needed to build a well-functioning, technically precise, and efficient team.

Unsurprisingly, we follow many of those principles and practices at Bitnoise. While you can freely adapt some of them, a few come from past projects and attitudes which is difficult to emulate.

In any case, I hope the below summary will be an inspiration.

So what makes React.js teams truly special?

#### Experience
At Bitnoise, We’ve been part of the React.js journey since its beginning. When it was released in 2013, we already had years of experience in software development. Before the advent of this library, we worked with various technologies where we struggled trying to achieve user-friendly and efficient applications. However, we’re always looking for new technologies to help expedite our work and provide top-notch solutions using the best possible tools.

Over the past decade or so, we’ve watched React.js grow and evolve. Unfortunately, it has become bloated with multiple offshoot libraries making it rather clumsy to use. Consequently, a few challenger frameworks have emerged, including Vue.js.

Lately, we’ve been contented to see that React.js has become leaner, more efficient, and developer-friendly. We can thank the community and amazing frameworks such as Next.js and Remix.js for helping facilitate this change.

As for our role, it’s safe to say that after delivering dozens of software projects, building multiple frontend and full-stack teams, and speaking to hundreds of developers over the past decade, we know React.js inside-out. This technology bears few surprises to us.

Without this experience, we would not be able to build such good teams, and I doubt others would.

![ ](\uploads\Blog_artykul_PiotrB_React.js_blog01_1l87xFkyuQoNZiiA1pNBe0.jpg)
#### True engineering on the frontend
Typically, you might reserve the term “software engineer” for backend developers. And yet, this term fits front-end developers perfectly. It is not about the part of the application they work on or the technology they specialize in. Things like a degree in Computer Science or some other STEM subject are a great background for a great frontend engineer.

That’s why we tend to hire React.js developers with solid, relevant academic backgrounds. Furthermore, we have several backend and full-stack developers on our [team](https://www.bitnoise.pl/team)
. Node.js, Python, .NET, and PHP are just a few of the tools these developers work with. Whenever we work on a front-end project, our developers are always ready for consultation or ad-hoc work.

#### Pixel-perfect mentality
Being capable of expressing every imaginable design through code should be within reach of any good frontend team. To transform [clients](https://www.bitnoise.pl/clients)
’ blueprints into a reality, expert UX/UI designers should work hand in hand with developers. As a client, you can work with these designers one-on-one as they service your project. Otherwise, they should be available for consultations if you provide us with designs from an external agency.

In our case, part of our commitment to perfection comes in the form of our use of state-of-the-art tools for design and collaboration.

- **Figma** is a powerful cloud-based design collaboration tool. As such, it allows designers, product managers, owners, and developers to communicate and collaborate simultaneously. 

- **Storybook** is a workshop where developers can build frontend components and pages individually. This is useful because it enables us to demonstrate and check the component pieces of an application without needing to have the entire view or page ready at once. 

- **QA engineers** test all of the apps we build. At the bare minimum, we run our products through automated testing to ensure that the UX is excellent from day one. 


![ ](\uploads\Blog_artykul_PiotrB_React.js_blog02_1H7vOvuCMd7jNlJjqcps8H.jpg)
#### Bitbucket, Eslint, Next.js and Remix to complement React.js
Cutting edge projects usually take advantage of modern tools to complement React.js and streamline frontend work. As a result, high-quality software is created faster. Here are a few of the tools you might use:

- **Bitbucket/Vercel/Fly.io** for Continuous Development and Continuous Delivery (CI/CD). This toolkit helps us avoid long builds and unnecessarily complex configuration work. I.e., it relieves us of the typical mess and stress that comes with tedious development and QA processes. Furthermore, we like this combo because it provides collaboration tools alongside instant previews – thus leading to rapid iteration.  

- **Eslint/Prettier** for code quality. Linting tools analyze our code and look for errors within it. Since React.js does not have built-in compilers to check the validity and quality of our code, Eslint and Prettier are essential to our development process.   

- **Next.js** and **Remix** for a fast, slick UI. Using these two frameworks, we can optimize interactions even with the most intricate designs. They also help improve the developer experience while we’re coding thus making our jobs easier.  

- **React-Query, Redux-Toolkit, and styled-components** as libraries of our choice.


#### TypeScript
By using TypeScript on top of raw JavaScript, code becomes a lot more consistent. Of course, JavaScript is a scripted language, however, it does not use compilers. Therefore, it’s easy for developers to make errors while coding with it. TypeScript fixes this and makes code more maintainable in the process. Plus, it keeps code up to date with browsers as they change their standards.

Here are some of the many concrete benefits of using TypesScript:

- Increasing team performance

- Easier code management

- Early spotted bugs Increasing code readability

- Easily readable and understandable components


#### SEO mindset
Regrettably, raw React causes some issues with search engine optimization. Sometimes, search engine algorithms will shun pages built on React - especially if they’re a single-page application. We resolve this problem with Next.js. Since Next.js permits rendering React applications server-side, the SEO issue vanishes.

#### Community and knowledge sharing
Best teams are not the ones who become isolated from the rest of the world. Learning, teaching, talking to others, inspiring them, and helping others in the software community brings in a lot of new energy and motivation to developers.

In our case - the commitment to education is everlasting. We’re constantly investing in professional development and growth at every level. Here are some examples of our philosophy in action that may help your teams grow too:

- **Internal training**, which is directed and delivered by our senior developers or an external specialist.

- **Bitnoise Meet** is a learning initiative we began to encourage education and research in our field. In doing so, we invite professionals from other companies to learn alongside us.

- **PozTechTalks** is a series of podcasts and videocasts that we coordinate with other local software companies in Poznań. During these sessions, we discuss advanced computing concepts and challenge each other on our perspectives.

- **Land on Moon** is a meetup initiative where CEOs, founders, and product owners share their inside stories from the software development industry.




Blog_artykul_PiotrB_React.js_blog03.jpg

Blog_artykul_PiotrB_React.js_blog04.jpg

Blog_artykul_PiotrB_React.js_blog05.jpg

Bitnoise_events

I hope those hints will help your team become better and happier. If you’d like to work with me or my colleagues check out some of the services we offer and do not hesitate to reach out to us.

- [React.js teams](https://www.bitnoise.pl/services/remote-react-js-teams-next-js-typescript)
 

- [CTO as a Service](https://www.bitnoise.pl/services/cto-as-a-service)
 

- [Process consulting](https://www.bitnoise.pl/services/software-development-process-consulting)





small_Blog_artykul_PiotrB_React.js_blog_cover_high.png

thumbnail_Blog_artykul_PiotrB_React.js_blog_cover_high.png

Blog_artykul_PiotrB_React.js_blog_cover_high.png

What do best React.js teams have in common?

Adam Misiorny is a Frontend Engineer and Tech Lead at Bitnoise. Since Adam is one of the most experienced software developers on our team, we thought he would be the perfect person to offer insight into how our different developers cooperate during their work.

#### You are a leader, but what exactly is your role in your current project?
At the moment, I’m a Frontend Principal Engineer in a long-term project with JOIN. This means I have the most detailed knowledge of the project and the associated systems. As a result, I’m the one who makes decisions regarding development directions and front-end architecture. It’s a big responsibility. Sometimes, I work on developing the platform itself, but mostly, I’m in a leadership role.

From the perspective of the front-end developers working alongside me, my task is to accelerate product development and render it as efficient as possible. Since I am tasked with ensuring efficiency, I also get in the trenches and help solve complex problems should the situation require it. I’m always of use to other developers.

#### As a Frontend Principal Engineer, do you take part in onboarding new developers at Bitnoise?
Indeed, I often introduce new developers to the project. I take an active role so that each developer can get started working on our products quickly and eliminate onboarding uptake time.

Part of this onboarding task is to acquaint developers with our application architecture and coding standards. This helps light the path forward for quality work to get done. Under my watch, developers familiarize themselves with the common processes we use with each project. These range from pull requests to production deployment.

#### And how do you work with new developers in the project?
I assign each of my junior and middle-tier developers a senior “coding buddy” who assists them with their daily tasks if necessary. As the Principal, I supervise the developers at the review stage with an emphasis on the initial stages to ensure that we set the right tone. Should any of my developers have an inquiry, I am quick to answer them and assuage their doubts.

My role as a consultant is one of the most critical parts of my job. I need to give every developer context as to why we approach each problem a certain way. Less experienced developers soon absorb our general programming ethos at Bitnoise as a result. Understanding is the key to growth.

![ ](\uploads\Blog_artykul_Adam_React.js_02_BZ72URItqw8KOX2g07eZS.jpg)
#### What surprises you about working with less experienced developers? What attitude do you expect from juniors and mids?
While I am usually busy shepherding young developers, it’s not uncommon for me to learn a thing or two from them myself. My experience is a major asset, but that can sometimes mean that my programming approach is rather fixed. I benefit quite a bit when I receive fresh perspectives from young computer science graduates. Our work is enriched when I can look at an issue from a different angle.

Above all, I prize developers who have a passion for learning. Anyone who hungers for knowledge can be taught anything, making them more adaptable as programmers. It’s no use trying to force-feed solutions to a disinterested developer. You can lead a horse to water, but you can’t make it drink.

#### What keeps you in Bitnoise for so many years? If I'm not mistaken, this year we'll be celebrating your 10th anniversary at Bitnoise!
It’s a fantastic atmosphere. Isn’t it? After 9 years of working here, I still haven’t tired of my role. And I’ve grown along with it. Even as Bitnoise has evolved and grown, the team spirit has never changed.

When I was a young programmer, I worked on several projects with diverse topics. Consequently, my breadth of programming knowledge skyrocketed, and today I am happy to say that I have experience that ranges the entire spectrum of software development.  Once Bitnoise assigned me as the leader of a long-term project, I appreciated the new stability. It felt as though I had been preparing for years for this role given my work in so many different fields. After 4 years of working with JOIN, I still haven’t grown bored of the project – it keeps me on my toes as I learn new ways to solve the problems we encounter.

If you’re looking to work for a stable company where you can grow your programming skills, I highly recommend working at Bitnoise. The atmosphere is, as I said, top-notch. Personal development is a priority for all of us.



small_Blog_artykul_Adam_React.js_cover_high.png

thumbnail_Blog_artykul_Adam_React.js_cover_high.png

Blog_artykul_Adam_React.js_cover_high.png

How do mid and senior React.js developers cooperate at Bitnoise?

Tech companies, including Bitnoise, thrive on the success of their clients. When starting a new project or enhancing existing ones, our focus should always be to deliver high-quality services within a reasonable time frame, especially in React.js-driven projects. 

At our company, we have a strong commitment to our clients and prefer to establish long-term relationships with them. Hence, setting a high standard for product quality and ensuring that we meet these standards by implementing our philosophy throughout the organization is a must. Communication, accountability, and timely delivery are all integral to customer experience. We believe that by following these standards, is a path of consistently delivering the best possible work to our clients. 

Here are the 8 pillars of quality in further detail.

#### **1. Excellence Over Quantity**
While growth is an crucial aspect of any tech endeavor, it is important to understand that business goals should never supersede our commitment to quality. This commitment allowed companies like Biitnoise to develop a sparkling reputation in the first place. As a result, there is a need to be extremely careful during the hiring process so that it ends with bringing in **the best talent**. We should not be blinded by our desire for growth and take on projects our team can’t handle. In Bitnoise, most candidates we interview do not meet the caliber we expect in our organization. Thus, we turn them away.

Furthermore, it is important that developers work with confidence knowing that they have support systems behind them. The assistance of CTO and head of technology during the development process ensure that they receive support or guidance where needed. Realistically, no developer is infallible.

In Bitnoise, collectively, our team has a deep pool of knowledge. Our developers are always welcome to consult with one another when they need advice on how to solve a problem.

#### **2. Responsibility**
When working with clients, the **full ownership** of the product in development is a highly desirable feature. This is not so common in our industry, but it goes to show you just how committed the tech company is to delivering quality work for clients.

In Bitnoise we want to be there both for the scaling and the building of the software to watch the company evolve. Several of our clients have worked with us for over a decade. We're in it for the long run.

The secret is, instead of outsourcing developers, we focus on developing an internal culture of accountability. As a result, we partner with companies worldwide to service their technology needs.

#### **3. Working Globally, Coding Locally**
Many prominent tech companies have clients sprinkled throughout some of the world’s top global innovation hubs, ranging from Berlin to London to Silicon Valley, but still they prefer to work as a team at home.

In Bitnoise, we are located entirely in Poland. Most of the time, we all work at our office in Poznan even though we have the option of working from home.

The main advantage of this kind of setup is that since **we’re located within the EU**, we can all benefit from their legal framework, and our clients can expect stability when they work with us.

#### **4. Stable Teams With Low Turnover**
The software industry can be extremely chaotic, and its job market is always competitive. To build a stable team, you must have an attractive offer and a positive work environment that incentivizes everyone to stay on board.

![ ](\uploads\blog-Quality2_28l1PL2QiWf1AAmOJrGjkO.jpg)
By managing our employees sensibly without being overbearing, we’re able to win their respect. A good idea is to foster a **culture of independence** in organization and endeavor to exercise common sense in all situations.

As a consequence, the team can develop a level of stability that might make some of the competition jealous. 

In Bitnoise few of our engineers have worked with us for 8 years or more, and it is all thanks to an internal culture of independence, knowledge development and trust.

#### **5. A Holistic Approach**
In pursuit of quality a specialization is a very important feature, but it can not overshadow other technologies. For example in Bitnoisie we are a **React.js-driven company**, and you might assume that we only build frontends. But it is not the whole picture. We’re extremely competent with back-end technologies including Node.js, Python, and PHP. A large portion of our engineers are specialists in specific areas of technology. However, we also employ full-stack developers who can work on a project from start to finish. 

Some of our core competencies include UX/UI, quality assurance, and project management. So you know we’re a team that can excel at any aspect of app development.

#### **6. Seniority And Maturity** 
It's impossible to run a software development company without employing and training junior developers but what makes a difference is seniority. For our part, we emphasize **seniority** as much as we can. The majority of our developers at Bitnoise have over 7 years of industry experience. In some cases, they have worked with multiple tech stacks. Moreover, our developers usually have an educational background in Computer Science or a STEM field. 

As a result of their experience and education, our clients reap the benefits in the form of Quality Audits, Consulting and Strategy services, and CTO as a service. This variety is unique among software development companies. 

#### **7. Transparency**
Clients in many cases place their faith in companies whose fee structure is clear and simple. In Bitnoise we charge hourly or daily fees and validate our work on the invoice with corresponding timesheets. We don’t charge any upfront fees, recruitment costs, or any other cost that might arise during our work. In the case of a fixed-price project, we agree on a maximum fee from the beginning of the project so there won't be any unpleasant surprises down the road. Rest assured that you will get what you pay for. 

Even though we involve project managers in our work, our clients still have **direct contact with our developers** and often collaborate with them. There won’t be any middleman mediating your communication. Moreover, our entire management team is approachable in case you have any inquiries. Feel free to reach out to us.

#### **8. Fostering A Community**
To encourage growth and education in our industry, we made it our mission to build a thriving community of software developers. In doing so, we’ve founded or participated in several software initiatives such as: 

[**Land On Moon**](https://www.landonmoon.co/)
 – a series of Berlin meetups for founders, CEOs, and product managers to discuss their experiences with one another and inspire startup leaders and other businesses that are attempting to scale. 

[**PozTechTalks**](https://www.youtube.com/watch?v=zZB5qCQg9go&list=PL7zHBa_5KmnLSaEp4qQLNPCmm1SuUpEsl&ab_channel=Bitnoise)
 – an educational initiative where leading software companies based in Poznan promote engineering and development quality. 

[**ITCorner**](https://itcorner.org.pl/)
 – Poland’s most prominent software development business association made up of like-minded IT companies. 

[**Bitnoise Meet**](https://www.youtube.com/watch?v=AfCA-2nzN4A&list=PL7zHBa_5KmnJxiilc9bvKt48J3wHxsNw3&ab_channel=Bitnoise)
 – in which our in-house developers meet together to train and enhance their programming skills.

**These are the 8 pillars of quality in software development:** 

1. Excellence Over Quantity 

2. Responsibility 

3. Working Globally, Coding Locally 

4. Stable Teams With Low Turnover 

5. A Holistic Approach 

6. Seniority And Maturity 

7. Transparency 

8. Fostering A Community 


Of course, there is more to this topic, and we eagerly look forward to discussing it with you if you have any questions or suggestions. Reach out to us at hi@bitnoise.pl, and let's have a talk.

small_blog-8pillarsOfQuality_cover_cover_high.png

thumbnail_blog-8pillarsOfQuality_cover_cover_high.png

blog-8pillarsOfQuality_cover_cover_high.png

The 8 pillars of quality of a React.js project

When I talk to CTOs, I often recommend React.js, which might come across as biased since I work for a company that uses it on a daily basis. However, I made a conscious decision to work in an environment that emphasizes React.js and have been actively encouraging its further adoption within the company. I firmly believe in technology and wouldn't work in an environment that doesn't align with my beliefs, which are outlined below.  React.js is undoubtedly the most widespread, popular, and sought-after frontend technology within the software development community. This alone should be reason enough to make it your go-to framework for frontend development. However, let's delve deeper and explore other reasons supporting this assertion.

#### **Why choosing the right frontend framework matters**
When embarking on a new project or updating an existing application, one of the most crucial decisions to make is the choice of frontend technology. This decision is critical because it has long-term implications for your product and work. In my experience, I have seen several products struggle because of poor past technology choices. Selecting the appropriate frontend technology is a daunting task since it affects not only what the technology does and how it functions but also who can operate with it and what other tools can enhance and augment it.

#### **The pragmatic case for React.js**
The React.js community is massive and its popularity is evident from various statistics. For instance, a search on LinkedIn reveals that over one million people worldwide have mentioned React.js in their profile, indicating some level of experience or interest in the technology. This is significantly more than any other frontend framework.  

The widespread popularity of React.js has two important implications. Firstly, it is relatively easier to find developers with React.js experience than with expertise in any other framework. Secondly, due to the high demand for React.js talent, there is significant competition among employers to hire them.  

At first glance, it may seem like these two facts offset each other when it comes to hiring. Although there are more candidates, there are also more job openings, which should balance the job market. However, the concept of liquidity comes into play, much like in the stock market or altcoin market. The more developers with specific skills that are available, the more likely they are to seek out new opportunities, making it easier to hire.  When considering the long-term perspective, the size and liquidity of the React.js community play a crucial role for both you and your HR team.

![ ](\uploads\Blog_artykul_Grzegorz_React.js_blog_01_1pVcCpqFPKCNby6LpN9XI1.png)
#### **Net talent flows to frameworks**
It's important to remember that today's statistics may not reflect tomorrow's. It's also essential to consider the dynamic nature of people changing their expectations and enhancing their skills. One significant realization I've had over the past few years is that no one wants to switch from React.js or Vue.js to Angular. However, switching in the opposite direction is relatively common.  

For example, a skilled Angular developer with a good understanding of project work, methodologies, and business needs may decide to make a career move and explore a new framework. They could take a React.js course, work on some TypeScript projects in their free time, and be ready for a new challenge in a React.js team within a few months.  

This scenario almost never occurs in the opposite direction. As a result, if you start a project in Angular today, you are more likely to lose your developers to React projects than vice versa.

#### **Avoiding hypes**
Every once in a while, we witness a hype around a particular technology. I remember the sudden rise of Vue.js around 5 years ago. Many developers were attracted to it, mainly because of its ease of use. I talked to several Angular developers and backend engineers who were interested in trying it out. CTOs also wanted to experiment and started their projects in Vue.js. It was an exciting time with good energy, and it was an opportunity for junior developers to become proficient in a particular framework quickly.  

However, as of early 2023, the hype has largely dissipated. Although the technology is still in use, being developed and improved, it hasn't caught up with React.js by any means. I can see some companies now stuck with Vue.js. Although it is easy to use and gets the job done, the talent pool for Vue.js projects is relatively limited.  

(It's also important to note that Vue.js is not very scalable. If your app is likely to grow, you may find it cumbersome to use this framework.)

#### **The case for mobile apps**
If you plan to turn your web app into a mobile app, React is an ideal option. You can use your existing React team to build a cross-platform app in React Native. This approach saves you from having to allocate additional resources and performing the same work twice for iOS and Android. It also maintains the cohesion of your team and makes it easier for developers to switch contexts, ultimately reducing the costs of maintenance.  

In my opinion, an experienced React.js web developer can build a mobile app relatively quickly, even if they lack prior mobile development experience.

#### **Summary**
Choosing the right frontend technology is critical for any project's success, and I recommend React.js due to its widespread popularity, large community, and ease of finding talent. The size and liquidity of the React.js community play a crucial role in both hiring and long-term maintenance. While hyped technologies may be attractive, it is essential to consider their scalability and talent pool before choosing them. React.js is also an ideal option for developing mobile apps, as an existing React team can easily build a cross-platform app in React Native, reducing costs and increasing team cohesion.




small_Blog_artykul_Grzegorz_React.js_blog_cover_high.png

thumbnail_Blog_artykul_Grzegorz_React.js_blog_cover_high.png

Blog_artykul_Grzegorz_React.js_blog_cover_high.png

Why do I recommend React.js as a frontend technology to CTOs?

There are many ways to avoid the trap of being "just another generic software development company." For me, it is specialization, the value proposition that comes with it, and organizational culture. 

Why is it important not to be "just another generic software development company," you may ask? For us, it is crucial because **we like working with interesting brands, and our developers love coding in tech-challenging and satisfying projects.** We don't want to compete only with time and money because that is a dead end for any tech company. But what exactly is specialization and organizational culture for a company that mostly works on JS-driven projects and has a team of 50 tech-savvy programmers? Let's break it down.

#### **Specialization and the value proposition**
The main problem with genericity comes from the fact that many of us don't think and plan ahead when starting a company. We tend to have a vague concept of what we want to achieve with our business in ten years, relying on the technology that our CTO or tech lead knows best and a handful of recommended clients. This approach lacks experience, vision, and a positive attitude, leading to daily struggles. It can even consume the best entrepreneurs and undermine their motivation to work on their own unique value proposition. 

At Bitnoise, we have adopted a "**doing things a little different**" approach, **with a strong vision and values, and specialization**. It may be easy to say, but the real challenge begins when you start implementing specialization in your company. For us, it took some time, but we eventually discovered that our holy grail is JavaScript - specifically **React**, **React Native**, and **NodeJS**. This does not mean that we have no knowledge of other technologies, but we consciously focus on JS and direct our messages to customers who require such services. 

It took years of work and deep experience to be able to say that we are specialists in this area, not only in our marketing communication but also in practice. To prove it, we have taken part in hundreds of large and small projects, run internal workshops, and participated in industry events over our 14 years of existence, and it has paid off. 

#### **Culture - take it seriously and you will see the difference**
In our case, it means always cooperating with people with matching characters, temperaments, and values. This does not mean "the same" people, **but if the teams work on the same page technologically and socially, you have a win.** For us, the most important thing that makes our team well-connected and cooperation easier is acceptance of differences to a reasonable extent. We have people on the teams with extremely opposite worldviews, but we have never had conflicts at this level. Why? 

One of our ideas is to create a space for casual discussion, an internal platform like Hyde Park, and we actually call it Hate Park (the rest is confidential). From my point of view, another important thing is to be "**a present manager**," not "the owner of a high castle." We have a custom of open doors. Any of the company's leaders, as well as a person who has just joined the organization, can at any time have a talk with me and the company CTO. The same thing applies to business partners; devoting time to them makes it much easier to deliver the value proposition we've promised. 

![ ](\uploads\blog-post_adrian_bitnoise_post_02_5mG9Sq5Y3QB3ptliYbzKgq.jpg)
#### **Specialization out of expertise and experience**
Face it, running away from generality into specialization is a challenge and takes a lot of work, not only in the marketing of your company but also on the level of your teams. Basically, **you need the best people, and they need to constantly develop their skills**. It is time and money-consuming, but in the end, it pays off. At Bitnoise, we have come up with [Bitnoise_meet](https://www.bitnoise.pl/blog/tags/meetup)
, where more experienced Bitnoise members can share their experiences with those with less skill in a given field. 

We provide training not only on technical topics - we have mastermind workshops, public speaking, or event storming workshops behind us, and mini-conferences **-** [Land on Moon](https://www.landonmoon.co/)
 **- organized in Berlin**, **where we encourage local communities of scale-ups and start-ups to share their knowledge** and acquire new skills. What impact does this have on our clients' business? It's simple: it translates into a committed team that not only completes tasks and builds high-quality products but also looks after each other and works effectively as a unit. 

#### **Summary**
Both tech socialization and culture are not a silver bullet, but they work well for me and Bitnoise. There is more to add, among others, a niche industry, extraordinary partnership, and many others. For us, what works is to have a mature, independent, and high level of seniority teams and a strong **React.js** core on the side of competency and in the clients' portfolio. It allows us to go outside the simple software development process, and if we see areas around the business in which we can support the client - whether in technical terms or in terms of processes - we help to make the right decisions or refer to one of our many partners who, in a given area, can help (being part of the community is something I'll discuss in the future).

Finally, what I think is worth mentioning - as owners and managers of Bitnoise, **we are always available to developers and customers to help dispel any doubts or problems that may arise.** On time and as efficiently as possible, because when our clients' business works well, it means that we do our job well. It is an important consequence of being a "present manager," which I mentioned previously. My final take on the whole genericity problem, if you want to overcome it: 

- Make an in-depth analysis of what is the strongest value of your company;

- Research how and what problems of your clients it answers;

- Specialize in technology; 

- And last but not least, build strong, independent, and experienced teams (and support them). 


Of course, it takes time and resources, but it is worth it. Do you agree? Or maybe I should talk more on some specific point? Give me a heads up, and let's talk.

small_blog-post_adrian_bitnoise_cover_high.png

thumbnail_blog-post_adrian_bitnoise_cover_high.png

blog-post_adrian_bitnoise_cover_high.png

Why we are not just another generic software development company

Prettier is like your very experienced colleague who constantly whispers advice about your code consistency and readability. Who wouldn’t want one? 


Unfortunately, very experienced developers are often busy, and that’s why [Prettier](https://prettier.io/)
 was created. In essence, it’s a tool that helps developers implement best coding practices automatically. 

Here is a concise **Prettier guide** including key benefits, **React** and **Typescript** code examples, and comments from our developers. 

#### **Key benefits**
- **Opinionated Formatting:** Prettier has a set of default formatting rules based on community best practices, making it easy to format your code without spending time on style debates. 

- **Multiple Language Support:** Prettier supports various programming languages such as JavaScript, TypeScript, CSS, HTML, and more. 

- **Customizable Rules:** Prettier allows you to customize the formatting rules to fit your project's specific needs, giving you more control over your code formatting. 

- **Easy Integration:** Prettier can be integrated into your development workflow with ease, enabling you to automate your code formatting and improve your productivity. 

- **Improved Readability:** By formatting your code consistently and following best practices, Prettier can make your code more readable and easier to understand. 

- **Reduced Maintenance Time:** Prettier can save you time on code maintenance, as it can automatically format your code as you write it, reducing the need for manual formatting.

- **Reduced Human Error:** By automating the code formatting process, Prettier can reduce the chance of human error and ensure that your code is always formatted correctly.


![ ](\uploads\blog-prettier_Lukasz_post_cytat_01-1_3tfodtSBNooCMUZATR9yqN.jpg)
#### **How does Prettier work?**
Prettier parses your code into an abstract syntax tree (AST) using a parser specific to the programming language you are using. 

1. Applies a set of formatting rules to the AST, modifying it to conform to the formatting rules. These rules are based on community best practices and are designed to ensure consistency and readability in your code. 

2. Generates formatted code based on the modified AST, producing a new code file that conforms to the formatting rules. 


Prettier also provides options to customize the formatting rules, allowing you to tailor the formatting to your project's specific needs. Once configured, you can integrate Prettier into your development workflow using various tools such as code editors or build scripts. This way, **you can automate your code** formatting and maintain a consistent code style across your team.

#### **How to install Prettier?**
To configure Prettier, you can create a configuration file in your project's root directory. Here is the step-by-step guide:

1. **Install Prettier:** You can install Prettier either globally or locally to your project using a package manager like npm or yarn. For example, to install Prettier globally, you can run the following command in your terminal:


``npm install -g prettier``

2. Create a configuration file: Create a ``.prettierrc`` or ``prettier.config.js`` file in your project's root directory.

3. Specify formatting rules: In your configuration file, you can specify the formatting rules you want Prettier to apply. You can find a list of available options in the Prettier documentation. Here's an example ``.prettierrc`` file that sets the maximum line length to 80 characters and uses single quotes for string literals:

![ ](\uploads\blog-prettier_Lukasz_post_cytat_01_C7f9YCZX42n8FbuHij8i2.jpg)
#### **How does Prettier work with JavaScript and Typescript?**
Here are some examples of how Prettier works with JavaScript and TypeScript:

1. Formatting JSX  

Before:




3. Formatting TypeScript in a Functional Component

Before:



#### **What are alternative and complementary tools?**
1. [ESLint](https://eslint.org/)
: ESLint is a popular static analysis tool for identifying problematic patterns found in JavaScript code. It has built-in rules and plugins for code formatting and styling.


2. [JSHint](https://jshint.com/)
: JSHint is a community-driven tool that helps detect errors and potential problems in JavaScript code. It has built-in options for enforcing code style and formatting.


3. [StandardJS](https://standardjs.com/)
: StandardJS is a style guide and linter for JavaScript code. It has a built-in code formatter and can be integrated into various editors and IDEs.


4. [Beautify](https://marketplace.visualstudio.com/items?itemName=HookyQR.beautify)
: Beautify is a code formatter that can be used with various programming languages, including JavaScript. It has plugins for popular editors and IDEs like VS Code, Atom, and Sublime Text.


5. [CodeMirror](https://codemirror.net/)
: CodeMirror is a versatile text editor for the web that can be used for formatting and styling code. It has built-in features for code highlighting, indentation, and autocomplete.


6. [JS Beautifier](https://beautifier.io/)
: JS Beautifier is a simple tool that can be used for formatting and beautifying JavaScript code. It has options for configuring the code style and formatting rules.


7. [Black:](https://github.com/psf/black)
 Black is a Python-based code formatter that can be used for formatting code in various programming languages, including JavaScript. It has options for configuring the code style and formatting rules.


#### **Summary**
Prettier is a code formatting tool that automatically implements best coding practices, and improves code consistency, and readability. 

It has default formatting rules based on community best practices, supports multiple programming languages, is customizable, and can be easily integrated into a development workflow. Prettier works by parsing code into an AST, applying formatting rules, and generating new formatted code. Developers can install Prettier by creating a configuration file with specified formatting rules. Prettier works - among others - JavaScript and TypeScript. 

I encourage you to try out Prettier and other similar tools. 

If you have any questions or are interested in our services, do not hesitate to reach out to us.

small_blog-prettier_Lukasz_cover_high.png

thumbnail_blog-prettier_Lukasz_cover_high.png

blog-prettier_Lukasz_cover_high.png

How to make your code better with Prettier?

How to keep your team sane while dealing with technical debt?

Max

Switching from Java to Node.js as a senior developer - Tomasz’s story

Tomasz

What do best React.js teams have in common?

Piotr

How do mid and senior React.js developers cooperate at Bitnoise?

Adam

The 8 pillars of quality of a React.js project

Adrian

Why do I recommend React.js as a frontend technology to CTOs?

Grzegorz

Why we are not just another generic software development company

Adrian

How to make your code better with Prettier?

Łukasz

GET IN TOUCH