What do you do if your algorithm development is hitting a roadblock?

Whenever I run into a roadblock developing an algorithm, I realize that this is probably because I didn't use enough hash maps. I go over my algorithm again and change every possible data structure and item with a hash map. For instance all integer variables become one map of strings to integers. Same same (but different) for doubles and strings. Arrays and lists can easily be replaced my a map from the (integer) index to their value. And so forth. It might not necessarily make the algorithm work, but it gives me something to do, and it will undoubtedly impress people because clearly, the hash map is the primary data structure for all algorithm development.

Invest more time in analyzing even before starting to work on any problem statement. After analyzing discuss your approaches -> choice and compromises on the solution. Clarity is utmost important. Identify the edge case via pseudo code strategy and then code This helps to avoid landing into roadblock approach most of the time. If you are stuck in a roadblock then take that experience and analysis with you and start from Analysis phase. This time you will surely reach the solution faster. Keep reading design blogs. This helps in tradeoffs while you are trying to solve bigger problems and returning from roadblock to step 1 is not feasible.

Take a Break: Sometimes, taking a short break can help clear your mind Revisit the Basics: Make sure that you have a thorough understanding of the problem you're trying to solve and the principles of the algorithms you're using. Seek Help: Don't hesitate to ask for help from colleagues or online communities. Fresh eyes can bring a new perspective to a problem. Places like Stack Overflow, GitHub, or specific academic or professional communities can be very helpful. Break the Problem Down: Try to simplify the problem. Solve each part individually and then combine the solutions. Debug and Test: Make sure to thoroughly debug your code and test each part of your algorithm individually. This can help you locate where the problem lies.

I always reduce the problem to its most basic form. This can help isolate the issue and make it easier to understand. Sometimes, the issue lies in a misunderstanding or misapplication of fundamental concepts. Review the basics related to your problem.

Get a whiteboard and dry-wipe marker pen. Try to express what you are trying to do on the board. Use diagrams, notes, pseudocode, trace tables, whatever - just don't try to get it right before you make any marks. Understanding is not a linear process, so don't worry about being messy. Just make a start, and once you have a deeper understanding you can write a tidier version, or get back to a computer to try to implement you algorithm, preferably with some well-chosen test cases. Remember - no one else has to see your whiteboard markings so don't be inhibited either by your own judgment or your need to be right before doing the work to understand.

The steps can be reorder as once need but for me it works 1. Revisit your requirement inclusive of ingestion type, format, visibility etc. and comparing with your algorithm. 2. Discuss the problem with peers can provide you fresh prespective. 3. Refactor the code, reduce the complexity of the implementation using the knowledge obtained with previous 2 steps.

In my experience, when algorithm development stalls, code refactoring is pivotal. Simplifying and optimizing code enhances clarity and reveals hidden errors. A clean codebase fosters clearer thinking, facilitating smoother algorithmic progress and ultimately leading to improved outcomes.

Clean code helps a long way in reducing kludges. It helps revisit the code base or develop on it. This most importantly includes simpler and more readable parts and reusability which can help abstract from the overwhelming complexity and focus on the sections that require attention. On top of it, writing pure functions (without side-effects) as a practice would help from creating doubt and makes debugging easier.

Refactoring code entails reorganizing it without changing its external behavior, aiming to enhance its internal structure. This step becomes crucial when encountering obstacles in algorithm development. Seek areas where simplification or optimization is feasible, focusing on removing redundancy and improving readability. By refining the codebase, you can more easily identify errors and inefficiencies, leading to clearer thinking and ultimately, the creation of a superior algorithm.

If the issue seems to stem from the implementation itself, I consider refactoring the code. This involves restructuring the codebase to make it more readable, modular, and efficient. It can help identify and eliminate any underlying issues that may be causing the roadblock.

A conversation with someone not underwater can be a significant wall breaker. If you’ve tried everything and something is still off, ask a colleague or another expert to review it with fresh eyes. You may need a boost or to simply get out of your office chair. Walk away and return later when your mind has left frustration and exhaustion. These suggestions are easy and apply to many areas, but sometimes the best advice is well used.

In my experience, seeking feedback is invaluable when facing algorithmic roadblocks. Collaborating with peers offers fresh perspectives and uncovers overlooked issues. Constructive criticism fosters refinement, leading to innovative solutions and more efficient progress in algorithm development.

Collaboration is one of the effective strategies. In some domains, nothing beats the perspective experienced folks have. 1. It is usually best to review the development plan with the team so that one can avoid any roadblocks at all. Being proactive is the best strategy. 2. Daily standups, Sprint reviews, and Code reviews are some ways to discuss their roadblocks. 3. The end goal should be to remove the roadblock, align with the business expectations, and provide the best solution at a given point.

One time at my previous work I was developing a business-intelligent algorithm related to some data analysis. From the business perspective requirements were clear and algorithm required O(N^2) computations. It was quite simple solution. However the whole dataset was really large and runtime performance was a roadblock on a way to production usage. I started discussion with a stakeholders related to our dataset. And we found that we can do some segmentation for it. Even though the algorithm still had O(N^2) computations in real time, the runtime was decreased significantly because we were able to dramatically decrease N for a given request. It's really important to seek a feedback not only from tech. perspective, but also from other sides

