Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

lanraccoon.com

Post reply on HN
Print view View original

131–140 of 143 posts

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

#131

Post by dwheeler »

I think this is important advice that needs to be repeated over and over and over again. The number of software developers who get caught up in the latest fashion choices, instead of carefully picking the right set of tools for the job, is absurd. Sometimes it's really important to use the latest thing because it solves a key part of your task; often it's better to use a "boring" technology that is well-understood and does the job without a lot of fuss.

I remember years ago, when I was in high school, reading advice that "customers don't want drills, they want holes". Software developers should constantly focus on what the customer actually wants (that is, the problem the customer is trying to solve).

It sounds trite, but it's easy to get distracted when you're knee-deep in trying to solve the problem.

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

#132

Post by klysm »

Ozzie_osman wrote: post #23

I liked this article, but one point it misses is that you should be solving problems in a way that makes it easy to keep solving problems in the future, and that's a tradeoff that even more people get wrong. For instance, writing good, maintainable code only matters because if you don't, you might reduce your ability to solve more problems in the future when the problems you need to solve might change, due to learnin…

This seems like an interesting generalization/characterization of technical debt.

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

#133

Post by Reelin »

Yajirobe wrote: post #126
Reelin wrote: post #106

Earlier quoted context omitted.

In Python, I fight with dependencies and the GIL (try getting Matplotlib to update an interactive graph in real-time, it's not fun). In Lisp, I lose time manually writing FFI wrappers. It really makes you appreciate the size of Python's ecosystem. In C++, I spend inordinate amounts of time buried in the language standard. It's just _so large_. In C, I have "fun" with manual memory management, name collisions, and boi…

How do you update an interactive graph in Lisp?

Via the FFI declarations you manually wrote to your favorite graphing library that exports a C API? All major Common Lisp implementations have threading built in, and unlike Python performance is excellent without dropping to C.

As an example, I recently wrote a GLFW backed program with the GPU boilerplate in C++ and all the high level logic in Lisp. I could have done the entire thing in Lisp, but there was less API surface area to wrap this way.

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

#134

Post by friendlybus »

mettamage wrote: post #57
muglug wrote: 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…

Flipping bits on a computer screen can appear helpful when it isn’t. Building an abstraction needs to be constantly grounded with solving real world problems.

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

#135

Post by frez1 »

bsdubernerd wrote: post #30
datalist wrote: post #19

"You're not cooking meals, you're solving problems"

By extension (and legitimate curiosity), who _isn't_ solving an actual problem in his day job? I can think of many classes of artists, but cannot put a blank statement for _all_ of them.

The idea is to keep your mind clear on what the priority is. If you didn't write many lines of code but still solved problems, you did your job. The two aren't mutually exclusive, but it helps in prioritization

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

#136

Post by pezo1919 »

"You’re not writing code, you’re solving problems" is true, but in an appropriately bad company its also true and maybe much more important:

You are not solving problems, you are writing code.

That's when management or upper levels in hierarchy are not experts and have no idea what's the software and the particular problem is about and micromanage.

My point is that the warning the title refers to is real, but there is another (bigger) problem when people know they are not solving the problem the right way but they are forced to ship asap and "just code".

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

#138

Post by mikekchar »

Pareto Principle... If some young person is at a loss for a science fair project, I humble suggest to attempt to replicate this experiment: Grow some peas. Count the number of peas in a pod. Verify that 20% of the pods contain 80% of the peas.

In case you prefer the thought experiment version, consider that you have 100 peas. 80% of 100 is 80 (I like easy math). That means that 20% of the pods contain 80 peas. It means that 80% of the pods contain the other 20 peas. If we have 10 pods total, it means that 2 of the pods have 40 peas each and the other 8 have 2.5 peas each on average. I ain't never seen no pea pods with 40 peas in them, so it must be more pods. I think the most peas I can imagine in a pod are 10, so let's say that 8 pods have 10 peas each and 32 pods share the remaining 20 peas. Since you can't have less than 1 pea, that means that you have at least 12 pods empty even if the other 20 pods only have 1 pea each. If you have a more reasonable distribution, you will find that more than 40% of the pods will be completely empty.

I've grown peas a lot. I've never, ever seen a distribution of peas like that in pods. What strange peas was Pareto growing? Is it just that we have better strains of peas now, or was Pareto just making stuff up? (small voice: just like practically every application of the Pareto principle I've ever seen...) ;-)

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

#139

Post by liquidify »

reedwolf wrote: post #93
lainga wrote: post #87

Earlier quoted context omitted.

Hoh! I spend most of my time figuring out pipenv (not my design choice!) .

Python packaging is now a solved problem. Use Poetry. Resolves all your dependencies and manages your virtual environments. Also lets you build and publish your own projects with a few commands. https://python-poetry.org/

Wait, whats wrong with pip and venv with a requirements.txt file?

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

#140

Post by wetwiper »

Despite having used the "we're solving problems" argument myself on occasion, I think what we're really doing is identifying problems and assisting with possible solutions using particular knowledge of our domain.

Somebody wants something done within particular constraints, so our job is to identify potential issues that may occur, such as scalability problems, costing issues, UX concerns, etc. And help explain to that client such concerns and possible solutions or compromises, and let the client decide on the solution.

Once actually implementing some plan, we have some creative freedom on the implementation details, but I'd hardly call that solving a problem (apart from it being your own problem on how to get the design coded up).

Post reply on HN