Update, Dec 9, 2025 Some time ago, we decided to migrate all our technology-oriented content to our main website engine. All articles now live under https://evojam.com/technology-blog.

Focus

What you can expect on that blog:

• Software architecture
• Fast and/or big data
• Scala ecosystem
• AngularJS & JavaScript mastery
• Development process
• Microservices
• Reactive Manifesto principles

Who's Behind This Blog?

Brave engineering team of Evojam. We're a bunch of engineers consisting of the best fronted, backend and infrastructure engineers you can find.

Connect

To stay in the loop you may want to consider following us on Twitter @evojamcom or liking Evojam on Facebook. Especially if your main source of information is LinkedIn - our posts are not suitable for that medium, so will not be advertised there ;)

Permalink

]]>Stories About Engineering of High-Performance Web AppsLukasz KoralMon, 11 Aug 2025 14:53:40 +0000https://evojam.com/blog/aiorautomation54c889aae4b008ef3778f726:54cb762ce4b07c950cd2fd16:6899fe75ec257771ae4d2596“Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.” Antoine de Saint-Exupéry

In the rush to innovate, it is easy to believe that adding more is always better: more data, more features, more intelligence. Lately, “more” has often meant AI. It is the word lighting up investor conversations, shaping product roadmaps, and driving search queries like how to implement AI in my company. But complexity is not the same as progress. Sometimes the real leap forward comes from removing what is unnecessary and doing the essentials extremely well. That is where business process automation quietly outshines AI, solving problems with less cost, less risk, and faster results.

Where Automation Quietly Wins

If you look closely, the situations where automation beats AI fall into a few simple categories. Spotting them early can save you months of development and help you avoid the trap of chasing technology for its own sake.

1. Structured, predictable workflows - Some processes are so consistent they can be mapped in a single line on a whiteboard. Processing invoices from regular vendors, scheduling recurring meetings, or onboarding new hires all fit here. These do not require AI-powered process automation services. They simply need reliable logic. Rule-based workflows handle them with precision and zero surprises, helping companies reduce operational costs with automation without touching AI at all.
2. High-volume, low-complexity communication - Not every customer touchpoint needs “understanding”. Sometimes it is just acknowledgement: confirming an order has shipped, sending an auto-reply to a support ticket, or routing a message to the right team. Here, automation works better than over-engineering a chatbot. This is also why many AI consulting and development partner firms advise clients to separate “communication at scale” from “conversation at scale”. The first is a perfect match for automation; the second may need AI.
3. Event-driven operational sequences - Some business flows are triggered by a single event: a payment processed, a compliance check passed, an inventory level dropping below a threshold. From there, the sequence is fixed: update records, send notifications, generate labels. Clear triggers and deterministic steps win every time. For example, in manufacturing, this kind of manufacturing process automation handles routine tasks, while computer vision solutions for quality control can be layered on top only when human-level inspection is required.

When Rules Fail You

This is not to say AI does not have its place. Bring it in when the problem refuses to sit inside neat boundaries, when your data is messy, inputs are unstructured, or you are dealing with complex patterns. That is when you explore AI for workflow optimization, or use intelligent document processing with AI to extract meaning from varied formats at scale. It is also where sectors benefit from tailored solutions, like AI software for real estate companies predicting market shifts, or computer vision solutions for quality control in high-precision manufacturing. And in the bigger picture, this debate about AI vs automation connects directly to the current market conversation around AI vs RPA: which is better for automation. The answer, as always, is: it depends on the problem.

Looking Ahead

If you are following AI automation trends in 2025, you will see an interesting pattern: companies are increasingly blending the two approaches, using automation for structure and AI for ambiguity. That blend is where the future lies and where the smartest cost savings and performance gains will come from.

A Simple Thought to Carry Forward

Next time someone on your team says, “Let’s use AI for this”, pause and ask: “Could we automate it instead?” If the rules fit on a whiteboard, automation will give you clarity, speed, and reliability without the overhead of training models, wrangling data, or debugging black-box decisions. In business, the simplest thing that works is often the thing that scales. And whether you work with a custom AI software development company or simply tighten your business process automation, the real win comes from matching the right tool to the right problem. Sometimes, the brightest star in your toolkit is the one you have had all along.

However, HVAC companies are facing challenges that are stopping them from providing great service to their customers.

In this article, we'll look at these challenges and introduce a HVAC custom software solution for HVAC companies that will help you overcome these issues and succeed in the ever-changing market. Whether you run an HVAC business or are a high-level manager, you will learn how to make the most of your HVAC company's potential!

Main Challenges Faced by HVAC Companies

Lack of Information About HVAC Business Customers

In our experience, one significant challenge faced by HVAC businesses is not having enough information about their customers. And how can you help anyone if you don't know what they need?

Understanding customers, how they use their products, and where the hardware is installed is key to delivering top-notch service and keeping them happy.

Complex Remote Control Systems and Mobile Apps

Another obstacle is the absence of user-friendly remote control systems or mobile device apps for HVAC devices.

Users often struggle with complicated interfaces or outdated control systems, which leads to frustration and a less-than-optimal user experience. This has a negative impact on a business’s profitability and customer loyalty — something you definitely want to avoid.

Limited Scope for Additional Services and Upselling

HVAC manufacturers find it challenging to offer extra services or tempting upsell opportunities to end users because they lack direct communication channels. This limitation hinders their ability to engage with customers and maximize upselling opportunities.

Difficulty in Scheduling Maintenance Visits

Scheduling maintenance visits for HVAC systems is a major challenge for manufacturers. This results in missed opportunities to maintain peak system performance, reduce warranty claims, and build customer loyalty.

No Feedback Loop for HVAC End Users

End users often lack a reliable way to report problems or issues with their heating and air conditioning systems.

Without a feedback loop, you can't address these concerns promptly, leading to customer dissatisfaction and potential harm to your reputation.

By taking on these challenges head-on, you'll reap the rewards of happier customers and smoother operations thanks to custom top-notch HVAC software and nifty mobile apps.

So, what are the most important features of a custom mobile app for your HVAC company?

What to Look For in an HVAC Custom Software Solution?

To effectively tackle these challenges, Evojam offers the opportunity to create a fully customised HVAC business software solution: an intuitive mobile app designed specifically for end-users of commercial HVAC companies and systems. This comprehensive app can be designed to fit your business like a glove, whether you are large commercial HVAC company or a small business focused on residential services.

So, what features should you pay attention to?

Potential Key Features of a Custom Mobile App for HVAC Businesses:

Seamless Registration Form for Customer Management

The app can include a simple, user-friendly registration form that captures important client and hardware data. This helps manufacturers gain valuable insights into their customer base and personalise their offerings accordingly.

User-Friendly Control System 

The custom HVAC software can include a seamless and user-friendly registration form that efficiently captures crucial client data. This data serves as the foundation for robust customer management, helping HVAC businesses tailor their services, schedule jobs, and maintain comprehensive customer details.

Intuitive Control System with Real-Time Monitoring

A custom mobile app can provide your HVAC contractors and technicians with an easy-to-use control system for managing HVAC systems. This user-friendly interface can simplify job scheduling, dispatching, and technician tracking tools, enhancing field service management efficiency.

Engaging Push Notifications and Alerts

The innovative custom mobile apps empower HVAC businesses to engage with customers through push notifications and alerts, ensuring excellent customer satisfaction. These messages provide updates, service agreements customer notifications, and personalized service options, enhancing the overall customer experience and building loyalty.

Service Desk Module

The app can integrate a service desk module, enabling HVAC professionals to streamline project management, with HVAC scheduling, estimates, and technician scheduling. It can also offer GPS tracking for mobile devices and vehicles, allowing HVAC businesses to manage leads effectively — up to you!

By leveraging this comprehensive mobile app and HVAC management software solution, you will maximize your operational efficiency and provide great customer service.

Now, let's move on to the benefits of a custom HVAC app!

If you're an HVAC manufacturer looking to improve your user experience and streamline your operations, we invite you to schedule a call with our team. Let's discuss how our custom software solutions can address your specific needs, enhance customer satisfaction, and position your company as a leader in Europe's rapidly evolving HVAC industry.

Benefits of a Custom HVAC App

With the ever-evolving HVAC industry landscape and the complex challenges it presents, embracing a custom HVAC software solution with an easy-to-use interface is a game-changer for your business. The benefits it offers fully address the needs of HVAC businesses:

Enhanced Efficiency in HVAC Business Operations

Custom HVAC software solutions can streamline business operations, from inventory management and scheduling jobs to dispatching HVAC techs.

In a custom app for mobile phones, we can include features like technician tracking tools and GPS tracking, so you can gain real-time insights into field operations. This will result in more efficient resource allocation, reduced downtime, and optimized workflows.

Improved Customer Management and Satisfaction

Effective customer management is crucial in the HVAC industry.

Custom software allows for comprehensive customer data management, ensuring easy access to customer information and histories. You will be able to offer personalised service, quickly resolve issues reported through the integrated service desk, and provide great customer service.

Optimal Resource Utilization for HVAC Service

Managing field technicians and HVAC techs becomes a breeze with a custom mobile app!

It enables HVAC business owners to schedule jobs effectively, assign tasks, and track progress. By optimizing job scheduling and dispatching, you can provide quicker response times, resulting in happier customers.

Accurate HVAC Estimates and Invoicing

Custom HVAC software can include features for HVAC estimating and invoicing, ensuring accurate and professional invoices for customers. This not only enhances your company's image but also helps manage leads and upselling opportunities more effectively.

Comprehensive Business Insights and Reporting

Custom HVAC management software can offer robust reporting and analytics capabilities!

You will be able to gain valuable insights into your business performance, allowing for informed decision-making and strategic planning. It also helps track project management, monitor service agreements, see customer history and assess pricing options for maximum profitability.

Streamlined Accounting and Financial Management

Integrating HVAC accounting software into the custom mobile app can simplify financial processes, including credit card processing. It reduces the chances of double data entry errors and ensures smooth financial transactions, benefitting both the business and customers!

Increased Profitability and Growth for an HVAC Business

Ultimately, a custom HVAC software solution can equip you with the tools you need to maximise your profits and grow your entire business. By embracing this technology, you can efficiently manage your entire operations, from the first customer contact to project management and beyond. This comprehensive approach translates to a healthier bottom line and sustainable business growth.

Choosing the Best HVAC Software Company

When it comes to selecting the perfect software company to craft tailored solutions for your HVAC company, the decision can significantly impact your operational efficiency and profitability.

Take a look at our guide on how to evaluate and choose the best software partner for your HVAC business, with a keen focus on factors like scalability, integration capabilities, and ongoing support.

Assessing Custom Software Companies

Choosing a custom software development company for your HVAC business requires careful evaluation. Follow these steps to ensure you make an informed decision:

Define Your HVAC Business Needs

Begin by meticulously outlining your precise requirements and objectives for the HVAC business software.

What are your short-term and long-term business goals, and how can a custom software solution assist in achieving them?

Establishing a clear understanding of your needs will help you select the right partner to provide you with the best HVAC software.

Thoroughly Research Potential Custom Software Development Companies

Dedicate time to researching and identifying custom software development companies. Delve into their case studies, check client testimonials, and scrutinise their portfolios. Read our detailed guide on how to find a tech company that doesn’t suck.

Prioritise Scalability

Make sure that the chosen company possesses a wide range of experience in creating software solutions that are highly scalable. Scalability is essential to accommodate the growth of your HVAC business; your software should seamlessly adapt to increased demands.

