26 ms·
You're missing the point. The goal of cooking meals is to have a meal at the end. Because people need to eat. The food is the solution to the problem you have.
by SCdF 7y ago
You're missing the point.
The goal of cooking meals is to have a meal at the end. Because people need to eat. The food is the solution to the problem you have.
People don't consume software, slurping up lines of code like ramen. Having a steaming bowl of software is not the end goal. The end goal is to solve some _other_ problem which may or may not, once you dig into it, require writing software, and if it does then still: more software doesn't mean more food.
- globular-toast 7y agoI think you're missing the point. Humans can live perfectly well eating raw food. But we don't because it's not nice.
- uncletaco 7y ago> humans don't consume software what even is gaming
- darepublic 7y agoThe prevention of starvation is the problem which currently requires food but in the future may not (photosynthesis, man machine merger etc)
- jackcviers3 7y agoYou are missing the point. As is almost everyone else who says this stuff. Most of us get paid to write software other people have requested in order to solve their problems. Every problem software solves can be solved by a sea of pencil pushers or factory line workers or human calculators or office clerks with filing cabinets or telephone switchboard operators or typists. The world used to run that way. It no longer does because it is extremely cheap to program a computer to do repetitive actions. Compared to previous real-estate and labor-pool costs, paying even a thousand programmers to automate work done by people is incredibly inexpensive. The problem is already solved. Your job is to translate the solution into a well-specified, easy to manipulate series of steps for a computer to execute that can be operated in production as cheaply as possible. You are literally the last step in the race to the bottom. You are literally payed to solve the problems of translating flexible human activities into code. That's the problem you are solving. If someone asks you to program something that they don't already know how to do, then you are solving three problems - what to do, how to do it, and whether or not it is cheaper to do in software, which it ALMOST ALWAYS IS. You should be being paid three salaries - one as a business executive, one as a business analyst, and one as a software engineer. The people pushing you to "solve problems, not code," are people pushing you to do more work in one job role to keep them from paying three people for those jobs. As a software engineer, you should be able to assume by the time something hits your task queue that others have decided that it will be cheaper to use software to solve the problem, they were competent in that assessment, and you can start executing. As a consultant, I frequently take on all those roles for a client. But they pay me as a consultant to do those three roles. Remember that as an employee, in an extremely in-demand field, with specialized expertise compared to the rest of the work pool, you are a sole proprietorship trading time for resources. If that trade is lopsided, you need to push back and negotiate higher pay and a promotion. Don't give away work responsibilities for free because of culture hero points.
- SCdF 7y ago> Most of us get paid to write software other people have requested in order to solve their problems. ... The problem is already solved. ... You are literally payed to solve the problems of translating flexible human activities into code. OK then, I think the confusion is that your experience (and definition) of software development doesn't align with mine. > You should be being paid three salaries - one as a business executive, one as a business analyst, and one as a software engineer. ... Don't give away work responsibilities for free because of culture hero points. I don't know what culture hero points are. Anyway, while I agree those are three different roles, I don't think because the "BA" role exists the "Soft Dev" role should just ignore req gathering and demand a fully completely spec that they then in no way question: that feels like waterfall from the 2000s. In the same way I think that a BA should understand how software works to a point and use that knowledge to direct their design, a software dev should understand the problem and design and contribute to that solution. The roles are not rigid black and white barriers where you throw things over the wall to the next person, they are just places where you concentrate.
- BurningFrog 7y ago> Every problem software solves can be solved by a sea of pencil pushers or factory line workers or human calculators or office clerks with filing cabinets or telephone switchboard operators or typists. The world used to run that way. I know what you mean, but this is the wrongest thing I've seen in quite a while! Because it ignores performance. Try implementing a video game with human clerks.
- wool_gather 7y agoIt's a good counterpoint; high-speed games like platformers and FPS are only really possible with a computer. Lots of other game types have analog analogs, though. Pinball is certainly a precursor to video games; there's other low-impact games of manual dexterity like ring toss/bocce/..., darts/target shooting. Choose your own adventure books/pencil and paper role-playing/wargames obviously predate computer gaming -- the computer just runs a timer maybe and acts as the gamemaster. People have been playing various forms of puzzle solitaire with cards for years; Bejewelled or whatever could be done with a custom deck. Minesweeper is not different in kind from the old logic game Mastermind. Even something like Tetris seems new, but I think is similar fundamentally to a tabletop game like Boggle: randomized input + a timer to find solutions -- the geometrical nature of Tetris is kinda just an implementation detail. But I would venture that the number of problems that are only quantitatively different -- i.e., faster -- because of computers utterly dwarfs the number that are qualitatively different, or even impossible without them.
- datalist 7y agoI am afraid, as jackcviers3 already said, you are missing the point. The goal of making applications is to have a piece of software at the end. That piece of software is the solution to the problem you have. Actually, in that very sentence of yours you explicitly repeated what I already wrote