It's about layers of abstraction, the need to understand them, modify them, know what is leaking etc.

I think people sometimes substitute magic when they mean "I suddenly need to learn a lower layer I assumed was much less complex ". I don't think anyone is calling the linux kernal magic. Everyone assumes it's complex.

Another use of "magic" is when you find yourself debugging a lower layer because the abstraction breaks in some way. If it's highly abstracted and the inner loop gives you few starting points ( while (???) pickupWorkFromAnyWhere() )). It can feel kafkaesque.

I sleep just fine not knowing how much software I use exactly works. It's the layers closest to application code that I wish were more friendly to the casual debugger.

Jumping from thing to thing without time set aside for "stop, reflect, adjust" makes it very challenging to make changes. I realized that you don't become organized if you don't spend time on it. Picking up physical messes. Thinking about what was important in your day vs what you got done. How the week went. Writing it down.

I found it was only after I started consistently putting time aside to catchup, think and adjust that I started being able to consider if any particular methods would be helpful. Parts of GTD have helped me (capture first) - but the aha moment really came before that.

If you want to be organized, put time into reflecting and adjusting (eg. organizing) the critical parts of your life. Once a day, every day. Maybe more than once a day. Then use one of those to reflect on the week. Not reading about it or endlessly sorting the books on your shelf, but focusing intently on stuff you'll remember 20 years from now.

Problematic because it leads ICs to think of themselves as the quarterback throwing or wide receiver making the game winning catch with 1 minute left, getting lifted up into the air, renegotiating a contract for millions more, retiring early, getting inducted to the hall of fame etc.

Why is this so problematic? I think it leads engineers to overvalue the short term wins (getting a particularly tricky implementation correct) sometimes at the cost of their health and wellbeing if they work nights and weekends to get it done. And no one is watching it live at the edge of their seats. Even more distressing is that having more junior ICs have to pull heroics to keep the business alive is a tremendous anti-pattern. The point of management is make the right decisions so the organization steers clear of asking their least experienced contributors to damage their health on a regular basis (...really at all!).

A well run org couples decision making and seniority. If an IC is making a lot of org impacting decisions they are probably as senior or more-so than most line managers (or should be promoted to be if this happens regularly) and are comped the same way. Now it would be nice if decision making was as transparent as coaches making the right/wrong play (the offensive coordinator calling a running play no one watching thought was a good idea). In an ideal org failures or inaction would be more transparent. If a manager is basically not making any decisions (adding no value) there are certainly management failures at several levels (maybe up to the top) preventing folks from getting upset about it. Again ideally audibles are a very occasional exception.

Where does money comes from? In sports, teams competing are the product. Players are kinda like features and marketing all built into one. Companies spend a significant portion of all their money on building product and marketing it. I think IC engineers are probably closer to the support staff than the players on the field...the comparison is problematic.

And which hall of fame? - the engineers in our hall of fame are the folks doing things for the first time, trailblazing, largely researchers (Turing awards etc). There is no "got 4 hours of sleep for months delivering a poorly planned product and got an autoimmune disease" hall of fame.

A line of questioning: Do you have time to write clear code? Time for comments? Time to manually test your changes hundreds of times? Time to refactor existing code when adding new code? Time to remove dead code? Time to automate the testing while you still have the little state machine you are working on in your head? Time to add observability to spot performance issues? Time to consider your rollout plan? Time to keep on top of changes which are in use? etc...

Automated tests (including unit tests) are just one part of writing correct code. If you are asked, "How long is it going to take?" that implies finishing all aspects of coding required to get something correct into use. You prioritize that, not anyone else.

Was willing to spend 5 minutes on a walk. Tried the web app - ios safari is not supported :( downloaded the ios app and registered. Got a totally blank app - no onboarding, no template / samples, no obvious way to import from my existing google sheets to see how things scaled. I added a datasource and a few fields (which felt confusing) and my walk was over.