Evaluate Integration Capabilities

Consider the company's prowess in integrating your custom HVAC software with your existing systems, whether it's accounting software, customer management tools, or inventory management solutions. A seamless integration process enhances operational efficiency and the flow of critical data within your HVAC business.

Emphasise Ongoing Support

Beyond the development phase, ongoing support is crucial. Ask about the support and maintenance services offered by potential partners to ensure they align with your expectations. Prompt issue resolution, regular updates, and adapting to your evolving needs are all part of effective customer support, too.

Choosing the perfect custom software company for your HVAC business is a game-changer that can seriously boost your profits. By meticulously evaluating potential partners based on scalability, integration capabilities, and ongoing support, you can confidently move forward with the development of a tailor-made HVAC service software solution that propels your business to new heights!

As a software development company, Evojam provides services to external businesses. We believe that shared team values are the core of employee satisfaction and successful collaboration with our colleagues and clients. The success of any software development project relies heavily on the cohesion and alignment of our values. Possessing technical expertise is not enough.

Our views on core company values and culture differed due to our diverse backgrounds. However, working in a team requires sharing values and principles. In addition to fostering a positive work environment, team values facilitate collaboration and cooperation between members, allowing mutual understanding and guiding decision-making. 

Some of us needed help understanding how Evojam approaches values in our daily work towards our clients and team members. This drove our urge for transparency in company culture and values. We didn’t want them to be just a buzzword; instead, we aimed for something we all believed in.

So, what did we do?

Our Path to Establishing Core Values in a Technical Team

The book by Ken Blanchard and Michael O’Connor, ‘Managing By Values: How to Put Your Values into Action for Extraordinary Results’ came to our rescue. To follow its advice, we invited the whole Delivery Team consisting of developers, project managers, a QA engineer, and a UX/UI designer. We wanted every team member to help narrow down the specific values we stand for. 

Our company offsite (our team-building event) turned out to be an excellent opportunity to do so. 

During the workshop, we aimed to come up with three values that would become the core principles of the Delivery Team. The whole team was involved in choosing the values from the list of over 50 words that could become the core of our culture. 

Firstly, each person chose three values from the list. After a while, bigger and bigger teams were created to choose three values from the list they compiled.

In the last round, we had two large teams with six values to choose from. This led to a discussion on how we perceive corporate values, what is the most important when choosing them, and what their purpose will be in the future. 

As it turned out, the criteria by which these two teams chose the values varied. The values were similar but with different depth levels and side meanings. Eventually, we decided to proceed entirely with the values picked by one of the teams, as the workshop was over.

But it wasn’t the end.

Later that day, the workshop discussions didn't cease. Some of our colleagues felt they hadn’t had enough time to finish the debate, and they couldn’t fully agree with the established values.

The objective of the workshop was to pick the values we all share, and we hadn’t met it. Without a clear set of shared values, our team could easily become fragmented and struggle to work towards common goals. This could negatively impact employee engagement and decelerate business growth.

The second round was necessary. 

After a few weeks, during another company team-building event, we reviewed the six values again. We worked in groups, and we gave each team member enough time and space to express their views. By involving everyone in the decision-making process, we ensured that our values truly reflected our team's collective beliefs and aspirations. It also fostered a sense of ownership among team members, as they felt invested in the outcome.

By the end of the session, the Delivery Team successfully identified three values to serve as the core of our culture: Sustainability, Trust and Rightfulness.

Let’s dive into what these established values mean to us!

Sustainability

Sustainability is one of our main requirements when choosing the projects we will work on. We strive to deliver software that positively impacts the world and/or society. It's not just about environmental responsibility; it also encompasses the long-term viability of our team and the impact we have on our clients. 

By prioritizing sustainability, we ensure that our actions today contribute to a better future for everyone involved. We always opt for solutions that will lead to a successful outcome in the long run.

Trust

To collaborate successfully with our clients, trust is essential. We know that to earn their trust, we must communicate openly and transparently. We present all possible solutions and recommend the best one rather than the easiest. If the project assumptions, scope or timeline change, our client is immediately notified.

Rightfulness

No matter what we do, we always do it the right way. This involves considering the potential impact on users, society, and the environment, and making choices that align with ethical principles. 

Communicating and Living Our Team's Values

The intensity of the discussion regarding values has proven that we have gathered outstanding IT specialists with an ownership mentality. This means taking responsibility for what kind of company culture they will represent as the Delivery Team. The workshops have created a sense of unity and purpose among us, allowing us to work towards a common goal with shared enthusiasm and commitment. 

Now, after we have decided which values we want to follow, we can show them off both internally and externally. We do our best to make sure that the candidates in the recruitment process, new team members, and clients understand them and feel they can cherish them in their daily work by collaborating with us.

Sustainability, trust, and rightfulness are the core values that define us as a team. Sustainability guides us to make choices that have a positive impact on the environment and society. Trust is the foundation of our relationships within the team and with our clients, which enables open and constant communication. Rightfulness drives us to act ethically, ensuring fairness in all aspects of our work. These values serve as guiding principles for all business decisions we make, helping us focus on what truly matters!

Being a software developer, I created Rich Media Applications and Games in Adobe Flash technology for most of my life. As you can imagine, I felt safe in my position, focusing on what I knew best. As it turned out, I was soon to leave my comfort zone.

The reality hit me in July 2017 when I was a TechLead in a small GameDev company.

The game we were creating at that time was the biggest project I had ever worked on — an MMO RPG. I created it from scratch, so it almost felt like having a child and watching them grow up. I was deeply attached to the project.

We used many remarkable frameworks and libs, like Away3D, Starling, Feathers, and AS3 Signals. I felt thrilled creating Proof of Concepts and testing Away3D engine capabilities. 

The game is still available for desktop (Windows) — you can check it out here — but I can’t say the same about my involvement in the project.

So, what happened in July 2017?

Adobe deprecated Flash and announced its End-Of-Life (EOL) at the end of 2020, which meant they would cease support, distribution, and security updates for Flash Player.

It was devastating news — I invested over ten years of my life in that technology, and I was very good at it.

But then, it shouldn’t come as such a surprise. The apparent truth is that IT technologies are constantly changing and evolving. Learning is the bread and butter for every good programmer.

Still, this sudden change made me quit and stay jobless for six months. The first two I spent resting and thinking about what I wanted to do about my career. For the remaining four months, I learned 6 hours per day every day.

Today, I’m a backend developer at Evojam. I no longer make the mistake of preserving the status quo, but I keep growing.

And so should you, so let me show you how!

1. Make a choice: Technology

It is one of the most important steps, if not the most important, because it will strongly affect your future.

It’s also a perfect time to experiment. 

Pick the top 3 of your favourite technologies/programming languages and try them out. Don't be afraid to change your mind. 

Do you like frontend or backend more? 

Would you like to work on creating mobile apps or web apps? Or would you like to develop games? 

Do you like Linux and want to be a DevOps specialist and write Ansible scripts? 

Possibilities are abundant! Remember, however, that there are harder and easier topics. So, if you've never programmed, don’t start with a low-level language like C, as it requires a greater understanding of the processes handled by high-level languages under the hood, i.e. memory management. As a beginner, focus on learning the basics.

If you don't know the answers to the questions I asked above, just google it! Google the list of questions, too, if you need more help and inspiration. From now on, self-discovery and curiosity are your best friends.

When you check out all technologies you like, commit to one of them. If the choice is still hard for you, check the number of job offers on the market. More job offers will likely mean you'll need less effort to find a job in this technology later.

2. Don't be afraid to make mistakes: Mistake is the mother of motivation

Do you think you're great and don't have to study too much because you have extensive programming experience and will find a job right away? 

Do a reality check and go for an interview! The interviewers are very likely to throw cold water on your assumptions.

That’s how it worked for me. With my TechLead experience in game production, I believed I knew it all and would easily find a job in any GameDev company. I ended up going for an interview at a large GameDev company without much preparation. 

And guess what? I didn't get the job. I left the interview devastated. 

The person conducting the technical interview could have done a better job, too. They didn’t show any interest in my skills but focused on proving me wrong and trying to diminish my experience. 

I would call it a toxic conversation, yet I needed it at that point to understand the power of humility.

Making mistakes is a natural part of the learning process. I will remember this lesson for the rest of my life. At that moment, I understood how much work awaited me.

3. Own your story: Find a friend/mentor/tribe to talk about technology

Take a close look at your circle of friends and acquaintances. There must be someone with similar interests or even someone who is also learning new technology. Use this connection!

Awakening curiosity together and exchanging information work magic; it gives you more positive feelings and makes the learning process fun.

Not sure where to start? My tip is to be open about what you are doing at the moment and share it with your friends on various occasions.

One of my friends' partners happened to be a Java programmer who did what I was doing at that time a year before. We quickly connected and started to share articles, experiences, and valuable information. It was stimulating and motivating, and I no longer felt alone with my mission.

And all it took was a short conversation about my projects and goals.

4. Learn to learn

There are many tools you can use to learn. Find out what works best for you. 

Some people learn best by reading articles and books, and others like video courses. There is a lot of knowledge to find on Youtube in the form of tutorials, podcasts, and videos from conferences. And, of course, there is the famous Stack Overflow. 

We live in times when information is available like never before, so use it wisely!

My personal favourite is online courses.

When I was learning Java, I completed "Java Programming Masterclass" by Tim Buchalka and "Spring Framework 5: Beginner to Guru" by John Thompson. When I needed to learn Ansible, I used "Ansible for the Absolute Beginner - Hands-On - DevOps" and "Ansible Advanced - Hands-On - DevOps" by Mumshad Mannambeth. 

The cool thing about these sources is that they include exercises for you to do yourself and a community that, among others, consists of specialists who actively answer your questions. Focus on these two aspects while looking for a course on your topic. Practice is a crucial part of the learning process because programming combines knowledge and skill.

To acquire and sharpen my skill, I used code practice websites, which offer programming puzzles on every level. Another perk is that the ability to program on a website without an IDE is useful for some recruitment processes. Not to mention it's generally a good practice. If you don't care about live coding, you can use IDE and paste your solution. 

Find a website that suits your needs and matches your technology, or explore all of them. They are easy to find — just google "best code practice websites." 

Even such a simple website like CodingBat will be great if you want to learn the basics of Java or Python

5. Identify core skills you need

You can easily learn your entire life with so much knowledge, topics, and frameworks available. And you probably will!

Still, concentrate on several areas of expertise to protect yourself from information overload and maintain focus, at least at the beginning. 

Find out what you need to apply for the job you want. Do research, ask around, check job offers, and even ask interviewers!

When I started my adventure with Java, I quickly discovered that I also needed to learn the Spring framework. It was a revelation for me, but it has allowed me to advance my career.

6. Self-care: Mindset is the key to your inner power

Even though growth is strongly associated with education and experience, you won’t sustain it without proper self-care.

For this purpose, I developed a routine to go through every morning after brushing my teeth. It only takes about 20-30 minutes, depending primarily on how long you want to meditate.

Meditation

It’s scientifically proven that 12 minutes of meditation daily benefits your ability to focus and mental health.

If you’re a newbie or need guidance, try HeadSpace — an application with meditation programs. For absolute beginners, I recommend the "Basics" course, which starts with 5 minutes a day. When ready for the next step, find meditations designed to improve your focus or happiness.

Affirmation

Write down who you want to be, what you’d like to change in yourself, or what you want to continue doing. Structure the sentences to indicate you are already doing all the items. The list should include things that are possible to achieve. 

