problem solving software it fundamentals

What Is Problem Solving? How Software Engineers Approach Complex Challenges

From debugging an existing system to designing an entirely new software application, a day in the life of a software engineer is filled with various challenges and complexities. The one skill that glues these disparate tasks together and makes them manageable? Problem solving . 

Throughout this blog post, we’ll explore why problem-solving skills are so critical for software engineers, delve into the techniques they use to address complex challenges, and discuss how hiring managers can identify these skills during the hiring process. 

What Is Problem Solving?

But what exactly is problem solving in the context of software engineering? How does it work, and why is it so important?

Problem solving, in the simplest terms, is the process of identifying a problem, analyzing it, and finding the most effective solution to overcome it. For software engineers, this process is deeply embedded in their daily workflow. It could be something as simple as figuring out why a piece of code isn’t working as expected, or something as complex as designing the architecture for a new software system. 

In a world where technology is evolving at a blistering pace, the complexity and volume of problems that software engineers face are also growing. As such, the ability to tackle these issues head-on and find innovative solutions is not only a handy skill — it’s a necessity. 

The Importance of Problem-Solving Skills for Software Engineers

Problem-solving isn’t just another ability that software engineers pull out of their toolkits when they encounter a bug or a system failure. It’s a constant, ongoing process that’s intrinsic to every aspect of their work. Let’s break down why this skill is so critical.

Driving Development Forward

Without problem solving, software development would hit a standstill. Every new feature, every optimization, and every bug fix is a problem that needs solving. Whether it’s a performance issue that needs diagnosing or a user interface that needs improving, the capacity to tackle and solve these problems is what keeps the wheels of development turning.

It’s estimated that 60% of software development lifecycle costs are related to maintenance tasks, including debugging and problem solving. This highlights how pivotal this skill is to the everyday functioning and advancement of software systems.

Innovation and Optimization

The importance of problem solving isn’t confined to reactive scenarios; it also plays a major role in proactive, innovative initiatives . Software engineers often need to think outside the box to come up with creative solutions, whether it’s optimizing an algorithm to run faster or designing a new feature to meet customer needs. These are all forms of problem solving.

Consider the development of the modern smartphone. It wasn’t born out of a pre-existing issue but was a solution to a problem people didn’t realize they had — a device that combined communication, entertainment, and productivity into one handheld tool.

Increasing Efficiency and Productivity

Good problem-solving skills can save a lot of time and resources. Effective problem-solvers are adept at dissecting an issue to understand its root cause, thus reducing the time spent on trial and error. This efficiency means projects move faster, releases happen sooner, and businesses stay ahead of their competition.

Improving Software Quality

Problem solving also plays a significant role in enhancing the quality of the end product. By tackling the root causes of bugs and system failures, software engineers can deliver reliable, high-performing software. This is critical because, according to the Consortium for Information and Software Quality, poor quality software in the U.S. in 2022 cost at least $2.41 trillion in operational issues, wasted developer time, and other related problems.

Problem-Solving Techniques in Software Engineering

So how do software engineers go about tackling these complex challenges? Let’s explore some of the key problem-solving techniques, theories, and processes they commonly use.

Decomposition

Breaking down a problem into smaller, manageable parts is one of the first steps in the problem-solving process. It’s like dealing with a complicated puzzle. You don’t try to solve it all at once. Instead, you separate the pieces, group them based on similarities, and then start working on the smaller sets. This method allows software engineers to handle complex issues without being overwhelmed and makes it easier to identify where things might be going wrong.

Abstraction

In the realm of software engineering, abstraction means focusing on the necessary information only and ignoring irrelevant details. It is a way of simplifying complex systems to make them easier to understand and manage. For instance, a software engineer might ignore the details of how a database works to focus on the information it holds and how to retrieve or modify that information.

Algorithmic Thinking

At its core, software engineering is about creating algorithms — step-by-step procedures to solve a problem or accomplish a goal. Algorithmic thinking involves conceiving and expressing these procedures clearly and accurately and viewing every problem through an algorithmic lens. A well-designed algorithm not only solves the problem at hand but also does so efficiently, saving computational resources.

Parallel Thinking

Parallel thinking is a structured process where team members think in the same direction at the same time, allowing for more organized discussion and collaboration. It’s an approach popularized by Edward de Bono with the “ Six Thinking Hats ” technique, where each “hat” represents a different style of thinking.

In the context of software engineering, parallel thinking can be highly effective for problem solving. For instance, when dealing with a complex issue, the team can use the “White Hat” to focus solely on the data and facts about the problem, then the “Black Hat” to consider potential problems with a proposed solution, and so on. This structured approach can lead to more comprehensive analysis and more effective solutions, and it ensures that everyone’s perspectives are considered.

This is the process of identifying and fixing errors in code . Debugging involves carefully reviewing the code, reproducing and analyzing the error, and then making necessary modifications to rectify the problem. It’s a key part of maintaining and improving software quality.

Testing and Validation

Testing is an essential part of problem solving in software engineering. Engineers use a variety of tests to verify that their code works as expected and to uncover any potential issues. These range from unit tests that check individual components of the code to integration tests that ensure the pieces work well together. Validation, on the other hand, ensures that the solution not only works but also fulfills the intended requirements and objectives.

Explore verified tech roles & skills.

The definitive directory of tech roles, backed by machine learning and skills intelligence.

Explore all roles

Evaluating Problem-Solving Skills

We’ve examined the importance of problem-solving in the work of a software engineer and explored various techniques software engineers employ to approach complex challenges. Now, let’s delve into how hiring teams can identify and evaluate problem-solving skills during the hiring process.

Recognizing Problem-Solving Skills in Candidates

How can you tell if a candidate is a good problem solver? Look for these indicators:

• Previous Experience: A history of dealing with complex, challenging projects is often a good sign. Ask the candidate to discuss a difficult problem they faced in a previous role and how they solved it.
• Problem-Solving Questions: During interviews, pose hypothetical scenarios or present real problems your company has faced. Ask candidates to explain how they would tackle these issues. You’re not just looking for a correct solution but the thought process that led them there.
• Technical Tests: Coding challenges and other technical tests can provide insight into a candidate’s problem-solving abilities. Consider leveraging a platform for assessing these skills in a realistic, job-related context.

Assessing Problem-Solving Skills

Once you’ve identified potential problem solvers, here are a few ways you can assess their skills:

• Solution Effectiveness: Did the candidate solve the problem? How efficient and effective is their solution?
• Approach and Process: Go beyond whether or not they solved the problem and examine how they arrived at their solution. Did they break the problem down into manageable parts? Did they consider different perspectives and possibilities?
• Communication: A good problem solver can explain their thought process clearly. Can the candidate effectively communicate how they arrived at their solution and why they chose it?
• Adaptability: Problem-solving often involves a degree of trial and error. How does the candidate handle roadblocks? Do they adapt their approach based on new information or feedback?

Hiring managers play a crucial role in identifying and fostering problem-solving skills within their teams. By focusing on these abilities during the hiring process, companies can build teams that are more capable, innovative, and resilient.

Key Takeaways

As you can see, problem solving plays a pivotal role in software engineering. Far from being an occasional requirement, it is the lifeblood that drives development forward, catalyzes innovation, and delivers of quality software. 

By leveraging problem-solving techniques, software engineers employ a powerful suite of strategies to overcome complex challenges. But mastering these techniques isn’t simple feat. It requires a learning mindset, regular practice, collaboration, reflective thinking, resilience, and a commitment to staying updated with industry trends. 

For hiring managers and team leads, recognizing these skills and fostering a culture that values and nurtures problem solving is key. It’s this emphasis on problem solving that can differentiate an average team from a high-performing one and an ordinary product from an industry-leading one.

At the end of the day, software engineering is fundamentally about solving problems — problems that matter to businesses, to users, and to the wider society. And it’s the proficient problem solvers who stand at the forefront of this dynamic field, turning challenges into opportunities, and ideas into reality.

This article was written with the help of AI. Can you tell which parts?

Get started with HackerRank

Over 2,500 companies and 40% of developers worldwide use HackerRank to hire tech talent and sharpen their skills.

Recommended topics

• Hire Developers
• Problem Solving

What Factors Actually Impact a Developer’s Decision to Accept an Offer?

• All Articles
• Let's Connect
• Fundamentals
• Soft Skills
• Side Projects

A Guide to Problem-Solving for Software Developers with Examples

If I ask you, out of the blue, what’s the role of a developer, what would you answer? Coding all day? Drinking coffee? Complaining about the management?

To me, a developer is first and foremost a problem solver, simply because solving problem is the most important (and the most difficult) part of our job. After all, even if our code is perfect, clear, performing great, a masterpiece of form and meaning, it’s useless if it doesn’t solve the problem it was meant to solve.

So, let’s dive into problem-solving today. More specifically, we’ll see in this article:

• How to define a problem, and the difference sometimes made between problem-solving and decision-making.
• Why some problems should not be solved.
• The two wide categories of problems you can encounter.
• Why it’s important to correctly define the problem, and how to do so.
• How to explore the solution space.
• Why deferring a problem might be the best decision to make in specific situations.
• Why reflecting on the whole process afterward can help you in the future.

This article is mostly based on my own experience, even if I apply here some ideas I found in books and papers.

We have our plan. Now, it’s time to dive deep into the difficult, but rewarding, process of problem-solving.

Problem-Solving and Decision-Making

“When I use a word,” Humpty Dumpty said in rather a scornful tone, “it means just what I choose it to mean — neither more nor less.” “The question is,” said Alice, “whether you can make words mean so many different things.” “The question is,” said Humpty Dumpty, “which is to be master — that’s all.” Lewis Caroll Source

Words are ambiguous; they can mean different things for each of us. So let’s first begin to agree on the definition of “problem-solving” here, to be sure we’re on the same page.

Let’s first look at the definition of the word “problem” in a dictionary:

• According to the American Heritage Dictionary , a problem is “a question to be considered, solved, or answered”.
• According to the Oxford Learner’s dictionary , a problem is “a thing that is difficult to deal with or to understand”.

In short, in any problem, there is some degree of uncertainty. If you’re certain of the solution, the problem is already solved. Nothing would need to be “considered, solved, or answered”.

Information is useful to reduce this uncertainty. The quantity is often not the most important, but the quality will be decisive. If I tell you that 90% of my readers are extremely intelligent, would it help you to solve a problem in your daily job? I bet it wouldn’t. It’s information nonetheless, but its usefulness for you is close to zero.

This is an extreme example, but it highlights an important point: before collecting any data, define your problem clearly; then, according to the problem, decide what data you need. Yet, many companies out there begin to collect the data and then decide what problem to solve. We’ll come back to that soon in this article.

So, to summarize, a problem is a situation with some degree of uncertainty. Sometimes, this uncertainty needs to be reduced to come up with an appropriate solution, or, at least, a decision to move forward to your specific goal.

Is there a Problem to Solve?

Whenever you (or somebody else) see a problem, you should always ask yourself this simple question first: is it really a problem, and should we solve it now ?

In other words, ask yourself the following questions:

• Why is this problem important to solve?
• Would be solving the problem creates some value? What value?
• What would happen if the problem was not solved?
• What desired outcome do we expect by solving the problem?

If the problem doesn’t bother anybody and solving it doesn’t create any value, why allocating effort and time to solve it?

It sounds obvious, but it’s an important point nonetheless. More often than not, I see developers heading first in solving problems without asking themselves if they should solve them at the first place.

The most common examples I can think of are useless refactoring. I saw developers refactoring parts of codebases which never change, or is rarely executed at runtime. In the mind of the developer, the code itself is the problem: refactoring is the solution.

I remember a similar case: a developer refactored part of the codebase which was basically never used. We discovered, months later, when we had more and more users using this specific part of the codebase, that the refactoring didn’t really simplify anything. To the contrary; we had to refactor the code again. The first refactoring tried to solve a problem which didn’t exists.

Of course, the developer could argue that the value created is a “cleaner” codebase, but it’s arguable, especially when the code is neither often modified nor used. The value created here is not clear, and it would have been easier if the first refactoring never happened. In this specific situation, I recommend refactoring when you actively change part of the codebase for another reason (implementing a new feature for example).

Whether a problem is worthy to be solved is subjective. It also depends on the problem: if the solution is clear and straightforward, it might be useful to solve it, if the consequences of the solution are also clearly known and the risks are low. Unfortunately, these kinds of problems, in practice, are quite rare.

Types of Problems

I would define here two wide categories of problems: the problems with a (or multiple) clear solution (what the literature call “problem-solving”), and the problems without clear solution (it’s sometimes called “decision-making” instead of “problem-solving”).

In fact, if the problem you’re trying to solve has a clear, accepted answer, it’s very likely it has been solved already. It’s often the case for mechanical, technical problems. For example, let’s say that you need to order a list; you just have to search on the wild Internet how to do so in your programming language of choice, and you’re done! You can ask an “AI” too, or stack overflow, or whatever.

In my experience, most technical problems have one (or multiple) accepted solution. I won’t speak about these kinds of problems at length in this article, since they’re the easiest to solve.

