Plan your financial future with our easy-to-use SIP Calculator. Calculate the future value of your Systematic Investment Plan (SIP) investments by inputting your monthly investment amount, expected annual return rate, and investment duration. Our clean and intuitive interface ensures that you can quickly and accurately determine how much your investments will grow over time. Ideal for those looking to make informed decisions about their savings and investment strategies, our SIP Calculator is a must-have tool for achieving your financial goals. Start planning today and see how your regular investments can yield substantial returns over the years.

The post SIP Calculator appeared first on ProdSens.live.

Week 10 of coding bootcamp was marked by lots of junk food, a sleepless Sunday night from drinking my coffee too late, and oh yeah learning about Spring JPA entities. Learning them felt like mental gymnastics for me. Now that my brain has shakily landed from its endless flips and rumination, I wanted to share my basic understanding of the how behind each.

Table of Contents

1. One to Many
2. One to One
3. Many to Many

One to Many

Below we have two entities from the basic backend framework of an ecommerce’s app’s backend. A customer has a one to many relationship with orders. In other words, a customer can buy multiple orders.

*Note: Even though we don’t see a list of orders or the customer object – we can access that relationship programmatically via JPA, as discussed above.

Here are how the Order and Customer Table look respectively on Postgres.

@JsonIgnore

The @JsonIgnore is to prevent “looping” (aka circular dependency) when we display the data. For example, when we made a request to get orders tied to a customer, without JSON, it would show the order, then the customer, which then shows the customer field info and then calls the order field which then calls the customer, ad infinitum.

With @JsonIgnore– only the Order information would show when making that get request.
When deciding where to place @JsonIgnore– you can think of it as we don’t need to show the customer when querying orders, but it would be more helpful to show the orders when querying a customer. An alternative way of approaching that thought process is: we put @JsonIgnore over the customer field, because a customer can exist without orders but not vice versa.

Owning Table

Orders is the owning table, which means any changes to the relationship, such as adding or removing orders for a customer, should be made through the customer field in the Order entity.) The owning side is also where the relationship is persisted in the database.

We chose orders as the owning side, because of operational logic. You typically create orders and associate with customers, not the other way around.

The example code block shows how we add an order to a customer. order represents the new order we are adding (sent via the request body in the API call @PostMapping("https://dev.to/customers/{id}/orders")).

 public Customer addOrderToCustomer(Integer id, Order order) throws Exception {
        Customer customer = customerRepository.findById(id).orElseThrow(() -> new Exception("Customer not found"));
        order.setCustomer(customer);
        orderRepository.save(order);
        return customer;
    }

Notice how the updates in the code are done via the order’s side. The customer that has made the order is set to the customer field in the Order entity. This Order instance that now has the respective customer tied to it is then saved (persisted) to the Order database.

Bidirectional

As a side note, as cascade persist is not used above, you can set the order on the customer side as well to allow for bidirectional navigation. Cascade persist means that operations on say a customer entity would persist to the associated order entities (i.e. if you deleted a customer, then the associated customer would aso delete) …however, in our case- as we are primarily accessing orders from the orders side (i.e. we typically retrieve orders and associate them with customers), then we don’t need that bidirectional code added.

One to One

Below we see how each record in our Address entity is associated with one record in the Customer entity., and vice versa. That is, in our hypothetical scenario: each customer can have one address, and one address can belong to one customer.

All the annotations are handled on the Customer entity side:

• @OneToOne annotation in our Customer entity above private Address address means that one customer instance has one address
• CascadeType.ALL in our Customer entity means that for any actions taken on a Customer instance, should also be applied to the Address. For example, if a customer is deleted, then its respective address will also be deleted. Likewise, if a customer is created, then it will be expected to have an address added.
• @JoinColumn annotation indicates the address_id is the foreign key.
• nullable=falsemeans the address_id can’t be null, or in other words each customer needs to have an address associated with it.
  –unique=true means that for each customer, they must have a unique address.

This screenshot below shows the Customer table in Postgres, and you can see the foreign key address_id as the first column- essentially allowing this table to “link” to the Address table.

Many to Many

Below we see a relationship where one order can have multiple products (i.e. TV, sofa, etc), and one product can have many orders. In other words, orders and products have a many to many relationship.

*This below screenshot shows the Join Table that is actually created in Postgres from that @JoinTable annotation.

Side note:

• On the Order table: =new ArrayList<> initializes the list of products with an empty array list, so that as products are added to an order, that array list is updated. This ensures that the products field is not null even if no products are associated with that order at initialization time.
• On the Product table: =new ArrayList<> initializes the list of orders with an empty array list, so that as new orders are made with that product, then those orders can be added in. This ensures that the orders field is not null even if no orders are associated with that product at initialization time. |

The post spring JPA entities: cheat sheet appeared first on ProdSens.live.

Recently the personal care brand, Dove (Unilever) released a new ad celebrating the 20th anniversary of their famous Campaign for Real Beauty that’s getting a lot of attention. The company isn’t sheepish about its stand against the marketing of “fake” beauty products, photoshopped fashion models, and social media images that market impossible beauty standards to young girls. With this latest ad, entitled “The Code”, Dove has doubled down its efforts and taken on the explosive market of AI-generated images, which it pledges to never use to “create or distort women’s images”.

The ad is flooding social media platforms, giving fresh oxygen and awareness to the hotly debated topics of social media impacts on young people, impossible standards of beauty, and the rising depression and anxiety levels among teenage girls. The ad also throws down the marketing gauntlet to firms and companies around the world, implicitly asking, “Will you follow “The Code” of conduct we’re committing to?”

However, the ad’s strong message and stance against AI comes on the heels of a recent spike in concern among Americans around AI and its influence on our daily lives. The fear of AI, or algorithmophobia, is a topic I covered in an earlier piece where I make the argument that our industry’s marketing strategy needs to better understand the causes of algorithmophobia so as to adapt its messaging to overcome common consumer fears.