I know how hard it is to write it, so I am sharing my affirmation as an example:

I care for my sleep quality. 

I stay hydrated.

I only eat foods that are good for me.

My weight is dropping, which allows me to do new things.

I am slim and well-built.

I achieve everything I dream of because I work wisely.

I do and create; I am a creator.

I leave my comfort zone every day.

I’m the best at choosing valuable things, events, and people.

I provide value to others, which improves their lives.

Thinking positively, I attract positive people and experiences into my life.

I am confident in my abilities.

Programming is easy for me.

I am free from addiction.

I am a yogi. 

I am a runner.

I am a traveller.

I am a programmer.

I am an entrepreneur.

I am a podcaster. 

I am a leader.

I am a billionaire.

I am a musician.

I am a lover.

I am myself.

Visualisation

Imagine yourself in the near future after you reach your goal. Create an image of situations, people you meet, and things you achieve. Your new apartment or car, or whatever it is you need. 

Make your vision as detailed as you can. Feel the handshake of the new boss when you have just signed the employment contract. 

Write it down. You can go back to your visualisation notes every day and change them if you like. Use your imagination and be creative. 

Example:

I have a good job where I fulfil myself, and it allows me to do whatever I want.

I live in a big house with a garden.

I have completed a marathon.

Be grateful to yourself

Every morning, write down three victories from the previous day — significant achievements or small accomplishments, changed habits, research, completed course lessons, or even the fact that a new diet makes you feel good. It is personal and only for you. 

Example:

I read the next chapter of the book.

I ran 5km.

I finally started cooking.

All these techniques don’t take much time, but they completely change the mindset and help you stay motivated, positive, and relaxed.

7. Testing the waters: Be brave 

What I’m going to say might sound counterintuitive, but give it a chance.

Start looking for a job even before you finish your course or plan. 

It’s not as crazy as it seems! Here’s why:

• You need to learn the interview process itself. In time you will be better even as an interviewee. 

• You will not find work straight away. 

• Use every job interview as an opportunity to grow. Write down all questions you don't know the answer to. Ask for feedback. 

• Show that you are interested and fully committed to improving and learning. For many companies, your attitude, commitment, and ability to learn are more important than knowledge, especially in Junior level positions. 

8. The company of your dreams

Have you read the headline and immediately thought about a specific brand? If you could tell a company name off the top of your head, be patient, as it might be worth a wait. 

Go through some recruitment processes and gain some confidence. If you are confident already, well, then go for it. Apply for your dream job at your dream company. Like I said before — don't be afraid to make mistakes!

And if you need more tips at any stage of your career path to keep growing, feel free to contact me at kkalinowski@evojam.com. After all, I used to be you!

If you’re one of them, you know what I’m talking about — the problem with acquiring new talents.

We react to these changes primarily by investing in employer branding activities. Why? Because building a strong employer brand on the Internet is a perfect remedy for problems related to candidate attraction.

As long as you know how to do it, that is.

You’ve probably seen the most acknowledged EB campaigns and would love to make something as creative and spectacular. 

But then reality kicks in, and you realise your budget and time are too limited to prepare your magnum opus.

I can relate as an HR/EB Specialist who has been working for small companies. Employer branding is only a part of my responsibilities, and I can’t focus solely on it. To use my time wisely, I’ve developed certain practices to effectively show an employer brand online. 

As it turns out, you don’t need a big budget or a huge team to start with EB. Even small steps make a difference!

1. Strategy first

Do you know this feeling when you start a new project? All the excitement and novelty make you want to immediately put your ideas into action.

Hold your horses and make a plan first. Taking things slowly pays off in the longer run.

Consider why you (and your company!) want to engage in EB activities online on social media. 

What’s your goal? Do you want to fill open roles for junior candidates? Or maybe you want to raise brand awareness? 

Set a few objectives and choose relevant metrics to keep an eye on what’s working and what’s not. 

Think about your target audience. Who do you want to reach? 

Knowing that helps you choose the proper channels for your company’s presence. 

While TikTok is an excellent source for gen Z candidates looking for their first job, there might be better places to search for experienced managers.

2. Give your company a face

Whether it is your company website or a LinkedIn page, stock photos aren’t your best choice. They come as too polished, bland, and, most importantly — fake.

Instead, show photos of actual employees: during work at the office, at company events, or with company gadgets. You can also include the photos of recruiters and/or hiring managers in a post about a new job opening. 

3. Don’t focus on job offers only

Speaking of job openings, let’s make one thing clear — your company's social media profiles shouldn’t be full of open roles and ‘We’re hiring!’ posts. 

Posting about ongoing recruitment processes can be helpful, but it’s not enough to make your employer brand stronger or more attractive. 

No one enjoys a LinkedIn or Facebook page that looks like a job board, so make sure to diversify your content. 

4. Stay authentic

Authenticity is the key to every successful employer brand. Social media communication should align with your company’s EVP (employee value proposition). 

I’m lucky to have worked at places where EVP was already established, but if it’s not your case — I strongly encourage you to do it first. 

Many methods can be helpful; the most popular ones include focus interviews and surveys. 

If your colleagues come to the office in oversized hoodies and sweatpants, there’s no need to make them wear a shirt for a photoshoot. If the company doesn’t do anything to support diversity and inclusion in the workplace, don’t make a post stating they do. Stay up-to-date with what your competitors are doing, but don’t hop on every single trend. 

After all, you don’t need to attract the whole world — just a few candidates that fully match your company culture. 

5. Let the employees speak

This advice is slightly related to EVP. How can you know what makes your company unique and what makes people stay if you don’t talk to them? 

And how can you convince anyone that your company is a great place to work if you don’t give them any proof? 

Make sure to include employees’ testimonials in your social media strategy. By telling the real stories of real people, you’ll make your employer brand more relatable to the target audience. 

Maybe there’s a senior employee who’s been working at the company since they were an intern? Or maybe there are parents who spend more time with their kids thanks to remote work and/or flexible working hours? 

Such points tell a potential candidate much more than statistics and bulleted lists of the company benefits. 

6. Try different formats

What’s exciting about social media is that you can experiment with various types of content. Photos, graphics, videos, reels, blog posts… It’s impossible to get bored. 

Whenever I come up with a new content idea, I think about versatile ways to present it. 

For example, to promote our Evojam webinar “Make IT big at a small software company,” I created a few types of graphics [1, 2, 3] and made a few reels [1, 2]. 

Different formats also work well when reusing old content. 

Yes, you read that right — reusing old content is absolutely fine and even necessary. You’ll be able to post more frequently, reach new audiences, and boost your message. 

And let’s face it, you don’t have time to create new content from scratch every time.

7. It’s a team sport

Daria Siwka gave me many tips and inspirations at her workshop on strategic employer branding, one of which was that you can’t do EB alone. 

And it’s not only about engaging the employees. It’s also about you receiving enough support and time to conduct EB activities. 

I’m sorry to break it to you, but if the board doesn’t see the value of EB (even after you presented reliable data to prove how crucial it is), it is challenging to start with it and convince the employees to be brand advocates. 

In this case, my advice is to keep trying, keep bringing this topic up, and not get discouraged. 

Staying on the topic of the board and top executives, they strongly impact the work culture. 

Internal EB comes before external EB. The employees won’t be keen on becoming the face of your employer brand if they feel unsafe and underappreciated at work or suffer from burnout. 

It doesn’t sound like engaging social media content, does it?  

But let’s leave these pessimistic scenarios behind. 

Without any doubt, the support of executives is helpful, especially at the beginning when you’re still learning and experimenting. If your organisation has a marketing team, it’s even better, as their support can be a real game-changer. 

Marketers know how to promote and sell services or products to customers, so why not learn from them? You want to promote your employer brand to potential candidates through employer branding activities on social media. 

Great things can happen when mixing marketers’ knowledge and experience with your understanding of the job market and EVP! 

That's why at Evojam, the People & Culture team works closely with the Head of Marketing.

8. Keep an open mind

Social media is a highly dynamic environment. 

New trends are born daily, and platforms compete by constantly introducing updates and adding new features. Something that works now might not work in a year.

Follow social media experts — for example, Dagmara Pakulska — who share the latest news from this field to stay in the loop. Be open to inspiration and adjust your strategy accordingly.

Also, don’t be afraid of experimenting. Some posts will flop, and that’s unavoidable, especially if you’re new to the game. 

Don’t beat yourself up over mistakes; remember that you don’t become a pro overnight. 

As you understand by now, starting with employer branding activities online isn’t so scary and intimidating. You don’t need much money or time to prepare exciting and authentic content. 

So, put yourself out there, and, who knows, maybe after a while, you’ll become a fan of EB just like me!

For such an important topic, it's underresearched and misunderstood, as my experience has shown me. Having joined a small software development company — Evojam — I could observe it directly.

It all started with feedback.

At Evojam, you get feedback from your colleagues every quarter. The first time I participated in this process, I felt nervous. What will they say about my work? How will they rate it?

My worries were completely unnecessary. My teammates were enthusiastic about my accomplishments and satisfied with my contribution. If it were a test, I would pass it with flying colours. Phew!

What struck me was the number of questions as to how they could support me in my daily tasks. To give you a general context, I'm the only QA engineer at the company, and some of my teammates haven't had a chance to work with QA testers before.

No wonder they were confused and expected some guidance. I'm sure they're not the only ones.

If you feel like you could be an author of such a question, this article is for you!

The artificial division between software developers and QA engineers

Let's start with something basic — the role of QA teams. It's not as evident as it seems, and some companies tend to diminish it.

According to some people, QA engineers and testers:

• just click around;

• are not technical;

• find edge cases and bother software developers with fluff; and

• don't have an important role, as only programmers write code.

There's a tiny grain of truth there — only programmers write code. But this code often doesn't come without defects, which affects the client and end user. So it's better for the internal team to spot them beforehand, right? After all, our goal is to deliver software of the highest possible quality in the allotted time.

If we don't detect them, we might even lose a customer.

Now, I don't mean to dismiss any negative experience you might have had. In your career, you could meet a QA engineer or tester who has:

• reported as many tickets in Jira as possible,

• reached out to you without checking the documentation first,

• not inquired about the reason the error occurred, and

• pushed tasks on different people to keep an unblemished reputation.

If you can relate to this description, your negative opinion is more than justified. Still, skilled QA engineers don't work like that, and this list isn't a rule.

On the contrary, it applies to the minority!

How to improve the testing process as a developer

So, you implement new functionality, add a new collection to the database, and hand it over for testing. It is a perfect opportunity to improve collaboration with the QA team and product quality.

During a handover, point out to QA engineers and testers where to pay special attention. Consider:

• whether the correct values are set in the DB;

• how to manipulate them; and

• what is the desired effect, and what is not.

Not much work on the software developer's side, but it makes much difference.

I appreciate such gestures as they prove that the task team realises bugs happen and won't settle for low-quality code.

If it hasn't been standard practice at your company, introduce it. It only requires one developer to hop on a call with QA engineers and show how each point works.

If there's no time for such a meeting, record a simple DEMO.

Both actions increase the quality of tests and the chance of the functionality working correctly. And if there are ever any regression-related bugs, QA engineers and testers should be able to identify where the error lies more quickly.

Win-win, right? And there are more easy wins that rely on developers' goodwill. Let's explore them together!

When stuck in the middle of working on a new feature, call a tester

And when you do so, start the conversation with what you've done so far.