When you’re in front of a problem which has no clear solution (even after doing some research), it’s where things get more complicated. I’d argue that most problems you’ll face, as a software developer, are of this category. Problems which are directly linked to the domain of the company you work with are often specific (because they depend on the domain), and complex.

For example, I’m working for a company providing a learning platform for medical students who want to become doctors, among other services. This context is changing because the real world is changing; medicine is no exception.

Recently, we had to create new data structures for the knowledge we provide; these data structures are directly linked to the domain (medicine) here. But what data structures to create? How can they adapt to the ever-changing environment? How to capture the data in the most meaningful way, with understandable naming for other developers?

Decisions had to be made, and when there are no clear solutions, you need to come up with a couple of hypothesizes. They won’t feel necessary like solutions , but rather decisions to take to move forward toward the desired outcome. It often ends up in compromises, especially if you’re working in a team where the members have different opinions .

Also, architectural decisions have often no clear solutions because they depend, again, on the changing context. How to be sure that an architectural decision is good today and in three months? How can we make the architecture flexible enough to adapt to the blurry future?

As developers, we deal with complex codebases, which are somewhat linked to the even more complex real world. It’s difficult to know beforehand the consequences of our decisions, as well as the benefits, the drawback, and the potential bugs we introduce.

Before jumping into the solution space however, we first need a good detour in the problem space.

Defining the Problem

Correctly stating the problem.

After determining that we indeed have some kind of problem, it’s tempting to try to find a solution directly. Be patient: it’s better to look at the problem more closely first.

If you don’t specify well the problem, you might not solve it entirely. It’s also possible that you end up solving the wrong problem, or the symptoms of a problem, that is, other minor problems created by a root problem. Often, the ideal scenario is to find the root problem, even if you don’t want to tackle it first. In any case, it’s always useful information.

For example, not long ago, our users didn’t find the content they were searching for, using our search functionality on our learning platform.

We could have directly solved the problem by asking the search team to adjust that for us, but this problem was only a symptom. It wasn’t the first time that we had to spend time and energy trying to communicate to the search team what we wanted to fix; the real root problem here was that we didn’t have any ownership of our search results.

The solution: we created a better API communicating with the search team, to be able to adjust ourselves the search results in a more flexible manner.

When looking at a problem, a good first step is to write it down. Don’t do it once; try to find different formulations for the same problem.

Writing is nice (I love it!), but other ways to represent ideas can be really useful too. You can try to draw what you understand from the problem: a drawing, a diagram, or even a picture can help you understand the problem.

From there, you can ask yourself: do you have enough information to take a decision? The answer will be mostly based on the experience of the problem solver, there is no magical formula to be sure that you can and will solve the problem.

You should also try to look at the problem from different angles, to really frame it correctly. The best way to do so is to solve problems as a team.

Solving Problems in a Team

Trying to describe and think about a problem is a great beginning, but it’s even better if you do it as a team. You can exchange experience, opinions, and it’s easier to look at a problem from multiple angles when multiple developers are involved.

First, make sure that everybody in the team is aware of the problem. Defining it altogether is the best. If you have a doubt that somebody is not on the same page, you can re-explain it using different words. It might bring more insights and ideas to the discussion.

Don’t assume that everybody understands the problem equally. Words are powerful, but they are also ambiguous; never hesitate to ask questions (even if they seem stupid at first), and encourage the team to do the same. If your colleagues see that you’re not afraid to ask, it will give them confidence to do the same.

The ambiguity can also build overtime, after the problem was discussed. That’s why it’s really important to document the whole process, for anybody to be able to look at it again and fix the possible creeping misconceptions. Don’t try to describe everything, but try to be specific enough. It’s a delicate balance, and you’ll get better at it with experience.

If you don’t like writing, I’d recommend you to try anyway: this is a powerful skill which will be useful in many areas of your life.

Regarding the team of problem solvers, diversity is important. Diversity of opinion, experience, background, you name it. The more diverse the opinions and ideas are, the more chances you’ll have to solve the problem satisfyingly (more on that later). If the members of the team have enough respect, humility, and know how to listen to their colleagues , you’re in the perfect environment to solve problems.

As developers, we’re dealing with moving systems, because they need to reflect the ever-changing business domain of the company you’re working with. These problems are unique, and even if similar problems might have been solved in the past, they’re never the exactly same. The differences can have an impact on the solution, sometimes insignificant (allowing you to re-apply the solution found previously), sometimes important enough to change the solution entirely.

Exploring the Solution Space

Now that we’ve defined the problem, thought about it with our team, tried to look at it from different angles, it’s time to try to find solutions, or at least to make a decision.

What is a good decision? The one which will bring you closer to your desired outcome. It sounds obvious, but there can be some ego involved in discussions, which will push us to try to be right even if it’s not the best solution in the current context. Our personal incentives can conflict with the company’s best interest; it’s always good to try to stay aware of that.

The solution should also be the simplest possible, while still moving forward to the desired outcome. It should also have an acceptable level of risk when we decide to apply the solution. In my experience, complicated solutions are the ones which come up first: don’t stop there. Take some time trying to find the best solution with your team.

For example, here’s what we do with my actual team:

• We define the problem altogether.
• We try to think about different hypothesizes. Not only one, but a couple of them.
• We write the benefits and drawbacks of each hypothesis (which can lead to more ideas, and possibly more hypothesizes).
• We commit to a hypothesis, which then needs to be implemented.

What I meant by “hypothesis” here is a solution which might work; but only the implementation of the hypothesis can be considered as a solution. Before the implementation, it’s just an informed guess. Many things can go wrong during an implementation.

This process looks simple, but when you have multiple developers involved, it’s not. Again, if each member of the team have good soft skills and some experience, it can be an enjoyable and rewarding process. But you need a good team for it to work efficiently (that’s why it’s so important to ask the good questions when joining a company). It’s even better if the members of the team are used to swim in uncertainty, and take it as a challenge more than a chore.

The process described above is just an example; in practice it’s often more chaotic. For example, even when a decision is made, your brain might still continue to process the problem passively. If you find some flaws in the hypothesis you’ve committed to, congratulations! You have now a brand-new problem.

I can’t emphasize it enough: try to be as detached as possible from your ideas, opinions, and preferred hypothesizes. The goal is not for you to be right and feel good, but for your company to move in the good direction. It’s hard, but with practice it gets easier.

I also want to underline the importance of finding both benefits and drawbacks for the different hypothesizes you (and your team) came up with.

To find good solutions, we might also need to reduce the uncertainty around their possible consequences. Doing some external research can help, like gathering data around the problem and the possible hypothesizes. In the best case scenario, if you can find enough data, and if you feel confident that you can move forward with a hypothesis, that’s already a great victory.

If you don’t have enough external information to reduce the uncertainty to a level you feel comfortable with, look at your past experience. Try to find problems similar to the one your deal with in the present, and try to think about the solutions applied at the time, to see if they could also be applied in your current case. But be careful with this approach: complex problems are context-sensitive, and the context you were in the past will never be exactly the same as the present and future contexts.

For example, I recently changed the way we display search results in our system, because we had some data indicating that some users had difficulties to find what they really wanted to find. The problem: users have difficulties to find the good information; it’s a recurrent problem which might never be 100% solved. That said, thanks to the data gathered, we found an easy way to improve the situation.

The data was very clear and specific, but it’s not always the case. More often than not, your data won’t really prove anything. It might only show correlations without clear causality. It will be even more true if you begin by gathering data without defining first the problem you try to solve. You can find problems looking at some data, that’s true, but it needs care and deep understanding of what you’re doing; looking at data when you know exactly what you want to solve works better.

Using this kind of process, the hypothesis is often some sort of compromise. That’s fine; committing to a hypothesis is not the end of the process, and there will be other occasions to revisit and refine the solution.

If you don’t feel comfortable with the level of uncertainty of the problem (or the risk involved by applying your hypothesis), you need to dig more. Writing a prototype can be useful for example, if you hesitate between two or more approaches. If your prototype is convincing enough, it can also be useful to gather feedback from your users, even if the ones testing your hypothesis will always be more invested if they test a real-life functionality, instead of a prototype which might use dummy data, or be in a context which is too remote from the “real” context.

In my opinion, prototypes are not always useful for complex problems, because a prototype only test a new feature at time T, but doesn’t allow you to see if the solution stay flexible enough overtime. That’s often a big concern: how will the solution evolve?

But prototyping can still help gather information and reduce the uncertainty of the problem, even if the prototype doesn’t really give you the solution on a silver platter. It’s also great for A/B testing, when you’re in the (likely) case when you have not much information about the real needs of your users. You could ask them of course, but nothing guarantee that they know themselves what these needs are.

If you don’t find any satisfying hypothesis to your problem, you might also challenge the desired outcome. Maybe a similar, simplest hypothesis, with slightly different outcomes, could work better? If it makes things easier, faster, and less complex, it could be the best solution. Don’t hesitate to challenge your stakeholders directly on the desired outcomes.

Deferring the Problem

In some cases, you might be hesitant to try to solve a problem if there is still too much uncertainty around it. In that case, it might be best to defer solving the problem altogether.

Deferring the problem means that you don’t solve it now ; you keep things as they are, until you get more information to reduce the uncertainty enough.

We had a problem in the company I worked with some time ago: we have dosages which can be discovered in articles, but users didn’t really find them, and nobody really knew why. Because of this lack of information, the problem was not tackled right away, but differed. From there, data have been collected overtime, allowing us to understand the scope of the problem better.

Don’t forget that deferring a problem is already taking a decision. It might be the less disruptive decision for the application and its codebase, but it’s s decision nonetheless, and it can have consequences. Seeing a differed problem as a decision will push you to think about the possible consequences of your inaction, and you’ll look at it as a partial “solution”, with some uncertainty and risk associated to it.

In my experience, deferring the problem works well only when you try to actively seek more data to solve it later. It can be some monitoring to see how the problem evolves, or some data taken from users’ actions. Sometimes, simply waiting can also give you important information about the nature of the problem.

What you shouldn’t do is try to forget the problem. It might come back in force to haunt your sleepless nightmares later. Avoiding a problem is not deferring it.

Here’s another example: we began recently to build some CMS tooling for medical editors, for them to write and edit content on our learning platform. We had one GraphQL API endpoint at the beginning, providing data to two different part of the application:

• Our CMS for medical editors.
• Our learning platform for medical students.

We knew that using one single GraphQL endpoint for these two types of users could cause some problems.

But we didn’t do anything about it, mostly because we didn’t see any real, concrete problem, at least at first. When a minor symptom, related to this unique endpoint, popped up, we spoke about it, and we still chose not to do anything. We preferred deferring the problem once more, to try to solve the real problem (one API for two different kinds of applications) later.

Finally, when we had enough symptoms and some frustration, we decided to split our graphQL API in two different endpoints. It was the best moment to do so: we had enough information to come up with a good decision, we applied it, and we stayed vigilant, to see how our applied hypothesis would evolve.

Moving fast and breaking things is not always the best solution. In some situations, waiting a bit and see how things evolve can allow you to solve your problems in a more effective way. But, as always, it depends on the problem, its context, and so on.

Reading this article, you might have wondered: how much information is enough to be comfortable enough to apply a solution? Well, again, your experience will be the best judge here. You’ll also need to consider carefully risks, benefits, and drawbacks. It doesn’t mean that you need to chicken out if you don’t have 100% certainty about a problem and some hypothesizes; being a software developer implies to have some courage and accept that mistakes will be made. It’s not an easy task, and there is no general process to follow in any possible case.

In short: use your brain. Even if you’re totally wrong, you’ll have the opportunity to fix the bad decisions you’ve made before the implementation, during the implementation, and even after it. We don’t code in stone.

The Implementation: The Value of Iteration

You’ve gathered with your team, tried to define the problem, found multiple hypothesizes, and agreed to try one of them. Great! Problem solved.

Not so fast! We still need to apply the hypothesis, and hope that it will become a good solution to the problem. Doing so, you’ll gather more information along the way, which might change your perspective on the problem, on your hypothesizes, and can even create some baby problems on its own.

It’s where the agile methodology is useful: since we’ll never have 100% certainty regarding a problem and its possible solution, we’ll learn more about both while implementing the hypothesis. That’s why it’s so valuable to iterate on the implementation: it gives you more information to possibly adjust your code, or even the problem, or even switching hypothesizes altogether. Who knows? A solution which is not implemented is just a guess.

If the hypothesis applied is not the ones you would have personally preferred (compromising, or even giving up on your preferred solution is common in a team), only applying it will tell you if you’re right or wrong; that is, if the hypothesis can become a solution solving the problem, at least in the present context.

If you’re worried about how a specific solution will evolve overtime, it’s more complicated, because an implementation won’t give you the information you seek. Still, implementing a hypothesis can be a great source of learning (the most valuable to me is when I’m wrong, because I learn even more). If you think that your hypothesis can have better outcome at time T, you might also try to implement it and compare it. Again, it’s where prototyping is useful.

