I haven't seen anyone mention the following yet, and it's INCREDIBLY important! When something is not working right and you have to debug it, you need to re-ev

I haven't seen anyone mention the following yet, and it's INCREDIBLY important! When something is not working right and you have to debug it, you need to re-evaluate your abstractions and drop down a level in your technology stack. In Dan's case, he had to look at, and think about how the logic gates worked. In a more modern case, when your REST calls aren't working right, you may have to debug HTTPS stuff. If your HTTPS stuff isn't working you may have to look at key negotiation and exchange, etc etc. If your Entity Framework isn't working, you may have to (horrors!) look at what's going on with the database. If the database isn't working, you may have to (gasp!) look at the hardware it's running on. Too often people look at surrounding code or state, and do not verify the abstractions of lower-level code or hardware. Those things have "always worked" - it's never the compiler's fault, until it is (or a bad assumption of how the compiler works) I've seen people here talk about iterating, which is fine and good for many problems. For many debugging problems iterating will take you until the heat death of the universe to solve. I don't really think "fullstack" devs are always the best solution, or a scale-able approach to development; but a fullstack dev with a debugging background is hard to beat when you have problems. Edit: To put it another way: If your technology isn't working, you have to examine the engineering under it. If the engineering isn't working, you have to examine the science. If the science isn't working, you have bad assumptions, or you've found new science! (you probably have bad assumptions)