Simple discussion and articulating the problem can show you what you need to add or improve. Talking it through, you can add test cases to cover possible paths.

This way, QA engineers and developers work together to ensure the functionality does precisely what it's meant to, and regression-related bugs can be caught already at the unit/integration testing stage.

An added benefit is the detection of a bug at an early stage, which translates into a much less costly fix.

I'm a big fan of such calls because we get a chance to solve issues together and build our working relationships.

The bug's title alone might not be enough

As a QA engineer, you receive a testing task. The title doesn't say much; the description is just white space characters. The best part is that even the reporting person often forgets what they meant. What to do with such a bug report?

At this point, not much. But we can avoid these situations altogether.

Here's how:

• Report the ticket correctly.

• Attach a screenshot or, even better, a video showing how to reproduce the bug.

Only two steps and they will make everybody's job easier.

Say goodbye to tasks with technical descriptions only

Somewhere in the development cycle, it turns out that developers need to add something and spend extra time doing so. In response, they create a technical task on the fly. Then the development team adds new lines of code, moves the task on the board, and submits it for QA testing. QA engineers read it and... understand nothing!

To start testing, they need to get rid of confusion, though. So, they ask the person responsible for the task what it's about.

"Oh, it doesn't matter; you don't have to test it!"

I think it's worth fighting in this case to get an answer. One of the most important lessons QA teams can get is a deep dive into what's underneath the app.

So, spend some time explaining what you've done and how it's affected the application's performance. It's an additional step towards improving quality, even if it doesn't feel so at the time!

Take these steps before moving the task to the "for testing" status

1. Ensure that all Acceptance Criteria (AC) have been implemented.
   Seemingly obvious, but it can slip your mind.

2. During Code Review, pay attention to the solution.
   In the current project, developers also test the solution their teammates implemented. Sometimes, they write that some functionalities don't work in some instances. It takes the pressure off the QA team as they know their co-workers focus on the outcome and care about the quality, too.

3. Verify design compliance.
   If some changes have been introduced and approved by commercial stakeholders during the development process, write them down in the task. We often wonder why something is different from the initial design, and suddenly no one remembers the reason for alternations.

4. Add a PullRequest link to the task.
   When time allows, we visit the linked pages, review the post-written tests, and try to find instances that aren't covered. I run my tests, look at PR, check the paths, and focus on cases I haven't managed to test. This way, I can spot the bugs and fix them with developers before passing them on to the client.

5. Check whether the code deployed to the environment is complete.
   On a daily meeting, somebody decides to hand over a new module for tests, which requires adding new values to the form. Developers deploy code to the testing environment and inform QA engineers they can start their tests. After all, checks have turned green on CI/CD.
   In the meantime, the tester finishes the remaining tests, which takes longer than anticipated. It's 3 pm. The tester completes the backlog and starts testing a new module.
   He clicks "add new values to the form," fills in the inputs, clicks the "save" button and... nothing happens. The change is not visible.
   "Well, okay, maybe if I refresh the page, the data will appear," hopes the tester.
   Not a chance.
   A glance at DevTools and everything becomes clear — no request goes through. He looks at his watch, and it's already 3:30 pm.
   He immediately sends a message to the team, informing other members that the module doesn't work as it should. Here comes the eagerly awaited response:
   "Philip was doing a deploy, and he works until 3 p.m. He'll check it tomorrow."
   Theoretically, the tester has 1.5 hours of work left, which is ok — he'll find something else to work on. 

The worst-case scenario is when the teams work in different time zones.
The moral of the story? It's better to check whether all the necessary code has been deployed correctly to the environment!

The takeaway points

What I’ve told you today might seem obvious. And I hope, one day, it will indeed be for all developers out there! 

As a QA engineer, I ask you to write comprehensive descriptions for each task. 

I also encourage all QA engineers and developers to start working closely together. It will be beneficial to both parties. QA engineers will understand better how the application works and be able to test it more thoroughly. Having understood how testers think, developers will be able to write more resilient code.

And the outcome for the whole development team? It’s a higher quality of the delivered code and software product, which is what we all care about the most!

I was pretty surprised when I heard that. While working at Evojam, I got used to everyone having a keep-growing mindset, and I forgot not the whole world is like that.

I’ve decided to write this article to help you switch from your way of thinking to a more growth-oriented mindset. And the change is only six steps away!

1. Value process above gains

There are lyrics of a Japanese song, “壁は高ければ高い程乗り越える意味があるから," which translates to “the higher the wall, the more meaning there is in climbing over it.” When I heard this sentence, I realised it perfectly describes my mindset.

So, let’s see how to climb over a high wall.

What’s more satisfying — doing one push-up or doing one hundred push-ups? Obviously, the latter. But to get there, you first need to be able to do one, then two, then three, and so on. It’s a process; each step is as important as the others, and they’re all connected, so you can’t omit them and fast-forward to the end.

The important part is not to focus on the gains but on the process itself. Just like watching a growing plant — if you keep staring, you’ll feel like nothing is happening, but if you come back in a week, you’ll notice the progress.

2. Collect and utilise feedback

Think about what learning is, just following the steps of someone who figured out something before. That’s why the key to growth is feedback. At Evojam, we take feedback very seriously, and you get direct feedback from colleagues you work with every three months.

Sometimes you need someone else's view because if you look in one direction, you won’t see the others. Getting different perspectives makes you notice things you might have missed. It seems obvious, but learning from feedback is a skill in itself. We often think we are doing something right, and being confronted makes us defensive; that’s how our brains work. It’s essential to overcome that mechanism and learn from others.

Some people have learned the same thing you’re learning; they’ve probably made the same mistakes, so use their knowledge. It’ll push you further.

3. Be bold and take action  

Not even trying means you have already lost. 

Don’t be afraid of taking action and doing something new. No one has ever achieved anything by doing nothing. Step out of your comfort zone, take risks, and make mistakes.

I’ve made many mistakes, but they only strengthened me because I did my best to learn from them. Again, feedback played a vital role here — I often didn’t know I was doing something wrong until somebody pinpointed it.

You can read about my journey in my other article, “How to stop overthinking and start working towards your goals.”

4. Appreciate yourself and get validation

Celebrate what you’ve accomplished and share your progress, regardless of its significance.

Look for people who want to see you succeed. A positive environment helps you move forward faster, and that’s why I love Evojam’s culture. My coworkers keep telling me, “You did a good job; keep it up!” It’s a no-brainer that such words feel good and motivate you.

Many plants only flourish in specific conditions and wither in others. Humans are no different in this aspect, so cut toxic people out of your life and surround yourself with those who think alike.

5. Stop comparing yourself to others

Don’t compare yourself to others. Just don’t. Everyone is different, and everyone is given different opportunities. Social privilege, anyone? No life is the same. 

Even if it took you longer to achieve your goals, it doesn’t matter — it’s not a race. Just keep moving forward; the speed is irrelevant.

6. Enjoy yourself

If there’s only one point you’ll remember from my article, let it be to have fun. 

You only have one life, and doing something you hate isn’t worth it. If you want to try something new and, for example, switch careers — go for it! The sky is the limit, and you can even become a software developer without a degree.

Society makes us choose our path very early in life when we’re not ready yet, so it’s perfectly fine if it takes you years to figure out what you enjoy. Finding this area is already an essential step in your growth. 

Don’t get stuck in a sunk-cost trap — it doesn't matter how much time you’ve invested in something; if you no longer like it, move on!

Work environment matters. When you end up in a company that promotes a different working style than your native one, you'll suffer. You won't feel like you belong, you won't develop yourself, and it's just a step away from burnout and frustration.

Why condemn yourself to eight hours of deep unhappiness a day?

Let's leave this dramatic picture behind and discuss your career options.

As a software developer, you face a dilemma about whether to work for a software development company or a product company. It's something to think through, so take some time to do so.

But today, focus on a different question — should I work for a big corporation or a small boutique company with less than 50 employees?

A small company is like a tribe

Scientific evidence shows that a human can comfortably maintain stable social relationships with no more than 150 people. It’s called Dunbar’s number, in the name of a British anthropologist Robin Dunbar. 

Yes, there’s a limited number of people you can comfortably maintain regular contact with. We don’t know for sure, but it might be related to early humans forming tribes or groups of about 150 people.

A small software company is like a tribe or a village. All employees have an opportunity to meet and get to know each other well. You learn very quickly what to expect from each colleague, and you know their preferences and favourite topics of conversation.

It means that you’re not just another face in the crowd.

For many people, it can be very motivating because your engagement in work is more likely to be seen and acknowledged. Closer relationships with coworkers can also mean firmer mutual support.

With high visibility comes high ownership

If you prefer to hide in a big team, where at least a few people have the same skills as you, a small company might not be the best fit. 

You know how it is — the bigger a company, the broader its resources. There are more opportunities to gain knowledge from someone specialising in a different field than you. Stumbling upon a particular problem might not be that challenging when there are more colleagues to help.

But if your main goal is to grow quickly and learn to take ownership of your tasks, you will thrive in a small software development company. Smaller teams often require learning different aspects of software development. 

If you aim to become a full-stack developer or learn CI/CD, even if you’ve previously specialised in React, a small software company is your go-to place! 

Based on my experience, it’s also less possible to over-engineer solutions with smaller-scale projects.

In a small company, there is a high chance that somebody will notice and appreciate your efforts. You can be more engaged in your work and have a considerable impact on the company that you’re working for.

Small scale, enormous possibilities

If you have any experience working for big corporations, you’re probably familiar with slow processes. You just wanted to replace your broken mouse, yet you needed a million approvals for that!

Small companies are usually more flexible — they have less inertia and adapt quickly to changing external conditions. But at the same time, it can create organisational chaos.

As I mentioned, working for a small team requires wearing different hats. Not only can you quickly jump between technologies, but it's also easier to try yourself in a very different role, e.g. as a tech recruiter or a content writer. It can pave the way for a quicker promotion, which doesn’t usually require multiple steps and approvals from senior managers and other executives.

So, how does it all sound? Do you tingle with excitement or fear?

If a small software company seems to be a good fit for you, why not join Evojam?

The environment, excited about such a turn of events, started celebrating… with a trace of cautiousness.

My reaction was less favourable, to put it politely. I felt like Grouchy Smurf, muttering, “I hate JavaScript types!” I decided to let my grouchy side speak for a little longer, hence this light-hearted blog post.

In the following paragraphs, I’ll share my concerns about upcoming changes and explain why I don’t see them through rose-tinted glasses.

Take it with a grain of salt, and let me know how you feel about JavaScript types!

Eagerly awaited

As underlined by the proposal's authors, there's no denying that typing has been one of JavaScript’s most anticipated features.

There are even charts confirming this trend in the documentation of the new functionality. Considering the reliability of the State of JavaScript report, the results are impressive.

It’s comforting that Pattern Matching, which I’ve also recently described, is the third item on the list, just behind the introduction of Standard Library. Yet, static typing dominates both positions, outperforming the competition by 800 points.

Well, it’s not unusual that sometimes we want something that’s not truly needed.

No wonder someone has finally addressed the problem. And it wasn’t some random crowd but the people who knew the topic perfectly. After all, they’ve been working on TypeScript — a superset that gives excellent possibilities to a relatively simple language, JavaScript.

While giving another language superpowers with an additional compiler is practical and fun to implement, making such changes to an existing language — one with a past — is a different story.

And the implementation part is what I mainly have on my mind.