When applying the solution, you need to look at the details of the implementation, as well as the big picture, to judge if the solution you’re creating is appropriate (leading to the desired outcome). This is a difficult exercise. In general, a developer should be able to reason on different levels of abstraction, more or less at the same time. Again, if you’re aware of it, your experience will help you here, and you can also push yourself to think of all the possible risks and consequences at different levels.

If you work in a team, try to participate (at least a bit) into the implementation of the solution. It’s not good to create silos in teams (that is, only a couple of members have some information others don’t have).

You can go as far as looking at other projects, and ask yourselves these questions:

• Did we had similar problems on these other projects? How did we solve them?
• What was the context of these projects? Is it similar to our current context?
• What did we learn from these other problems, and their implementation? Is the implementation similar to what we’re doing now?

In any case, I would definitely recommend you to write a development journal. I write mine for years, and it has been valuable in many cases. I basically write in there:

• The interesting problems I had.
• The decisions made.
• How the implementation of the solution evolved overtime.
• The possible mistakes we made along the way.

It’s a great resource when you have a problem and you want to look at your past experience.

To evaluate your decisions overtime, nothing will beat a good monitoring process: logs, tests, and so on. It’s what the book Building Evolutionary Architecture call “fitness functions” for example, some monitoring allowing you to measure how healthy your architecture stays overtime. It doesn’t have to stop to the architecture; you can think about different monitoring system to see how something evolve, especially if the solution has still a lot of uncertainty regarding its benefits, drawbacks, and risks.

You can also do that retrospectively: looking at how the code complexity evolve overtime using Git for example.

Retrospective on the Process

We defined the problem, implemented a solution iteratively, and now the problem is gone. That’s it! We made it! Are we done now?

Decisions are sometimes not optimal, and implementing a solution successfully doesn’t mean that there wasn’t a better (simpler) one to begin with. That’s why it can be beneficial to look back and understand what went right, and what went wrong. For example, we can ask ourselves these questions:

• Looking at what we learned during the whole process, is there a potentially better hypothesis to solve the problem in a simpler, more robust way?
• What are the benefits and drawbacks we missed when speaking about the different hypothesizes, but we discovered during the implementation? Why we didn’t think about them beforehand?
• What other problems did we encounter during the implementation? Did we solve them? Did we differ some? What should be the next steps regarding these new problems?
• What kind of monitoring did we put in place to make sure that the solution won’t have undesired outcomes overtime? Can we learn something with this data?

Reflecting on past solutions is a difficult thing to do. There is no way to logically assess that the decision taken was better than others, since we didn’t implement the other hypothesizes, and we didn’t look at them overtime to appreciate their consequences. But you can still look at the implementation of the solution overtime, and write in your developer journal each time there is a bug which seems directly related to the solution. Would the bugs be the same if another solution would had been applied?

Bugs are often not an option; they will pop up, eventually. Nonetheless, it’s important to make sure that you can fix them in a reasonable amount of time, and that you don’t see them creeping back in the codebase after being solved. Some metrics, from the DevOps movement (like MTTR for example) can help here. Sometimes, bugs will show you a better, more refined solution to the original problem; after all, bugs can also give you some useful information. They are also the most direct result of the implementation of your solution.

If you want to know more about measuring complexity (which can be also used to measure complexity overtime after applying a solution), I wrote a couple of articles on the subject .

Humility in Problem-Solving

It’s time to do a little summary. What did we see in this article?

• We need to ensure that the problem we found is really a problem we need to solve. Is there any value to solve the problem? Is it even a problem?
• Try to determine what kind of problem you have: a problem which can have multiple, specific, known answers (like a technical problem), or a problem which depends on the real-life context, without known solutions?
• Defining the problem is important. Try to define it using different words. Write these definitions down. Does everybody in your team understand the problem equally?
• It’s time to explore the solution space. Draft a couple of hypothesizes, their benefits, drawbacks, and risks. You can also do some prototyping if you think it would give you more information to take the best decision.
• Do you have enough information to implement a hypothesis, becoming effectively a solution? If it’s not the case, it might be better to keep the status quo and try to solve the problem later, when you’ll have more information. But don’t forget the problem!
• If you decide to implement a solution, do it step by step, especially if you’re unsure about the consequences of your decisions. Implement an independent part of the hypothesis, look at the consequences, adjust if necessary, and re-iterate.
• When the solution is implemented, it’s time to reflect on the whole process: did we solve the problem? What other problems did we encounter? Maybe another solution would have been better? Why?

As I was writing above, most problems you’ll encounter will be complex ones, embedded into a changing environment with different moving parts. As a result, it’s difficult to train to solve problems in a vacuum; the only good training I know is solving real life problems. That’s why your experience is so important.

Experience build your intuition, which in turn increase your expertise.

You’ll never have 100% certainty that a solution will bring you the desired outcome, especially if you are in front of a complex problem with a blurry context. If you are absolutely convinced that you have the good solution without even beginning to implement it, I’d advise you to stay humber in front of the Gods of Complexity, or they will show you how little you know.

• How to solve it
• Hammock Driven Development
• When Deferring Decisions Leads to Better Codebases
• Lean Development - deferring decision

Filter by Keywords

The 10 Best Problem-Solving Software to Use in 2024

Engineering Team

February 14, 2024

Do you want a solution to help your teams work well together, reduce friction, and speed up productivity?

The best problem-solving software has all the answers for you. Problem-solving software helps find bottlenecks, simplify workflows, and automate tasks to improve efficiency. The result? Communication is easy, and your team enjoys a collaborative work environment.

Problem-solving software gives you the right visualization tools and techniques to better articulate your ideas and concepts.

That’s not all; it also automates repetitive tasks while your team focuses on brainstorming and ideating. 

In this article, we’ll cover the best problem-solving software and highlight its various features, limitations, customer ratings, and pricing details to help you make an informed decision. 

What Should You Look For In Problem-Solving Software? 

1. clickup , 2. omnex systems , 5. meistertask, 6. teamwork, 10. airtable .

Businesses encounter many challenges, from operational inefficiencies and customer complaints to financial discrepancies. 

As your team slowly navigates through these issues, having problem-solving software with the right features will reduce the hassle. Before investing in one, consider some of these following factors:

• User-friendly interface: The software should have an intuitive and easy-to-use interface to minimize the learning curve for users
• Versatility: Look for software that addresses various problem types and complexities. It should be adaptable to different industries and scenarios
• Mind maps and Visualization features: Get yourself problem-solving software solutions that offers mind maps and other visual tricks. It must be a digital canvas for your team to brainstorm ideas, connect the dots, and execute strategies
• AI assistant: If your team is stuck with repetitive mundane tasks, then it’s time you let AI take over. With the right problem-solving tool comes in-built AI that handles  everyday tasks, leaving your team to focus on the important stuff
• Automation capabilities:  Look for problem-solving process that’s all about automation. This way, you ensure efficiency and effectiveness without the grunt work
• Goal tracking: Your efforts improve when you optimize your tracking process. You need goal monitoring and tracking features to ensure you are on track 
• Cost-effectiveness: Look for the features that various plans offer and compare them to choose an option that provides maximum features while the benefits justify the cost 

The 10 Best Problem Solving Software In 2024

While you have many options, select the one with the right features that suit your needs . 

Check out our list of the ten best problem-solving tools to ensure you have the features to solve complex issues effectively: 

Henry Ford once said that success takes care of itself if everyone moves forward together. ClickUp problem-solving software helps you succeed by ensuring all your team members are always on the same page. 

With its live collaboration, you can see if your teammates are looking at or editing documents. Also, edit documents together in real-time. Moreover, any changes on any device are updated instantly, so nobody falls behind. 

The whiteboard feature is super helpful in getting your team together for brainstorming and ideating. As problem-solving involves generating and evaluating multiple ideas, the whiteboard helps write, modify, and build ideas together. 

Now that you have brainstormed on core problems, you must establish a clear visual reference point for ongoing analysis. That’s where the ClickUp mind maps feature stands out. Create a hierarchical structure, with the main problem at the center and subtopics branching out.

Since these maps have interconnections, it is easy to visualize connections between different elements. This feature effectively identifies possible cause-and-effect relationships in a problem.

ClickUp best features 

• Documentation: Address and solve problems by storing and accessing project-related documents in ClickUp Docs
• Mind maps : Identify critical connections, uncover insights, and implement creative approaches by visually mapping relationships between concepts and information with ClickUp Mind Maps
• Task prioritization: Make problem-solving easier for your software developers—sort tasks by urgency. This helps your team focus on the most crucial aspects, making problem resolution more efficient 
• Virtual whiteboards: Enhance collaborative problem-solving and critical thinking through ClickUp Whiteboards . Brainstorm, visualize ideas, and collectively work towards solutions in an interactive setting 
• Goal monitoring: Set and monitor business metrics to address challenges, track progress, and ensure the software development team remains aligned with objectives 
• Custom access rights: Customizing access rights ensures that the right individuals have the necessary permissions to contribute to problem resolution 
• ClickUp AI: Use ClickUp AI to automate repetitive tasks, analyze data for insights, and enhance productivity in tackling complex problems 

ClickUp limitations 

• Learning curve is involved in fully grasping all features and capabilities

ClickUp pricing

• Free Forever Plan 
• Unlimited Plan: $7 per month per user
• Business Plan : $12 per month per user
• Business Plus Plan : $19 per month per user
• Enterprise Plan : custom pricing 
• ClickUp AI: $5 per Workspace on all paid plans

ClickUp ratings and reviews

• G2: 4.7/5 (2,000+ reviews)
• Capterra: 4.7/5 (2,000+ reviews)

Omnex’s problem-solving software has many helpful features to track, manage, and solve problems quickly. It’s a one-stop shop for dealing with internal and external issues. 

The platform is also customer-centric, which responds to customers in their preferred formats. This ensures a tailored and user-friendly experience, further enhancing problem resolution through seamless interaction with stakeholders. 

Omnex best features 

• Define timelines and metrics for problem resolution 
• Leverage several problem-solving tools, such as 5Why, Is/Is Not, etc
• Respond to customers in various formats, including 8D, 7D, and PRR

Omnex limitations

• Initiating projects involves many steps
• Temporary delays may occur

Omnex pricing 

• Omnex has custom pricing plans 

Hive is another excellent platform to instruct your teams better while solving complex challenges and enhancing their problem-solving skills. It’s highly interactive and lets all your team members view what’s happening and express their opinions simultaneously. 

Collaborative work management helps you solve issues effectively. Hive is your virtual file cabinet where sharing documents with different teams and collaboratively working becomes more accessible. 

Hive best features

• User-friendly interface ensures seamless navigation
• Gantt view helps in mapping out project timelines
• Project hierarchies allow for easy task execution
• Kanban view allows you to understand progress better

Hive limitations 

• Being a relatively new tool, it needs frequent updates and additional features
• There are occasional bugs that slow down processes
• Locating notes from tasks and meetings is time-consuming
• Auto-generated reports are not always accurate
• Apart from ticketing, the platform needs some intuitive features

Hive pricing 

• Teams: $12 per month per user
• Enterprise: custom plans

Hive customer ratings

• G2: 4.6/5 (480+ reviews)
• Capterra: 4.5/5 (190+ reviews)

Asana is a popular problem-solving tool that speeds up decision-making . It improves project management , and its many integrations are useful. The well-organized project documents make it easy to find what you need quickly.

It’s excellent for managing many small projects and suitable for teams without complex workflows or collaboration features.

Asana best features 

• The rules and workflow feature helps automate repeating activities
• Customizable workflows help teams adapt the tool to their unique needs
• For easy understanding, organize tasks as a list, calendar, timeline, Gantt chart, or Kanban board
• Integrate with popular tools and apps such as Google Drive, Dropbox, Slack, Zoom, Microsoft, etc. 

Asana limitations

• Inefficient for handling larger projects with sub-projects and multiple workstreams
• Limited capability to measure project deviations from original plans
• Lack of comprehensive workflows and customizable animations, a feature some competitors offer
• Pricing is less favorable for smaller teams; advanced features like custom fields, portfolios, and timeline views are only available in premium plans

Asana pricing 

• Personal (free)
• Starter: $10.99 per month per user
• Advanced: $24.99 per month per user 

Asana customer ratings 

• G2: 4.3/5 (9,520+ reviews)
• Capterra: 4.5/5 (12,290+ reviews) 

Mesitertask is one of those problem-solving tools that offers strong kanban boards. These boards visualize the workflow and make it easier to identify bottlenecks and trace issues back to their source. Such visualizing features are similar to the ones found in the best root cause analysis tools . 

A customizable drag-and-drop feature further allows users to rearrange and prioritize tasks easily. Therefore, your team members will easily play around the field and segregate tasks effectively. 

Meistertask best features 

• Gain a visual representation of task timelines with a timeline view
• Streamline processes with automated workflows
• Easily categorize and prioritize tasks within sections 
• Monitor and analyze time spent on tasks for valuable insights

Meistertask limitations 

• Unnecessary negative space impacts task visibility
• Limited report and analytics features, not accessible offline
• Confusing registration process

Meistertask pricing

• Basic (free)
• Pro: $6.50 per month per user 
• Business: $12 per month per user 
• Enterprise: custom pricing 