In the article, I explored how popular culture often polarizes our view of AI, depicting it as either entirely benevolent or entirely malevolent. I argued that such extreme views could heighten anxiety about adopting new technologies. In this piece, however, I aim to delve deeper into the psychological factors that shape our attitudes towards technology and to examine the recent surge in concerns and their underlying causes.

In doing so, I do not wish to dismiss legitimate concerns about AI or AI-generated content and its potential impact on body image and mental health. There are valid reasons for caution, given AI’s unpredictable effects and recent emergence. Instead, my focus is on exploring the deeper-rooted anxieties that arise with the advent of technologies like AI—fears about the very concept of artificial intelligence and the apprehensions that typically accompany such disruptive innovations. Addressing these fears is crucial for us to fully leverage the benefits that AI offers.

Concerns Around AI Among Americans is Rising Sharply

A recent 2023 Pew Research Center Survey looked at how Americans felt about the role of artificial intelligence in their daily lives. The survey showed a sharp increase from the two previous years. When asked how the increased use of AI in daily life made them feel, 52% of respondents said they were more concerned than excited. In 2022, that number was 38%, and in 2021 it was 37%. So, what’s contributing to this bump in concern?

One factor is the explosive growth in AI’s development and deployment, along with the resulting increase in media coverage and debate. We hear, see, and read about AI everywhere now. The public’s awareness is rising and likely outpacing a fuller understanding of AI.

In fact, Pew reports that while most Americans (90%) are aware of AI, the majority are limited in their ability to identify many common uses of the tech (e.g. email spam detection or music playlist recommendations). Awareness without understanding promotes anxiety. It’s functional. Our ancestors (those who survived to procreate) tended to focus more on a general awareness of potential threats than our kin who felt compelled to gain a true understanding of what was making noises in the bushes over there!

To that point, the survey showed that education plays a role in attitudes. Adults with a college or postgraduate degree are more likely to be familiar with AI than those with less education. Also, Americans with higher levels of education tend to be more positive towards AI’s impact on their lives.

However, it’s also important to note that more educated Americans are more likely to work with AI. In 2022, 19% of American workers were in jobs that are most exposed to AI. Those jobs tend to be in higher-paying fields where higher education was beneficial. Working with AI on a practical level helps explain more positive attitudes in this population. Education and experience often allay fears.

Two competing perspectives of artificial intelligence dominate today: 1) AI as the supplanter, leaving humanity to wither towards extinction (left). 2) AI as an assistant to unleash unlimited potential (right).

The Function of the “Human Element” in our Attitudes

One of the more interesting take-aways from the Pew surveys was the shifting levels of trust in AI when it came to the absence or existence of the “human element”— those parts we tend to value (creativity, empathy, analytical thinking) and those we tend to avoid (bias, destructive impulses, impulsiveness).

However, it’s this ambivalence to the human side of AI that provides more valuable insights into how we form our attitudes. Consider these Pew Survey findings on health care:

65% of Americans say they would want AI to be used in their own skin cancer screening.
67% say they would not want AI to help determine the amount of pain meds they get.
Now, consider how U.S. teens responded to a Pew survey asking them about using ChatGPT for schoolwork:

39% said it was “acceptable” to use ChatGPT to solve math problems.
Only 20% said it was “acceptable” to use ChatGPT to write essays.
What explains the apparent contradiction here? What’s the difference between skin cancer screening and pain med management? Why did twice as many respondents find it acceptable to use AI to solve math problems but not write essays?

Part of the answer is we assign varying levels of subjectivity or “human-ness” to different tasks (even though humans do them all). In other words, it’s more “human” to compose an essay because writing is about expressing yourself. Math is about following strict rules. The same attitude usually applies even when you’re tasked with writing an objective, unbiased, and factual piece like a news article. However, aren’t these the same strategies you need to solve math problems?

To diagnose skin cancer successfully, it helps to be experienced, objective, and unbiased. AI skin cancer detection systems are trained on thousands of high-res images of skin lesions. These systems can remember and compare them all, dispassionately and efficiently. No ambiguity. No corrective lenses. No hangover from last night’s bar hopping.

On the other hand, accurately gauging someone’s pain level requires a person who feels pain, a human who’s shared the experience of pain, who has empathy and compassion. It’s likely it’s this lack of human connection that engenders distrust in AI on this issue.

Our Attitudes are Contextual

It’s also important to recognize our attitudes align with the aim of our motives. While most of us are capable of compassion and empathy, these faculties also make us easy to manipulate. In most instances, it’s easier to bullshit your way through a book report than a calculus problem. Also, most people would have more success convincing a human doctor to over-prescribe pain meds than an AI physician. If we need moral nuance or ethical wiggle room, we distrust AI to accept such gray areas. I may be able to convince you that 2 + 2 = 5, but I can’t “convince” my calculator.

What these surveys show is that our attitudes and trust in AI are highly contextual. They change based on the stakes of potential outcomes and the need for objectivity or subjectivity (perceived or actual). If the potential negative outcomes are low (a robot cleaning our house), we tend to trust more. However, we wouldn’t want a robot to make life-altering decisions about our health, unless that decision required high levels of objectivity and unbiased judgment…but only to a point. Thus, this back-and-forth “dance” with AI is our ambivalence at work.

Subjectivity and objectivity are both part of the human experience, yet we prioritize subjective faculties like compassion, empathy, trust, expression, and creativity as “truly human” qualities. The crux of the issue is that, while these aspects of ourselves are indeed some of our best features, they are also the source of our distrust of ourselves and, by extension, AI. Because we are compassionate, we can be manipulated. Because we are emotional, we can be biased. Because we are trusting, we can be deceived. This double-edged sword pierces the heart of our shifting attitudes towards AI.