Currently, TypeScript is a solution that some apply while others don’t. These various approaches are a bone of contention in the environment as projects without TypeScript tend to be immediately considered legacy.

The idea of introducing types emerged to turn this ugly duckling into a swan and clear up the problem. Everybody would write type-strong applications and refactor them instead of endlessly rewriting them.

Of course, nobody treats it seriously. This industry is all about rewriting applications.

The end of TypeScript as we know it?

The very example of how the idea of types was proposed shows what the process might look like in the future — a petition, four photos, a registration journal, coming into force, five meetings, four stages, and it’s done! After half a year, we finally have a new, generic Omit for correct typing.

It doesn’t sound appealing, does it?

Comparing this with the TypeScript release cycle, where we get new versions with fixes or functionalities every few weeks, it even looks disturbing.

TypeScript is a library, and this is how we can treat it, even despite its specificity. We decide which version to use when we add it to a project. If we’re not ready for some solutions, we can stick to an older version with guaranteed compatibility.

What will it be like when TC39 controls the development centrally? Someone will have to let go, and it will probably be JavaScript that will bet on backward compatibility, which is hardly a catalyst for growth.

I haven’t found any explicit declarations that the introduction of static typing would end the development of TypeScript. Yet, Microsoft's people responsible for TypeScript are the primary originators, so their priorities may quickly change.

Naturally, one technology will compete with the other, reaching a deadlock, and we can imagine how they resolve it in the long run.

Is there anything to wait for? 

Now, this is my greatest fear — is it worth it?

I don’t see any significant benefit of having static typing in JavaScript. At least not in this form.

It’s worth noting that type annotations will be checked while the application is built, but they’ll be treated as comments when the application is in a runtime environment.

Functionalities known from TypeScript that affect the JavaScript code, i.e. enums, won’t be presented in the first iteration of the proposition — precisely because of their “commentary” type.

There’s more. 

The type-checker will be “external to JavaScript.” It won’t be a part of the interpreter but… a superset?

As you can see, there are many uncertainties. You may get the impression that the main goal of this proposal is to standardise tools such as TypeScript or Flow. Is this really what respondents of the State of JavaScripts survey voted for?

Static typing in runtime, which could solve IO data uncertainty problems and consequently replace libraries like io-ts, would be the game-changer we want. 

Instead, we get a slightly more extensive syntax, similar to TypeScript, checked by an external type-checker like… TypeScript.

We’re not doomed to fail

Despite everything I’ve written so far, I keep my fingers crossed for the creators of this proposal. I hope they develop a model that will meet the community's expectations.

Static typing is indeed what JavaScript needs, and the massive popularity of TypeScript proves it. Still, if we want to reach a satisfactory level, we’ll have to undergo a series of iterations that won’t seemingly bring much value and will only be the basis for further changes.

The topic of typing isn’t new. In the specification of the never-published EcmaScript 4, there were related provisions. They were to depart from the existing JavaScript and introduce a new order without backward compatibility.

At the time, in 2008, people feared it would be too big a breakthrough, but we know now that it was actually a missed opportunity.

These days, there’s nothing else to do but to make up for the wasted years by trying to fill the gap.

This article has been translated from Polish with the consent and cooperation of the author. You can find the original text on Robert's blog: rduraj.dev.

It started even before the pandemic — on the days when I was working from home, that person never even tried to ring the bell. They always go straight to my postbox with a notice. I have often wondered why I must pick up my letter or package from the post office. Something isn’t working here.

As an engineer, you get into a habit of trying to understand a given problem and coming up with a solution. 

And so, I suspect that this is a systemic failure. Maybe they have too many packages to deliver daily, and carrying them around is impossible. So they leave the parcels in the car and only hand out notices by default.

Either way, there's much to learn from the flawed processes and broken things. 

As children, many of us would crack broken electronics open to see what was inside. 

The same applies to the most remarkable scientific endeavours, like studying the human mind.

Things that stop working correctly are like cracks in otherwise impenetrable monoliths. They let us peek inside. The only thing to say in the beginning is, “Oh, that's interesting.” But if we keep digging and look beyond the obvious, we may learn something new.

Karl Deisseroth presents this idea in his book “Projections.” See this passage about genetic mutations:

Biologists speak of genetic mutations that are "loss of function" or "gain of function" – this means that a change has happened, a mutation that turns the function of the gene up or down. These mutations help reveal what the gene is for.

But let’s leave genetic mutations to biologists and return to undelivered mail.

I’ve analysed the figure of the postman, but there is also something about the notice itself that I found interesting:

Monday 12:00-20:00

Tuesday 12:00-20:00

Wednesday 12:00-20:00

Thursday 12:00-20:00

Friday 12:00-20:00

Saturday 00:00-00:00

Sunday 00:00-00:00

The weekend opening hours caught my attention immediately. Is the office open throughout the weekend? Or is it closed? Is it the same for both Saturday and Sunday?

In my daily work, I do a lot of data modelling; hence I went straight to guessing what technology was used to store the data and how it was modelled. Seeing something not working brings much more value if you know how it's made.

The first implementation in Kotlin that came to my mind looks like this:

data class OpeningHours {
	val officeId: Int,
	val day: Int,
	val start: Int,
	val end: Int,
}

The last two fields – start and end – are not nullable, meaning they need to have a value. To satisfy this condition, someone might have needed to put zeroes there.

But at the same time, it's the same exercise as looking at a puddle of water and guessing the shape of an ice cube that melted:

As developers, we have access to many tools to study the system. HTTP 500 error pages in the browser often include error messages easily deciphered by any of the system's authors. Even more informative are the stack traces:

They look ugly, but they're our favourite thing, showing almost all the necessary details.

Some ideas are not apparent mistakes until we try to implement them. You need to put everything to the test.

While talking to Lex, Rick Rubin, the legendary music producer, describes one of the rules that work well for him while working with bands. And he has quite an experience — he's worked with Beastie Boys, Red Hot Chili Peppers, Johnny Cash, Jay-Z, Adele, Kanye West, and many others. 

The rule says that no idea gets rejected until it's tested. You're not allowed to say no until you hear it. Only then can everyone see how it turns out and discuss it further to decide if it's worth pursuing.

I imagine that with music and the world's most accomplished musicians giving an idea a go is not very costly. 

Creating software and writing working code means crazy costs. But there are shortcuts to verification that we can take. We can visualise what we mean with ad hoc drawings, stickies even. Whatever it is, it needs to facilitate communication. Otherwise, if we describe an idea in our own words and someone confirms they understand, what makes us think they fully understood? Or rather that their understanding is anywhere close to ours?

Coming back to Karl Deisseroth's book “Projections,” there is another passage about people's personal stories revealing biological truths:

Just as when a fabric frays, its hidden structural threads can be revealed (or when a bit of DNA mutates, the original functions of the damaged gene can be inferred), the broken describe the unbroken – and so each story underscores how the hidden inner experiences of healthy human beings, and perhaps of a doctor as well, might be revealed by the even more cryptic and shadowed experiences of psychiatric patients.

That happens in almost every book and movie you've ever seen. You meet the protagonist under certain circumstances. Then the situation changes, and they need to adjust. In the end, we see a completely different person. 

Try to notice what the main character is like in the first scenes. Chances are that the journey ahead of them is all about changing the most striking character traits.

My favourite example of misalignment between a character and her new life situation is Ann Hathaway's Rebekah Neumann in “We Crashed.” Just like her husband, she doesn't change much throughout the mini-series. 

I enjoyed seeing her in action for different reasons. She's a self-proclaimed Student of life for life (SOLFL, pronounced soulful), taking inspiration from Eastern spiritual traditions. But is she? 

To me, the most comic moments are all the times her ego takes control. She weaves her power and brings misery onto anyone who questions her. The camera helps us see the rage in her eyes, a hint that there's yet another absurd harm coming someone's way. And she doesn't learn. She doesn't change one bit. You could say she remains true to herself! 

The story of WeWork's sudden rise and unavoidable crush shows that the naive adoption of thousands of years old Easter tradition into slogans like elevating the world's consciousness is not the way to go. Good thing someone else has tried, and now we know how it’s turned out.

I still don't know what to do about the postman. They told me I could file a complaint, but they outsource deliveries, so it's unlikely to have any effect. It must be one of the things we can't influence. I also have no idea what exactly should be changed. I can't let my ego get the better side of me, but accept it as a constraint. No negative reaction. 

Would I have to sell the apartment? Let it be.

Like with most questions, your first instinct might be to look for help in a search engine. The internet is full of people selling courses, books, and other resources, promising a fast way to get spectacular results. 

I'm sorry to disappoint you; there is no easy, speedy path. 

In this article, I'll share my story and what worries and misconceptions I had before I started my software development journey to support you on your bumpy ride. Let my experience work as your buffer.

My formal education ended after high school. I tried attending university but was not too fond of it and felt it wasn't for me. I didn't know what I wanted to do with my career for a long time. 

Eventually, in February 2021, I decided I wanted to try coding. The reason was quite simple — the market has shifted to remote work. I live in a small town, and moving out wasn't an option, so being able to work from home was a requirement. 

I didn't know anything about coding. I only knew some buzzwords, but I didn't truly understand them. For example, I thought scrum was something related to pigs. In Polish, the onomatopoeic word for the sound pigs make is "chrum," which looks similar to "scrum." Hence I imagined a scrum master to be a guy with a lasso chasing pigs and leading them back to their enclosure. I thought Java and JavaScript were the same things. So as you see, I was utterly clueless.

Many say there's no point in entering the IT industry without a computer science degree. Still, I was determined to do so anyway. 

I was interested in web development because I read that it's the most in-demand programming career path. I asked my friend, who works as a web developer, to give me a roadmap of what I need to learn to become one. The roadmap looked roughly like this:

1. Learn JavaScript. Learn HTML and the most important CSS concepts. Start slowly adding TypeScript.

2. Learn Git basics.

3. Learn how to make a REST API in Node.js and connect it to a MongoDB database.

4. Learn React.

My first question was, "What if the market changes and all the stuff I learned is no longer in demand?" 

My friend answered, "It doesn't matter; once you learn a programming language and web development concepts, you'll be able to apply them in other languages using different tools." 

At first, I didn't believe it, and I spent way too much time worrying about which tech stack to pick.

Having made up my mind, I started studying. I used primarily free materials I could find on the internet and bought some cheap courses — Udemy is excellent for this, but make sure to always purchase on sale. The only course I fully finished was a JavaScript one. Why? I'd drop a course as soon as I learned the basics and simply start coding. 

That brings me to the best advice I can give a rookie — code a lot. 

Try not to use too many libraries in your projects; code as much as you can on your own. 

Reinventing the wheel isn't usually a good idea. However, you're still learning, and figuring things out yourself is a perfect way to learn.

My best learning experience wasn't actually a web dev project, although related, but a Discord — chat application — bot. The bot fetches data from a fanpage about a game I used to play and displays it in the chat.

Initially, I scrapped all the data, but it got pretty tedious, and any small change would break my code. I contacted the fansite admin and asked whether there was any API I could use. It turned out that there was an API, but it wasn't documented. The admin was very kind and listed all the endpoints for me, and as the project grew, I asked him to add more endpoints. I even found some bugs and logical errors and helped fix them. 

This experience has taught me a lot about communication with other devs.

I didn't know whether recruiters checked your GitHub, but I had to put something on my CV, so listing my personal projects seemed like a good idea. I chose frontend-oriented projects for the rest of my projects because it's easier to show off your work this way. 