Meister task ratings and reviews 

• G2: 4.6/5 (170+ reviews)
• Capterra: 4.7/5 (1130+ reviews) 

Teamwork is another viable problem-solving software dealing with operational challenges. It provides a clear overview of task assignments, project profitability, and other essential details. 

When combined with effective brainstorming techniques , such a clear division of work will help you solve complex issues faster. 

Teamwork features 

• Get four distinct project views, including List, Table, Boards, and Gantt
• Efficient task management simplifies the process of creating and assigning tasks to users, enhancing team collaboration  
• The time tracking feature helps determine billable hours, aiding in project budgeting and resource allocation
• Standard communication features, such as commenting and mentioning coworkers, are seamlessly integrated, promoting practical collaboration 

Teamwork limitations 

• You need to subscribe to premium plans to unlock advanced features
• The user interface is intricate and poses a challenge for some users
• Certain features, like the reminder function, do not operate on mobile apps
• Continuous email notifications have the potential to disrupt focus, as not all updates or status changes are crucial

Teamwork Pricing 

• Free Forever
• Starter: $5.99 per month per user 
• Deliver: $9.99 per month per user
• Grow: $19.99 per month per user 
• Scale: custom pricing 

Teamwork Customer Ratings 

• G2: 4.4/5 (1,070+ reviews)
• Capterra: 4.5/5 (830+ reviews)

Trello is another good option if you are searching for efficient problem-solving software. With powerful task management tools, it ensures you handle your issues efficiently. 

However, Trello’s communication and collaboration tools are not up to the mark compared to other problem-solving tools. Also, it relies heavily on integrations to do the heavy lifting.

Trello Features 

• Streamline your workflow effortlessly by arranging tasks with a simple drag-and-drop interface
• The project map feature gives a complete overview to help you visualize tasks, dependencies, and progress at a glance
• Focus on what matters the most and prioritize tasks effectively with its intuitive tools 
• Stay on top of your responsibilities with dynamic to-do lists

Trello Limitations 

• The free version imposes limitations on file attachments, a lack of advanced integrations, and automation
• Manually arranging Trello cards one by one is a time-consuming task
• There is a lack of functionality for creating a comprehensive dashboard or Gantt chart to provide a clear overview
• The absence of restrictions on card movement poses a security risk, with anyone accessing and potentially disrupting the board
• Trello becomes less practical when the board becomes densely populated with cards

Trello pricing 

• Standard: $5 per month per user 
• Premium: $10 per month per user 
• Enterprise: $17.50 per month per user 

Trello customer ratings 

• G2: 4.4/5 (13,000+ reviews)
• Capterra: 4.5/5 (23,000+ reviews)

Wrike is one of the preferred project management collaboration tools that help businesses of all sizes. With preconfigured templates for tasks, workflows, and communication, it takes the burden off your shoulders. 

It also has a user-friendly dashboard with enterprise-grade tools to manage recurring and one-time projects. 

Wrike best features 

• Planning tools to outline tasks, set deadlines, and allocate resources
• A clear visual overview helps in identifying potential challenges
• Detailed reports to analyze project performance
• Helps efficiently address issues by prioritizing tasks

Wrike limitations 

• There are no options to view projects on the Kanban board (only tasks)
• Basic project management features are missing, such as time breaks for a task
• Pricing remains on the higher end

Wrike pricing 

• Professional variant: $9.80 per month per user 
• Business variant: $24.80 per month per user 

Wrike customer ratings 

• G2: 4.2/5 (3500+ reviews) 
• Capterra: 4.3/5 (2540+ reviews) 

Monday is a cloud-based open platform, allowing businesses to collaborate better on projects. Explore many pre-built templates or create one from scratch depending on what you need. 

Monday best features

• Streamline workflows by making bulk changes efficiently
• Plan and organize tasks effectively with powerful scheduling tools
• Keep a detailed record of project activities, providing transparency and aiding in tracking progress, which is critical for troubleshooting and resolving issues
• Gain valuable insights through customizable views and comprehensive reporting, facilitating data-driven decision-making

Monday limitations 

• There is a minimum team size of three required for paid plans 
• The free trial lasts only for 14 days
• Advanced features like time tracking are only available in premium plans 

Monday pricing 

• Basic: $8 per month per user 
• Standard: $10 per month per user 
• Pro: $16 per month per user 
• Enterprise: custom pricing

Monday customer ratings

• G2: 4.7/5 (9,570+ reviews)
• Capterra: 4.6/5 (4,430+ reviews)

Airtable is a cloud-based collaboration platform that combines the simplicity of a spreadsheet with the complexity of a relational database.

It allows users to create and manage databases, spreadsheets, and other types of structured data in a flexible and user-friendly way. With its user-friendly interface,  you will quickly organize and track crucial information for problem-solving. 

Airtable best features

• Supports real-time collaboration 
• Attach files, images, and other multimedia directly to records
• Highlight and format cells based on specific conditions with conditional formatting
• Use pre-built templates for different use cases 

Airtable limitations

• While the interface is user-friendly, users unfamiliar with databases may find it initially complex
• For extremely large datasets or complex relationships, Airtable may face performance challenges
• As a cloud-based platform, it relies on an internet connection, and lack of connectivity may hinder problem-solving efforts

Airtable pricing 

• Team: $20 per month per user
• Business: $45 per month per user 

Airtable customer ratings

• G2: 4.6/5 (2,180+ reviews)
• Capterra: 4.7/5 (1920+ reviews)

Solve Problems to Drive Successful Business Outcomes

It is best to invest in problem-solving software to ensure that problems do not bog down your team and that you have the tools to solve and focus on strategic work. Our list of the ten best problem-solving software should help you find the right fit for your organization. 

Thousands of businesses of all sizes choose ClickUp. With ClickUp, you get different tools to map your project, divide tasks, view the interdependence of tasks, allocate resources, and resolve bugs on time. Whether improving team productivity or identifying and squashing bugs, ClickUp does it all!  

Get in touch with our team, or sign up for FREE .

Questions? Comments? Visit our Help Center for support.

Receive the latest WriteClick Newsletter updates.

Thanks for subscribing to our blog!

Please enter a valid email

• Free training & 24-hour support
• Serious about security & privacy
• 99.99% uptime the last 12 months

How to Learn the Fundamentals of Software Engineering – in a More Interesting and Less Painful Way

This article is intended to be an introductory guide to the fundamentals of software engineering.

I have written it with the assumption that you, dear reader, may not know much about the basics of the field, why they are important, and when you should bother to learn them.

We shall go into each of these questions and finish by discussing some ways in which I recommend you learn and approach them.

For those who do happen to be familiar with this subject, there may still be some interesting new perspectives, and particularly in the last section, useful ways to speed up your learning process.

In this article we will discuss:

• What made software engineering spooky and intimidating for me, and how that changed
• The reason for, and metrics by which we look at some code and conclude that it is less efficient than another approach (computational complexity)
• A simple but hopefully useful introduction to Data Structures and Algorithms
• The things I personally do to learn topics in software engineering for maximum efficiency and understanding
• A way to motivate your efforts by adding in some basic tests to measure correctness and efficiency of your algorithms

Please be aware that I have tried to structure this article in a logical progression where each section (apart from the next which is more about getting over the fear of diving into this subject) builds upon or motivates the next.

I am condensing over a thousand hours of practice and study into one article, and have done my best to explain things clearly and simply as well.

Where The Problems Began

Throughout my limited formal education, I did not have the best relationship with the field of mathematics. And by extension, this impacted my relationship with a great deal of computer science (CS) and software engineering (SEng).

To be specific, it is not that I am bad at math, but I am poor at arithmetic and bad at remembering formulae.

I also found that the way in which mathematics, CS, and SEng are usually taught in schools does not tend to work for me either.

My own learning process to this day is largely driven by pragmatism (emphasis on practical over theoretical knowledge), curiosity about nature, and how this information can help me earn a living – three things I saw rarely emphasized in my western education.

Apart from my uneasy relationship with dry and boring presentations of things which are predominantly of a mathematical nature, I am a self-taught programmer.

To be clear, I took a single programming class at a community college (circa 2013), and the rest of my knowledge comes from self-directed studies. During my early years of that process, I also had to work various day jobs in order to pay the rent, which left me very little spare time and energy to learn my craft.

The end result was that I chose to spend most of my time building personal projects and learning topics specifically for those projects.

This led to me being really quite good at the skill of writing code, learning new technologies, and solving problems. However, if I did apply any concepts in CS and SEng to the code I was writing, it was largely by accident. To summarize this introduction, I am trying to say that the biggest obstacle in my study of SEng was that I just was not very interested in learning it.

I did not know the sense of accomplishment you can get from making a small change to an algorithm which reduces its runtime to completion by a factor of tens or hundreds of times.

I did not know how important it was to pick a data structure based on the nature of the problem I was trying to solve, let alone how to make that decision.

And I had no idea how it was relevant to me slinging mobile apps for a living.

So just in case you are in the same boat, before we get to the technical details, I would like to attempt to answer some of those questions for you. To make things less boring, I will motivate this topic by sharing a true story about what changed my attitude towards this subject.

Swimming With the Big Fish

Towards the end of 2019, I had taken a break from studying Android Development in order to take a deep dive into UNIX Operating Systems and C/C++ programming.

I felt very comfortable with the Android SDK, but many years of JVM programming had left me with a strong sense of having no idea how computers actually worked under the hood. Which bothered me quite a bit.

I was not really looking for work, but at the time a recruiter from a big tech company had reached out to me about my interest in an Android Software Engineer position.

Despite being many months out of practice with Android, I did well in the first interview (it was all core Android concepts that I was familiar with) and was sent an email detailing the topics to be covered in future interviews.

The first section of this email, which detailed Android specific knowledge, was extensive, but I was at least somewhat familiar which most topics and not intimidated. However, when I scrolled down to the section on Data Structures and Algorithms, I suddenly felt like I did when I first started writing code: Like a fish out of water. It is not that I had never applied any of these concepts in my code, but I certainly had not formally studied any of them.

Although I will do my best to give you a soft and clear introduction to these topics, SEng will immediately hit you with a wall of jargon terms, and my face was figuratively very sore and bruised after reading the entire list of DS and Algos I had to learn in that email.

I was very up front about that with my recruiter, who kindly gave me four weeks to prepare before the next interview.

I knew I could not cover every topic in four weeks, but I did hope that learning a year or two of SEng in a few weeks would show some talent and initiative.

I would love to tell you a juicy story about how I epically failed, or completely dazzled in the next interview, but the reality is that things fell apart before I even got the chance.

I am a Canadian citizen, and the position required relocation to one of many campuses in the United States, in either California or Washington State.

Two weeks into my first deep dive into SEng, I received an email from my recruiter stating that their immigration department did not want to sponsor me. I suspect it had to do with some difficulties around sponsoring a worker who had no degree, but the brewing global pandemic may also have been a factor.

In the end, even though I wanted the chance to succeed or fail in real time, I was happy knowing that I had a very clear idea of the knowledge I was lacking to be a software engineer in a big tech company.

With a clear but difficult path in front of me, I resolved to no longer let the field of SEng intimidate me. I wanted to know what it truly means to be a software developer versus a software engineer.

With that in mind, we shall go into the core ideas in SEng, and how to make the learning of them easier. Not easy – just easier.

The "Big Three" Topics in Software Engineering –And Why They Matter

The main topics in software engineering can be summarized using a bunch of big scary words and phrases – as is the tradition in anything related to computer science and mathematics. To avoid confusion, I will instead explain them using the English language and examples which prioritize clarity above all else.

I suggest you follow this section in the order I have laid out, as I have deliberately structured it in a logical progression.

First - What Are Runtime And Memory Space?

I want to start off by explaining the reason why we study these topics to begin with.

Being a fan of physics, I was happy to learn that the interplay of time and space which we see in nature is also directly observed in any kind of computer.

However, in this field, we refer to these qualities as runtime and memory space .

To better understand what runtime is, I suggest you pull up your Task Manager, Activity Monitor, or whatever program you have that tells you about your system’s active “processes.”

A process is just a “running program,” and through the magic of having multiple “processors”, CPU virtualization, and time slicing, it can appear that we have tens or hundreds of processes running at the same time.

I threw those jargon terms in so that you can look them up if you are curious about how operating systems work, but doing so it is not necessary to proceed with this article. In any case, a process’s runtime can generally be thought of as any point in time during which it can be viewed in your system’s process tracking tool.

I use this definition to point out that an active process does not need to have a user interface or even do anything useful even though it may still be taking up runtime in the CPU and memory space.

Speaking of memory space, in order for something to have run time, it has to be somewhere too. That somewhere is the physical memory space of the computer, which is virtualized (again, look up virtualization on your own time but it is not necessary for this article) in order to make it more secure and easier to use.

Every process is allocated its own distinct and protected virtual memory space, which can grow or shrink up to certain boundaries and depending on various factors. Let us take a break from theory to talk about why we should care about it. Since runtime and memory space can be accurately measured but are also limited , humans like you and I can really screw things up if we do not pay attention to these limitations!

