At least for the hard software problems. Let's define easy and hard software problems.
- Posting a form to a server - easy
- Hacking http to implement a server push - hard
Solving the easy problems is trivial. Even if you have not solved them before someone else has, and they published a tutorial with pretty diagrams. It's paint by numbers, and the biggest number you're going to have to deal with is 9. Hard problems are daunting. It can feel like being asked to create the [Sistine Chapel][1] with nothing but a fist full of sharpies.
Luckily for us software problems conform to certain rules that art does not and we can offer the following advice on attacking these problems.
When you decide to start in on a hard problem get right down to business. Do not start by checking your email, or tweeting 'Solving a hard problem', that would be [lame][3]. Tell your co-workers to shut their pie holes and turn off the [Rammstein][5].
Remember what you have learned
Solving software problems does not typically involve inventing new solutions. You may think your solution is novel, but you're probably just as lame as your 4th grade reading partner who claimed to have invented [Lego time travelers][6]. I mean seriously, letting the Lego pirates play with the Lego astronauts takes no stretch of the imagination.
What you're really doing is applying techniques you have seen before in new and imaginative ways. To get there you have to use your existing knowledge to explore the problem before going directly for the best solution, which brings us to the most important point...
Don't be clever
At least not at first. Start with the simplest brute force solution that gets the job done. Cherish the moment when you see the problem solved, and then ride this confidence boost to apply what you have learned to a more elegant and robust iteration.
Someone explained it to me with the following anecdote.
>Take the problem of creating an algorithm to solve a maze. The simplest solution is to follow the right wall until you reach the exit. It's not the shortest path but now you know there is an exit and you know how to get there. Now you can go back over your path and cut out the unnecessary segments and produce the shortest route.
If this is truly a *hard* problem then you don't know [jack][7] about how to effectively solve it. Going full bore on a three layered redundant fault tolerant cached architecture is going to be a waste of time when you realize that the do_what_you_expected() method does the opposite and you really needed to build the thing in [assembly][8].
[1]: https://mv.vatican.va/3_EN/pages/CSN/CSN_Volta.html
[2]: https://www.youtube.com/watch?v=WGOohBytKTU
[3]: https://twitter.com/ryanwilke/status/1297792473
[4]: https://www.albinoblacksheep.com/flash/piehole
[5]: https://www.youtube.com/watch?v=doTBT46wMvA
[6]: https://en.wikipedia.org/wiki/Lego_Time_Travels
[7]: https://en.wikipedia.org/wiki/Jack_Shephard
[8]: https://en.wikipedia.org/wiki/Assembly_language