3 ms·

There is more discernible levels of lagging between "instantly" and "1-2s", and more levels above "a weekend". For example, for about 3 years I worked on a pro

There is more discernible levels of lagging between "instantly" and "1-2s", and more levels above "a weekend". For example, for about 3 years I worked on a project where I had to send the code I wrote to an external entity to get it compiled and signed before I could run it on my device. It took one week at the minimum. I had to completely change the approach to my personal coding process as well as development process in general. It was so powerful that even to this day I am developing for days without compiling code and people are very surprised it usually runs on the first try -- if you can write in ANSI C for a week and have it running on the first try, doing the same in Java is a piece of cake. Trust me, waiting for a week for your code to run is very different from waiting for a weekend, where you can leave your computer on Friday and plan to conduct your tests on Monday. Other even larger orders of delay concern ability to change things in the environment. For example annoying things like broken process, broken automation, etc. In one company you could be able to fix things on your own, sometimes in minutes. In other companies you could face multi-month wait to get even slightest changes. If you have to wait for a quarter to get a new Jira ticket field you are not very likely to do it or care for the process in general. Then you have the world of shorter delays. Things that take a millisecond will usually already require you to take this into account when you work with it. Can I do this in a loop? Can I recalculate this whenever I need or do I need to cache the value? Etc. Whatever the solution, it costs you a bit of your focus and as we all know, focus is the main resource of software developer. Then you go to 20-50 milliseconds and this is where users notice delays. It is not as snappy as it was even if they can't exactly specify what changed. By the time you get to 200ms, the users will complain the application is slow and irritating, especially if they spend a lot of time in it clicking on things.

LoganDark 3y ago
> I am developing for days without compiling code and people are very surprised it usually runs on the first try this is a thing that surprises people? Perhaps I'm not as brave by doing it in Rust, but I can go weeks without compiling code. Rewrite or refactor everything, be done, have it entirely work or only require a couple tweaks.
- onetimeuse92304 3y ago
  Welcome to the club. I spent a lot of time thinking why exactly this is surprising and the result improved my hiring game a lot. So the issue really comes down to the fact that most people do not really have an idea what they are doing. They don't really know what their program is going to do before they actually run it. They don't have a model, an intimate understanding of what is really happening underneath the magic incantation they just laid on the screen. When you can't predict what your program is going to do, you also have a hard time debugging your own code (debugging, after all, is finding out how the program works different in reality from what it should be doing). When you are this person, a natural tactic is to continuously compile the application and verify it works. You write a function, you check if it works well. If something doesn't work correctly, you know it is most likely code you just wrote, so it makes it easier to fix it. Just keep changing the code you just wrote until it works. This lets people write code, but there are some huge problems associated. For one, it is very inefficient. Second, it does not work with large sweeping changes -- I many times worked with people who were paralysed by trying to run large refactoring on a code base. Among these types of developers this usually does not happen and rather than keep fixing existing codebase (which requires you to understand the codebase) people will default on rewriting (which is the process they already know). Third, it does not force you to get better understanding of the application you are working on and the framework you are using. It is a crutch that you never let go of and will forever keep you from being able to run until you do. Fourth, it hurts ability to design new features and take part in intelligent design discussion. But most importantly, it leaves a huge trail of bugs. When you write code not knowing what you do, you will generate a huge number of problems, but only fix the ones that presented themselves during testing, deployment or in production. So now when I hire developers, my coding exercise is specifically designed to, among other things, detect which type of developer you are. If you rely on running the code to tell you what it is doing, you will not pass the interview. I also thought about causes of this. I think, for the most part, the cause of this is that these people never had a stimulus to learn do better. I did and I am happy for it. Unfortunately, the way people learn is through tutorials and short succinct examples where they are constantly asked to write a short piece of code and then run it to confirm you are still in sync with the tutorial. It is also a natural way of learning a new topic, technology, framework, etc. -- when I learn something new I don't write long pieces of code because I just can't predict what it is going to do. Only through learning I can build my mental model of what the framework does and only then I can achieve the goal of being able to predict what the code does and run for long stretches of time.

LoganDark 3y ago

> I am developing for days without compiling code and people are very surprised it usually runs on the first try this is a thing that surprises people? Perhaps I'm not as brave by doing it in Rust, but I can go weeks without compiling code. Rewrite or refactor everything, be done, have it entirely work or only require a couple tweaks.

onetimeuse92304 3y ago
Welcome to the club. I spent a lot of time thinking why exactly this is surprising and the result improved my hiring game a lot. So the issue really comes down to the fact that most people do not really have an idea what they are doing. They don't really know what their program is going to do before they actually run it. They don't have a model, an intimate understanding of what is really happening underneath the magic incantation they just laid on the screen. When you can't predict what your program is going to do, you also have a hard time debugging your own code (debugging, after all, is finding out how the program works different in reality from what it should be doing). When you are this person, a natural tactic is to continuously compile the application and verify it works. You write a function, you check if it works well. If something doesn't work correctly, you know it is most likely code you just wrote, so it makes it easier to fix it. Just keep changing the code you just wrote until it works. This lets people write code, but there are some huge problems associated. For one, it is very inefficient. Second, it does not work with large sweeping changes -- I many times worked with people who were paralysed by trying to run large refactoring on a code base. Among these types of developers this usually does not happen and rather than keep fixing existing codebase (which requires you to understand the codebase) people will default on rewriting (which is the process they already know). Third, it does not force you to get better understanding of the application you are working on and the framework you are using. It is a crutch that you never let go of and will forever keep you from being able to run until you do. Fourth, it hurts ability to design new features and take part in intelligent design discussion. But most importantly, it leaves a huge trail of bugs. When you write code not knowing what you do, you will generate a huge number of problems, but only fix the ones that presented themselves during testing, deployment or in production. So now when I hire developers, my coding exercise is specifically designed to, among other things, detect which type of developer you are. If you rely on running the code to tell you what it is doing, you will not pass the interview. I also thought about causes of this. I think, for the most part, the cause of this is that these people never had a stimulus to learn do better. I did and I am happy for it. Unfortunately, the way people learn is through tutorials and short succinct examples where they are constantly asked to write a short piece of code and then run it to confirm you are still in sync with the tutorial. It is also a natural way of learning a new topic, technology, framework, etc. -- when I learn something new I don't write long pieces of code because I just can't predict what it is going to do. Only through learning I can build my mental model of what the framework does and only then I can achieve the goal of being able to predict what the code does and run for long stretches of time.