To be clear, here are two very important things we want to care about as programmers and engineers:

• Will our program or even the whole system crash because we have mismanaged the finite resource of memory space ?
• Will our programs solve problems for our users in a timely and efficient manner , or will they hang so long that our users decide to force quit, demand a refund, and leave a nasty review?

These question largely dictate the success of our programs whether you formally study them or not. With any luck I have motivated you to learn what I call the big three topics in software engineering, which we shall go into now.

How We Measure Runtime And Memory Space

The first of the big three topics is described using a big scary term: Asymptotic Runtime & Space Complexity .

Having already described runtime and memory space, I think a serviceable replacement for the word complexity here is “efficiency." And asymptotic is related to the fact that we can represent this efficiency (or lack thereof) on a two dimensional Cartesian Graph. You know, x and y , rise over run, and all that stuff.

Do not worry if you are unfamiliar with this stuff. You only need a very basic understanding of these things to apply it in your code.

Also, note that there is such a thing as a Graph data structure , but that concept is far removed from a Cartesian Graph and not what I am referring to.

Since we can represent our code and how it behaves with respect to either runtime or memory space on a Cartesian Graph, it follows that there must be functions which describe how to draw such a graph .

The way in which we describe how efficient our code in this way is to use “Big O” notation.

Here is the simplest introduction I can give you in order to understand this topic. I will use the modern programming language Kotlin for my code samples which will hopefully provide a happy middle ground for you web and native developers.

Suppose three functions (also sometimes known as methods, algorithms, commands, or procedures):

Function printStatement :

Function printArray :

Function printArraySums :