Mechanisms That Shift Attitudes Towards Technology

The Pew Surveys show American’s trust of AI runs along a spectrum. Just as the temperature in a building is regulated by a thermostat, our individual and collective trust in AI is influenced by an array of ‘control mechanisms’—such as our education levels, occupations, media portrayals—that continuously modulate our comfort levels and perceptions of safety with the technology. So, what else adjusts the thermostat? I asked clinical psychologist Dr. Caleb Lack to help me identify some common factors that could influence public sentiment on AI.

Habituation

One common mechanism to calm nerves around technology is the simple passage of time. All big technologies—like automobiles, television, and the internet—follow a similar journey from resistance to full adoption. Given enough time, any new tech will go from being “magical” or “threatening” to being commonplace.

“I think what often happens with tech is people habituate to it,” explains Lack. “As with any new technology, you just become used to it. Rule changes in sports are a good example. People will often complain about them at first. Two seasons later, no one is talking about it. It’s how it is now, so that’s how it’s always been. Humans have very short memories and most of us don’t reflect much on the past.”

Social Media & Mental Health

We often hear mental health and technology experts sounding the alarm about the negative effects of smartphones and social media. And with good reason. Studies continue to show the negative effects of smartphones, social media, and algorithms on our mental health, especially in adolescents.

One 2018 study showed participants who limited their social media usage reported reductions in loneliness and depression compared to those who didn’t (Hunt, Melissa G., et al). Another found significant increases in depression, suicide rates, and suicidal ideation among American adolescents between 2010 and 2015, a period that coincides with increased smartphone and social media use (Twenge, Jean M., et al).

Few of us have failed to notice the irony that “social” media seems to be making us feel more alone. Many are asking will AI super charge social media, create something that further alienates and damages mental wellbeing of young people. The Dove ad is a product and a reflection of this collective anxiety.

The “Black Box” of Technology

The term “black box” refers to any kind of system or device where the inputs and outputs are visible, but the processes or operations inside are hidden from the user. For most of us, the world is one big black box, technologically speaking.

“Technology of all kinds has become impenetrable for most of the population,” says Lack. “I think that’s where we’re seeing a lot of concern around AI. To someone completely unfamiliar, DALL·E or ChatGPT look like magic. It’s completely incomprehensible. But, then again, how many of those people know how their car works, or their phone, or the internet even. We eventually habituate and just accept them as normal.”

Even if we normalize new technology and forget our previous concerns, an opaque world is still a strange one, and we don’t do well with strange for extended periods of time. We need resolution. We either find out what’s really making noise in the bushes over there, or we run away. Either way, we’re satisfied with our newly acquired knowledge of the real squirl we discovered or the imagined snake we avoided. Yet, how do we run away from an inscrutable technology that’s increasingly integral to our lives? Enter anxiety…

Skills Specialization

The jobs and tasks we do are getting more and more specialized. It’s a consequence of technology itself. We can’t know everything obviously, and specialization can increase efficiency, bolster innovation, and raise wages for workers. However, these benefits have social costs, according to Lack, who offers an insightful perspective on the connection between specialization and social isolation:

“Our knowledge and skills have become so siloed we don’t know what anyone else is doing. You only know your own skills and knowledge. These knowledge silos are keeping us from connecting with others. At the same time, we’ve also become more physically disconnected from people mostly because of technology. The resulting social isolation is a major source of anxiety for humans. If you socially isolate someone, the same areas of their brain become active as if you’re actively torturing them,” he cautions.

The Great Replacement Theory

As we’ve seen, algorithmophobia draws on other common parts of general tech phobia. However, it does seem to carry a unique feature not seen with other technologies. Lack refers to the feature as the “fear of supplantation” or the idea that AI could replace humanity altogether. The notion goes well beyond just taking jobs, but making humanity obsolete, a vestigial species.

“When cars came along,” he explains, “people weren’t worried Model T’s would become sentient, take over, and kill everyone. Today, that fear does exist. So, it’s not just worries around the safety of self-driving cars. It’s about safety, and the fear that humanity may not survive, that life will become Christine meets Terminator.”

Although supplantation is a unique fear with respect to technology and AI, it’s an anxiety as old as humanity itself. “We see fear of supplantation in racist tropes also,” Lack explains. “They’re coming to take my job. They’re coming to marry into my family. They’re coming to replace me. Humans are really good at creating Us vs Them mentalities.”

“Artificial Intelligence” as Competitor to Humanity

Previously, I’ve argued that how we market “artificial intelligence” is important to how consumers will respond to it. To quell anxieties in consumers, I’ve called for “Dehumanizing” AI, by minimizing its human side and “promoting it as a tool first and foremost.” There is a balance to be struck. Imbuing AI with too much “humanity” risks stoking fears of replacement. Too little may diminish the advantages of technology to automate our thinking.

Lack agrees that what we call AI has important psychological implications. In fact, he argues that the moniker “artificial intelligence” creates an antagonistic relationship by making it a direct competitor for resources.

“You’re setting AI up essentially as another species,” he explains. “Competition over resources has been one of the biggest drivers of conflict for our species. We have a hard enough time getting along with even slightly different members of our own.”

Conclusion

As AI continues to permeate every facet of our lives, it is essential to understand and address the multifaceted anxieties it generates among the public. The 2023 Pew Research Center survey serves as a bellwether for rising concerns, indicating a need for greater education and transparency about AI’s role and capabilities. By exploring the psychological underpinnings and societal impacts of AI integration, we can better navigate the complex dynamics of technology adoption.

