small_avatar_AdrianR3.png

thumbnail_avatar_AdrianR3.png

avatar_AdrianR3.png

Adrian

GET IN TOUCH

Being a Product Owner (PO) is a challenge that requires managing many aspects of the project, from understanding user needs to working with the development team. Especially in the MVP phases, it is worth balancing between what is necessary and what is unnecessary. However, there are essential tools that cost nothing, can improve the quality of your work, and make it much easier at the same time. In this article, we will look at several of the most critical tools, such as Jira, Miro and Chat GPT and how they helped me build digital products for German students and teachers.

#### Jira - Backlog and Task Board Management

Holly Jira, but I won't hide it - I like this tool. Maybe I'm old-fashioned, but I enjoy collaborating with teams in this particular tool. In the beginning, when building an MVP, the free version was completely sufficient for me! Why?

**Because I could flexibly manage the development plan (so-called timeline).**
Jira's timeline uses the epic level to build a delivery plan. At first, I managed to create just a few epics (including login/registration epics, building the basic architecture, etc.). Still, as development work progressed, I learned more and more and eventually built a 4-month development plan (for both applications - teacher and student). This was great because I made sure that the most important screens and functionalities for both end-users would be delivered, tested, and working. What's more, the timeline function revealed to me the fact that it's worth starting development work by building an architecture and backend to get ahead of the frontend a bit - thanks to this, we built interfaces based on a working system and endpoints.

**Because I could manage the backlog at the level of tasks and functions**
For me, the backlog is a sacred tool for every Product Owner. Properly organised, it supports the team, and introduces transparency and order instead of chaos. How did we organise it within the project?
- Backlog as a list - and looking at it from above - there were tasks with the most significant degree of detail, which were refactored and ready for development. At the bottom of the backlog were tasks at an early stage of their preparation.
- project scope in form of ticket types
as the development team progressed, the backlog was supplemented with backend tickets, stories, bugs or extra change requests from the CEO, CTO and other stakeholders.
- impact analysis - every time a new scope (sometimes more or less needed) was reported to the team - we tried to analyse its impact on the timeline and current priorities in the backlog. 

