Live data from Hacker News

You’re not writing code, you’re solving problems

lanraccoon.com

61–70 of 143 posts

Re: You’re not writing code, you’re solving problems

#61
post #41

Earlier quoted context omitted.

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…

You 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…

> 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.

Re: You’re not writing code, you’re solving problems

#62
post #46

This reads to me like the faux-deep inspirational, vaguely-self-help-ish platitudes that litter facebook. Are there software engineers out there that don't know this? You're there to solve a problem and/or create a product. Code is a liability.

For most developers "productivity" is a measure of lines of code written per month.

Instead of number of problems solved MINUS the number of lines of code written.

Re: You’re not writing code, you’re solving problems

#63
post #17

I think this article constructs a strawman argument – pretty much all developers are solving some sort of problem. The big question is who you're solving problems for – when I was a single person doing freelance web work (like this article seems to assume), I was always solving problems for customers and their clients. Once I started working with other developers, I became interested in solving their problems too – s…

Aren't a lot of jobs about solving problems? A therapist solves psychological problems. A lawyer solves problems between people and organizational entities. A surgeon solves medical problems. The reason I'm asking this question is because a few groups proudly say that they are problem solvers. The most notable groups that I've seen are programmers and the consulting industry. But who isn't solving problems? Why this…

I think it's a reaction to programmers' particular tendency to focus on things that aren't best serving the goal of solving the problem at hand. Programmers often have a "pet" focus that relates to what they enjoy: performance optimizations, writing "clean" code, using some particular pattern or technology they like or want to try out, etc. None of those things are bad as long as they don't take precedent over solving the problem at hand.

Re: You’re not writing code, you’re solving problems

#64

Earlier quoted context omitted.

There's a real lack of humility among our industry, especially in the AI space. Literally you can google "AI solves world peace" or "AI solves COVID-19" and you'll hit an article. We also call ourselves ninjas when most of us are just building hugely complex infrastructure behind what is ultimately just a CRUD website.

That lack of humility also exists in other industries. You can Google "healthcare saves lives" and hit many articles

I’m gonna steal this for a comic I’m working on verbatim.

Re: You’re not writing code, you’re solving problems

#66
post #15

Earlier quoted context omitted.

If you don’t like it, don’t vote for it and move on. A content-free comment complaining that someone on the internet made something and gave it to you for free doesn’t add to the conversation.

My life would be much easier if I didn't have to dig through piles of useless garbage like that post. As a matter of fact that's why I like and keep coming back to Hacker News is because most of the posts I can read here are less fluffy than anywhere else. So yeah, if I don't respect something I am willing to fight for the right to see something I have respect for; even if I don't like it btw.

Vote for things you like and move on - commenting is just generating noise since it doesn’t affect ratings.

Re: You’re not writing code, you’re solving problems

#67
post #41

Earlier quoted context omitted.

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…

You 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…

> 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.

Re: You’re not writing code, you’re solving problems

#68
Very well written article. But i dont agree you should always rely on someone elses solutions. I think we went too far with it. Too many dependencies is as bad as duplicating code. Also i would add that sometimes solving problems with software can create new problems. Problems that can be solved only by more software. And this is also a risk

Re: You’re not writing code, you’re solving problems

#69
post #17

I think this article constructs a strawman argument – pretty much all developers are solving some sort of problem. The big question is who you're solving problems for – when I was a single person doing freelance web work (like this article seems to assume), I was always solving problems for customers and their clients. Once I started working with other developers, I became interested in solving their problems too – s…

Aren't a lot of jobs about solving problems? A therapist solves psychological problems. A lawyer solves problems between people and organizational entities. A surgeon solves medical problems. The reason I'm asking this question is because a few groups proudly say that they are problem solvers. The most notable groups that I've seen are programmers and the consulting industry. But who isn't solving problems? Why this…

Other than medical problems the rest aren’t necessarily real and could be seen as learned habits.

We “make up” problems and invent solutions at scale for people to abide social norms of needing a job.

Feeding oneself and learning about the world is work enough.

We don’t need all these “jobs”.

It’s social control at scale. Necessary evil, but we can do it differently now.

Re: You’re not writing code, you’re solving problems

#70
post #17

I think this article constructs a strawman argument – pretty much all developers are solving some sort of problem. The big question is who you're solving problems for – when I was a single person doing freelance web work (like this article seems to assume), I was always solving problems for customers and their clients. Once I started working with other developers, I became interested in solving their problems too – s…

I don't think it's a strawman at all. E.g., I've seen plenty of code where the problem the developers are solving is "I'm bored with work" or "I don't like my boss yelling at me about the deadline".

As an example, I was once brought in to help sort out a build pipeline. It was quirky, unreliable, and mysterious to the team using it. I dug in and it was built around Docker 0.8. But not even the official Docker 0.8; there were assorted patches applied for who-knows-what. And there was a bunch of other stuff glued on around it to compensate for the kinds of issues you would expect in 0.8-grade software.

Looking at the version history, the person who wrote it was long gone. So I searched for him on the Internet. One of the top hits was a conference talk, presented not long after finishing the build pipeline, on how awesome Docker was, and how very clever he was in applying it.

Sure, he was nominally solving the company's build pipeline problem. But really, the only problems he was solving were his own. Ego. Resume building. Wanting to play with fun toys.

At the end of the day, I ripped it all out and did what he should have done in the first place, which was to use simple, reliable tools that the team was comfortable working with.

Post reply on HN