Then, I spent some time solving challenges on HackerRank to prepare for technical interviews. 

For a long time, I was worried that my code wasn't "real code," which made me anxious about applying for jobs. Eventually, after a conversation with my friend, I decided to start applying to prove to her that I wasn't ready and good enough yet. And then I got a job. 

Another misconception I had was that you constantly create new concepts and develop innovations as a programmer. When I started working, I realized that you mainly apply existing concepts to the requirements. If you ever need to come up with something new, you have your team to back you up, and you won't be alone in it.

By now, you might think it's an easy path after all, but keep in mind that I still had to spend over a thousand hours studying. It wasn't always fun; I was often frustrated when I couldn't figure something out and couldn't find helpful answers on Google. So I took breaks, and usually, after resting for a bit, solutions would pop up in my head. 

So, how do you start an IT career without formal education? 

In a nutshell:

• Code a lot.

• Be curious.

• Don't worry about choosing "the right" technology.

• Remember that you don't need to be a genius to work as a programmer.

• Don't give up!

After graduating high school, I didn’t consider applying to any science majors, as I perceived them as incomprehensible and out of my reach. Computer Science was one of those majors hidden behind a wall I thought I couldn’t pass through.

That’s why I decided to go in a different direction — I chose an International Relations major with a specialisation focused on South-East Asia. I travelled a lot, learned Chinese, and had a lot of fun, but I didn’t know what career path I should follow after.

After some research and thought, I decided to apply for MA in Computer Science. It was a bold move — I was afraid I couldn’t make it, but I wanted to challenge myself and see if I found it fascinating.

I did, and I quickly landed my first job as a frontend developer. I was constantly learning more and more, and I soon graduated and found myself where I am now.

So, did my unscientific mind cause me any problems on the way?

I wouldn’t say it did, and it probably wouldn’t for you.

I want to share my observations and conclusions to make you feel more confident about your skills and possible profession and not hesitate to fulfil your dreams.

Does maths matter?

At the beginning of my journey, while still learning the basics, I came across many comments and articles about how maths is essential for a good developer.

I was pretty determined, so I didn’t take them too seriously, which was a great approach.

A software developer is quite a broad term — you can create webpages or mobile apps, work on server-side programs, take care of deployment, or engage yourself in machine learning. There are plenty of activities, and each requires a different skill set. 

And while you most certainly will have to deal with maths while working on Artificial Intelligence or algorithms, you’ll probably never need it while building a website or creating a backend for your microservice.

Also, soft skills are way more important for a software developer than advanced maths. After all, the work of a software developer comes down to accurately interpreting clients' business needs and turning them into a working code.

Maths is handy but not essential

Recently, I stumbled upon a remarkable piece of code, and all it did was animate a spinning doughnut made of ASCII characters; you can check it out here. It serves as an example of what you can do with your mathematical knowledge, and it gave me an impulse to write this article.

You’d have all the right to call me a liar if I told you that maths wasn’t useful for a programmer at all.

You can do some fantastic stuff with mathematical knowledge, and the more concepts you know, the more creative things you can come up with.

In most fields, you won’t need maths daily, but there is a 1% chance of facing a problem that requires some maths concepts to be solved. 

Some fields, though — like AI, cryptography, or graphic design in the game industry — can only be mastered with advanced maths. You must push yourself and start learning if you want to dive deep into it.

Challenge yourself

Ok, what if you wanted to try something that requires daily maths?

I discovered that learning new things outside the field of subjects you’re most comfortable with can be a suicide mission, but it’s also a great challenge you can benefit from.

During my studies, machine learning caught my interest. Although it required some advanced mathematical knowledge, I went for the AI specialisation and wrote my thesis about it. In the end, I wasn’t eager to continue that path, but I don’t regret choosing it as I learned a lot.

If you thought you would like to try, say, AI, don’t be afraid and don’t overthink it. Many things may scare you, but you need to get it going and try your best. Even if, in the end, it turns out the path you chose is not for you, the experience will make you grow. 

Don’t hesitate to go for it even if you have to touch a little maths on the way.

The bottom line

The idea behind this article was to encourage people with no scientific mind and who are afraid of advanced maths to try their hand at software development.

Maths is a perk, an added value, not a necessity. You can do plenty of stuff without it and quite a lot with some basic knowledge. Only a fraction of activities in the IT field will require a lot of maths daily.

The worst thing you can do is to read comments on the internet about how difficult it is to be a software developer or how only scientific minds can succeed in this area.

Do things your own way, and remember you can achieve everything with the right attitude and an open mind.

“Speed is irrelevant if you are going in the wrong direction.”

Mahatma Gandhi once said those words, and they’re painfully true — no matter how fast you're progressing, you will not reach your destination if you're not going in the right direction.

The same rule applies to the software development process.

You’re part of the best technically skilled development team globally, and you could create the software at blazing speed. Still, suppose the increments you’re building aren’t in line with the customer’s needs and expectations. In that case, no development speed will justify the direction misalignment.

What can cause the misalignment between the customer's needs and expectations and how the development progresses?

The list of possible causes is endless — starting from the customer not being able to explain their goal clearly and ending with team members creating false assumptions and thinking they know the customer's needs.

They all produce the same result — a lack of understanding on the development team’s side.

And, newsflash, there's virtually no chance to build a successful product without a proper understanding of customers’ or end-users' needs. This understanding is the "direction" in which we should progress.

So, let's try to ask ourselves the following question:

“Are we always sure we're going in the right direction? Do we always know the destination?”

This question is crucial for both the project manager and the tech team. Actually, it applies to any role involved in software creation. 

How can we build a valuable piece of software without understanding who will use it and for what purpose? 

The majority of project failures in the software industry stem from the lack of such understanding. All assumptions made during the project planning, no matter how complex and insightful they are, mean nothing as long as you don’t confront them with the actual end-user needs.

How can you ensure that you understand the direction?

Now, this is the question. Answer it to know whether the work you perform is what the customer needs and expects. 

If I said to you, “Use the green colour to paint this room,” what would you do? 

Are you sure that I want every wall to be green? Or maybe some of the walls? Perhaps you should only paint them green to a specific height?

If you’re unsure about the exact requirements, you won’t bring value to the end-user even if you do your absolute best.

Not to worry, though. Many techniques help establish the customer’s needs and find the right direction in the development process. They work as a compass in your journey through the project.

These methods aren’t necessarily complicated — sometimes, a simple question can prevent you from wasting time.

The power of “why” and “what for”

At the beginning of any project, your go-to question is, “Why does the customer want this piece of software to be built?”

The answer may surprise you in many cases.

Commonly, the real cause is very different from what seems to be on the surface. When you ask this question, the customer might also start looking at the purpose of the functionality differently.

The reason changes the optics and perspective from which you will look at the functionalities you are implementing. 

So don’t be shy or afraid to ask this question to either your manager or the customer when you have such an occasion. 

It may be the most critical question you ask throughout the whole project lifecycle.

Other techniques

You may need more than a simple question to get to the bottom of things. That’s when other techniques come in handy.

Consider using:

• event storming,

• user story mapping,

• persona mapping, or

• a combination of a few.

They differ in terms of the use case, but they will all bring you to the same point —  understanding the direction you should go.

Once you know that everything, or most of it, is in your hands, it’s a matter of adjusting the speed.

What are the benefits of a team that understands the customer’s needs?

What would you choose from the project management standpoint — having a highly skilled team without a clear sense of direction or a less experienced one but with a strong understanding of the customer’s needs?

The votes might be fifty-fifty, and it’s unfortunate.

Mind that there’s no guarantee that the skills will compensate for the lack of understanding of the purpose.

As a project manager, I know that ensuring that my team knows the purpose of their work is my main job. 

Once your team gets the direction, you’ll enjoy substantial benefits, such as:

• higher performance,

• less technical debt, and

• exceptional ability to innovate.

All you need to get there is to answer the question, “Does my team know the direction they should head in?” with a solid yes!

What can you do to make your team understand business goals?

Often, the team will need your help to find the right direction; it goes without saying. But don’t feel burdened by this! 

You don’t have to know the answer to this question upfront. 

In many cases, finding this answer is the most challenging and critical part of the project, and that’s why we have the tools for that! 

Some of them I’ve mentioned in the “other techniques” section, but the list isn’t limited only to those.

Identify the layer that contains the answer you’re looking for and adjust the technique, or a combination of techniques, to extract the information you’re striving to find! 

Once you succeed in that step, you’re ready to guide your team through the journey — both in the right direction and at relevant speed!

A couple of months before, I got into a creative writing course with an idea I wanted to develop. Writing has always been my passion, and it was an excellent opportunity to go through the process of creating an entire story from beginning to end.

Apart from giving me support in writing, the course influenced my life in many surprising ways — I met friends who share the same passion, and working on a book has turned out to help me grow professionally.

So, what are the three areas in which creative writing has helped me become a better software developer?

Motivation

Writing a book is not a cakewalk, and it requires a massive amount of motivation and discipline not only to start but also to work on it regularly to finish. You go through many crises, and there are even times when you’re close to giving up and throwing your keyboard out of the window!

It was the first time I realised that motivation needs to stem from an internal, not external, source. I didn’t have a boss who’d check out my progress and ask, “How’s the book going? How many words have you written today? Is that chapter already finished?”

But that’s precisely how motivation works in creative jobs, and we even have scientific evidence for that. 

In his book “Drive. The Surprising Truth About What Motivates Us,” Daniel H. Pink summarises the research about motivation. It turns out that external incentives such as higher pay result in better performance only if the task requires basic mechanical skills. It’s the opposite for more complex tasks that require creativity and higher-order cognitive skills.

So, what do we need to motivate us in a more creative job such as one in software development?

• Autonomy — we desire to be self-directed and prefer engagement over compliance.

• Mastery — we want to get better and become more skilled.

• Purpose — we want to do something meaningful that is important for us and others.

Writing a book gave me lots of autonomy. The more I wrote, the better I became. Learning a new craft satisfied me and paved the way for mastery. I’ve always wanted to tell stories that entertain others.

How do all the above help me in my job as a software developer?

• Autonomy — I’m trying to be self-directed and not only do what others expect from me but also take the initiative.

• Mastery — I ask myself what I can do to improve and keep growing!

• Purpose — I used to see it from a narrower perspective: I need to deliver my tasks and make sure they work correctly. Now I’m trying to ask myself on a regular basis what value my work will bring to the client?

Ownership

When you mix all ingredients from the list above, you get the recipe for ownership.

Writing a book requires independence, and I was the only one responsible for the whole idea and its execution from beginning to end. 

Yeah, to be honest, it’s not a hundred per cent a lonely job. I conducted some research, consulted with a couple of people, and showed text parts to other friends who write.

But nobody else would write the goddamn book for me — neither my friends nor the editor — I am the single person in charge of completing the whole project.

And as my writing tutor said, “There are no rules in writing; there are only consequences.” I need to be ready to bear the outcomes of any decision I make. 

Just like in life, huh? 

I can learn the three- or five-act structures, teach myself about different narratives, and avoid adverbs like the plague, just like Stephen King advises. But none of them is carved in stone. I can break any rule I have learned if that helps my story become more compelling to the reader.

It’s similar to software development. You can endlessly argue about what is better — React or Angular — be a die-hard supporter of functional programming or other paradigms. But what matters the most are the trade-offs that come with every decision and whether you’re ready to bear their consequences when working on your project. 

Delivery