Keeping the nice and clean backlog is not easy, but it is necessary if the Product Owner expects the development team to operate efficiently at the delivery stage.
![blog-grafika 1_poprawiona (1).jpg](https://bitnoise-cms.btn.fyi/uploads/blog_grafika_1_poprawiona_1_b9f060cf50.jpg)



**Because I could order delivery on the Kanban board**

For me, the Kanban board is a must and a standard tool for tracking tasks and communicating with the team. A good task board reflects the team's current work and helps rather than hinders. Therefore, our Kanban board has evolved, as the needs reported by, among others, the team have grown. We started from the level of "TO DO, IN PROGRESS, DONE" columns and ended up... on the Mendeleev board ;)

![blog-grafika 2.jpg](https://bitnoise-cms.btn.fyi/uploads/blog_grafika_2_f5c7177481.jpg)

#### MIRO - visual collaboration and brainstorming

Miro is an interactive board that made it easier for me to visually present ideas and collaborate in real-time. Since our team worked entirely remotely, it was a challenge to work out solutions together. MIRO came to our aid. 
- Discovery and Research—If you red a previous article and learned what our Discovery phase looked like, you will know that all diagrams, User Personas, research results, Customer Journeys, and BMS were visualised and developed in MIRO.
- Workshops and Brainstorming: Miro was primarily used in my work to plan new features and their early visualisation. For example: gamification logic in the student and teacher application.  I visualised several scenarios for both end-users and carried out a requirements refinement, which was then used to create the final design and flows. In addition, our developers were also very keen to use it for their activities. For example, our Senior BE developer led Event Storming sessions in MIRO, thanks to which we learned the scope of necessary endpoints to prepare for the entire project.
- Retrospectives and presentations at review meetings - Miro is very rich in [templates](https://miro.com/templates/retrospective/), and I decided to transfer the process of conducting retrospectives and tracking actions from retro right there . My favorite retrospective is [the 4L method](https://miro.com/templates/4-ls-retrospective/) - and it's great that I didn't need any additional external tool to conduct it. 

![blog-grafika 3.jpg](https://bitnoise-cms.btn.fyi/uploads/blog_grafika_3_15848c3225.jpg)

Going further into experimenting with MIRO, I also decided to check the slide-show function - I used it to present the results of increments at a review meeting. But here, honestly? I would go for simpler tools like Google Presentations or Canva :)

#### ChatGPT - my personal advisor

Last but not least - ChatGPT. There is so much talk about genAI in products and projects, but I personally had a hard time getting used to this new reality. However, I managed to find a practical application for ChatGPT in my work as a Product Owner. What did I do with this tool?
- I planned meetings - the structure, flows, timeboxes and Agendas e.g Review Meetings. ChatGPT gave me also insights on how to engage programmers and stakeholders so we could conclude any assumptions and key points from discussions
- I looked for statistical data - ChatGPT came in handy during the discovery phase when I validated various data and statistics regarding the education industry in Germany. And so, among other things, I learned that the most popular age group among young people are children aged 6 to 14, and German schools have problems accessing wifi and working equipment. So I adjusted the strategies of both products (teacher and student) with additional assumptions: the age of end-users and the need to design the flow of the feedback and self-assessment process so that it meets its goals both remotely (on users' private devices) and at school (on, e.g. a school tablet).

#### Summary

Creating an MVP, which is really two products, requires managing many tasks and collaborating with various specialists. Although I built products from scratch and didn't need advanced tools to start with, without Miro, Jira and ChatuGPT, everything would have taken me longer, and the quality of my work as a Product Owner would have been questionable.

large_blog-Inclusion Digital Saga part. 2_cover_high.jpg

medium_blog-Inclusion Digital Saga part. 2_cover_high.jpg

small_blog-Inclusion Digital Saga part. 2_cover_high.jpg

thumbnail_blog-Inclusion Digital Saga part. 2_cover_high.jpg

blog-Inclusion Digital Saga part. 2_cover_high.jpg

Product Owner Tools: What to start with and how we dealt with this topic - the Inklusion Digital Saga part 2

I'm Luiza, the Head of Production at Bitnoise, a software development company. I also work as a development process consultant, focusing on team communication, project management tools, and efficiency. In this blog post, I will share some tips and tricks on how to organize your development process to keep it lean and efficient, using a real-world example from my collaboration with a London-based client. 

I will cover the importance of frequent delivery and client feedback, improved backlog management, and transparency in the development process. 

From this post, you will learn how my team and I delivered better, faster, and increased average sprint velocity by 35%.

#### **Background**
As a Head of Production and Project Manager, my main goal is to maximize the business value of projects. During my collaboration with clients, they expect three types of activities from me: 

- optimizing the development process, 

- speeding up delivery, 

- and generating savings.  


In this post, I will share how we achieved these goals with **a mobile front-end team** I collaborated with in the role of a Scrum Master. 

The company I worked with is an **international e-learning company with over 15 years of experience in the market**. Their solutions are used by millions of users worldwide. We were delivering for both iOS and Android platforms while trying out the Scrum approach for our development process.

#### **Measuring Success**
From what point did we start our reorganization process? From process metrics. What were they telling us? That we were inefficient and that we needed to understand why.  

The velocity chart displays the amount of work that was committed at the beginning of the sprint (gray bar) and completed at the end of the sprint (green bar). We used story points to measure the workload, and **chart no. 1** visualizes the velocity results from seven sprints before any of the process improvements were made. The measurements were taken in the middle of the year. Sprint velocity results suggested that the development process was not as effective as the company had expected, and only half of the planned tasks were eventually delivered (average CaC = 52%).  

**Chart no. 2** represents the sprint velocity results after 6 months of improvements. The measurements were taken at the end of the year, and **the effectiveness of the mobile team's delivery increased from 52% to 82%.**

**CaC = Completed / Commitment * 100%**

![ ](\uploads\blog-Boosting_efficiency_post01_73wsaA6BpWrq4vOUbw1Lzr.png)
![ ](\uploads\blog-Boosting_efficiency_post02_48PZie37iQTD0LuouVXtbJ.png)
For additional measurements of the development process effectiveness, we used the **burndown chart**. The burndown chart also represents the amount of work (in story points) that was completed in a sprint (2 weeks), but it also provides information about the history of story point completion and suggests any impediments in the development process.

Referring once again to the middle of the year period (so before any improvements were made) and **sprint no. 7** results, we noticed that our realization of the delivery plan was far from effective and perfect. The red line, instead of dropping down and getting closer to the gray line every day, was following horizontally. It meant that as a team, we were struggling with task delivery, and what's more, we were often adding new tasks to the sprint (shown as ups on the red line chart). We explored this situation further during the retrospective meeting and noticed that during **sprint no. 7**, we spent a lot of time waiting for requirement specifications and discussing excessively instead of focusing on development.

At the end of the year, after implementing all necessary process improvements, we measured **sprint no. 19** and **noticed a significant increase in our efficiency**. We were finally delivering and had minimized the gap between the realization and perfect plan lines. Although there were still ups on the red chart, indicating that we may have forgotten some tasks/requirements during sprint planning, we were able to present the increment by the end of the sprint.


![ ](\uploads\blog-Boosting_efficiency_post03_1xPIJErbzjEUjO2w6nSIYV.png)
![ ](\uploads\blog-Boosting_efficiency_post04_2ed0YhpBPBGulwyap3Bzs0.png)
So, what steps did we take to achieve this improvement in our software development process?

#### **Frequent delivery and client feedback**
One critical aspect of boosting mobile team efficiency was to implement frequent delivery and obtain regular client feedback. Our two-week development cycle always ended with a valuable increment, presented during a review meeting. **This allowed stakeholders to test the functionality and provide early feedback.** The review meeting included developers, the Product Owner, Scrum Master (the Scrum Team), internal clients such as business analysts and designers, and external clients. Moreover, together we discussed the backlog (requirements) and adjusted the plan for the next iteration (sprint).

For example, in a few sprints, we delivered an improved feature that allowed users to play, pause, skip, and seek the video. **The client's feedback after every iteration helped us identify some usability issues, which we addressed in the subsequent sprint.** This iterative approach ensured that the end product met the client's expectations, and we were able to deliver a feature that increased user engagement.

Regular retrospective meetings with the scrum team also helped us  identify areas for improvement. These meetings provided insights into  what went well and what didn't in our last iteration, offering valuable  information for planning the next steps.

Both review and retrospective meetings served as inputs for planning the next iteration, ensuring that the planning process also addressed necessary improvements and backlog adjustments.

These frequent feedback loops helped us minimize the risk of delivering unexpected results, set continuous process improvements, and foster better collaboration among team members.

#### **Improved backlog management**
However, at some point, we realized that poorly prepared requirements led to delays and inefficiencies in our development process. To address this issue, we took the following steps:       

- **Designated a single person (Product Owner) responsible for keeping the backlog up to date.** The Product Owner is the person who knows how the functionality should look and has the final say in its implementation. In our case, the Product Owner had a deep understanding of the client's industry and had been working with the client for over three years.     

- **Used JIRA as a single source of truth for the backlog.** This provided a central location for stakeholders to review the backlog during review meetings and for the technical team to discuss it during retrospectives and planning sessions.     

- **Organized the backlog as a list, with clear prioritization rules, issue types, and workload estimates (story points).** These steps helped us improve the quality of our requirements and streamline our development process.


Below, you will find the issue types that our team is currently using in Jira backlog:


![ ](\uploads\blog-Boosting_efficiency_post08_1oAJUGnZkAfJ8Knaqs1KiW.png)
Below, you can find the prioritization rules that our team is using in Jira backlog:

![ ](\uploads\blog-Boosting_efficiency_post07_tb5y0VLiEddmfgMgVQ4Pi.png)
- **Seek input from developers for technical analysis and involve designers and business analysts in refining requirements.** The Product Owner does not have all the knowledge about implementation details, so it's essential to get input from developers, designers, and business analysts when refining the requirements. Involving these team members in the refinement process eventually decreased the number of misunderstandings at the development stage. 

- **Ensure that all necessary requirements are finalized before the start of each sprint.** Having finalized requirements at the beginning of the sprint reduces uncertainty and ensures a smooth development process. Avoid changing these requirements at the implementation level.  


These improvements led to faster delivery, reduced time spent on unnecessary discussions, and increased transparency of what is going to be delivered next.

#### **Transparency and useful board flow**
Having a transparent and useful board flow is essential for an efficient development process. We customized our board flow to suit our team and sped up delivery. The board flow provides a visual representation of our development process, making it easier to track progress and identify bottlenecks.  

We have implemented **Work in Progress (WIP) limits** to quickly identify and address bottlenecks. As you can see in the example below, once we put three tickets in the "blocked" column, it becomes red. This means that developers should drop any ongoing work and quickly address issues with the Scrum Master or Product Owner so that they can support unblocking them. Why? Because without those tickets (requirements), we won't deliver what clients expect at the end of the sprint. Visualization is a vital practice in board management and supports fast delivery.  

Additionally, we used **burndown charts to visualize our sprint progress**, helping the team stay on track and adjust their efforts when needed. The burndown chart and up-to-date board became essential tools for our daily stand-up meetings, where we discussed our progress, identified any blockers, and ensured everyone was aligned with the sprint goals.

Below you can find the board rules set for our Mobile Frontend Team:


![ ](\uploads\blog-Boosting_efficiency_post05_5EDWNXN5NXg3eh0Nb97vmL.png)
#### **Conclusion**
In conclusion, by focusing on frequent delivery and client feedback, improved backlog management, transparency in the development process, fostering a collaborative culture, and measuring success, we were able to significantly boost the efficiency of our software development process. These improvements not only led to better quality products but also generated substantial savings for the client.  

Remember that every team is unique, and the methods we used might not be suitable for every situation. However, by continuously evaluating and refining your development process, you can unlock its full potential and achieve outstanding results.  

If you have any questions or suggestions, feel free to leave a comment below or reach out to me on social media. I'm always happy to help and share my experiences.

For the complete presentation and slides from the **Land on Moon event** (hubraum, Berlin), please check the video below.



Land on Moon #3

Land_on_Moon_3_-_Luiza_Kwiatek.mp4

small_blog-Boosting_efficiency_cover_high.png

thumbnail_blog-Boosting_efficiency_cover_high.png

blog-Boosting_efficiency_cover_high.png

Boosting the efficiency of software development processes: a real-world example

#### **Why do you need automation?**
 When working on a new feature, improvement, or bug fix, it is crucial to ensure that all changes adhere to the rules specified by the linting tools, such as [ESLint](https://eslint.org/)
 and/or [prettier](https://prettier.io/)
. Similarly, it is essential to run tests whenever changes are made to guarantee that there are no regressions.

 With a simple project setup utilizing ESLint for linting, and [jest](https://jestjs.io/)
 and [cypress ](https://www.cypress.io/)
for testing, at some point, you will need to execute the  following command:



 This is a lot to remember and as the project grows there can be more commands to run.  It can become annoying and repetitive really fast to run all of these commands by hand. Moreover, forgetting to run some of them can cause production builds to fail or introduce bugs that could’ve been easily avoided by executing these commands locally.

 It can become quite challenging to remember and manage all of these  commands, especially as the project grows. The list of commands can  quickly become overwhelming and repetitive to execute manually.  Additionally, forgetting to run some of these commands can lead to  production build failures or introduce bugs that could have been easily  avoided by running these commands locally.

Fortunately, there are tools available that can assist you in configuring all the necessary commands to run automatically whenever you need them, relieving you of the need to think about them ever again.

#### **Knock-out repetitiveness with Lefthook!**
[Lefthook](https://github.com/evilmartians/lefthook)
 is an incredibly useful, lightweight, and easy-to-configure tool that automates various aspects of your workflow, including code formatting, test execution, and more!

To begin, you'll need to install Lefthook in your project.





#### **Configure it with ease**
After the installation is complete, you can begin configuring Lefthook by creating a ``lefthook.yml`` file in the project's root directory.



So clean and simple! Now, whenever you commit changes, Lefthook will automatically execute all of these commands. Whenever you commit changes, you should expect to see something similar to this:

![ ](\uploads\blog-Leftook_post_01_6VHv6PDrJMZOEMQSUR0YMM.png)
If Lefthook is not firing, try running the following command:



#### **Built-in features**
 However, this script can be further improved. For example, there is no need to lint the entire project every time you commit changes. Ideally, linting should only be performed on the staged files. 

Moreover, it would be beneficial if the script could also handle fixing any auto-fixable warnings and errors automatically.

Lefthook has you covered with built-in lists of files that can be used for that exact purpose for example ``{staged_files}``.

Updated configuration will look like this:



- ``staged_fixed: true`` makes sure that any file that was changed by ESLint auto-fixing will be re-added to staged files.

- ``glob: “/*.{ts,tsx,js,jsx}”`` makes sure that ESLint is run only against javascript / typescript files within all the staged files.

#### **Running concurrently**
Running each command individually can be time-consuming, particularly when there are numerous commands involved. To expedite the process, Lefthook can execute all the commands in parallel by adding a single line to the configuration file, as demonstrated below:



- ``parallel: true`` will run all the commands concurrently, which should make the whole process a little bit faster.

#### **What else can be automated?**
 Another command that can be automated is the installation of packages whenever you merge changes into your working branch. Other developers may have added different packages at any given time, so it can be advantageous to install them automatically before starting your work.

How to achieve this in Lefthook:





Important to note: ``post-merge`` hook will not run if any conflicts were detected!

Whole lefthook.yml file should like like this:





#### **Conclusion**
Lefthook is a very powerful tool that can help with automating repetitive processes, thus improving the overall developer experience by allowing your team to focus on delivering code that will be linted and tested automatically.

It is very easy to configure in new and existing projects, so I highly recommend trying it out on your own!



small_blog-Lefthook_cover_high.png

thumbnail_blog-Lefthook_cover_high.png

blog-Lefthook_cover_high.png

How Lefthook helps improve development teams’ workflows

This year's [Vercel Ship](https://vercel.com/ship)
 event (May 1st - 5th, 2023) proved to be quite  interesting for Vercel users who find it a highly useful tool but  wouldn't mind some additional upgrades. Vercel introduced three major  innovations during the event, although it's important to note that some  of them are still in the beta-testing phase.

The new features are as follows:

1. Vercel KV: store key-value Redis, based on Upstash. 	 

2. Vercel Postgres: PostgreSQL database, based on Neon (beta). 	 

3. Vercel Blob: file storage, based on Cloudflare R2 (beta).  


At Bitnoise, we extensively utilize [Vercel](https://vercel.com/)
 for **developing, deploying,  and scaling websites and web applications**, both for our internal  projects such as [Land on Moon](https://www.landonmoon.co/)
 and while working for our clients.  Consequently, we closely monitor these changes and actively test the  available features.

In my opinion, once these new Vercel updates become available, they will greatly benefit us, especially during the MVP and PoC phases of software development. These phases require efficient time management, agility, and effective feedback from the end client for successful outcomes.

Now, let's delve into what Vercel is and how we utilize it.


#### **What is Vercel?**
Vercel is a cloud platform renowned for its **streamlined approach to website and web application development, deployment, and scaling**. It leverages a serverless architecture, allowing developers to create and host websites that seamlessly integrate both static and dynamic content. Vercel's key strengths lie in its user-friendly interface and exceptional performance, making it a highly effective choice for contemporary web development needs.  

The key advantages of utilizing Vercel in software development process are:  	  

- **Accelerated development**: Vercel empowers developers to iterate swiftly and collaborate seamlessly. Its user-friendly interface and comprehensive toolset facilitate a streamlined and efficient development workflow, minimizing the time spent on setup and configuration tasks.  

- **Scalability and performance**: Vercel incorporates built-in scalability features that ensure web applications can effortlessly handle high volumes of traffic. By automatically scaling resources based on demand, Vercel guarantees optimal performance and responsiveness for end-users.  	  

- **Continuous deployment**: Vercel simplifies the deployment process through seamless integration with popular version control systems like Git. With automated deployments and preview capabilities, developers can easily test modifications and confidently roll them out to production environments.


#### **How does Vercel benefit Bitnoise's software development process?**
As I mentioned in the introduction to the blog post, Vercel is a very useful tool that helps to speed up and improve our software development process, both for clients and internal projects.  

We have used and continue to use Vercel primarily for frontend applications. However, we have also used it for applications where we separated the frontend from the backend. Vercel enables us to **work seamlessly with testers who can immediately test individual changes before they are deployed to the production version**. It also offers quick configuration and setup for new projects, **significantly reducing the need for extensive DevOps work**.   

![ ](\uploads\blog-VercelChanges_post01_5xd70JrtoRsIKODvRhvRJg.png)
Here is an example of how we use Vercel:      

- Hosting websites and apps written in Next.js and Remix.     

- Integration with platforms like Bitbucket is a great convenience because it allows you to deploy your website or app directly from the repository using webhooks.     

- Creating hosting and testing environments, as well as staging environments for projects that are still in development.


#### **Use of Vercel in MVP and PoC**
What was mentioned before is especially important in [MVP and PoC](https://www.bitnoise.pl/services/proof-of-concept-mvp-development)
 phases of development when time and the possibility of consultancy and feedback from the client on every major change and development are crucial.

For me, it is particularly useful when we use Next.js to start any new application. Vercel's integration with Next.js simplifies the deployment process by **automating configuration, providing Git integration for seamless deployments**, enabling preview deployments for collaborative testing, supporting continuous deployment, and offering a secure and flexible way to manage deployment-specific environment variables.

In other words, it saves you time and effort, allowing you to focus on developing your Next.js app and delivering new features to your users with ease.

#### **How will the upcoming changes affect the future of Vercel usage?**
First, you need to keep in mind that most of these changes are still in the beta phase. There is a waitlist to test them, and it will take some time to fully introduce those features to new projects. However, based on our best knowledge and experience, as well as the information provided during the Vercel Ship event, there are some insights we can share: 

- **Vercel KV** upgraded serverless Redis implementation by leveraging the capabilities of Upstash. Redis, a widely adopted key-value store, is commonly utilized for tasks such as rate-limiting, session management, and application state. Vercel KV streamlines the process of creating Redis-compatible databases, enabling seamless read and write operations through Vercel's Edge Network in designated regions. This solution guarantees durability, simplicity, and minimal configuration requirements. By collaborating with Upstash, Vercel ensures the availability of serverless tooling that ensures data persistence in both memory and disk storage.  

- **Vercel Postgres** - PostgreSQL is a favored option for developers when it comes to handling relational data. In a collaborative effort with Neon, Vercel introduces Vercel Postgres, the inaugural serverless SQL database specifically designed for the frontend cloud. This innovative solution seamlessly integrates with popular frameworks like Next.js, Nuxt, and SvelteKit. Vercel Postgres offers comprehensive management, remarkable scalability, and fault-tolerance. It ensures high-performance and low-latency data retrieval, empowering developers to efficiently fetch data from Postgres databases and dynamically render content on the server.  

- **Vercel Blob** is a fast and efficient solution for storing files in the cloud. Powered by Cloudflare R2, Vercel Blob simplifies file storage by providing a storage API built on web standards. Developers can store various types of files, including images, PDFs, and unstructured data, without the need for complex configurations or heavy SDKs. With Vercel Blob, developers can easily manage files hosted on Vercel and programmatically upload or generate files during the build process.  Vercel's serverless storage solutions will enhance the platform's frontend cloud capabilities. Vercel KV is going to provide a durable Redis database, Vercel Postgres will officiate  a serverless SQL database, and Vercel Blob will simplifie file storage.   


**These changes are aimed at shortening the time of tests and deployment, and reduction of  extensive DevOps work.**  

#### **Conclusion**
Vercel's recent innovations and ongoing improvements position it as an excellent tool for accelerating project development, which is particularly crucial in the MVP and PoC phases. In my opinion, it can save around 3-4 days of work in a given project. With its user-friendly interface, comprehensive toolset, and integration capabilities, Vercel empowers developers to iterate swiftly, handle high volumes of traffic, and deploy changes seamlessly.  

Vercel has introduced new functionalities such as Vercel KV, Vercel Postgres, and Vercel Blob. These features aim to enhance key-value storage, provide a serverless SQL database, and enable efficient file storage, respectively. Although these features are currently in beta testing, they hold the promise of further optimizing the software development process and improving overall project efficiency.  

As Vercel continues to evolve and expand its offerings, it solidifies its position as a valuable resource for developers seeking speed, agility, and exceptional performance in their projects.



small_blog-VercelChanges_cover_high.png

thumbnail_blog-VercelChanges_cover_high.png

blog-VercelChanges_cover_high.png

How Vercel's upcoming changes will make it an even better tool for accelerating product development

If you have a million-dollar idea, you want to validate it as quickly as possible. Spending time on things that don't add much value can be wasteful, so it's important to be strategic. Component UI libraries can help you create your MVP quickly and efficiently. 

#### Tools tailored to your requirements

There are plenty of solutions in the market that help with that, and each of them will fit different needs. 

Bootstrap has been around for quite a while and is well-known in the web development world. It was created to make it easy to build responsive web apps. It is basically a simple CSS library, but it got integrated into many popular libraries and frameworks like React or Angular. 

Material UI draws its inspiration from Google's innovative design philosophy, "Material Design," which emphasises user experience, depth, and visual consistency. Its main focus is customization, allowing developers to create interfaces tailored to their specific needs. Based on that, you could create your own design system that would fit your needs exactly as you want it.

If you’re looking for more enterprise-level solutions, Ant design might be a better choice. It offers a big collection of components designed to facilitate the development of complex business applications, which include sophisticated interfaces for data tables, forms and charts.

Chakra UI prioritises developer experience through its modular, customizable components. It allows you to define and apply themes, promoting code reusability and ensuring a consistent look and feel across elements. However, it is less known than the predecessors, so the community might be a little smaller.

While established solutions have a track record, their designs may appear dated. If you're aiming for a modern look and feel, Next UI is a compelling choice with its focus on aesthetically pleasing components. Plus, they made sure it runs fast by using Tailwind CSS as the core, which cuts down on the extra classes in the bundle.

Considering the advantages and disadvantages, most of the solutions are similar, and by the end of the day, it could be a matter of personal choice. Let’s dive in and see the use of specific components to assess the developer experience.

#### Compare different components

In the next section, I will compare specific components, showing which features are available by default and which are not. Take into account that most of the things mentioned could be somehow implemented, however, I will focus only on the aspects that are handled by the library.

#### Commonly used component

I think the Button is the most used component from such libraries, so it would be best to start the comparison with it.

![tabelka 1_.png](https://btnw-strapi-prod.dev.btndev.space/uploads/tabelka_1_63332c5fbb.png)

All the component UI libraries support different button variants such as primary, outlined or of different colours and sizes. Managing the state can also be achieved by all of them, however, Bootstrap needs a little more code to be written around the logic of the loading state. Bootstrap also lacks icon support, so if we want to implement that, we have to manage it ourselves. 

#### A more advanced example

I think working in modals can be either pleasant or a nightmare, depending on the specific developer experience the tools provide. Seeing what features different libraries could offer can help us understand what would be easier to use in the long run.

![tabelka 2_.png](https://btnw-strapi-prod.dev.btndev.space/uploads/tabelka_2_1fa58e692d.png)

Compared to Button, here we can actually see some significant differences between the libraries. Ant Design simplifies the most common use case for models, which are confirmed dialogues. It provides an additional confirm function, which takes only texts and callbacks, allowing us to trigger it anytime we need it without focusing on defining content each time. This library also handles async logic, so calling APIs and showing its effect could also be simplified. Another difficult case would be modal nesting, which is supported by Material UI and Ant Design. This could facilitate handling of some complex business flow. Material UI also lets you drag modals around. It's a handy feature, but personally, I don’t see much use in business contexts.

#### What to choose?

With so many libraries on the market, choosing the one that works best for you can be challenging. If your design is simple, it is probably a matter of personal preference. With more complex applications, it would be good to assess if there are any specific harder use cases that some of the libraries might support better than others.

large_blog-DecodingReactUI_cover_high (1).png

medium_blog-DecodingReactUI_cover_high (1).png

small_blog-DecodingReactUI_cover_high (1).png

thumbnail_blog-DecodingReactUI_cover_high (1).png

blog-DecodingReactUI_cover_high (1).png

Decoding React UI: Unveiling the Best Component Libraries in a Head-to-Head Showdown!

### Cracking the Code: TypeScript Tips & Tricks to Catapult Your React Application

#### Introduction

Every project that uses Typescript under the hood will contain some custom types that are being used across the application. As an application evolves or demands shift, it's important to manage all those types in accordance with DRY and KISS foundations. In the name of type safety, it might be tempting to type every single element within the codebase. However, it can be beneficial to stop for a minute and ask those 2 questions:

- **Why** is there a need for a given type?
- **What** is it needed for?
- **Where** will it be used?

It's important to note that creating too many custom types can lead to the over engineered codebase. When one change request or a new feature requires updating x amount of custom types, it can make the codebase harder to maintain.
This blog post will cover some useful tips and tricks to add to the cauldron of typescript magic to keep in mind when working with custom types.

### The less typescript, the better

Excessive inclusion of types for every single data structure may seem like a good thing at first. However, having a lot of custom types can lead to an unnecessarily bloated and redundant codebase, where some types may be duplicated unnecessarily.

To better understand why often less is more it's best to show by example:


At first glance, the above code looks good. Everything is type safe, but this code can definitely be improved.
By following the three questions asked in the introduction:

- **Why** is there a need for `ParsedUser`? - So that an array returned by `parseUserData` could be used in different places in the codebase.
- **What** is `ParsedUser` needed for? - To have a simplified type of `User` type.
- **Where** is `ParsedUser` used? - For example, in some components' prop types.

Doing one thing at a time. `ParsedUser` is just a simplified version of the `User` type, so it makes sense that when `id` or `username` on the `User` type changes,  `ParsedUser` would also adapt.

This can be achieved by introducing typescript's built-in utility types. It's possible to reuse the `User` type to construct the `ParsedUser` type by using `Pick`.


With that small change, `ParsedUser` and `User` are "connected" so whenever `username` or `id` changes the `ParsedUser` will also update.

The next thing to consider would be how to handle the return type of the `parseUserData` function. If there ever will be a need to change the shape of `ParsedUser`,  e.g. adding a `fullName`. With the current state of the code, every change to `parseUserData` must be followed by updating the `ParsedUser` type, which may not be ideal.

Since `ParsedUser` type is closely related to what `parseUserData` returns, it's possible to use `ReturnType` utility type from typescript and create this type like so:

Two things have happened:

1) Typescript is smart enough to understand what types will be returned from a given function so it's possible to skip it in function declaration.

2) By using the `ReturnType` utility, the `ParsedUser` type will not only be dependent on the `User` type, but also on the `parseUserData` function. When the shape returned by `parseUserData` changes, the `ParsedUser` type will reflect that change as well.

  
_As an addition, it is still possible to use this approach with async functions by introducing yet another utility type `Awaited`, e.g._


_Adding [number] to array type will tell Typescript to look on type of an item within that array._

As the above example presents, with less typescript the code is still type safe AND highly adaptable to any changes.

Utility types used in this example are just the tip of an iceberg.
In typescript's documentation, there are   way more utility types that can lead to enhancing the implementation of custom types and reducing the number of types needed in the application.

[https://www.typescriptlang.org/docs/handbook/utility-types.html](link)

### Master union types

A type union is most commonly used when a given property can have more than one type or when creating a custom type.
Basic type unions could look like this:

However, type unions can also enhance the developer experience when working with React components.
Again, best explained by example:

This example is invalid because `UserCard` requires to pass both `userStatus` and `adminStatus` no matter what user role is passed. A better experience would be to require passing the `userStatus` only when the user's role is `USER` and vice versa.

Possible fixes would be:
- Make both `userStatus` and `adminStatus` optional, but that may not be the intended behavior of `UserCard`.
- Create a separate `AdminCard` for handling admin stuff, but that can lead to code duplication, which could violate the DRY rule.

In this simple example, it would not be the end of the world to make `adminStatus` and `userStatus` optional. Oftentimes, components have more complex structures and making a lot of optional types can make it harder to understand what components require and when.

There is a better way of solving this issue with both type unions and typescript magic:

By extracting the common properties (`fullName`) to separate type and creating additional two separate types joined by union `UserCard` now have props that will be required based on the provided `role` prop.

_Typescript will know that both types used in the union have a role property, so it will "merge" these into one type. In the end, the role will be of type "USER" | "ADMIN"._

This behavior improves the developer experience, when working with this component because it requires different props depending on the user's role.

With great power comes great responsibility, so this pattern should be used wisely as it has some drawbacks:
- it can make props type less readable
- can be difficult to implement when there are two or more props that change the outcome overall props shape

#### Generic types for not a generic dev

Implementing generics enhances the flexibility and reusability of code segments within a codebase. This typescript is a fundamental tool that developers should frequently reach out for, becoming an essential tool in the toolkit of every developer working with typescript.

Generics can simply be used to create custom utility types e.g.


Function `swap` can only be used with strings, but what if there is a requirement to swap numbers, or some other custom typed data? It's a good idea to make this function generic:

_Specifying return type [T, T] makes sense here, because this array will always consist of just two elements._

Now this function can swap not only numbers, but any data thrown in as arguments.

When working with React, generics can be used to create generic components f.g
instead of creating Lists components for every single array the codebase has, it can be done with one generic component:

_Thanks to adding <T extends { id: string }>, id which is used in item's key will be required part of item type._

The list can now be used with any type of data structure, which makes it a highly reusable component.

#### Summary

TypeScript is approachable for beginners with its gradual typing and JavaScript compatibility, but mastering its advanced features like typing nuances and generics can be challenging. Despite the learning curve, the benefits of static typing lead to more reliable code, better collaboration, and reduced bugs. TypeScript's robust tooling and community support further enhance its appeal. The initial ease of use gives way to long-term advantages, making it a worthwhile choice for developers aiming for code quality and maintainability.

Typescript is easy enough for beginners to start their journey with static typing, but some more complex features (generics or type unions) can be hard to get around at first. Still, they can improve the maintainability and reusability of some parts of the codebase, so it's worth getting to know them.

I hope this blog post will ease the learning curve of the more complex topics of Typescript.

large_blog-DecodingReactUI_cover_high (3).png

medium_blog-DecodingReactUI_cover_high (3).png

small_blog-DecodingReactUI_cover_high (3).png

thumbnail_blog-DecodingReactUI_cover_high (3).png

blog-DecodingReactUI_cover_high (3).png

Developer is sweaty, TypeScript spaghetti


Git is a fundamental tool that every developer must have in their arsenal. In a modern and agile world of software development, where codebases are managed by huge teams, having a tool that helps to streamline the process of adding features, changes, or fixes is, without a doubt, a necessity.

Like many tools, git is, with no exception, easy to learn and hard to master. In just one day, an inexperienced developer can learn how to connect to a remote repository, create a branch, push commits, create pull requests, and merge the code. This blog post aims to help developers become more mindful about what and when is being committed to keeping the history well organized, informative and clean.

Keeping the commits history clean helps understand what changes were made to the codebase to backtrack easier if something is not working properly. Not having descriptive commit messages or having too many changes in a single commit are common issues of larger codebases.

![blog-DecodingReactUI_blog_01.png](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_Decoding_React_UI_blog_01_8c93667a61.png)

#### The easy parts

Every developer knows these commands by heart:

These commands are the foundation of working with Git. However, some of these commands can be slightly modified to create better commits.

##### git add

When working on a new feature, it is often hard to stop in the middle of the process just to create a commit. After some time, the feature is fully implemented. X number of files have been altered, and Y files were added. The time to commit code has come. Instead of creating one big commit, it is often better to have multiple smaller ones, e.g., creating a UI component, creating a test case, updating the types, etc. But the work is already done, so how can one split it now?

Simply by adding `-p` (patch) flag to `git add` command will open an interactive window that will go change by change (it **will not** go through newly created files). Developer will be able to decide whether or not to add given change, skip it or break it down even more. Now all changes regarding the tests, creating new ui components or updating the types can be separated into a different commits. Same file can be committed multiple times containing different changes that are part of a given commit, thus bringing it one step closer to create a clean commit history.

##### git commit

Now that the bigger changes can be grouped into smaller chunks adding a descriptive commit message is next in order.

Adding one `-m` flag will create a header for the commit message that will be shown in the history. However, sometimes one liner is not enough to fully describe the changes because more context is required. Adding another `-m` flag will create a commit's description:

When running the `git log` to display the commit history, it will be displayed as so:

_To quit the git log command, click 'q' on the keyboard._

Descriptions can be improved by adding `$` before the description to introduce better text formatting.


_Adding \n creates a new line_

This will be visible as:


Not every commit requires a description. It is always up to a developer to consider if changes that are being committed require more context or not.

_At Bitnoise, we follow the guidelines laid out by the [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/) to ensure that our commit messages are well structured. This ensures that commits in the history have a similar structure, making them easier to read._

There can be cases where the commit was made, but there was a typo in the code, or some small improvement was still missing. Instead of creating a new "fix typo" or "remove console.log" commit ```--amend``` flag can be used.


It will add all new changes to the last existing commit, so it's super useful for small updates on the last commit (how to update commits that are higher in the history will also be covered later in the blog post).

_Amending will change the commit hash, so if the commit has been pushed to the remote branch, it will be required to force push; thus, amending on shared branches must be avoided!_

#### Bringing it all together

Moving changes from one branch to another is a crucial part of working with git. It serves three purposes:

- shared branch can be merged to a local branch to have it up-to-date with the latest changes made by the rest of the team,
Local branches can be merged into a shared branch to make the new feature or bug fix accessible to other developers in the team (usually via pull request).
- local branch can be merged to another local branch to have them up-to-date

These cases may seem the same at first - making one branch up-to-date with the changes of the other. However, there is an important difference between the shared branch that is being used by the whole team and the local branch that's being used by one developer. The difference is that on a shared branch, the commit hashes should never change (pushing with force should never be required). On local branches, commit hashes can change (until the changes are not merged to the shared branch), and it will not impact the team's work.

In those scenarios, the developer has access to two different strategies: **merging** and **rebasing**.



**When is it safe to rebase?**

- when updating the private branch with the shared / main branch to preserve linear history.
- When making changes to the commits made on the private branch that are not a part of the shared branch, e.g., editing commits, rewording commit messages, squashing commits, or deleting them.

**When is it not safe to rebase?**

- when working on a shared branch like development or main, it's always better to use merge over rebase to ensure that commit hashes will not change and no forcing push will be required. If merge commits are not needed, `git merge branch-name --ff-only` can be utilized to merge changes without adding the merge commit.

  
##### Interactive rebasing

Where rebase surely shines is the interactive version, which can be used to alter the commit history in many ways.

_ n - number of commits in the history to take into the rebasing from latest to oldest f.g if two latest commits should be rebased, then n = 2_

Interactive rebasing allows you to edit committed files, reword commit messages and even squash or delete commits.

When running the command, it will show a window that can look like this:


For example, above following actions can be utilized to organize the commits better:

_When editing a commit, after editing was finalized, `git rebase --continue` should be executed to move to the next commit_

Rebase will go through each listed commit, execute the desired action, and after completion, replace a commit, thus **changing commit hash**, and move to the next one.

_If the commits were already pushed to the remote branch push with force will be required._

When a need arises to edit a commit message or whole commit that is not the latest one (the latest one can be updated by amending with `git commit—-amend`), interactive rebasing truly becomes handy.

#### More is not always better

On the other hand, having 30 commits for a single feature or bug fix might be an overkill and reduce the history's readability rather than improve it. Sometimes, it makes more sense to join or squash some commits into one bigger commit with more substance.

For example:


The commits above are very granular, and it does not make sense to have them separated like that. One can leverage interactive rebasing to squash these commits easily.

The end result may look something like this:

Now, instead of having multiple remove console.logs, typo fix commits can be organized into one big, easy-to-understand commit.

#### Conclusion

Many developers stop learning git after understanding the basics, which can negatively influence the team's work. Clean history is a part of code documentation and improves not only tracking what was done and when but also reviewing the code in pull requests. Tracking where something could've gone wrong when bug fixing is also less painful if commits are well organized.

This blog post shows that small changes to well-known commands can drastically improve the quality of the commits being created. Adding interactive rebasing into the mix will also make any developer an even better team player.

#### Useful tips and tricks

##### Git game

If you're a beginner and those topics still appear too advanced, you may want to check out this [game](https://learngitbranching.js.org) to familiarize yourself with the git basics.

###### Editing name of the branch

Sometimes, a typo can sneak into a branch when creating it. So here is a flow that will allow me to edit branches to fix the typo. 


##### Removing all local branches

When working on a big project, sometimes a lot of old branches can be deleted. Instead of going branch by branch, this command can be used to delete all local branches:

large_blog-DecodingReactUI_cover_high.png

medium_blog-DecodingReactUI_cover_high.png

small_blog-DecodingReactUI_cover_high.png

thumbnail_blog-DecodingReactUI_cover_high.png

blog-DecodingReactUI_cover_high.png

Git Gut: Take care of your commits history like a pro

In the latest episode of PozTechTalks, Łukasz, Piotr, and Patryk delve into the realm of AI tools for developers. Serving as a continuation, this discussion builds on the insights and evaluations presented in the previous episode and accompanying article, providing a deeper exploration of innovative AI solutions tailored for programming challenges.

[**What the Diff**](https://whatthediff.ai/): This tool, aimed at enhancing pull request descriptions, integrates directly with GitHub. It distinguishes itself by generating comprehensive change summaries. However, its effectiveness varies, with occasional inaccuracies in generated descriptions, highlighting a mismatch between actual changes and the tool's interpretations. The tool also offers code review suggestions, which didn't perform well in tests, suggesting unrelated changes. Its usage is constrained by token limitations, making its free plan somewhat impractical for regular use.

[**Lintrule**](https://www.lintrule.com/): Differing from traditional linters, Lintrul allows for the creation of custom, human-readable rules for code consistency checks. It directly integrates with GitHub, enhancing code quality by enforcing project-specific conventions that might not be covered by standard linters. Despite its innovative approach, the need for precise rule definition and potential costs for extensive usage were noted.

[**ChatGPT**](https://chat.openai.com/auth/login): Not directly a development tool, ChatGPT's versatility is highlighted, showing its ability to analyse dependencies, generate code snippets, and interact with APIs using natural language. Its ability to browse the web and execute plugins extends its utility beyond simple Q&A, proving useful for various development-related tasks. However, reliance on this AI requires careful verification of its outputs due to occasional inaccuracies.


To conclude, the trio's exploration of AI tools reveals the evolving landscape of software development, where AI not only optimises workflow but also introduces new methodologies. Their discussions underscore the necessity of blending technical precision with creative experimentation to leverage AI's potential in programming fully. This insightful journey through AI tools not only broadens understanding but also invites developers to engage with these technologies, promising enhancements in efficiency and innovation.

Check out the full episode (in Polish)!


PozTechTalks 19

large_blog-AI Tools for Developers_cover_high.png

medium_blog-AI Tools for Developers_cover_high.png

small_blog-AI Tools for Developers_cover_high.png

thumbnail_blog-AI Tools for Developers_cover_high.png

blog-AI Tools for Developers_cover_high.png

Exploring AI Tools for Developers: Insights from PozTechTalks part 2

Quite recently, we delivered a project for one of our German clients, Inklusion Digital. Our task was to design and build an application for two groups of users: German teachers and students. Within the solutions provided, both groups had a common goal: to develop annual goals for students and verify their progress through feedback and self-reflection.

This is a fascinating example of an implementation in which we involved many different specialists; I had the pleasure of acting as the Product Owner of the entire idea. Today, I want to tell you the history of this whole project in several posts - so that you can understand the completed stages of the project, learn about the tools and practices... and learn from our mistakes.

We will start by analysing the discovery and design phases, allowing us to develop product design and UX tailored to users' needs.


In startups, the discovery and design phase is often overlooked and, as it later turns out, the most necessary. This stage of the product creation and development process aims to understand user problems, market needs, and technological possibilities. During this phase, the product team collects and analyses information to define the product's vision and determine its potential value and the risks associated with its implementation.

Suppose you are asking yourself what this is or are already answering this question by claiming that you do not see the relationship between the project's success and this phase. In that case, I will help you pragmatically out of this mistake.

According to [the latest research](https://www.nngroup.com/articles/discoveries-in-industry-revealed/) by Nielsen Norman Group and MIT:
- Product Discovery can help you lower the risk of failure by 75%.
- Teams using Product Discovery report 83% 𝗼𝗳 𝗽𝗿𝗼𝗱𝘂𝗰𝘁 𝘀𝘂𝗰𝗰𝗲𝘀𝘀.
- Discovery saves 50% of development rework time & 𝗰𝘂𝘁𝘀 𝗰𝗼𝘀𝘁𝘀 𝗯𝘆 33–50%. 

![blog-grafika 1 - discovery phase.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_grafika_1_discovery_phase_639acd94c3.jpg)


The above information guided us and convinced us that it is worth investing money into the discovery phase, as the results at the delivery and launch stages can be much more profitable. 
Before we started the design phase, we decided to work with the client in several weekly sprints to understand the needs of our end users (teachers and students) and their most significant pain points. How did we do it?

#### Customer Journey - process mapping

We set out to build a tool for the German education market to digitize the existing manual process of creating and managing students' annual goals. Using customer journey mapping, we analyzed the current process in German schools and identified the associated challenges. The results exceeded our expectations—it became clear that goal cards are often lost or forgotten, and their current format needs to be updated and made more appealing. As a result, students are less motivated to achieve their goals.

We definitely obtained tips and information that—as it now turns out—were the core of building basic functionalities in both applications.

We have placed the map and all information in MIRO.

#### User Personas - who is our end-user?

In parallel to building the Customer Journey, we decided to deepen our knowledge about our potential users - teachers and students in Germany. We started from the level: we want to make applications for all children and teachers in Germany. We concluded that the needs and requirements for using different applications are different and depend, among others, on the age of children/teachers, the type of school, and the education regulations of a given Bundesland. And this is how we defined our end-users (in an extensive summary :)):

- children and teenagers from various backgrounds, aged 10 to 16 (the most popular age group, we do not want to expose younger ones to technology), from secondary-level schools (business reasons for the client: gymnasium, Forderschule, Gesamtschule.. - the largest group of students)
- teachers - of different ages (challenge here!), and secondary-level schools (the same as above).
In addition to the specific characteristics of our users group - we have defined their key pain points, wishes and expectations in accordance to the build solutions. 

![blog-grafika 2 - personas.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_grafika_2_personas_26f5211ca0.jpg)
_Sample user personas template: https://miro.com/templates/personas/_


#### Business Model Canvas + User Stories
##### What do we want to build, and what are its chances of success?

After completing work on the customer journey and user personas, we felt ready to define the scope of our new product—digital applications for teachers and students that will improve the process of achieving school goals—together with the client.
We knew that: 
![blog-grafika 3.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_grafika_3_599cd991e0.jpg)


We started developing a [BMS](https://miro.com/templates/business-model-canvas/) and an Epic and User Stories outline. And we were like, wow - we create products tailored to the real needs of users! The Discovery Phase lasted about a month in total. After that, we started the design phase with full excitement. 

Those needs were converted into user stories with a MoSCoW prioritisation. We ended up with two scopes of products: one for teachers and a second for students. Suddenly, we realised that we were creating products that truly meet user needs. The Discovery Phase lasted about two weeks, and we moved on to the design phase, which took about a month.
Here, you can see the effects of the user stories slicing process: in the form of 2 maps in the Miro board.

![blog-grafika 4.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_grafika_4_1a511232de.jpg)
![blog-grafika 5.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_grafika_5_ac22b5d1a6.jpg)

The design was really smooth, primarily because of the great output from the discovery phase and the client’s involvement in the reviewing process. Teachers could expect a module as an add-on to the existing platform, and students would experience a separate app (independent of this platform). Teachers could, among other things, set annual goals together with students, leave feedback on progress, view results on an interactive chart, set a reward system and monitor students’ emotions. On the other hand, students carried out the self-assessment process, were recipients of rewards, collected points and shared their emotions. We have validated the design three times and, most of all - tested prototypes with teachers and students. We have received an enormous amount of input that has confirmed that we are ready for the development process.


Product Owner Tools: What to start with and how we dealt with this topic - the Inklusion Digital Saga part 2

Luiza

Boosting the efficiency of software development processes: a real-world example

Luiza

How Lefthook helps improve development teams’ workflows

Michał

How Vercel's upcoming changes will make it an even better tool for accelerating product development

Piotr

Decoding React UI: Unveiling the Best Component Libraries in a Head-to-Head Showdown!

Wioletta

Developer is sweaty, TypeScript spaghetti

Michał

Git Gut: Take care of your commits history like a pro

Michał

Exploring AI Tools for Developers: Insights from PozTechTalks part 2

Magdalena

The discovery and design phase as the main component of product success - the Inklusion Digital Saga part 1

Luiza

GET IN TOUCH