For ease of understanding, suppose that every time println(...) is called, it takes 100ms, or 1/10th of a second on average to complete (in reality 100ms for a single print command is terribly slow but it's easier to imagine than a microsecond or picosecond).

With that in mind, let us think critically about how these functions can be expected to behave differently , based on what inputs they are given .

printStatement , barring anything other than a catastrophic failure of the system itself, will always take an average time of 100ms to complete.

In fact, while Big O notation is very concerned about the size of the arguments given to a function (that will make more sense shortly), this function does not even have any arguments to change its behaviour.

Therefore, we can say that the runtime complexity (time taken until completion), is constant , which can be represented by the following mathematical function and graph:

In the above graphic, T represents the runtime for println(...) which we established to be an average of 100 milliseconds. I will explain what n refers to momentarily.

printArray presents a new problem. It stands to reason that the time it takes for printArray to complete will be directly proportionate to the size of the Array, arr , which is passed into it.

If the Array has four elements, that would result in println(...) being called four times, for a total average runtime of 400ms for printArray itself. To be more mathematically precise, we would say that the runtime complexity of printArray is linear :

printArraySums takes things a step further into something which you should be concerned about even as a junior or intermediate level developer. The number of arguments/inputs to any given function is referred to with a small n, when using Big O notation.

In our second function, this refers exclusively to the size of the Array (that is, arr.size ), but in the third function it refers to the collective size of multiple arguments (that is, arrOne and arrTwo ).

In Big O notation, there are actually three different qualities of a given piece of code that we can pay attention to:

• How efficient is the code if n is small (best-case performance)?
• How efficient is the code if n is of an average expected size (average performance)?
• How efficient is the code if n is near or at the its maximum allowable value for the system (worst-case performance)?

Generally speaking, in the same sense that a civil engineer is most concerned about the maximum number of vehicles a bridge can support, a software engineer is usually most concerned about worst-case performance.

By looking at printArraySums , you should be able to reason that we can represent its worst-case runtime complexity (the number of times println(...) will be called) as n * n; where n is at or near to the maximum allowable size of an Array in the system.

In case it is not clear, we are not just pairing and summing the elements of arrOne and arrTwo at the same indexes, we are literally summing every value of them together in a nested loop .

From here you can start to truly understand the importance of asymptotic runtime and space complexity. In a worst-case scenario, the runtime grows exponentially in a quadratic curve:

Two final notes on this topic: Firstly, if I suddenly made you a bit fearful of nested loops (and yes, each nested loop potentially adds another factor of n ), then I have done a good job.

Even so , understand that if you are certain that n will not exceed a reasonable size even in a function which has exponential growth, then there is not actually a problem .

If you would like to know how to determine if n will have a negative impact on performance, stick around for the last section of this article.

Secondly, you may have noticed that all of my examples were about runtime complexity, not memory space complexity.

The reason for this is simple: We represent space complexity in exactly the same manner and notation. Since we do not actually allocate any new memory apart from a temporary reference or two within each frame of the forEach{...} loops, asymptotically speaking , the second and third functions are still linear, O( n ), with respect to memory allocation.

Data Structures

The term Data Structure, despite what any single teacher may tell you, does not have a singular definition.

Some teachers will emphasize their abstract nature and how we can represent them in mathematics, some teachers will emphasize how they are physically arranged in memory space, and some will emphasize how they are implemented in a particular language specification.

I hate to tell you this, but this is actually a very common problem in computer science and engineering: One word meaning many things and many words meaning one thing, all at the same time.

Therefore, rather than trying to make every kind of expert from every kind of academic or professional background happy by using a plethora of technical definitions, let me upset everyone equally by explaining things as clearly as I can in plain English .

For the purposes of this article, Data Structures (DS) refer to the ways in which we represent and group together our application’s data in our programs. Things like user profiles, friends lists, social networks, game states, high scores and so on.

When considering DS from the physical perspective of the hardware and operating system, there are two main ways to build a DS. Both ways take advantage of the fact that physical memory is discrete (a fancy word for countable), and therefore addressable.

An easy way to imagine this is to think about street addresses and how, depending on which direction you are physically moving (and depending on how your country organizes street addresses), the address increases or decreases in value.

Physical Array

The first way takes advantage of the fact that we can group pieces of data (for example a list of friends in a social media application) into a chunk of contiguous (physically next to each other) memory space.

This turns out to be a very fast and efficient way for a computer to traverse memory space. Instead of giving the computer an n sized list of addresses for each piece of data, we give the computer a single address denoting the start of this DS in physical memory, and the size of (that is, n ) the DS as a single value.

The instruction set for doing this could be as simple as telling the machine to move from left to right (or whatever direction), decrement the value of n by 1 each move, and to stop/return when that value hits 0.

Lists Of Links (Addresses)

The second way requires each piece of data in the structure itself to contain the address(es) of the next or previous (maybe both?) item within itself.

One of the big problems with contiguous memory spaces is that they present problems when it comes to growing (adding more elements) or shrinking (this can fragment the memory space, which I will not explain but suggest a quick google search).

By having each piece of data Link to the other pieces (usually just the previous or next one), it becomes largely irrelevant where each piece sits in physical memory space. Therefore, we can grow or shrink the data structure with relative ease. You should be able to reason that since each part of the structure stores not just its own data, but the address of the next (or more than that) element, then each piece would necessarily require more memory space than with the contiguous Array approach.

However, whether it is ultimately more efficient depends on what kind of problem you are trying to solve.

The two approaches I have discussed are generally known as an Array and a Linked List . With very little exception, most of what we care about in the study of DS is how to group collections of data which have some kind of reason to be grouped together, and how best to do that.

As I tried to point out, what makes one structure better in a certain situation can make it worse in another.

You should be able to reason from the previous few paragraphs that a Linked List is typically more suitable for a dynamic (changing) collection, whereas an Array is typically more suitable for a fixed collection – at least with respect to runtime and space efficiency .

Do not be misled, however! It is not always the case that our primary concern is to pick the most efficient DS (or algorithm) with respect to runtime and memory space. Remember, if n is very small then worrying about a nanosecond or a few bits of memory here and there are not necessarily as important as ease of use and legibility.

The last thing I would like to say about DS is that I have observed a profound lack of consensus about the difference between a DS and a Data Type (DT).

Again, I think this is largely due to different experts approaching this from different backgrounds (mathematics, digital circuits, low level programming, high level programming) and the fact that it is really quite hard to make a verbal definition of one that does not at least partially (or entirely) describe the other.

At the risk of making the situation even more confusing, on a purely practical level , I think of data structures as things which are independent of a high level programming language’s Type System (assuming it has one). On the other hand, a data type is defined by and within such a Type system.

But I know that Type Theory itself is independent of any particular Type system, so you can hopefully see how tricky it is to say anything concrete about these two terms.

I took quite a long time to explain the previous two topics because they allow me to introduce and motivate this topic rather easily.

Before we continue, I must very briefly try to untangle another mess of jargon. To explain the term “algorithm” in my own way, it is actually very simple: An algorithm is a set of instructions (commands) which can be understood and executed (acted upon) by an Information Processing System (IPS).

For example, if you were to follow a recipe to cook something, then you would be the IPS, the algorithm would be the recipe, and the ingredients and cookware would be the data inputs (arguments).

Now, by that definition the words function, method, procedure, operation, program, script, subroutine and algorithm all point to the same underlying concept.

This is not by accident – these words all fundamentally mean the same thing. The confusion is that different computer scientists and language designers will implement (build) the same idea in a slightly different way. Or even more depressingly, they will build them the same way but give a different name. I wish this was not the case, but the best I can do is to warn you.

That is all you need to know about algorithms in general, so let us be more specific about how they can help us to write better code.

Recall that our primary concern as software engineers is to write code which is guaranteed to be efficient (at least such that it keeps our users happy) and safe with respect to limited system resources.

Also recall that I previously stated that some DS perform better than others with respect to runtime and memory space, particularly as n gets large.

The same is true of algorithms. Depending on what you are trying to do, different algorithms will perform better than others.

It is also worth noting that the DS will tend to shape which algorithms can be applied to the problem, so selecting the right DS and the right algorithm is the true art of software engineering.

To finish off this third main topic, we will look at two common but very different ways to solve the one problem: Searching an ordered Array . By ordered, I mean to say that it is ordered something like least to greatest, greatest to least, or even alphabetically.

Also, assume that the algorithm is given some kind of target value as an argument, which is what we use to locate a particular element. This should become clear in the example in case there is any confusion.

The example problem is as follows: We have a collection of Users (perhaps loaded from a database or server), which is sorted from least to greatest by a field called userId, which is an Integer value.

Suppose that this userId comes from taking the system time (look up Unix Time for more info) just prior to creating the new User. Rounded to the smallest value that still guarantees no repeated values.

If that previous sentence did not make sense, all you need to know is that this is a sorted collection with no repeats.

A simple way to write this algorithm would be to write what we will call a Naive Search (NS). Naive, in this context, means simple, but in a bad way , which refers to the fact that we just tell the computer to start from one end of the collection and move to the other until it finds a match to the target index.

This is generally achieved by using some kind of loop:

Function naiveSearch :

If we happen to only have a few hundred, or even a few thousand users in this collection, then we can expect this function to return quite quickly all the same.

But let us assume we are working in a successful social media tech start up, and we have just hit one million users.

You should be able to reason that naiveSearch has O( n ) asymptotic complexity as its worst case runtime complexity. The reason in short is that if the target User happens to be located at n , then we must invariably traverse the entire collection to get there.

If you are not already familiar with the Binary Search (BS) algorithm, then you should prepare to have your mind blown.

What if I told you that by using a BS algorithm to search our collection with one million elements, you will only ever make, at most, 20 comparisons? That is right; 20 comparisons (as opposed to 1 million with NS) is the worst case scenario .

Now, I will explain how BS works in principle, but my one piece of homework for you to do is to implement it in your preferred programming language. It may be that the language you choose already has a BS implementation from its standard library, but this is an important learning exercise!

In principle, rather than searching an ordered collection one by one, unidirectionally, we start by looking at the value at index n /2. So in a collection with 10 elements, we would check the fifth element. The ordering is important, because we can then compare the element at n /2 with our target:

• If the value of that element is greater than the target, we know that the element we want must be located earlier in the collection
• If the value of that element is less than the target, then we know that the element we want must be located further ahead in the collection
• You should be able to guess what happens if we have a match

Now, the idea is that we are cutting the dataset in half every iteration. Suppose the value at element n /2 was less than our target value. We would next select the middle index between n /2 and n .

From there, our algorithm keeps slicing back or forth using the same logic over a smaller and smaller range of indexes in our collection.

This brings us to the beauty of the BS algorithm applied to a sorted collection: Rather than the time it takes to complete growing linearly, or exponentially with respect to n , it grows logarithmically:

If this article really is your first introduction to the main ideas in software engineering, then please do not expect everything to make sense immediately.

While I hope that some of my explanations helped, my primary goal was to give you a basic list of ideas to study yourself, and what I believe to be a good order in which to study those ideas.

The next step for you is to make a plan for learning this field, and to take action on it. The following section is all about how to do that.

How to Learn Software Engineering – Some Practical Advice

I will now discuss some ideas and approaches which I have personally used to make the process of learning various DS and algorithms easier (but not easy!), both practically, and from motivational perspective.

I am confident that there will at least be one or two points here which will be useful (assuming you have not already arrived at them yourself), but I also want to emphasize that our brains might work slightly differently. Take what is useful and throw away the rest.

As a learning aid, you might also want to watch my live lesson on youtube where I cover this topic. Do not skip the rest of this article though; I go into much more detail here!

Follow A Project-Based Learning Approach

This is actually the first thing I tell any new programmer who asks me the “best way” to learn how to code. I have given a longer version of this explanation many times, but I will summarize the general idea.

In any field of programming, you will notice that there is an incredibly large number of topics to study, and the field itself is constantly evolving both for academics and industry professionals.

As I mentioned in the introduction, not only did I have no curriculum to guide my studies, but I also had limited time to study because I had rent due at the end of each month. This led me out of sheer necessity to develop and follow my project based learning approach.

In essence, what I suggest you do is to avoid learning DS & Algorithms by simply studying things topic by topic and just taking notes about each one.

Instead, you will start by picking a basic topic (like the ones I covered before) and immediately writing a code snippet or small application which uses it.

I created a repository which had a package for every family of DS & algorithm that I wanted to learn. For general algorithms it was mostly the sorts and searches (Bubble Sort, Merge Sort, Quick Sort, Binary Search, and so on). For more specific DS like Linked Lists, Trees, Heap, Stack, and others, I wrote both the DS itself and a few algorithms specific to that particular DS.

Now, I found that some kinds of DS were difficult to understand and implement at first.

One family of DS which gave me trouble for quite some time were called “Graphs.” The field in general is full of some particularly awful and overloaded jargon, but this particular topic even has a misleading name (hint: a better name would be “Networks”).

After spinning my wheels for several weeks (although in fairness I was learning this on the side), I finally admitted to myself that I needed a clear reason to use this DS in some application code. Something to justify and motivate the many hours I was going to spend learning this topic.

Having previously built a Sudoku game using algorithms that worked with two and one dimensional Arrays, I recalled reading somewhere that it was possible to represent and solve a Sudoku game using an Undirected Colored Graph .

This was incredibly useful, as I was already familiar with the problem domain of Sudoku, so I could focus intensively on DS and algorithms.

While there is plenty more that I have to learn, I cannot describe how satisfying it was when I wrote an algorithm that generated and solved 102 Sudoku puzzles in 450 milliseconds.

Speaking of, let me talk about another way to write better algorithms which can also be a great source of motivation and goal setting.

Test Your Code

Look, I know many people make the subject of testing a complete nightmare for beginners. This happens because they confuse the very simple idea of how to test code with some very elaborate and confusing tools one can optionally use to test their code. But this one is important so please stay with me.

To go back to basics, without even talking about Big O notation, how do we know if one algorithm is more efficient than another? Of course, we have to test them both.

Now, it is important to mention that benchmark tests can give you a good (or even great) general idea, but they are also strongly influenced by the system in which they are tested.

The more precise your tests need to be, the more concerned you will need to be about your test environment, set up, and accuracy. However, for the kind of code I typically write, a good general idea is all I need.

There are two kinds of tests which I find most useful for when I am writing my algorithms, both for practice and production code. The first kind of test answers a very simple question: Does it work?

To take an example from my Graph Sudoku application, one of the first hurdles for me was to build what is called an Adjacency List for Sudokus of varying sizes (I tested 4, 9, 16, and 25, which are, not by accident, perfect squares (mathematically speaking).

I cannot explain what an Adjacency List is in detail, but think of it conceptually as a Network of nodes and lines (called edges for some reason). In practice, it forms the virtual structure of the “Graph.”

In the rules for Sudoku, every column, row, or subgrid of numbers may not contain any repeats. From these rules, we can deduce that in a 9x9 Sudoku, there must be 81 nodes (one for each number), and each node ought to possess 21 edges (one for every other node in a given column, row, or subgrid).

The first step was to simply check to make sure that I was building the correct number of nodes:

The algorithm for that was really quite easy to write, but things were slightly more difficult for the next one.

Now I needed to, as they say in Graph jargon, build the edges . This was a bit trickier as I had to write some algorithms to select for rows, columns, and subgrids of dynamic size. Again, to confirm that I was on the right track, I wrote another test:

Sometimes I followed the Test Driven Development (TDD) approach and wrote the tests before the algorithms, and sometimes I wrote the tests after the algorithms.

In any case, once I was able to verify the correctness of each algorithm to the point that I was generating a solved, variably sized Sudoku puzzle, it was time to write a different set of tests: Benchmarks!

This particular kind of benchmark testing is quite blunt, but that is all I needed. To test the efficiency of my algorithms, which at this stage could build and solve a randomly generated Sudoku, I wrote a test which generated 101 Sudoku puzzles:

Initially I had two calls to System.nanoTime() immediately before and after generating 100 puzzles, and subtracted the difference to get an unintelligible number.

However, my IDE also kept track of how long a test would take to complete in minutes, seconds, and milliseconds, so I eventually just went with that. The first set of benchmarks (for 9x9 puzzles) went as follows:

Although I did not have much of a reference point, I knew that it was taking longer than a second to generate a 9x9 Sudoku, which was a very bad sign .

I was not happy about how I was preloading the Graph with some valid numbers ahead of time, so I decided to refactor my approach there.

Naturally, the result after thinking up a new way to do that was worse:

After quite a few more benchmarks which seemed to get slightly worse over time, I was pretty demoralized and wondering what to do.

I had what I thought was a very ingenious way to make my algorithm more or less picky based on how certain it was about placing a number into the puzzle. It was not working out so well in practice, though.

As is often the case, on roughly the 400th pass of my code via a code stepper (part of a debugging tool), I noticed that I had a slight mistake which had to do with how I was adjusting the value which dictated how picky my algorithm was.

What happened next blew my mind.

I ran another benchmark test, and got a weird result:

I was in complete disbelief, so the first thing I did was to undo the change I just made and rerun the test. After 5 minutes I stopped the test as this was clearly the game changing difference, and proceeded to run five more benchmarks:

Just for the hell of it, I decided to try building 101 16x16 puzzles. Previously I couldn't even build one of these (at least I stopped trying after the test ran for 10 minutes):

The point I am trying to communicate is this: It is not just that writing tests allowed me to verify that my algorithms were working . They allowed me to have an objective way to establish their efficiency.

By extension, this gave me a very clear way to know which of the 50 different tweaks to the algorithm I made actually had a positive or negative effect on the outcome.

This is important for the success of the application, but it was also incredibly positive for my own motivation and psychological health.

What I did not yet mention is that the time it took me to get from the first benchmark to the fifth (the fast one), was approximately 40 hours (four days at 10 hours per day).

I really was quite demoralized by the fourth day, but when I finally tweaked things the right way, it was the first time I ever felt like a real software engineer instead of just someone studying it for fun.

To leave you with a great image, after I ran the 16x16 tests and saw they were promising, I took a full 15 minutes to run around my rural property hollering like an excited chimpanzee that just got dosed with adrenaline.

My Final Suggestion

I will keep this one short and sweet. The worst thing you can do as a student, upon not being able to understand something difficult and complicated, is to blame yourself.

Good teachers and explanations are rare, and this is particularly true of topics which most of us find relatively dry and boring.

I had to watch approximately four videos, read approximately five articles/textbook chapters, and blindly dive into writing some code which did not initially make sense to me, just to even get started with Graphs .

This may be good or bad news for you, but I work very hard at what I do, and I very rarely find things in my field which are natural or easy for me.

My goal with this article has never been to imply that learning software engineering was easy for me, nor that it will be easy for you.

The difference is that I am told from time to time that I explain things well, and that unlike people who just regurgitate what other teachers say, I put the time in to find out what works or does not work for me, and try to share that with you. I truly hope that something in this article was useful for you. Good luck with your learning goals, and happy coding!

Before you go...

If you like my writing, you will probably like my video content. I create everything from dedicated tutorials on specific topics, to weekly live Q&A sessions, to 10+ hour coding marathons where I build an entire application in one sitting .

Self taught programmer specializing in Object Oriented Design and Clean Software Architecture. Currently Professional Android Engineer.

If you read this far, thank the author to show them you care. Say Thanks

Learn to code for free. freeCodeCamp's open source curriculum has helped more than 40,000 people get jobs as developers. Get started

• Dev Concepts

How to Build and Use Problem-solving Skills [Dev Concepts #41]

Home » News » Dev Concepts » How to Build and Use Problem-solving Skills [Dev Concepts #41]

• Author: Nikol Ruseva
• July 22, 2022
• No Comments
• algorithmicthinking , devconcept , developerskills , logicalthinking , problemsolving , programming , software engineering

To become a skilful developer means not only being familiar with a programming language or software but also having a set of skills that are fundamental to the software development process. These skills can be classified into four groups :

• Coding skills;
• Algorithmic thinking and problem solving skills;
• Fundamental software development concepts;
• Programming languages and software technologies.

Technical Skills

The skill of coding is knowledge of the basic concepts of programming. They are universal and once learned, can be applied in many programming languages. The programming language does not matter to the ability to code.

You need to know how to:

• Use development environments (the so-called IDEs) and developer tools;
• Work with variables and data, calculations, conditional statements, loops and data structures;
• Use functions, methods, classes and objects, programming APIs and libraries;
• Troubleshoot and debug code.

Now that you are familiar with the foundations of programming, you need to put that knowledge together and plan every step of finding a solution to a problem. This will require your algorithmic thinking and problem-solving skills . 

Algorithmic thinking is the ability to break a problem into a logical sequence of steps (called “algorithm”), to find a solution for every step (or break it further into sub-steps) and then assemble these steps into a working solution. 

Algorithmic thinking is similar to logical, engineering, mathematical, abstract, and problem solving. All these concepts are related to the ability to solve problems : to think logically, analyse the problems, and find and implement solutions. Problem solving is a more general skill , while algorithmic thinking is a more technical .

The fundamental computer science and software development concepts include many programming paradigms, essential software development knowledge and skills, and software engineering principles and concepts that developers typically acquire as they gain experience over time.

Some of these knowledge areas and concepts are:

• Object-oriented programming (OOP);
• Functional programming (FP);
• Asynchronous programming ;
• Relational and non-relational databases;
• The concepts behind the Web technologies.

To implement your knowledge you need to be familiar with programming languages, software development technologies, software platforms, software libraries, development frameworks and developer tools.

On the graphic below you can see an example technology stack for a Java developer.

Technologies are ever-changing and evolving , but these four groups of skills described above represent essential and stable knowledge since they will not change significantly over time. In fact, technologies are highly dependent on these skills.

Soft Skills

Soft skills are as important as the ones described above. They include the ability to communicate with people and work in a team which is essential since you as a developer will work on projects with your colleagues. You need to manage your time effectively, to be empathetic , adaptable and creative . Having attention to detail will increase your productivity at work and reduce the chances of error.

Tech Problem Solving

In the IT industry, a tech problem is often an assignment to design and implement a set of functionality which has certain input data and program state and produces output data and program state. 

Every tech problem has a goal . In programming, the goals are to design and write a working code , build an app or software system, which corresponds to the assignment and implement its requirements and functionality. Developers may encounter certain technical difficulties or limitations in designing and implementing the required functionality, like lack of resources, experience or knowledge. The process of problem solving includes finding a way to overcome these difficulties. This can be, for example, learning a new programming language, software library or framework.

Stages of Problem Solving

How to approach a tech problem? You can see in the graphic below seven stages of resolving a problem.

First of all, you need to define the problem. This involves gathering the requirements of the assignment.

After that, you analyse them. Here you should think about constraints, objects, processes and potential obstacles related to the problem. Based on a deeper understanding of the problem, you can extract the important information from the requirements and discard the non-important information, and explore its properties, which will be useful for building a solution.

The next step is to identify several solutions. You try to generate and explore different ideas and technical approaches on how to build a well-working solution. Then you analyse these ideas, their correctness, their strengths and weaknesses, their practical applicability and the costs of their implementation.   

After you have gathered some ideas you need to choose one of them. This is a decision-making process and depends mainly on the requirements, your capabilities and available resources.

After that, you need to plan and describe your actions for executing the chosen solution. You plan your algorithm. Technically, this means to write the definition of several functions, methods or classes, which will implement the chosen idea.

Sometimes planning of the algorithm is done together with its implementation, and there is no clear separation between the stages of algorithm design and algorithm implementation.

Once you have a clearly defined algorithm, you implement it . This means writing code to execute the planned steps. In software development, the implementation process includes also testing and debugging.

The last stage of problem solving is to review the results or test the solution with different input data and conditions. For software problems and apps, you need to perform testing of the code, feature by feature: to check for usual and unusual input data and conditions, check for edge cases and special cases.

Tips for Solving Problems

When it comes to solving a tech problem, the first and foremost important thing is understanding it. Take your time to read and analyse it thoroughly. Do not start to code immediately, because if you have not read the problem carefully, there is a chance of making hasty assumptions about the requirements.

Use a sheet of paper or other visualization tools . This will help you sketch your ideas fast and will improve your logical thinking. Squared paper is preferable. It works best for algorithmic problems. It helps build drawings, diagrams, tables and coordinate systems.

Write down the given input and the required output. For example, if your task is to find all odd numbers of a given array ask yourself some questions:

• What do I have?  →  An array and odd numbers.
• What is an array and how does it work? What is an odd number? What data type should I use to store it?  →  These questions will help you understand the problem .
• What is the end goal? → To filter odd numbers in the array and return it.
• How can I do it?  →  You may have multiple answers to this question and they are your potential solutions . Write them down, compare their advantages and disadvantages and then choose one of them.

After you implement the code test and debug it if needed. Make sure that you have covered all cases . Then look back and try to optimize and simplify your code making it easier to understand.

Lesson Topics

• Technical Skills;
• Soft Skills;
• Definition of a Tech Problem;
• Stages of Problem Solving;
• Tips for Solving Problems.

Lesson Slides

Leave a comment cancel reply.

You must be logged in to post a comment.

Recent Posts

Case Study 2023: SoftUni Serbia [SoftUni Globe]

Shelly Academy: Autumn Semester [SoftUni Globe]

Franchise partnership: softuni serbia [softuni globe].

Empowering Home Automation: The Collaboration between SoftUni Global and Allterco [SoftUni Globe]

About softuni.

SoftUni provides high-quality education, profession and job to people who want to learn coding.

The SoftUni Global “Learn to Code” Community supports learners with free learning resources, mentorship and community help.

SoftUni Global is the international branch of SoftUni, the largest tech education provider in South-Eastern Europe. We empower the IT business through talent acquisition and development, educators through learning content and tools, and individuals through organized zero-to-career programs for developers.

• Services for Business
• Hire a Junior Developer
• Train to Hire
• Online Learning
• On Site Learning
• Technical Assessment
• Build an Academy
• Services for Educators
• Educational Content
• Educational Software
• Educational Services
• Course Catalog

Individuals

• Learning Resources
• Learn to Code Community
• About SoftUni Global
• Privacy Policy
• SoftUni Fund
• Code Lessons
• Project Tutorials

HTML Sitemap

Carnegie Mellon University Africa

04-330   Fundamentals of Software Development & Problem Solving

Location: Africa Units: 12 Semester Offered: Fall

Course description

This course lays the foundations for approaching problem-solving in a logical, well-designed approach and implementing solutions to a range of technical problems with well-written, high-quality, and extensible software using the basic “best practices” used in the field of software engineering.

Topics include algorithm development, problem-solving (decomposition and synthesis), program design, data representation, arithmetic and logical expressions, input/output operations, basic user interfaces, and object-oriented programming and design, with an emphasis on developing good programming habits. Intensive programming assignments are required.

Learning objectives

The programming will involve understanding and analyzing a set of requirements for a problem, formulating a solution, and implementing that solution on the computer along with tests that show that the program achieves its goals.

The successful student will be able to:

• Understand a basic Computer-Science approach to problem-solving, including algorithm development and proper testing.
• Demonstrate proficiency in programming using a modern programming language.
• Apply these problem-solving techniques and programming skills to develop software solutions to solve a wide range of technical problems.

Content details

• Classes, objects, methods, strings
• Control Statements
• Arrays, array lists
• Inheritance, polymorphism
• GUIs, graphics
• Files, streams

Prerequisites

None. It is expected that students will enroll only if they have no programming background whatsoever or have been recommended because they are unable to code in a programming language at an acceptable level. Prospective students who have already taken a programming course or are unsure of their abilities should consult the instructor prior to enrollment.

Ahmed Biyabani

• Class Notes

Digital Exclusives

• Blog Network
• School News
• Alumni Spotlight

Breaking Gender Barriers in the Board Room

How Ellen Stafford-Sigg WG88 influenced the leadership of Deloitte over 35 years

Using GenAI as a Collaborative Teammate

The technology can fill critical gaps and build trust.

A Wharton Legend Wows the Crowd at Impact Tour NYC

Emeritus finance professor Jeremy Siegel brought the audience back to the classroom before fielding questions from Dean Erika James.

Inside the 52nd Iditarod

Race CEO Rob Urbach WG91 talks livestream logistics, remote rescues, and building a dog-brand empire.

A Family Affair

How Hannah and Malick Diop WG09 collaborated with a famous relative to disrupt the beauty and entertainment industries

Alumni Book Roundup: Winter 2024

Aviation adventures, tales for children, and remembering a baseball legend

Insights from the World Economic Forum in Davos

An insider shares his decades-long experience with the annual meeting of international leaders in the Swiss Alps

How to Develop Talent in a GenAI World

Leveraging artificial intelligence to recruit and train future leaders

Insights From a Gig-Economy Executive

Taskrabbit CEO Ania Smith WG02 reflects on the digital platform’s growth, navigating global change, and the importance of resilience.

5 Questions to Ask Before Joining a Nonprofit Board

Make sure the board aligns with your passions and skills

Don’t Leave Your Job — Refresh It

Professor Samir Nurmohamed offers guidance for finding new opportunities within your current role

A Moment for Community and Opportunity

Pam Perskie W97, the new president of the Wharton Club of New York, reflects on the strength and impact of the alumni network

40 Years of Wharton’s Business Economics and Public Policy Department

Faculty and alumni reflect on how the first program of its kind has evolved

Black and African MBA Events Celebrate Milestone Anniversaries

The Whitney M. Young Jr. Memorial Conference turns 50 this year, while the Wharton Africa Business Forum marks its 30th

When to Speak Up in Meetings

Professor Michael Parke’s recent paper shows how employees can harness the power of “strategic silence”

A Veteran’s Lessons in Leadership

Daniel Moore WG00’s non-traditional journey from Air Force Captain to real estate CEO

The Eight Fundamentals of Problem Solving

As business leaders we are consequently required to solve problems. But what are the very fundamentals of problem solving?

Read on to find out.

1. Define the Real Problem

This is the biggie. Ensure that you are solving the right problem. Toyota is justifiably famous for its problem-solving savvy in perfecting its production methods. According to Toyota, the key to their method is to spend relatively more time defining the problem and relatively less time on figuring out the solution.

2. Solve the Root Cause of the Problem

Don’t treat the symptoms; solve the root cause of the problem. There are numerous methods to determine root causes—cause mapping, fishbone diagrams, etc. For me, the easiest and most effective is to use the “Five Whys.” Ask a question and to each answer ask. “Why?” again. Doing this for five times should get you to the root cause of the problem.

3. Use a Hypothesis

As happens on the “CSI” television shows, you should make a best guess as to the solution to the problem at the very beginning of your process—define the initial hypothesis. Then test this initial hypothesis by digging deep to determine whether the hypothesis is right or wrong and adjusting the hypothesis as the facts dictate.

4. Get the Facts

Dig deep and get the facts to truly understand the nature of the problem and the possible solutions. Do the analysis to let the facts do the talking instead of gut instinct. As Wharton’s own Peter Cappelli says: “I tell my MBA students that whenever you are going with your gut, you are doing something wrong. In most cases, you can actually figure it out. So you should sit down and figure it out.”

5. Keep the solution simple

Any solution to a problem has to be implemented by your team. So keep it simple. Be able to explain the solution clearly and precisely in 30 seconds. Limit the action items to solve the problem to three. Go for the solution that solves 80 percent of the problem but that is 100 percent implementable by the team—rather than a 100 percent solution that is unlikely to ever be properly implemented.

6. Do not re-invent the wheel

Plagiarism can be good. If someone has a clever idea or way to solve your problem, by all means legally use it. The “not invented here” syndrome is just sheer arrogance.

7. Gain momentum in problem solving

In situations where you have multiple problems to solve (e.g., business turnarounds) pluck the low-hanging but important fruit first. Solve the easy problems. This gives you momentum, shows progress and gives your team confidence.

8. Consider time

With any solution, ensure that you do first what needs to be done first. Also, ensure that the solution can be implemented in a reasonable period of time. Solutions that take longer than a few months will likely fail. The momentum will die out or top management will move on to another “critical issue.”

Everyday Advice for Business Leader Sanity

Simple to-do tips that are easy to execute in a how-to world drowning in advice.

7 Ways Your Smartphone May Be Killing Your Business

Today’s smartphones enable business leaders to constantly be in contact with the office and access the Internet or the cloud for needed information on the fly. Unfortunately, it is exactly this constant contact and easy access that often overwhelm the positives and make these devices harmful to the leaders’ businesses and lives.

9 Keys to Driving Cultural Change

The hardest part of a business transformation is changing the culture—the mindset and instincts of the people in the company. So, what are the keys to driving cultural change?

The Inside Story of How Creative Business Gets Done

Leadership consultant Roz Courtney translates the story behind an iconic Robin Williams cover photo to lessons in creativity valuable to any business executive.

• Registration
• Support 24/7
• Class Registration
• Account Registration
• Our Members
• Testimonial
• All Courses
• Resource Material
• Live Class Access
• Learner Dashboard
• Quiz Reports
• Groups Dashboard
• Paid Membership Levels

Fundamentals of Programming and Problem Solving

The mass production of computers and constant reduction in their cost has given more people access to computer technology in their homes, schools and places of work. The prevalence of computer communication hardware in developed and developing societies have given far more people access to powerful computers, in the form of desktops, laptops, handhelds, and notebooks, than was the case a decade ago. Yet, the myth surrounding the complexity of the matter of programming has kept many brilliant Caribbean scholars from pursuing programming as a business. Hence,  Caribbean nationals  remain more interested in being end-users rather than developers of computer programs.

This course seeks to change the skills set of the Caribbean Associate degree graduate by providing all ICT majors with the building blocks of problem solving and programming in C++.    It provides the right instructional conditions to develop, in students, programming skills that will enable them to create original computer programs that are solutions to problems that are unique to us in the Caribbean.

The course content challenges students to use their natural talents and creative powers to apply more imagination to the problems that exist among Caribbean societies. Thus, we hope that knowledge that is gained from this course will not only stimulate the student’s interest in pursuing a career in programming, but provide adequate foundational skills that enable those who choose to do additional programming courses to master them, and those who choose to pursue program development as a career to be exceptional creative programmers.

COURSE DESCRIPTION

This course introduces the fundamentals of computer programming and problem solving. It provides basic instructions on the process of problem solving, and deep exploration of fundamental computer-related problem solving techniques such as flowcharting, pseudo code and algorithms. It introduces students to the syntax of the  C++ programming language , and provides them with opportunities to use this language to generate solutions to real organisational and societal problems.

LEARNING OUTCOMES

On completion of this course students should be able to:

• Describe the basic control structures in C++
• Apply the principles of flowcharting to the software develop cycle.
• Create pseudo codes for real life problems and use to develop algorithms.
• Use abstraction to create Computer Software in an efficient manner.
• Analyze the features of one high level language to determine its constructs and program structure.
• Describe data types and structures for computer representation.
• Evaluate the functions and subroutines that are embedded in the C++ programming a language
• Write a simple program in C++ and use it to make decisions.
• Explain Event Driven Programming and Object Oriented Programming methods.

TEACHING AND LEARNING METHODS

To facilitate fulfilment of the requirements of this course lesson will utilise the following methods:

• Instructor Presentations
• Group and Individual Projects
• Demonstrations
• Peer-Tutoring

ASSESSMENT PROCEDURES

• Programming Assignment [20 marks]
• Programming Project [40 mark]
• Examination (40%)

ASSESSMENT SUMMARY

Nb : Dates are subjected to be changed.

TEXTBOOKS AND REFERENCES

• Zak, D.  An introduction to programming with C++.   Custom eight (8) edition, Course Technology.

READING LIST

• Farrell , J. (2014).  Programming Logic and Design, Introductory. Eight edition.
• Zak, D. (2012).  An introduction to programming with C++.  Custom seventh (7) edition, Course Technology.
• Zak, D. (2010). An Introduction to Programming with C++. Sixth (6) edition.

Course Outline 

• Revised_Fundamentals_of_Programming_and_Problem_Solving_IFTH1006_Sept_Dec_2023

Ratings and Reviews

This course was like no other, absolutely amazing!

This course is like no other you will find anywhere!

Information was easy to process.

I loved the information and doing the programming and codes.

This Course was manageable and flexible

I really enjoyed this course. It was very intriguing.

I adored both the material and the layout! Excellent work!

Provides all the necessary knowledge, and then some!

This was a great course. It allowed me to understand C++.

This course was very intriguing and easy to understanding , Inproving my knowlegde on C++

• WordPress.org
• Documentation
• Learn WordPress

Forgot password? New user? Sign up

Existing user? Log in

• Number Theory
• Probability
• Everyday Math
• Classical Mechanics
• Electricity and Magnetism

Computer Science

• Quantitative Finance

Take a guided, problem-solving based approach to learning Computer Science. These compilations provide unique perspectives and applications you won't find anywhere else.

Computer Science Fundamentals

What's inside.

• Tools of Computer Science
• Computational Problem Solving
• Algorithmic Thinking

Algorithm Fundamentals

• Building Blocks
• Array Algorithms
• The Speed of Algorithms
• Stable Matching

Programming with Python

• Introduction
• String Manipulation
• Loops, Functions and Arguments

Community Wiki

Browse through thousands of Computer Science wikis written by our community of experts.

Types and Data Structures

• Abstract Data Types
• Array (ADT)
• Double Ended Queues
• Associative Arrays
• Priority Queues
• Array (Data Structure)
• Disjoint-set Data Structure (Union-Find)
• Dynamic Array
• Linked List
• Unrolled Linked List
• Hash Tables
• Bloom Filter
• Cuckoo Filter
• Merkle Tree
• Recursive Backtracking
• Fenwick Tree
• Binary Search Trees
• Red-Black Tree
• Scapegoat Tree
• Binary Heap
• Binomial Heap
• Fibonacci Heap
• Pairing Heap
• Graph implementation and representation
• Adjacency Matrix
• Spanning Trees
• Social Networks
• Kruskal's Algorithm
• Regular Expressions
• Divide and Conquer
• Greedy Algorithms
• Randomized Algorithms
• Complexity Theory
• Big O Notation
• Master Theorem
• Amortized Analysis
• Complexity Classes
• P versus NP
• Dynamic Programming
• Backpack Problem
• Egg Dropping
• Fast Fibonacci Transform
• Karatsuba Algorithm
• Sorting Algorithms
• Insertion Sort
• Bubble Sort
• Counting Sort
• Median-finding Algorithm
• Binary Search
• Depth-First Search (DFS)
• Breadth-First Search (BFS)
• Shortest Path Algorithms
• Dijkstra's Shortest Path Algorithm
• Bellman-Ford Algorithm
• Floyd-Warshall Algorithm
• Johnson's Algorithm
• Matching (Graph Theory)
• Matching Algorithms (Graph Theory)
• Flow Network
• Max-flow Min-cut Algorithm
• Ford-Fulkerson Algorithm
• Edmonds-Karp Algorithm
• Shunting Yard Algorithm
• Rabin-Karp Algorithm
• Knuth-Morris-Pratt Algorithm
• Basic Shapes, Polygons, Trigonometry
• Convex Hull
• Finite State Machines
• Turing Machines
• Halting Problem
• Kolmogorov Complexity
• Traveling Salesperson Problem
• Pushdown Automata
• Regular Languages
• Context Free Grammars
• Context Free Languages
• Signals and Systems
• Linear Time Invariant Systems
• Predicting System Behavior

Programming Languages

• Subroutines
• List comprehension
• Primality Testing
• Pattern matching
• Logic Gates
• Control Flow Statements
• Object-Oriented Programming
• Classes (OOP)
• Methods (OOP)

CBSE Class 11 | Problem Solving Methodologies

Problem solving process.

The process of problem-solving is an activity which has its ingredients as the specification of the program and the served dish is a correct program. This activity comprises of four steps : 1. Understanding the problem: To solve any problem it is very crucial to understand the problem first. What is the desired output of the code and how that output can be generated? The obvious and essential need to generate the output is an input. The input may be singular or it may be a set of inputs. A proper relationship between the input and output must be drawn in order to solve the problem efficiently. The input set should be complete and sufficient enough to draw the output. It means all the necessary inputs required to compute the output should be present at the time of computation. However, it should be kept in mind that the programmer should ensure that the minimum number of inputs should be there. Any irrelevant input only increases the size of and memory overhead of the program. Thus Identifying the minimum number of inputs required for output is a crucial element for understanding the problem.

2. Devising the plan: Once a problem has been understood, a proper action plan has to be devised to solve it. This is called devising the plan. This step usually involves computing the result from the given set of inputs. It uses the relationship drawn between inputs and outputs in the previous step. The complexity of this step depends upon the complexity of the problem at hand.

3. Executing the plan: Once the plan has been defined, it should follow the trajectory of action while ensuring the plan’s integrity at various checkpoints. If any inconsistency is found in between, the plan needs to be revised.

4. Evaluation: The final result so obtained must be evaluated and verified to see if the problem has been solved satisfactorily.

Problem Solving Methodology(The solution for the problem)

The methodology to solve a problem is defined as the most efficient solution to the problem. Although, there can be multiple ways to crack a nut, but a methodology is one where the nut is cracked in the shortest time and with minimum effort. Clearly, a sledgehammer can never be used to crack a nut. Under problem-solving methodology, we will see a step by step solution for a problem. These steps closely resemble the software life cycle . A software life cycle involves several stages in a program’s life cycle. These steps can be used by any tyro programmer to solve a problem in the most efficient way ever. The several steps of this cycle are as follows :

Step by step solution for a problem (Software Life Cycle) 1. Problem Definition/Specification: A computer program is basically a machine language solution to a real-life problem. Because programs are generally made to solve the pragmatic problems of the outside world. In order to solve the problem, it is very necessary to define the problem to get its proper understanding. For example, suppose we are asked to write a code for “ Compute the average of three numbers”. In this case, a proper definition of the problem will include questions like : “What exactly does average mean?” “How to calculate the average?”

Once, questions like these are raised, it helps to formulate the solution of the problem in a better way. Once a problem has been defined, the program’s specifications are then listed. Problem specifications describe what the program for the problem must do. It should definitely include :

what is the input set of the program

What is the desired output of the program and in what form the output is desired?

2. Problem Analysis (Breaking down the solution into simple steps): This step of solving the problem follows a modular approach to crack the nut. The problem is divided into subproblems so that designing a solution to these subproblems gets easier. The solutions to all these individual parts are then merged to get the final solution of the original problem. It is like divide and merge approach.

Modular Approach for Programming :

The process of breaking a large problem into subproblems and then treating these individual parts as different functions is called modular programming. Each function behaves independent of another and there is minimal inter-functional communication. There are two methods to implement modular programming :

• Top Down Design : In this method, the original problem is divided into subparts. These subparts are further divided. The chain continues till we get the very fundamental subpart of the problem which can’t be further divided. Then we draw a solution for each of these fundamental parts.
• Bottom Up Design : In this style of programming, an application is written by using the pre-existing primitives of programming language. These primitives are then amalgamated with more complicated features, till the application is written. This style is just the reverse of the top-down design style.

3. Problem Designing: The design of a problem can be represented in either of the two forms :

The ways to execute any program are of three categories:

• Sequence Statements Here, all the instructions are executed in a sequence, that is, one after the another, till the program is executed.
• Selection Statements As it is self-clear from the name, in these type of statements the whole set of instructions is not executed. A selection has to be made. A selected number of instructions are executed based on some condition. If the condition holds true then some part of the instruction set is executed, otherwise, another part of the set is executed. Since this selection out of the instruction set has to be made, thus these type of instructions are called Selection Statements.

Identification of arithmetic and logical operations required for the solution : While writing the algorithm for a problem, the arithmetic and logical operations required for the solution are also usually identified. They help to write the code in an easier manner because the proper ordering of the arithmetic and logical symbols is necessary to determine the correct output. And when all this has been done in the algorithm writing step, it just makes the coding task a smoother one.

• Flow Chart : Flow charts are diagrammatic representation of the algorithm. It uses some symbols to illustrate the starting and ending of a program along with the flow of instructions involved in the program.

4. Coding: Once an algorithm is formed, it can’t be executed on the computer. Thus in this step, this algorithm has to be translated into the syntax of a particular programming language. This process is often termed as ‘coding’. Coding is one of the most important steps of the software life cycle. It is not only challenging to find a solution to a problem but to write optimized code for a solution is far more challenging.

Writing code for optimizing execution time and memory storage : A programmer writes code on his local computer. Now, suppose he writes a code which takes 5 hours to get executed. Now, this 5 hours of time is actually the idle time for the programmer. Not only it takes longer time, but it also uses the resources during that time. One of the most precious computing resources is memory. A large program is expected to utilize more memory. However, memory utilization is not a fault, but if a program is utilizing unnecessary time or memory, then it is a fault of coding. The optimized code can save both time and memory. For example, as has been discussed earlier, by using the minimum number of inputs to compute the output , one can save unnecessary memory utilization. All such techniques are very necessary to be deployed to write optimized code. The pragmatic world gives reverence not only to the solution of the problem but to the optimized solution. This art of writing the optimized code also called ‘competitive programming’.

5. Program Testing and Debugging: Program testing involves running each and every instruction of the code and check the validity of the output by a sample input. By testing a program one can also check if there’s an error in the program. If an error is detected, then program debugging is done. It is a process to locate the instruction which is causing an error in the program and then rectifying it. There are different types of error in a program : (i) Syntax Error Every programming language has its own set of rules and constructs which need to be followed to form a valid program in that particular language. If at any place in the entire code, this set of rule is violated, it results in a syntax error. Take an example in C Language

In the above program, the syntax error is in the first printf statement since the printf statement doesn’t end with a ‘;’. Now, until and unless this error is not rectified, the program will not get executed.

Once the error is rectified, one gets the desired output. Suppose the input is ‘good’ then the output is : Output:

(ii) Logical Error An error caused due to the implementation of a wrong logic in the program is called logical error. They are usually detected during the runtime. Take an example in C Language:

In the above code, the ‘for’ loop won’t get executed since n has been initialized with the value of 11 while ‘for’ loop can only print values smaller than or equal to 10. Such a code will result in incorrect output and thus errors like these are called logical errors. Once the error is rectified, one gets the desired output. Suppose n is initialised with the value ‘5’ then the output is : Output:

(iii) Runtime Error Any error which causes the unusual termination of the program is called runtime error. They are detected at the run time. Some common examples of runtime errors are : Example 1 :

If during the runtime, the user gives the input value for B as 0 then the program terminates abruptly resulting in a runtime error. The output thus appears is : Output:

Example 2 : If while executing a program, one attempts for opening an unexisting file, that is, a file which is not present in the hard disk, it also results in a runtime error.

6. Documentation : The program documentation involves :

• Problem Definition
• Problem Design
• Documentation of test perform
• History of program development

7. Program Maintenance: Once a program has been formed, to ensure its longevity, maintenance is a must. The maintenance of a program has its own costs associated with it, which may also exceed the development cost of the program in some cases. The maintenance of a program involves the following :

• Detection and Elimination of undetected errors in the existing program.
• Modification of current program to enhance its performance and adaptability.
• Enhancement of user interface
• Enriching the program with new capabilities.
• Updation of the documentation.

Control Structure- Conditional control and looping (finite and infinite)

There are codes which usually involve looping statements. Looping statements are statements in which instruction or a set of instructions is executed multiple times until a particular condition is satisfied. The while loop, for loop, do while loop, etc. form the basis of such looping structure. These statements are also called control structure because they determine or control the flow of instructions in a program. These looping structures are of two kinds :

In the above program, the ‘for’ loop gets executed only until the value of i is less than or equal to 10. As soon as the value of i becomes greater than 10, the while loop is terminated. Output:

In the above code, one can easily see that the value of n is not getting incremented. In such a case, the value of n will always remain 1 and hence the while loop will never get executed. Such loop is called an infinite loop. Output:

Please Login to comment...

Similar reads.

• School Programming
• CBSE Exam Format Changed for Class 11-12: Focus On Concept Application Questions
• 10 Best Waze Alternatives in 2024 (Free)
• 10 Best Squarespace Alternatives in 2024 (Free)
• Top 10 Owler Alternatives & Competitors in 2024
• 30 OOPs Interview Questions and Answers (2024)

Improve your Coding Skills with Practice

What kind of Experience do you want to share?

Programming for Problem Solving

This book provides an introduction to computer programming using Python as a way to solve problems. It focuses on programming concepts and fundamentals within the context of solving real world problems.

Table of Contents

• Attributions
• Acknowledgments
• Learning Objectives
• Introduction
• Computational Thinking
• An Example Algorithm
• Verifying your Algorithm
• The Process of Computational Problem Solving
• Values and Variables
• What is a Program?
• Computational Problem Design Using the Basic Programming Constructs
• The Role of Programming in the Field of Informatics
• Unit Summary
• Practice Problems
• Computer Hardware Architecture
• Digital Computing: It’s All about 0’s and 1’s
• Operating Systems—Bridging Software and Hardware
• Software Development Tools
• Learning Programming with Python
• Writing a Python Program
• The Python Interactive Shell
• The Basics of Python Programming
• Example: Using Variables and Literal Constants
• Operators and Expressions
• Practice with Operators & Expressions
• Evaluation Order
• Input/Process/Output Pattern
• Type Converter Functions
• Python’s Standard Library
• More on Strings
• Object Oriented Programming
• Simple Graphics Programming
• Graphics Windows: Coordinate Systems
• GraphWin Objects
• Text Methods
• Entry Objects
• Displaying Images
• Generating Colors
• Interactive Graphics
• Boolean Expressions
• Logical Operators
• Conditional Execution
• Exception Handling
• Practice with Handling Exceptions in our Programs
• The for…in Statement
• Nested Loops
• Basic File Processing
• Installing Python 3 and IDLE
• Using Python and its IDE 
• Appendix B: Python Cheat Sheet

This courseware includes resources copyrighted and openly licensed by multiple individuals and organizations. Click the words "Licenses and Attributions" at the bottom of each page for copyright and licensing information specific to the material on that page. If you believe that this courseware violates your copyright, please contact us .

Lumen Learning

Lumen Learning provides a simple, supported path for faculty members to adopt and teach effectively with open educational resources (OER). Read more about what we do.

Privacy Policy