Efforts to demystify AI through clearer communication, coupled with practical exposure, can alleviate fears and foster a more informed and balanced perspective. Ultimately, addressing the human element in technological development and ensuring ethical standards in AI applications will be pivotal in harmonizing our relationship with these advanced systems, ensuring they enhance rather than detract from societal well-being.

Works Cited

Twenge, Jean M., et al. “Increases in Depressive Symptoms, Suicide-Related Outcomes, and Suicide Rates Among U.S. Adolescents After 2010 and Links to Increased New Media Screen Time.” Journal of Abnormal Psychology, vol. 127, no. 1, 2018, pp. 6-17. DOI:10.1037/abn0000336.

Hunt, Melissa G., et al. “No More FOMO: Limiting Social Media Decreases Loneliness and Depression.” Journal of Social and Clinical Psychology, vol. 37, no. 10, 2018, pp. 751-768. DOI:10.1521/jscp.2018.37.10.751.

Pew Research Center Articles

What the data says about Americans’ views of artificial intelligence

60% of Americans Would Be Uncomfortable With Provider Relying on AI in Their Own Health Care

Which U.S. Workers Are More Exposed to AI on Their Jobs?

Public Awareness of Artificial Intelligence in Everyday Activities

Growing public concern about the role of artificial intelligence in daily life

Caleb W. Lack, Ph.D. is a Professor of Psychology at the University of Central Oklahoma.

The post What’s Fueling the Spike in American Concerns Around AI? appeared first on ProdSens.live.

Are you torn between React and Vue for your single-page application (SPA) project? Each has its own set of advantages and considerations. Let’s break down the key differences between these two popular front-end frameworks:

Core Architecture:

React:
A JavaScript library focusing on the UI layer. It requires additional tools for routing and state management, offering flexibility but with a steeper learning curve.

Vue:
A progressive JavaScript framework with built-in components for routing and state management. It’s easier to get started and offers a more structured approach out of the box.

Template Syntax:

React:
Utilizes JSX, combining HTML with JavaScript expressions, which may require learning a new syntax.

Vue:
Uses HTML templates with directives to bind data and handle events, providing familiarity to HTML developers and easier readability.

Learning Curve:

React:
Has a steeper learning curve due to its modular approach and reliance on additional libraries.

Vue:
Easier for beginners due to its simpler syntax and built-in features, requiring less code initially.

Component System:

React:
Emphasizes pure functions and virtual DOM manipulation, enabling highly reusable and independent components.

Vue:
Offers options for both functional and object-oriented component styles, supporting nested components with built-in features like slots and mixins.

Performance:

React:
Known for virtual DOM optimization, ensuring smooth performance in large applications, but efficient state management strategies are crucial.

Vue:
Offers good performance with reactive data binding, but might be less efficient in complex applications with larger state trees.

Community and Ecosystem:

React:
Boasts a massive, active community with extensive documentation, libraries, and tools.

Vue:
Features a rapidly growing community and ecosystem, offering various libraries and tools in a friendlier, welcoming environment for newcomers.

Use Cases:

React:
Suitable for large-scale SPAs with complex requirements and customizability needs, popular in enterprise applications and data-driven UIs.

Vue:
Ideal for smaller to medium-sized SPAs, rapid prototyping, startups, and projects with less time pressure.

In conclusion, selecting between React and Vue hinges on your specific project needs, team skills, and long-term maintainability. Both frameworks are powerful tools capable of crafting exceptional SPAs. Evaluate your options carefully, considering project size, complexity, and developer skills.

Remember, the right choice ultimately aligns with what best suits your project requirements and the expertise of your team. Happy coding!

Would you like to know more about React, Vue, or have any other questions? Feel free to ask!

The post React vs. Vue: Choosing the Right Framework for Your Single-Page Applications appeared first on ProdSens.live.

In this weekly roundup, we highlight what we believe to be the most thoughtful, helpful, and/or interesting discussion over the past week! Though we are strong believers in healthy and respectful debate, we typically try to choose discussions that are positive and avoid those that are overly contentious.

Any folks whose articles we feature here will be rewarded with our Discussion of the Week badge.

Now that y’all understand the flow, let’s go!

The Discussion of the Week

This week we’re spotlighting Dominic (@magnificode) for dropping the discussion “The Web Industry Has A Hiring Problem “:

The Web Industry Has A Hiring Problem

Dominic Magnifico ・ Oct 24

#webdev
#programming
#discuss
#beginners

Dominic’s post shines a light on the disheartening situation many beginner devs face when applying for entry-level positions. These positions are competitive and often have high expectations of those applying. As Dominic notes, many junior-level job descriptions are not-so-junior sounding and sometimes require formal education. Also, these days it’s the norm for applications to ask folks to participate in lengthy take-home projects.

The discussion that follows is complex, folks chiming in to agree that there are plenty of challenges new devs face as they apply for those entry-level roles. @pterpmnta brings up the difficulty of trying to land a role at a place that requires C1 or C2 English level:

Pedro Pimienta M.

•

Oct 25

I going to add and give some opinions about your. First, the post is great, because it covers many problems with contracts and companies looking for developers.

• The first point you talk about, is not simple, because so many companies are looking for people who at least have an engineering degree. Obviously, today, there are so many people that know how programming and they are not for the system program.

• That’s one of the pints most important in all world. For example, I am from Colombia and live there, and my native language is Spanish, but some companies looking for C1 or C2 English level, which to me is a crazy thing, because, so many developers have a maximum of B2, and these must be sufficient for me.

• I had been involved many times in this test, and in the end if the test was not finished at all, the company did not check the code, or the process, just said, it if is not finished, goodbye.

I will add one more, the tech lead or some developer of the team, should check the employee publication, because sometimes there are so many skills in the publication, that in the end, just need three or maybe just two, and the others, could be learning during the job.

