[twawaaay]

I do some photography on the side.

I think the sentence describe it perfectly.

Gear won't take good photos. But it sure makes it easier if you know what you are doing. And it also opens new possibilities.

It is all good, IF you know how to use it. Probably the best advice I got when I started was to settle on a simple piece of gear, fairly constrained, and learn how to use it creatively. I settled on a Fuji X100s which is prime, non interchangeable lens. I learned everything about it for the next year and I am probably better photographer for it. When you learn everything about your fairly simple camera you can start learning how to use it creatively. The camera itself becomes your tool and you learn to predict what is going to happen and what is/not going to work in a particular situation. Those skills, for some reason, transfer when you change to other cameras.

Give my full frame with my expensive lenses to my wife and the pictures are worse than she would do on a phone. It is just too complicated for her to be thinking about the photo, not that she pays a lot of attention to the composition anyway.

So what is the application?

Whatever you do, try to understand different aspects of your craft and maybe figure out which of those aspects you are underutilising and how you could force yourself to learn them better.

For example, as a developer, decades ago, I was thrown on a project that required me to write a lot of code in a very constrained environment (embedded C, low memory, etc.) without being able to compile and run it. I was able to run my code once a week.

I probably learned more about programming working for 3 years on this project than I learned over the rest of my career before and after. I learned that compile/run/fix loop is a crutch that most people never wean themselves of because it is just so damn convenient. I learned that you can teach yourself to write code for days and then get it to work correctly on the first try (most of the time). I learned it gives you superpowers.

I can now barely stand watching people who can't predict what their code does, it feels so amateurish. I know I did the same and I know it was a chance that I learned it, but still.

It also makes your code much, much more bug free and reliable. Because QA/QC/code reviews, etc. only find certain types of problems that manifest themselves fairly easily. To reduce other types of bugs you have to create less bugs in your initial version because nobody will ever find them and fix them for you. Those bugs are still there and will manifest themselves in those rare occasions or when you refactor the software a bit. It also means when you are done coding the application is pretty much production ready -- there is no QA/QC phase where bugs are getting fixed.

[vaidhy]

>I learned that compile/run/fix loop is a crutch

Why is this a crutch and not an optimal way to do things? At a higher level, this is TDD (maybe with test cases in your mind). Why is that a wrong thing?

You are ascribing knowledge to a particular process and that does not sound right.

[twawaaay]

It is a crutch because people rely on it to tell them what is wrong with their code instead of trying on their own. They can't tell until they run the code because they don't exert themselves normally, when programming. Just like driving exclusively with Google Maps atrophies the part of brain responsible for navigation. Why, if you have a compiler or your app to tell you in a moment?

Unfortunately, ability to predict what a piece of code will do, exactly, is pretty important for a programmer. Training this part of brain will make you a better programmer, overall.

Anyway, I do pair programming and people are amazed you can work for a whole day and run large new module at the end of it and everything works fine, as predicted. It is a good feeling.

It does not exactly save time, usually. But sometimes when I know what I want exactly I can do feats of producing larger pieces of code in extremely short time.

Once my manager asked me if it would be possible to implement a substantial, complex feature. He had a meeting in half an hour and he would like to know. I somehow immediately figured out everything I need and have implemented it in half an hour and did a short demo literally 2 minutes before his meeting. I have not ran the code before.

I am also the guy to go at my company when stuff fails and a piece code needs to be implemented on an extremely short notice. Like when a team broke a bunch of data and somebody needs to quickly develop a tool to undo the damage but without risking further complications.

It probably has something to do with ability to understand what you are doing and all consequences of the code. Also structuring the code and solution to the problem in a way that limits possibility for unexpected behaviour.