It’s tough to commit to a strict deadline when working on such a big task as writing a book. I tried to set some accurate completion dates, but most of them turned out to be unrealistic.

I planned my story and attempted to write it scene-by-scene, but many things happened in the meantime. 

It brought a parallel with software development and the agile approach to my mind. 

Sometimes a character started to behave in a way I never expected, which I’d compare to a client changing their requirements. Or a better idea for an already written scene came to my mind, so I needed to rewrite huge chunks of text — if it sounds like refactoring for you, that’s right!

The biggest lesson learned was that I should have delivered an MVP version of a book — the first draft — as soon as possible and incrementally improved it.

At first, it may look like the areas so distant from each other, like software development and creative writing, have nothing in common, but surprisingly, they do.

Now I’m convinced that trying various activities utterly unrelated to my job is extremely helpful for me to grow. And I encourage you to do the same!

It’s so hard to cope with rejection! Good thing Lisa Barrett’s beautiful book has taught me that there’s a lot to be gained from labelling and investigating one’s emotions. 

Now I know how well-curated each day’s set of talks was, so every cloud has a silver lining.

Let me sum up a few talks I found most interesting.

Hello Multitenancy World by PaweL MLynarczyk and Marek Chrapek

When your product gains traction, you may be too busy onboarding newly signed clients to plan your long-term approach. Hello Astra — a recruitment process automation platform Paweł and Marek are working for — addresses this problem. The company has many clients, and each of them used to get its independent instance of the platform. At some point, this became hard to maintain and not cost-effective. 

In making architectural decisions, we often talk about the last responsible moment to go one way or another. The later we make a choice, the more knowledge we have to base it on. If we postpone it too much, the technical debt keeps growing, and more extra work will be needed to change course.

Paweł and Marek covered the approach to multitenancy they were able to implement in great detail. I'm sure I'll be getting back to it next time I have to consider how to handle multiple tenants in a project.

Let me sum up what they did, and I hope I get it right.

They started by moving to Kubernetes, introducing Kafka messaging for module communication and choosing the easiest module to transition to multitenancy. They then used Kubernetes Ingress rules wherever they needed to route requests depending on the tenant’s request. In the multitenant module, they used Kubernetes config maps combined with cached MongoDB connectors to route requests to dedicated client — tenant — databases. They chose separated databases over differentiating clients based on the extra database document field.

Once the talk gets published on the 4developers YouTube channel, I recommend seeing it for yourself. Many projects can benefit from a clearer idea of what multitenancy entails. The talk also covered multiple paths that the team chose not to take, some of which may be right for you, given your unique circumstances.

How to Make Your Architecture Scream with Functional Domain Modeling by BartLomiej SLota

In Java projects on Evojam, we have been using a fair amount of functional programming concepts. This is not because of the team members' backgrounds in other languages but our ongoing emphasis on readability and maintainability.

Bartek prepared and presented a handy catalogue of functional techniques applicable to everyday Java projects. He began by showing an example of a method with numerous primitive arguments, making external calls, and throwing exceptions. It was a pragmatic way to present the benefits of using dedicated types, Result (or Either) classes, and currying (partial application).

Conducting technical interviews allows gauging the popularity of functional programming among Java developers. In my experience, everyone has heard about streams and lambdas by now. Many people are aware of functional interfaces and how Java lambdas make their ad hoc implementations very concise. Surprisingly, almost no candidates have spoken to have ever written a higher-order function, i.e., accepting or returning a function.

I would argue that picking up at least some of the techniques shown by Bartek can have a bigger impact on the work of Java developers than most of the classic design patterns. By work, I mean the low-level structure and organisation of systems they build and leave for others to maintain.

Team Architecture – monoliths or microservices? by Adrian Sasin

Many effective teams are like tribes. When you hear them talking about their work, the language is indecipherable to anyone outside the team. They almost understand each other without words. For these reasons, it's not easy to be a new joiner. At least that's what was happening when we were still working in offices.

It proves tricky to reproduce the same bonds in remote teams. Adrian talked about aspects of working in the same room that we are missing under the circumstances, like trust and well-understood work organisation. I agree with the importance of keeping the cameras on. If we were to go back to the office, would we wear balaclavas to feel more comfortable?

Chameleon Leader – Getting with modern leadership by Katarzyna Suska

At this point, millennials constitute around 90% of the IT workforce. In the current market situation, where jobs seek programmers and not the other way around, employees have to be treated like clients. The way I see it, Evo has a whole team we call Operations to supply our programmers with good value work and conditions.

Kasia talked about the need to know and understand your millennial workforce just like you want to know your customers’ needs. Rather than complaining about people's lack of loyalty, we should recognise that they are loyal to themselves and their values, not their employers. Instead of being afraid they will get bored and leave, let's leverage their adaptability and focus on providing value by giving our millennials interchangeably mundane and challenging tasks.

I must say that it's funny to hear about ways of coping with millennials, agree with them — I even plan on incorporating some in my work — and at the same time realise that I am a part of this group. It made me realise that my managers have been applying similar techniques to me for quite some time.

What’s next

Next month, I'm speaking at Javeloper, a one-day, fully remote event. Yes, it’s going to be the talk that didn’t make it to the 4developers agenda. Make sure you tune in!

It was a regular day at the office. We went for a coffee break — a part of the day dedicated to informal brainstorming and sharing ideas. And let me tell you, working on hardware prototypes at General Electric, we had a lot of them.

I continued, “I know we work mainly on hardware prototypes, but what if we took some of the best practices from IT and applied them to our processes? If we take the best out of Agile and add it to our project management practices, we might help our customers better!” I added.

I waited for a response from Łukasz with anticipation. It was vital for me to know what he thought — he was leading another team, and his support would make or break the initiative.

“Hmm, that’s interesting. Let’s see what you’ve got,” he replied.

It was a starter for a lengthy talk about Agile, Scrum, Kanban, and product and project management. We discussed how we could get better outcomes by redesigning transparency, inspection, and adaptation in our process.

It turned out it was stimulating not only for us as soon more people joined the conversation, and it got me even more excited to take the next step.

I went back to my desk and started sketching out the plan.

STEP 1: The Problem

Ideas often describe a product or approach that can make someone’s life better, which carries a significant risk of focusing too early on "what" — the solution — and "how" — the plan.

For example, “Let’s introduce Scrum! Next quarter we’ll be ‘Agile’ to perform better!”

There are major pitfalls of an idea stated this way. First, it's vague — it doesn't point to any measure or character of improvement. Second, you might end up solving the wrong problem right.

You can prepare everything very well — train the entire team, hire an Agile coach, set up Jira, and introduce daily scrums. But if your only goal is to market your organization as “Agile,” you forget about the problem and miss the opportunity to improve as a team.

Hence the most critical step is to start with "why." 

Mark my words, you should always start with "why." 

Still not convinced? Then Simon Sinek’s presentation on “how great leaders inspire action” is a must-watch.

Long story short, when you start with "why," you focus on a problem to solve and the purpose and motivation behind it. No matter how well-engineered your solution is and how terrific it looks, no one will use it if it doesn’t solve any problem. Period.

So, the first step is to define the problem fully. Write it down to have a clear guidepost for the future. You must remember why you’re taking specific actions at every step of the process.

When you identify the problem, you need to understand

• the core of the problem,

• the reason why it is a problem,

• who experiences it and how often, and

• what are the current methods of solving it.

Going back to my story — we had an excellent understanding of the situation. We could collectively articulate the problem definition before taking the next steps. We wanted to improve a particular part of our work, and it was essential to find out what slowed us down.

At the time, we used many project trackers to manage processes. We had difficulties getting accurate information about projects and ensuring smooth hand-offs across many global teams.

How come?

Maintaining the data was difficult, and every prototype had a random ID. We had to track orders, financials, peer-review documents, project charters, user manuals, reports, and other documentation. In the meantime, we had hand-offs, daily firefighting, new urgent projects, and regular deadlines. 

We couldn’t say whether we focused on the most vital and immediate task. We didn't know whether we helped each other efficiently. We spent a lot of time figuring all of that out.

But it was time well spent — we defined our problem.

Here's a simplified version:

"Due to the lack of a centralized project database, we spend 10% of our weekly time finding, maintaining, and communicating project information, which takes away space for creative work."

As you can see, the problem definition doesn’t say a word about Agile — the initial idea. It doesn't say anything about the solution — the "what" — or the plan to implement it — the "how." But it explains the problem and why it is a problem.

STEP 2: The Hypothesis

"Hypothesis" is a word used most often in science. However, it is also one of the most important words in product development. Any product development! Whether it’s a hardware product like in the example describing my days in General Electric or a software product, which I'm currently working on at Evojam. 

A hypothesis is a statement that we can assess true or false. You write it in a form that lays out your prediction as to what extent the idea will stand up in the real world. It should refer to a metric that we can measure to determine if the hypothesis is true or false.

This step is a brainstorming phase. Making hypotheses might not sound like creative work, but it is. It helps capture the ideas best, enabling you to assess them and iterate going through the inevitable moments of Kill, Pivot, and Persevere.

Our initial idea was about introducing some of the Agile methods to our game. But now, we had to tie the main idea to the problem we defined. And this connection is called a hypothesis.

In a nutshell, the hypothesis we created is as follows: 

"We believe that our team has a problem of spending too much time maintaining project information because it’s complicated and decentralized. If we introduce a redefined, standardized process, a regular Kanban board, and 15-minute daily scrums, our team will spend only 5% time on this activity."

Using a hypothesis like this, you make the goal and the metric clear — decrease the time necessary to update, maintain, and communicate project information from 10%, as defined in the problem statement, to 5%.

The critical part here is to define a "what" — the proposed solution — and "how" — the plan. And yes — it's time for brainstorming and creativity! The hypothesis is a structured outcome from this, usually chaotic, process. It leads to concrete success criteria, describing what we will introduce to move the needle.  

For creating your hypothesis, follow a template:

We believe [subject] has a [problem] because [reason]. If we [action], this [metric] will improve. 

A reasonable hypothesis is clear, actionable, and easy to assess. While I recommend including all essential parts of a hypothesis — the target audience, problem, reason, proposed action, and metric — don’t be afraid to find your way of phrasing it. It's you and your team who have to understand and use it.

A hypothesis is a crucial part of turning an idea into a reality. Most people go through that process unconsciously, but they only paint a picture of a hypothesis in their heads. So, if you want to maximize your chances of success — make it precise and write it down.

We are ready to go to the phase that is usually the core of an idea. The solution and making it a reality, or at least part of it!

STEP 3: The Experiment

So, we got the problem defined and laid out. We formed a hypothesis, determining the solution and predicting the outcome. This step is all about the action. Finally!

It is usually the most fun part. You put a coin into a slot machine, hoping to win! In this analogy, the coin is your effort, time, and budget. The win is the correct prediction in the hypothesis.

The coin is in — we

• created a well-defined procedure focused on transparency, accessibility, inspection, and adaptation;

• organized daily scrums for the entire team;

• created a Kanban board; and

• made sure everybody knows the process and commits to it.

We gave ourselves two weeks to monitor the experiment. It was us observing the symbols twirling in the slot machine. It was almost mesmerizing to see it unfold every day, showing us how the experiment was going.

“Daily scrums? What do you mean? Meeting more often will save us time? It’s insane!”

Change management was a lot of effort, but we needed it. Starting the process, we could only make decisions based on a discussion. It felt counterproductive to meet often, even if it could save time, so we wouldn’t do it. But thanks to this framework, we carried out an experiment that would give us data — a powerful tool to make informed decisions.

