4 ms·

I guess I'm a sucker for these programmers of yore stories. Yes, Mel would be an unsuitable candidate for most modern, team-oriented programming positions. But,

I guess I'm a sucker for these programmers of yore stories. Yes, Mel would be an unsuitable candidate for most modern, team-oriented programming positions. But, heck, to be truly one with the machine in understanding all of its nuances is extraordinary. (Yes, the machines were smaller and simpler then, but still...) It's disappointing that a great majority of software developers (read: corporate programmer drones) have little understanding of what's really going on under the covers of the layers upon layer of abstractions. Perhaps, if they truly did know, it might make them wonder if their code will run at all?

deleted 18y ago
[deleted]
greyman 18y ago
Hi I am a corporate programmer drone and yes, you are right, someone like Mel would not be very suitable. But that doesn't mean todays software building is any easier. Yes, I don't need to know numeric codes of the machine instructions, and I don't write code which modify itself. But the challenges are not lesser - we need to think about how to meaningfully build those layers of abstractions, how the pieces of software will communicate efficiently to each other (sometimes asynchronously), how to build the modules to be both maintanable and expandable, etc. etc... When I was a student, I played with machine code and assembler and cracking etc., so I have some knowledge of all the layers, but I don't think that qualifies me to be a so-called Real Programmer. ;-)
- Retric 18y ago
  The problem with corporate programming is not the layers of abstractions or asynchronous communication etc. The real problem is the staggering incompetence of most people involved in the process.
  - daniel-cussen 18y ago
    Don't forget the layers of management.
- jdavid 18y ago
  the real problem, is that software languages have not yet caught up with hardware. if software was as powerful now, as code is now, you used to be able to use one instruction and have a computer turn for a millisecond or so. yes it was slow, but it was still faster than having a person process 2 numbers and then add them, or divide them etc... now i find it hard to find 'useful' instructions that actually take 1ms of processing time. heck, TI's lates micro controllers can turn on and off, and still stabilize analog circuits in less than 1ms now. new processes and neural networks are becoming more practical every day as information overflow, and processing abundance are allowing us to write code on sample sets, and probabilities. soon, for loops will seem silly.
gcv 18y ago
Actually, I wonder about your assertion as to whether Mel would be suitable for a corporate programming job. In the sense that no typical corporate hiring manager would approve of him and his habits, then no, of course he would not fit. However, even corporations occasionally need people who just get things done. I have, in my past life as a programmer at a bank, seen some incredibly opaque, hard-to-maintain systems hacked together in the course of a few sleepless nights in 1992, which still tick, do their work, and help generate millions in revenue. IT departments then take months, if not years, to attempt to replace some of that code, and typically fail. So occasionally, people who work somewhat like Mel do get approved by higher-ups who value the productivity of one incredibly smart hacker over the productivity of a mediocre team.

deleted 18y ago

[deleted]

greyman 18y ago

Hi I am a corporate programmer drone and yes, you are right, someone like Mel would not be very suitable. But that doesn't mean todays software building is any easier. Yes, I don't need to know numeric codes of the machine instructions, and I don't write code which modify itself. But the challenges are not lesser - we need to think about how to meaningfully build those layers of abstractions, how the pieces of software will communicate efficiently to each other (sometimes asynchronously), how to build the modules to be both maintanable and expandable, etc. etc... When I was a student, I played with machine code and assembler and cracking etc., so I have some knowledge of all the layers, but I don't think that qualifies me to be a so-called Real Programmer. ;-)

Retric 18y ago
The problem with corporate programming is not the layers of abstractions or asynchronous communication etc. The real problem is the staggering incompetence of most people involved in the process.
- daniel-cussen 18y ago
  Don't forget the layers of management.
jdavid 18y ago
the real problem, is that software languages have not yet caught up with hardware. if software was as powerful now, as code is now, you used to be able to use one instruction and have a computer turn for a millisecond or so. yes it was slow, but it was still faster than having a person process 2 numbers and then add them, or divide them etc... now i find it hard to find 'useful' instructions that actually take 1ms of processing time. heck, TI's lates micro controllers can turn on and off, and still stabilize analog circuits in less than 1ms now. new processes and neural networks are becoming more practical every day as information overflow, and processing abundance are allowing us to write code on sample sets, and probabilities. soon, for loops will seem silly.

gcv 18y ago

Actually, I wonder about your assertion as to whether Mel would be suitable for a corporate programming job. In the sense that no typical corporate hiring manager would approve of him and his habits, then no, of course he would not fit. However, even corporations occasionally need people who just get things done. I have, in my past life as a programmer at a bank, seen some incredibly opaque, hard-to-maintain systems hacked together in the course of a few sleepless nights in 1992, which still tick, do their work, and help generate millions in revenue. IT departments then take months, if not years, to attempt to replace some of that code, and typically fail. So occasionally, people who work somewhat like Mel do get approved by higher-ups who value the productivity of one incredibly smart hacker over the productivity of a mediocre team.