Not to mention, there are also some thoughtful, respectful counterpoints brought forth from @theaccordance in this comment:

Joe Mainwaring

•

Oct 25

Hey Dominic,

First off, excellent article. I’m going to dissect it in this comment, but I still encourage you to share your thoughts as it will make you a better professional in the long run. I’ve been where you’re at (struggling to break into the industry), and while that was a decade ago, many of your points reflect my own experiences. Since that time, I’ve gained a significant amount of experience, not only as an engineer, but also as a hiring manager. Here’s my thoughts to points you’ve laid out in your article:

We need to stop prioritizing formal education or experience when hiring entry level developers.

I empathize with this point but unfortunately it’s not a practical in reality. The plain truth is that an overwhelming majority of businesses have finite time, money, and resources to deliver on its purpose (product or services). Hiring the wrong candidate can have tangible down-stream implications on the health/longevity of a business. Not only would a bad hire subtract diminish those finite resources, but they could have other consequences. For example, if a bad hire caused the company to miss an important deadline, it could result in lost or deferred revenue for a business, which may force the business to shrink its workforce since it can’t pay everyone. That may seem a bit dramatic in the context of a junior role, but I have witnessed it – both inside and outside of software development.

Additionally, as someone who’s taught bootcamp courses in software development, I have learned that while anyone can learn to code, not everyone is capable of doing it when they think they can.

We need to stop writing job descriptions for juniors that include responsibilities that mid level developers wouldn’t even qualify for

I don’t disagree with this point, but I do think it’s important to point out that there is no agreed-upon standard for what makes a Junior/Mid/Senior/etc software engineer. A senior level engineer at a small startup may be considered a junior-level at a FAANG type company.

We need to stop wasting human beings time by requiring them to complete a take home project to “assess their skills”

As much as I loathe the frustration when I fail these tests, I disagree with the premise that we should abolish this type of screening tool. They are very important tool when building teams as it enables hiring managers to onboard team members with a baseline set of skills. While I may not be a fan of abolishing these tests, I do believe we need to make significant improvements to this process across the industry to make these tests more equitable.

All in all, it was a solid discussion well worth having. If anybody has any thoughts on the state of entry-level hiring or perhaps some advice for junior devs who are busy job searching, hop into the thread of Dominic’s post and share them with us!

What are your picks?

The DEV Community is particularly special because of the kind, thoughtful, helpful, and entertaining discussions happening between community members. As such, we want to encourage folks to participate in discussions and reward those who are initiating or taking part in conversations across the community. After all, a community is made possible by the people interacting inside it.

There are loads of great discussions floating about in this community. This is just the one we chose to highlight.

I urge you all to share your favorite discussion of the past week below in the comments. And if you’re up for it, give the author an @mention — it’ll probably make ’em feel good.

The post Discussion of the Week – v8 appeared first on ProdSens.live.

What is software ROI and how to measure it? Why is important for business growth?

These are the main questions the article tackles, so if you’re after the answers, you’re in the right place!

We also share benchmarks, important metrics to track, and best practices.

Let’s get right to it.

TL;DR

• Software ROI, or Return on Investment, represents the financial and business benefits of implementing a software application while factoring in the cost of the investment.
• Hard ROI includes quantifiable and easily measurable financial returns from an investment, for example, increased revenue.
• Soft ROI comprises qualitative and less tangible benefits, for example, increased productivity from software implemented to improve internal business processes.
• Calculating software ROI is crucial for informed decision-making for technology investments. It also helps justify software implementation costs, decide between in-house and third-party solutions, and assess software performance.
• For custom software development in-house, consider factors like development, implementation, maintenance costs, staff onboarding, and missed opportunities. Assess estimated returns over the software’s whole lifetime.
• When investing in third-party SaaS applications, you still need to assess estimated returns, implementation, and staff onboarding and training costs but not development or maintenance costs – that’s on the vendor.
• A good ROI percentage varies across industries and it can range from 5-20%.
• KPIs for measuring ROI include the cost of ownership, implementation costs, time to value, risks associated, and return on time saved.
• When estimating the ROI, use a range of values for benefits and costs, not only the most optimistic ones.
• Be aware that the ROI may not be very high to start with and only increase gradually over time, so decide on the right timeframe to measure it.
• Comparing anticipated and actual ROI will help make future project ROI estimations more accurate.
• Userpilot is comprehensive product adoption software with advanced analytics, feedback, and engagement features. To find out about the benefits it can deliver for your business, book the demo!

What is the ROI of software?

Software ROI, or Return on Investment, is the financial and business benefits of implementing a software application.

We distinguish between hard ROI and soft ROI.

Hard ROI represents concrete, quantifiable, and easily measurable financial returns or benefits that result from an investment.

Soft ROI, on the other hand, is the qualitative and less tangible benefits of an investment.

These can be challenging to quantify in monetary terms and include improvements in internal business processes leading to increased productivity or improved customer service, to name just a couple.

Why is it important to calculate the ROI of a software system?

Calculating software ROI is vital for making informed decisions about technology investments and allocating resources adequately.

First, it can help organizations justify the costs of software implementation to secure the buy-in of the key decision-makers.

Next, it assists in deciding between building software in-house and licensing expensive software solutions from 3rd parties. And if choosing a 3rd party tool, organizations can use it to select the most competitive one.

Finally, software ROI is used to assess the performance of new software projects.

Calculating ROI for different software projects

How you calculate ROI depends on whether you’re developing the software in-house or buying a SaaS solution. In each case, there are multiple factors to consider.

Custom software development in-house

When calculating ROI for software built in-house, consider the following:

• Development costs – including salaries for software developers, architects, and project managers, as well as the cost of any necessary hardware, software tools, and infrastructure.
• Implementation costs.
• Maintenance costs – the ongoing expenses for bug fixes, software updates, and system improvements.
• Staff onboarding and training costs.
• Cost of missed opportunities – ones you could take advantage of if you had the software in place.
• Estimated returns – the projected benefits or gains generated by the software.
• Period of time – how long the software will keep generating returns.

Accurately assessing estimated returns is not easy as there are multiple ways in which software can benefit the organization.

For example, business process software projects can have lots of indirect returns that are difficult to pinpoint, like increased staff motivation.

Investing in a third-party SaaS application

Some of the factors to consider when investing in a 3rd party SaaS application are the same as when building it in-house. For example, you still need to assess the estimated returns, implementation, and staff onboarding and training costs.

Overall, however, the process is easier because you take away the most complex calculations, that is, the development and maintenance costs. SaaS vendors handle these aspects for you – you just pay the subscription fees.

How to calculate ROI for Software

Once you determine what factors to consider, a basic ROI calculation is fairly straightforward.

Here’s a generic formula that you can use for different software types, both built-in-house and SaaS.

Software ROI = (Actual or Estimated Gains – Actual or Estimated Costs)/Actual or Estimated Costs

What is a good ROI percentage for software projects?

This is a how-long-is-a-piece-of-string kind of question. That’s because the numbers will vary from industry to industry or product to product.

However, there are some figures to consider:

• According to iSixSigma, a decent ROI for IT projects is 5-10%.
• For ClearPoint Strategy, a good ROI sits at around 20%.

KPIs to measure the ROI for new software system

What KPIs and metrics should you use to measure the return on investment for new IT solutions? Let’s have a look.

Cost of ownership

The cost of ownership, or the Total Cost of Ownership (TCO), is a crucial factor in measuring software ROI.

It’s made up of all expenses associated with acquiring, implementing, using, and maintaining a software solution throughout its lifecycle.

TCO includes not only the initial purchase or development costs but also ongoing expenses like licensing, support, training, maintenance, and upgrades.

Calculating TCO is essential in software ROI measurement because it provides a comprehensive view of the true financial impact of the software.

Implementation cost

Implementation costs include all the expenses related to integrating the software into existing systems.

For example, it could include data migration or potential downtime during the transition when you’re not able to perform normal operations.

Time to value

Time to value is the time needed by employees to realize the software’s value.

The more complex the product and the more training it requires, the longer the TTV.

One factor that can affect time to value is the quality of the onboarding and training resources. If done well, they can flatten the learning curve massively.

Risks associated

Risks associated can be interpreted in two ways.

On the one hand, it could be all the risks related to software development and implementation, like project delays, budget overruns, technology changes, or security vulnerabilities.

On the other hand, this could also be the value of risks that the new software allows you to mitigate more effectively. For example, a new solution can make data storage safer, and protect the company from costly and damaging breaches.

Return on time saved

Return on time saved is a measure that focuses on the efficiency gains achieved through a software solution.

It quantifies the value of the time saved by employees or users, for example, thanks to automation of tasks, streamlined processes, or faster access to information.

The metric can be a valuable KPI in assessing the impact of software, especially in terms of workforce productivity and cost reduction.

Tips to implement when calculating the return on software investments

Because of the numerous variables, calculating the ROI for software tools may be tricky.

How can you calculate it accurately?

Here are a few tips.

Determine pessimistic and optimistic values for software expenses and benefits

When it comes to IT projects, things rarely go to plan. Such projects are notorious for running over the budget and behind schedule. These factors will reduce the return on your investment.

For this reason, calculate your ROI based on 2 values. Look at the most optimistic and pessimistic costs.

The same applies to benefits. Apart from the best-case scenario, look also at more pessimistic estimates.

While it’s important to be positive, it would be really naive to think that you’re going to realize 100% of the possible benefits, not immediately anyway.

Decide on the timeframe for ROI measurement

Speaking of which…it’s vital to consider carefully the timeframe for your ROI calculations.

Why so?

First, different software investments may have different payback periods. For example, a more complete solution that requires lengthy implementation and staff training won’t generate any returns in the first few months.

Even after that, your new software won’t deliver 100% of its potential value right off the bat. More likely than not, it will be a gradual process and the ROI will start increasing over time.

On the other hand, be aware that your solution may also stop generating returns after a period of time, for example as a result of obsolescence.

What’s more, consider both short-term and long-term gains of implementing the software.

Short-term benefits could be improved efficiency and lower staff workloads, while long-term gains could be higher staff retention, greater customer satisfaction, and higher profits.

Calculate both anticipated and actual ROI

At the beginning of a software project, it is incredibly difficult to make realistic estimates as to the duration of the project and its cost. Even if you’re choosing a SaaS solution, the actual time needed to implement it may vary from company to company.

The same applies to the benefits or gains. Based on case studies of similar projects at similar companies, you may be able to roughly predict what sort of return you’re looking at, but it won’t be accurate.

However, as more data becomes available during the project, use the figures to recalculate the estimated costs. Do the same with the returns once the software is implemented.

By comparing the anticipated and actual ROI, you will be able to better estimate the ROI for future software projects.

Example of software ROI for a user onboarding solution

When choosing a user onboarding solution, you have two options: either build your custom technology or use an existing SaaS product like Userpilot.

If you go with the first option, you can either build it in-house or outsource the process to a specialized software provider.

Let’s start with the in-house solution.

The first question to answer here is whether you have the technical expertise and bandwidth to create the solution.

If the answer is yes, you should also have the know-how to estimate the project duration and cost. This will include the costs of project management, development, quality assurance, software, and infrastructure needed to support it (like cloud storage).

If the answer is no, factor in the costs of hiring the right product team. That’s the actual salaries as well as the costs involved in their recruitment.

If you decide to outsource the product development process to an external provider, the custom solution is most likely going to be more expensive than building in-house but will require less effort.