After preparing all the changes, we trained everyone and went through the new process. Some people were excited to try it, some reluctant, and some neutral. However, we all committed to it as a team, which helped us understand if the idea was worth pursuing further.

STEP 4: The Learning

The last step is the assessment of the hypothesis. Was it a success? Or a complete failure? Maybe both?

When the experiment concludes, you should have a direct result that you can juxtapose with the hypothesis.

• Did you achieve the goal? Perfect! Let’s explore some more options and try to improve further! Maybe even roll out the process across other teams?

• Didn’t you achieve the goal? You have just obtained invaluable information that you can use in the future. Do you know why you didn't reach the target? Scope out another experiment.

Either way, the results are rarely black or white. Experiments work best when you can distil a specific change and see its impact on the metrics. In our case, we decided to make a more complex change and introduce three new approaches. We did that because we thought none of the three proposed changes would work without the others.

At the beginning of this process, the most important thing is not to push yourself to make a perfect problem statement, form a perfect hypothesis, and conduct a perfect experiment. The essence of this process is the learning opportunity you get with each iteration.

Start somewhere, give your best shot, go through the process, and learn from the experiments. Draw and document the lessons to keep improving over time instead of making the same mistakes repeatedly. Your product will keep growing, and so will your skills!

In our case, there was a significant drop in the time needed to maintain the project information. Still, we didn’t fully meet the intended target.

So, did we fail?

Not really. We saw we were going in the right direction, but we were left with some new questions to answer and some more tweaks to introduce.

BACK TO STEP 1: The Iteration

Have you ever heard the phrase “practice makes perfect”?

In iterative development, it is a mantra. Nothing affects the outcomes as substantially as proper experimentation and testing. The more iterations you make of a product, service, or any other solution, the better the result will be.

Take advantage of the small iterations. Those minor but controlled improvements can build up to an incredible effect.

Can you imagine Graham Bell inventing the telephone with the aim to create the smartphone as we know it today? With voice-activated, video-call functions that can gauge your mood when you speak to a group of people worldwide?

Of course not, it’s impossible. The technology was nowhere near as advanced as nowadays. We have all those tech miracles just because some intelligent, motivated people just kept iterating and learning.

So, trust this process and give it a try. 

Summary

Each idea is worth little until it becomes a reality.

Converting an idea into a reality requires proper planning, experimentation, and discipline. You might skip some of the steps, but only a consistent, iterative process will produce positive results over time.

This framework is about data — your most potent weapon when introducing new ideas. Get inspired by a scientific process and obtain data that can guide your decisions and help you influence stakeholders.

One of the concepts popular in product management is the build-measure-learn loop presented in the Lean Startup by Eric Ries. It embodies the iterative process and talks about the best ways to experiment and learn. The framework I present in this article was inspired by that approach, among other frameworks, i.e. Design Thinking.

So, to summarize, when you have a great idea, don’t just sell it and hope you get support. Instead, go through the four-step framework iteratively and gain traction quickly, keeping maximum control over each iteration.

The four-step framework to turn your idea into reality goes as follows:

Step 1: The Problem — Understand and clearly define the problem you want to solve.

Step 2: The Hypothesis — Set a clear target to assess if the solution from your idea solves the problem.

Step 3: The Experiment — Go through the assessment process of the hypothesis. Try to be as data-driven as possible, collecting valuable data for further analysis.

Step 4: The Learning — Understand the experiment’s outcomes and decide if it’s worth continuing, pivoting, or killing this idea. 

Back to Step 1: Iterate!

“How did you lose over 70kg all by yourself?”

“How did you quit smoking?”

I often have people ask me these questions, and I must tell you the answer to all of them is pretty straightforward — I’m just a regular person and I’m not an expert on any of these topics, I just do things.

We’re taught to think, or even “think twice,” before we act. People focus so much on trying to come up with a perfect solution that, in the end, they don’t reach their goals or even start to work towards them. 

My mindset is different — I do minimum research, then I take action. Over time, I extend my knowledge and improve what’s been done so far. 

My weight-loss journey serves as a perfect example — at the beginning, I didn’t know anything about nutrition, I actually still have a lot to explore in this matter. All I really knew was that I needed to lower my calorie intake, and that’s exactly where I started. As I learned more, I started improving my diet and working out. But the results were there from the very beginning — I changed significantly without being a nutritionist.

Don’t get me wrong, I’m not saying that thorough research is a bad thing. It’s just that, in a lot of cases, you can start doing something without knowing much. 

Stop spending all your time researching how to learn, start learning instead! Don’t overthink it.

Now, let’s take a closer look at the word “overthink” as it’s an interesting one. The suffix “over” implies there’s an abundance of thinking, which at first glance might seem like a positive. It’s on the contrary — as they say, enough is as good as a feast.

There’s another cornerstone of this mindset — consistency. Always try to take some steps, no matter how small. Don’t focus on the end goal, it leads to overthinking. 

When I started learning Japanese, I considered learning over 2000 kanji — Chinese characters —  to be an impossible task. To make it easier, I decided not to look at the bigger picture and just learn them daily, in small batches. Focusing on the result rather than the action itself can and will often lead to disappointment.

You might associate the word “daily” with “a daily standup meeting,” but it’s not exactly what I have in mind.

I grew up playing games, mostly from the MMORPG genre. Those games, by design, are very time-consuming — you need to spend thousands of hours to achieve something. To keep people coming back, game developers introduced the concept of daily activities — usually easy and highly rewarding challenges that you can complete only once a day. If you don’t do dailies, you lose out on a lot of potential gains. In consequence, it will take you much longer to reach your goals. 

Being used to this concept, I started setting daily goals for myself. However, unlike in games, there was no immediate reward for doing them. So, instead, I told myself, “You can’t go to sleep unless you do your dailies.”

There’s no one-size-fits-all approach to life, and my methodology isn’t perfect. I wouldn’t want to have a doctor perform surgery on me with a “just do it” mentality. But, in most cases, it’s best to give them a try. 

Don’t be afraid of failure, it’s an important part of learning. And remember that some action is better than no action. 

If you want to achieve something, get the ball rolling now and be consistent. Don’t pay too much attention to the end goal, focus on the small steps that will lead you there.

This is how I’ve learnt to code and speak Japanese, lost 70kg, and quit smoking. And this is how you can get to the finish line, too.

“What is the purpose behind it?”

You must have asked yourself these questions at least once.

Perhaps you’re among the people who think the answer is obvious — “To deliver more and quicker!”

If you are, I suggest you reconsider as this is the most common misconception about the purpose of Agile. In fact, if your answer is the above, you most likely don’t use the Agile approach at all.

The real reason for going Agile is to deliver more value to the end users. This is the cornerstone!

Achieving maximum efficiency isn’t the ultimate goal of Agile. Agile practices were introduced with end users in mind — the idea is to deliver a product that brings true value to the people that actually use it.

It might be the first time you’ve heard of it, probably half of the readers are surprised by this statement. Some of you may even disagree with it! And this is the root cause of the problem.

Think about what is your definition of a successful product. 

Some would say that a successful product is one that meets the stakeholders or business requirements. But are you sure that those requirements address real customer needs? At the end of the day, customers are the ones that pay for the product, so why is their opinion so often underestimated? 

We tend to see our success as the result of meeting the stakeholders' expectations, ignoring end-user satisfaction altogether. 

Again, if this is obvious to you, congratulate yourself. Still, there are way too many professionals who would put the stakeholders' opinion above the end-user experience, even if the discrepancy is clearly visible.

This is a comfortable situation — you can’t be blamed for the product failure if you met the given requirements. But is that the goal?

Ask yourself a question: “Why am I doing this?” 

Do you do your work just to tick the checkboxes and be paid for it, or do you want to make a difference? Do you want to truly influence somebody’s life?

“Duh, I want to make a difference! I want to change the world!”

Great! But have you ever wondered how to achieve it? Is it a matter of ticking all the boxes and fulfilling requirements, or is it about addressing a real-life problem your end user is facing? 

Of course, don’t automatically assume that those two are disjunctive! A properly done analysis should make the requirements meet the needs and expectations. Unfortunately, my experience shows this is not always the case. Don’t fall into this trap.

My advice is to ask yourself the following questions, again and again:

Why am I following the Agile approach?

What is the actual goal?

Am I sure that I’m making progress towards meeting the end user’s needs and expectations?

Or am I just checking the boxes? 

Find the answers to them, and you’ll never wonder why you’re using Agile.

Sometimes you need to know which levers to push if you want to bend a complex system to your will. The same can be said about your mind. I tend to trick myself into doing things that benefit me and the others around me.

The Antilibrary

I heard about it sometime in early 2021. I’m almost sure that it was from Krzysiek and he got it from Robert. The story comes from Nassim Taleb’s book, Black Swan. Someone asked Umberto Eco if he had read all the books in his huge library. In reply, Eco suggested we only hold onto the books we have finished out of vanity. On the contrary, we hoard books to read out of a need to grow.

I took this advice very seriously. In 2021, I started buying way more books than I could read. But soon I started seeing the side effects no one warned me about – I was also reading more than I ever had.

I’m not sure how this trick works. In part, I’m more excited to finish a book when I have so many others waiting. It must be something about them sitting on the shelves. Having a lot of files downloaded to my Kindle never had the same effect.

Physical barriers

In his book, Elastic Leadership, Roy Osherove talks about knowing when you are becoming a technical leader. Suddenly, you are involved in almost everything going on with your team. You become a bottleneck for everyone else – either because you know too much or are accepting responsibility for all decisions.

When Evojam moved to fully remote work in 2020 and 2021, I found myself in front of my keyboard when talking to someone. I was always able to start looking at the code or log into a machine over SSH. I ended up fixing things myself more often than I should have. And while I always offered an explanation, I was effectively stealing opportunities to learn from the rest of my team.

Once I understood this and started experimenting with the idea, I realised that not giving someone straight answers can be really challenging. At some point, I ended up dialling into a production emergency call with my team from outside my apartment. I kept my laptop in my bag and only talked over a voice connection. Seeing them figure things out by themselves helped me to interfere less in the future. But at that moment, I was only able to make progress by physically removing myself from my keyboard.

Losses > gains

Before 2021, I was planning to start writing blog posts. I managed to do around two during my time at GS – not a result I can be proud of over the two years of working there. Knowing I wasn’t going to stay there forever, I didn’t have the motivation.

At Evojam, there’s a 750 PLN bonus for each blog post written on your own time. Judging by the content we manage to put together, it may not be enough. It wasn’t for me or at least not until I framed the 750 PLN to me as a potential loss.

Here is what I did: I took my base salary (let’s say it’s 15k), added 750 PLN to it, and started telling myself that was now my base (almost 16k). I know it seems silly, but it works.

If you read Danny Kahneman’s book, Thinking, Fast and Slow, you know how much we want to avoid losses as compared to how little interest we have in gains. The fear of losing 750 PLN always beats the excitement of winning the same amount. Am I comfortable with being paid almost 1k less this month? Rather not, so I better write that blog post. This one included!

Keep growing!

I know, I know. All of this is specific to what I wanted to achieve, and my circumstances. But how often do you see one-size-fits-all solutions having a big impact? My aim here is to encourage you to look for your own. Your mind is much easier to trick than you would think.

And if you’re into this kind of growth, like we are at Evojam, let us know! We will be looking for more exciting projects to start and amazing people to hire in 2022.