3 ms·

I once saw a documentary about commercial Scuba diving. This is for the guys who work on oil rigs and such. At one point the instructor asks the students, "How

by cletus 4y ago

I once saw a documentary about commercial Scuba diving. This is for the guys who work on oil rigs and such. At one point the instructor asks the students, "How much will you get paid for diving in the first year?" They throw out a bunch of numbers and then he draws "0" on the blackboard and follows up with "You will get paid nothing for diving. You will get paid for what you do while diving." That means welding or whatever. Programming is a tool. Computers are tools. You're not getting paid to program. You're getting paid to solve some problem for your employer by programming. So I can related. I think we all can. But all that other stuff that you hate doing is really what you're getting paid for. Some jobs will have a lot of it. Ohters will have less. But you'll never get away from it except for possibly the most junior jobs where you're literally given tasks to complete by other engineers. For me, I enjoy understanding and improving systems. YMMV. Perhaps you'd enjoy something lower-level more? Fixing Linux kernel bugs is by its nature going to be more technical than, say, developing an ad revenue and reporting system. But even more technical projects will get large enough that you have to deal with other people.

blub 4y ago
The diving in your story is more like working on a computer than like programming itself. Otherwise the claim would be that we’re paid 0 to program which is easily disproven. I think many people are overthinking this and coming up with a problem solver myth when in reality programming is an independent professional skill which has been and continues to be paid for its intrinsic value. The stuff around programming - talking to customers, writing documentation, discussing business requirements, meeting of all sorts would be basically worthless without the actual code.
LeifCarrotson 4y ago
That's an excellent point - but I'd emphasize that it's the problem that's solved with the help of programming that the customer cares about, not the software package that's built by the programmer. Likewise, the end goal of the customer of the SCUBA welder is not the welding; it's the utility they gain from the pipeline or the structure or whatever the SCUBA welder has assembled. The customer doesn't really care about the welds themselves. As an automation integrator, I frequently have to push to the forefront of my mind that my customer's focus is not on the machine that I'm designing for them. Yes, I'm going to spend 600 hours on the intricacies of hazard mitigation and operating modes and IO and quality control and timing, with a deadline looming large to ship the machine - it is easy when you're that deep to think of the machine as the end goal. But for my customers, the focus is on the chairs or door handles or valves or whatever they're making that come out of the machine. Graceful fault handling, alternate paths through the sequencer, purge and single-cycle modes, calibration wizards, or whatever other features I can build in might be elegant and might be powerful - but the customer doesn't care about the machine itself. They especially don't care about the machine when logic I've written gets in the way of making products come out the other end!

by cletus 4y ago

blub 4y ago

The diving in your story is more like working on a computer than like programming itself. Otherwise the claim would be that we’re paid 0 to program which is easily disproven. I think many people are overthinking this and coming up with a problem solver myth when in reality programming is an independent professional skill which has been and continues to be paid for its intrinsic value. The stuff around programming - talking to customers, writing documentation, discussing business requirements, meeting of all sorts would be basically worthless without the actual code.

LeifCarrotson 4y ago

That's an excellent point - but I'd emphasize that it's the problem that's solved with the help of programming that the customer cares about, not the software package that's built by the programmer. Likewise, the end goal of the customer of the SCUBA welder is not the welding; it's the utility they gain from the pipeline or the structure or whatever the SCUBA welder has assembled. The customer doesn't really care about the welds themselves. As an automation integrator, I frequently have to push to the forefront of my mind that my customer's focus is not on the machine that I'm designing for them. Yes, I'm going to spend 600 hours on the intricacies of hazard mitigation and operating modes and IO and quality control and timing, with a deadline looming large to ship the machine - it is easy when you're that deep to think of the machine as the end goal. But for my customers, the focus is on the chairs or door handles or valves or whatever they're making that come out of the machine. Graceful fault handling, alternate paths through the sequencer, purge and single-cycle modes, calibration wizards, or whatever other features I can build in might be elegant and might be powerful - but the customer doesn't care about the machine itself. They especially don't care about the machine when logic I've written gets in the way of making products come out the other end!