You will also need to account for the effort involved in researching providers, negotiating the deals, and overseeing the process.

As both solutions won’t be available immediately, consider also the cost of missed business opportunities while waiting for the software, like losing your competitive advantage in the market.

With existing software like Userpilot, you can achieve ROI faster because of the time saved on development. A SaaS product also comes with lower upfront and maintenance costs.

At the same time, SaaS onboarding tools still allow teams to create native-like onboarding experiences, so customization isn’t a problem.

However, the overall cost of using the product over the years may exceed what you would spend on developing your own tool.

Conclusion

Software ROI compares the benefits of implementing a software solution against its costs. This is essential to build a sound business case for buying or developing a tool and helps the team track its performance once implemented.

To find out how Userpilot can help you maximize your returns on investing in user onboarding, book the demo!

The post How to Measure Software ROI For SaaS Products appeared first on ProdSens.live.

Get a glimpse into the daily experiences, work routines, and unique perspectives of tech professionals, both novice and experienced alike, in “A Day in the Life.”

What’s the most enjoyable part of your job?

Follow the CodeNewbie Org and #codenewbie for more discussions and online camaraderie!

CodeNewbie
Follow

The most supportive community of programmers and people learning to code. Part of the DEV family.

The post What’s the Most Enjoyable Part of Your Job? appeared first on ProdSens.live.

I’ve been somewhat obsessed with creating workflow engines for the better part of a decade. The idea of constructing a ‘mega’ machine from an army of smaller machines never seems to get old for me.

At their core, workflow engines are responsible for executing a series of tasks (typically referred to as a ‘job’, ‘pipeline’ or ‘workflow’) over a cluster of machines (typically referred to as ‘workers’ or nodes) as quickly and as efficiently as possible.

Building a workflow engine comes with a bunch of interesting challenges. Here’s a short and highly non-exhaustive list:

1. What do you use to author workflows? Do you use a general-purpose programming language? a configuration-type language like JSON or YAML or do you roll your own DSL (Domain Specific Language)?

2. How do we decide which tasks go to which workers such that busy workers are not overloaded while others are idle?

3. How do we deal with the requirement to scale up or down the capacity in response to fluctuations in computational demand?

4. How do we deal with intermittent task failures?

5. How do we deal with worker crashes?

6. How do we deal with a situation where we have more tasks to execute than available capacity?

Let’s put some rubber on the road

The first time I needed to actually build a workflow engine was while working for a video streaming startup. At the time, the company was outsourcing all its video processing needs to another company.

The existing process was slow, expensive and brittle. The company was regularly getting new content (movies, trailers, bonus video material, closed captions etc.) and we needed a way to quickly process this content in order to get it up on the service for customers to enjoy.

Moreover, the existing process was quite rigid and any changes to it (e.g. to introduce a new audio technology) took months or were simply not possible. I suggested to build a proof-of-concept that would allows us to bring the work in-house and luckily my managers were open to the idea.

At this point, you’re probably asking yourself why would you want to be build one when there are a million open-source and commercial options out there?

True, there are many options out there. And we looked at a good number before we made the decision to build one ourselves. But at least at the time (circa 2014), many of the existing options were either not designed for a distributed environment, were designed more particularly for data-processing use cases, were seemingly abandoned, or simply felt over-engineered to our taste.

The initial iteration of the workflow engine allowed us to start processing ‘low-risk’ content such as trailers, and as we gained confidence in the new system we slowly phased out the old process completely.

Later on, when a co-worker left to another media company that needed a similar system, he asked me if I’d like to come over and do it all over again from scratch. Naturally, I agreed. Our 2.0 was similar in spirit but a lot of the lessons learned from the old design were fixed in the new design.

Meet Tork

After building two proprietary workflow engines for highly specialized use cases I had an itch to see if other companies – possibly with vastly different use cases – could also benefit from a similar system. So I decided to build an open-source version of it.

Tork is a Golang-based implementation which is very similar in spirit to its closed-source predecessors. It can run in a ‘standalone’ mode on a laptop or deployed to a huge cluster of machines depending on your need.

The main components of Tork are:

• Coordinator: responsible for managing the lifecycle of jobs and tasks, routing tasks to the right workers and for dealing with task execution errors.

• Worker: responsible for executing tasks according to the instructions of the Coordinator. Workers are stateless so it’s easy to add and remove them as demand for capacity changes.

• Broker: the means of communication between the Coordinator and worker nodes.

• Datastore: holds the state for tasks and jobs.

• Runtime: tasks are executed by means of a runtime which translates the task into actual executable. Currently only Docker is supported due to its ubiquity and large library of images, but there are plans to add support for Podman and WASM in the future.

If you’re interested in checking it out, you can find the project on Github:

• Backend: https://github.com/runabol/tork
• Web UI: https://github.com/runabol/tork-web

The post Building a distributed workflow engine from scratch appeared first on ProdSens.live.

Are you tired from after writing comments after writing hundred lines of code, or you just started coding and you get stuck with no way to move on. I have the solution for you, Cocaptain is a vscode extension that aims to bring the potential of chatgpt to the visual studio code without any API-Key. The new features of Cocaptain include a pre-written patterns that make prompting more easy. We introduce two prompt for now : comment the selection and Complete the code. Those those two functionalites could be found in the context menu of vscode when selection a piece of code. We highly appreciate feature request and bug report (also a star in gitub motivate us) : https://github.com/Ayyoub-ESSADEQ/cocaptain/tree/main . Here is a simple presentation of those features :

The post Cocaptain new Features appeared first on ProdSens.live.

Attention all revenue operations professionals!

Is your data not engaging your team or shareholders? Is it swamping your ability to deliver valuable insights? Look no further than the power of effective data visualizations.