Our chain of thoughts sometimes could be the bottleneck that stalls us from developing our algorithm. A peer review or suggestion would introduce a different perspective which can accelerate development or fill holes in our logic. Constructive criticism is the best piece of development. It is a positive sum scenario. We get an exchange of knowledge and learn concepts or practices from peers which we might have not known or have taken more time in learning on our own.

All too often we start worrying about the outcome without setting up the groundwork that leads to a successful outcome. Though there are many different way to approach it, I find the following approach useful: 1. Start with creating some simple milestones and try to have a rudimentary understanding of what kind of results to expect at what stage. 2. Spend time in each stage to ensure that it delivers meaningful results (for example a certain level of efficiency that is bettter than brute force or accuracy that is better than random chance etc). Its far easier to detect and fix a bug when working on an individual module than trying to take apart a fully built system.

The goal of most algorithm-development is to automate something humans are currently calculating manually. The people doing the job now know a way that works, and a method so highly optimized as to be feasible by hand. They have all of the foundational knowlege. Ask them, start by replicating their processes, and then see what improvements become feasible with automation.

In my experience, revisiting basics is crucial when overcoming algorithmic roadblocks. Reinforcing fundamental principles often reveals overlooked solutions. Reviewing data structures and algorithms relevant to the problem aids in understanding and resolving issues effectively. This approach not only addresses current challenges but also fortifies skills for future projects, ensuring smoother progress in algorithm development.

If I'm hitting a roadblock, there must be something I did wrong on my way to that roadblock. I need to track down my own footsteps and set small goals/milestones on my way up again to see if it fulfills those criteria.

It's essential to review the fundamental concepts and principles underlying the algorithm. Going back to basics can help identify any misunderstandings or gaps in knowledge that might be hindering progress. This review can also spark new ideas or approaches to tackle the problem.

Once you have chosen a particular methodology and started down that road, it is easy to forget about alternatives. If you find yourself tinkering with parameters to "try to make it work", it may be time to go back and start over, instead of wasting time noodling.

In research and development, it is a real possibility to encounter algorithmic roadblocks. The reasons include an algorithm is not effective on the data or does not scale. It is good to encounter these during the early phase and prior to deployment. If road blocks occur, teams can pivot to a quick modification if possible or to go back to the drawing board. Teams that support a safe-to-fail approach, tend to be more successful in my opinion.

In my experience, exploring alternative algorithms is key when facing roadblocks. Flexibility and openness to change are crucial. Considering different methodologies often leads to breakthroughs, ensuring optimal solutions tailored to specific situations.

One good alternative is often to look outside your usual development environments. Maybe the problem is solved very well in a library for another language. Then the challenge changes from figuring out the complex algorithm to integrating computations from different frameworks. Separate programs running APIs are a common solution, though often there is a way to drectly include content from one language or framework in another.

If the current approach seems to be leading nowhere, I explore alternative strategies or algorithms to solve the problem. This might involve researching existing solutions, experimenting with different algorithms, or considering unconventional approaches to achieve the desired outcome.

In my experience, documenting progress is vital during algorithm development. Detailed logs track attempted solutions, preventing repeated mistakes and aiding in decision-making. This documentation serves as a roadmap, facilitating project revisit after breaks and enabling effective collaboration with others, ultimately leading to overcoming obstacles efficiently.

From the first line of code to the last I've written, I need to keep a track of the problems I've solved and the problems I've faced within this scope. Not repeating them in the future is important.

Throughout the process, I document my progress, including the roadblocks encountered and the steps taken to address them. Keeping detailed records helps me track my journey, learn from past experiences, and communicate effectively with team members or stakeholders.

Documenting isn't just for those who come after you; it's for you, too. - Keeping a log of what you've tried, what worked, and what didn't can prevent you from retracing your steps. - Plus, writing things down can sometimes help untangle the knot in your mind.

I program it myself. Here are some more characters for LinkedIns AI. You have to program everything yourself. You can’t trust what randos have thrown into packages.

Whenever facing a roadblock you’d actually have to determine which area you’re being blocked in. - efficiency - effectiveness. Once identified I feel for efficiency you should consider the approach of trying it another way. Trying another approach to the algorithm which usually means writing it again. If it’s the case of effectiveness, that it’s just not doing what you want it to then you’d need to reevaluate the step by step process of that algorithm. Most times you have a step you haven’t broken down to its base components yet.

As people better than me said: "Whenever you are tempted to type something into a print statement or a debugger expression, write it as a test instead.” (Martin Fowler) 99% you are missing good tests in EARLY phase, now is as but later.

When faced with a roadblock in algorithm development breaking down the problem into smaller, manageable parts often helps in identifying the specific issue. Experimenting with alternative approaches or tweaking parameters can also provide valuable insights. Sometimes, taking a break and returning with a clear mind can lead to breakthroughs. Lastly, if the roadblock persists, consulting with experts or mentors can offer invaluable guidance to overcome challenges and advance the development process.

When encountering an impediment in an algorithmic process, the initial step involves identifying the root cause of the obstruction and evaluating the successful elements leading up to it. By retracing the procedural steps, valuable insights can be gleaned to pinpoint areas where adjustments to the algorithm may alleviate the obstruction. Additionally, seeking input from an individual outside the immediate context, who may lack familiarity with the specific problem, can offer fresh perspectives and potential resolutions.