4 ms·

When interactive compilers and debuggers started to become more available, my father complained that junior devs would just make random changes to the code unti

When interactive compilers and debuggers started to become more available, my father complained that junior devs would just make random changes to the code until it worked, rather than taking the time to understand it, as compared to when you had to wait for your punchcards to go through an overnight batch process. It seems that lowering friction will always lower understanding, because industrious people will always try to get the most done, and inexperienced people will conflate getting the most done now with getting the most done in general.

YeGoblynQueenne 2y ago
To be fair, I would guess that 90% of the programmers I know would never have learned to program if they had been forced to do it on ancient mainframes with punched card readers. Personal computers made programming something that any schmuck could learn. That sure includes me. But I think all that does is point to the fact that the average programmer's knowledge about computers and programming becomes poorer and poorer as time goes by. We are continuously pessimising for knowledge and skills.
- cc101 2y ago
  I'm sympathetic to what you are saying, but you should include the increase in the number of things a programmer needs to know and to consider today. I've been programming for 57 years. There is a huge amount to know and the tasks are huge compared to what I knew and did back in 1968. Over that time I grew as a programmer as the work became more difficult. I couldn't keep up with the technology. In spite of my attempts to keep up, it seemed that every few years I had to further limit the scope of my work in order to cope. Judging by my experience, today competent programmers will fall further and further behind with what they know becoming more obsolete while they restrict their scope so they can learn the new work on the job. Young programmers won't need to know much of what today's competent programmers know. At the same time the increasing complexity of their assignments will require them to go deeper into new matters, and they in turn will become overwhelmed. And so on it will go. On the other hand, perhaps I don't know what I'm talking about. : )
- BobbyTables2 2y ago
  I don’t think the issue is even even a lack of knowledge. I don’t fault a C developer for not knowing and appreciating the intricacies of a superscalar pipelined processor using out of order execution. But when a C developer writes a multithreaded program they need to really understand why multiple threads are necessary, proper use of locking, and how it will impact the overall application. They need to look beyond their tiny bit of code and the assigned task. Unfortunately a number of developers fully expect to drive on a busy street blindfolded and successfully reach their destination.
  - aidenn0 2y ago
    > But when a C developer writes a multithreaded program they need to really understand why multiple threads are necessary, proper use of locking, and how it will impact the overall application. They need to look beyond their tiny bit of code and the assigned task. Not really, just add the "volatile" keyword to global variables at random until the bugs go away!
- euroderf 2y ago
  > if they had been forced to do it on ancient mainframes with punched card readers Interesting point. I for one started out with punched cards, and your point is valid: you had to think deeply when preparing your next program submission, because turnaround was slo-o-ow and often kept you in the computing center waiting, waiting, waiting. So one might argue that when we got terminals that submitted "virtual punch cards" and got back "virtual printouts" (this is late 70s), it debased the practice of programming. /s OTOH in this day and age, the quick compile times of Go are - to put it bluntly - absolutely wonderful.
BobbyTables2 2y ago
In the past 20 years, I’ve seen some people make random changes until the code “worked”. Fortunately, I’ve had the privilege to be on teams where such were relatively few. Your father was certainly right.
senko 2y ago
Linus echoing your father's thoughts in 2006: I happen to believe that not having a kernel debugger forces people to think about their problem on a different level than with a debugger. I think that without a debugger, you don't get into that mindset where you know how it behaves, and then you fix it from there. Without a debugger, you tend to think about problems another way. You want to understand things on a different _level_. Full email at https://lkml.org/lkml/2000/9/6/65 https://lkml.org/lkml/2000/9/6/65
ohdaaaaam 2y ago
[dead]

YeGoblynQueenne 2y ago

To be fair, I would guess that 90% of the programmers I know would never have learned to program if they had been forced to do it on ancient mainframes with punched card readers. Personal computers made programming something that any schmuck could learn. That sure includes me. But I think all that does is point to the fact that the average programmer's knowledge about computers and programming becomes poorer and poorer as time goes by. We are continuously pessimising for knowledge and skills.

cc101 2y ago
I'm sympathetic to what you are saying, but you should include the increase in the number of things a programmer needs to know and to consider today. I've been programming for 57 years. There is a huge amount to know and the tasks are huge compared to what I knew and did back in 1968. Over that time I grew as a programmer as the work became more difficult. I couldn't keep up with the technology. In spite of my attempts to keep up, it seemed that every few years I had to further limit the scope of my work in order to cope. Judging by my experience, today competent programmers will fall further and further behind with what they know becoming more obsolete while they restrict their scope so they can learn the new work on the job. Young programmers won't need to know much of what today's competent programmers know. At the same time the increasing complexity of their assignments will require them to go deeper into new matters, and they in turn will become overwhelmed. And so on it will go. On the other hand, perhaps I don't know what I'm talking about. : )
BobbyTables2 2y ago
I don’t think the issue is even even a lack of knowledge. I don’t fault a C developer for not knowing and appreciating the intricacies of a superscalar pipelined processor using out of order execution. But when a C developer writes a multithreaded program they need to really understand why multiple threads are necessary, proper use of locking, and how it will impact the overall application. They need to look beyond their tiny bit of code and the assigned task. Unfortunately a number of developers fully expect to drive on a busy street blindfolded and successfully reach their destination.
- aidenn0 2y ago
  > But when a C developer writes a multithreaded program they need to really understand why multiple threads are necessary, proper use of locking, and how it will impact the overall application. They need to look beyond their tiny bit of code and the assigned task. Not really, just add the "volatile" keyword to global variables at random until the bugs go away!
euroderf 2y ago
> if they had been forced to do it on ancient mainframes with punched card readers Interesting point. I for one started out with punched cards, and your point is valid: you had to think deeply when preparing your next program submission, because turnaround was slo-o-ow and often kept you in the computing center waiting, waiting, waiting. So one might argue that when we got terminals that submitted "virtual punch cards" and got back "virtual printouts" (this is late 70s), it debased the practice of programming. /s OTOH in this day and age, the quick compile times of Go are - to put it bluntly - absolutely wonderful.

BobbyTables2 2y ago

In the past 20 years, I’ve seen some people make random changes until the code “worked”. Fortunately, I’ve had the privilege to be on teams where such were relatively few. Your father was certainly right.

senko 2y ago

Linus echoing your father's thoughts in 2006: I happen to believe that not having a kernel debugger forces people to think about their problem on a different level than with a debugger. I think that without a debugger, you don't get into that mindset where you know how it behaves, and then you fix it from there. Without a debugger, you tend to think about problems another way. You want to understand things on a different _level_. Full email at https://lkml.org/lkml/2000/9/6/65 https://lkml.org/lkml/2000/9/6/65

ohdaaaaam 2y ago

[dead]