In today’s fast-paced business world, where data is king and RevOps is the future, raw numbers alone won’t cut it, this is where data visualization comes in.

Not only can it transform your complex data sets into clear and concise visuals, but it can also tell a compelling story that drives action.

In this article, we’ll cover everything you need to know about data visualization, from why it’s important to how to build effective visuals, and how to persuade your team and management to take action.

Don’t miss out on this opportunity for innovation and to elevate your revenue operations game. Read on and visualize your success today!

Here’s how we’ll break it down:

• What is data visualization and why is it important?
• How to build effective data visualizations
• Telling compelling stories with visualizations
• Final thoughts‌‌

What is data visualization and why is it important?

‌‌Simply, data visualization refers to the graphical representation of data and information.

In revenue operations, data visualization is used to present complex data in a more intuitive and understandable format. This enables RevOps professionals to easily identify trends, patterns, and outliers that may be difficult to spot in raw data.

Businesses that implement revenue operations see 19% faster growth and 15% more profits than those that don’t, and data is the fuel for this, so harnessing it effectively is crucial.

Compelling data visualization is key to helping RevOps professionals make better, objective, data-driven decisions.

But if it isn’t presented clearly and visually, it can be impossible to understand, especially in the world of RevOps which deals with multiple teams and datasets at the same time.

Along the same lines, when dealing with a vast range of data sets and metrics across departments, data visualization can aid revenue operations by identifying patterns and trends, helping to guide the direction of growth tactics.

Seeing what is working well and what isn’t can also benefit future forecasting.

When the data is clearly laid out and you have identified patterns, you can use this framework for analyzing previous years, building a bigger picture, and helping to focus on goals.

Another hugely important use of data visualization in RevOps is its ability to make data accessible.

Communication is an essential part of the RevOps function and so data should be able to clearly share insights and key information to all departments, shareholders, and directors.

With better communication, understanding, and alignment comes better results and growth.

How to build effective data visualizations

So how can you actually build effective revenue operations data visualizations? Consider the following steps:

1. Determine the purpose and audience: Before creating any data visualization, it’s important to determine the purpose of the visualization and the intended audience. This will help guide decisions about which data to include, the type of visualization to use, and how to present the information.
2. Choose the right type of visualization: There are many types of data visualizations, including charts, graphs, infographics, and dashboards. Choose the type that works best with your industry and the type of data you’re presenting, making it easier for your audience to understand the information.
3. Simplify the data: Complex data can be difficult to interpret, so it’s important to simplify the data before creating a visualization. Remove any unnecessary data points, and use labels and annotations to highlight any key parts.
4. Use appropriate colors and fonts: Choose colors and fonts that are easy to read and that make the data clear. Avoid using too many different colors or fonts, as this can make the visualization confusing, and always aim to keep color themes professional.
5. Test the visualization: Before presenting the visualization to your team or your board of directors, test it to ensure that it accurately represents the data and that it effectively communicates the message or information you want to show.‌‌

If you can nail all of these steps, communicating complex key information in a way that is easy to understand, your data visualizations are on track to boost your revenue operations function and drive overall growth.‌‌

Telling compelling stories with visualizations

Data visualization bridges data analysis with compelling storytelling. We’ve looked at how it can help with analysis, and now let’s look at how it can boost your narrative message.

Presenting your data in a way that tells a clear and engaging story is crucial for persuading your audience to take action and further highlight key points. Here are some tips:

You should start with a clear message, before even creating a data visualization, you need to determine the key message behind the data you want to convey.

By doing this you can guide your decisions for selecting the right data and the right way to present it to make it most effective.

Try to use a narrative structure, to make your data visualization more engaging, build a story, set the scene, present the data, and conclude by summarizing your key message.

Make an attempt to include visual cues, like color or size for example that will draw your audience’s attention to the parts you want them to see, or even annotations.

Highlight your most important data points strategically in this way, to engage and help your audience understand whilst trying not to overwhelm.

Providing context is also important to help your audience understand the full picture of the data, you can do this by including benchmarks or historical data. This can then highlight the DNA of the data for your audience and show patterns of improvement or decline.

Boost your storytelling with your data visualizations, and use real-world examples or case studies to illustrate the impact of the data on the business.

Cementing all these steps with a final call to action will really encourage your audience, whether that’s your team, shareholders, or board of directors, to take action.

This could range from anything to implementing a new strategy, increasing resources, or changing a process.

Regardless, by using data visualizations in revenue operations to show data in a way that is easy to understand and by illustrating the potential impact of taking action, you can persuade your audience to make informed decisions that drive business success.

Final thoughts

Data lies at the heart of revenue operations and any business growth, so harnessing it effectively is hugely important to secure success.

Therefore effective data visualization is a crucial tool for any revenue operations professional and by transforming datasets into actionable, clear, and concise visuals, trends, patterns, and outliers can be quickly identified.

For a function so focused on alignment and streamlining, compelling data visualizations only act to boost RevOps, helping you to make better, objective, data-driven decisions.

By following the steps outlined in this article, and even using the help of data visualization software like Tableau,  you can build effective data visualizations that tell a clear and engaging story and persuade your audience to take action based on the valuable data insights.

This stands only to secure better outcomes, drive business and optimize revenue growth. RevOps success is yours for the taking!

Most newcomers to the C-suite don’t feel prepared.

That’s because they don’t know how to:

• Steer their psychology to take care of their mental health, eliminate imposter syndrome, and finally achieve work-life balance.
• Quickly establish a company-wide vision and framework for developing and implementing a winning strategy.
• Deftly handle cultural differences to maximize team togetherness.

The C-Suite Masterclass will teach you to do all this, plus a load more.

Click the banner below for more info.

The post Visualizing success: How effective data visualizations can drive action appeared first on ProdSens.live.