What's your process for creating complex programming solutions?

Try to rephrase the problem. Can you break a complex solution into 3 or 4 simpler problems? SIS (Skip if Skimming): A "Complex Solution" is something to avoid, especially when trying to define the problem. Eliminate scope and complexity when trying to identify the problem to solve. Cut everything back to the bare minimum and rebuild your assumptions from the trunk and soul of the base goal. When faced with undeniable, inevitable complexity, find the critical path. What is the critical path to a minimally viable product. Relate every requirement back to this critical path. Understand your definition of done and success within the scope of the problem. Otherwise you will never finish.

They vary based on application and WiFi solutions needed. When you program you set goals based on app needs and WiFi solutions and make meetings on whether the app works or not. Then you work out the links with the programmers. When you program WiFi use you may also need data. You make data plans to suit for the internet providers available and you make use of WiFi ideals at prices from low to high.

Have fun with this one. Sometimes the 'problem' isn't a problem at all. More likely it's an idea from a distant part of the organization that somehow made it your way. Sometimes you will spend months communicating back and forth with stakeholders who might not be sure exactly what they want. If you are lucky the problem is straightforward. That sort of problem solving can be taught in classrooms. The kind of problem solving that will get you paid entails listening carefully to differing voices, competing requirements, and especially when third party vendors are involved, you will become a politician for better or worse. This is not a bad thing necessarily -- sometimes it is the only way to prevent you from performing heroics.

A good approach is to ask "What?", "Why?" and "How?" questions during the preparation for the planning. - What do we need to do/solve/improve/fix? - Why do we need to do that (what is the added value)? - And how would we do that?

For complex program development, defining the problem is often the most challenging part, because if you define the scope of problems too broadly or not precisely enough, you may not be able to solve it. A good approach is to break down a large problem into several smaller ones and then address each problem one by one. If a small problem is still difficult to solve, you can further break it down into even smaller sub-problems until each problem is either resolved or an alternative solution is found.

Some cultures do a lot 'in-house'. This is not always bad, because with third party libraries there is almost always baggage, especially when licensing agreements that can take years to resolve are entailed. If you are lucky, you are the dumbest person in the room and can spend some time talking to your smarter colleagues who have ideas. But nobody has seen it all. Obviously searching can sometimes yield useful results, but frankly you need to run experiments to converge on something that is tenable. I write lots of small programs. They aren't always unit tests, because if my test is garbage it will break CI. By analogy, sometimes you need to write 100 bad songs to write 1 good one. Write crap code. Often. Throw it away.

In tackling complex programming challenges, I employ a multidimensional approach. 1. Delve into programming forums such as Stack Overflow, extracting valuable insights from discussions and learning from the experiences of other developers. 2. Search GitHub for open-source projects addressing similar challenges. I analyze the codebase, documentation, and issues for potential solutions. 3. Read technical blogs, programming books and tutorials from reputable sources. These sources often have practical solutions to real-world programming problems. 4. Join official community forums (Slack etc) related to specific technologies. Ask questions and seek advice from experienced developers who might share valuable insights.

1. Have a weaver’s mindset, knitting with repeated patterns. This will help in coming up with a design that is efficient to implement due to presence of repeatable patterns, simplicity and completeness. 2. Share a mathematician’s mindset. This is extremely helpful in thinking provable patterns which are easily and reliably testable. This also helps in identifying where we have wilfully digressed from precision thinking and made calculated judgements plus tradeoffs to fit the real world limitations by avoiding over-engineering and sacrificing some accuracy.

I hate software design, architecture, UML, all of it. Here is how I design software. I write some lines of code. I write some more lines. I refactor it. Patterns emerge. Lightbulbs go off and eventually I find design patterns that might fit the problem. After a couple weeks of experiments, I come up with something that looks like a design, but it didn't start from a UML diagram. It started from solving a few little problems and then using induction to figure out how they fit together to solve a bigger problem. Most code is written this way and anyone who tells you differently is lying.

One of the most nefarious parts of software engineering is ideology. It falls in the same camp as 'the scientific method'. It's a rough approximation of the process as a whole but really you are going back and forth in a feedback loop between implementation, research, and often redefining the problem as you realize "oh crap we didn't need that" or "this one part will take 6 months do we need this?" As far as brass tacks goes, you should know how to write good sentences and paragraphs. Good code should read like boring non-fiction. Variable names should be descriptive. If you are going to be lazy about anything, don't let it be naming. Make frequent commits, in a feature branch if you need to. Get help with testing if your brain is mushy.

Code review is pain but you will like it in the end. I am convinced that nobody can learn to code without somebody else critiquing it. It is the most ego destroying part of the job and it is the only thing that will actually teach how to write decent code. After getting hammered in reviews for a few years you might find that you stop getting hammered because the ghosts of reviewers past will haunt you and whisper things in your ear about const-correctness before you post a review.

To solve a complex problem, i think we really need to understand the problem statement first and to get an answer as to why exactly we are doing this, the approach in mind, will that be able to cater to the solution and later on benchmarking on a few best approaches/tech-Stack/tools available and later to go with the best which solves the problem as well as gives a flexibility to alter/modify the solution to a later stage as need arises mostly if talking about software architecture atleast.

Don't forget about the Pareto principle: you spend 20% of time to accomplish 80% of the project, then 80% of time to do the remaining 20%. But do you really need these 20%? Focusing is good, however, sometimes you need to see things from a higher perspective asking yourself: what is the impact of implementation of this particular feature?

Firstly, you should have the necessity to do it. Secondly you should have an experience and knowledge. A little luck will be helpful too :) That’s all.