What are the top pains of software developers?

Triaging, fixing, and backporting patches to CVEs that we were never _really_ vulnerable to but that are going to show up if a customer runs a scanner (and customers love to have zero tolerance policies for CVEs above a certain severity score).

A specific recurring example: My team works on CLI tools. CLI tools are not web servers, but may need to make network calls and so consume networking libraries. We have a steady trickle of server-side CVEs to triage, and some of them we need to apply the patch just for the sake of someone else's compliance/policy.

Solutions include: - make libraries more granular (e.g. a client-only library which is consumed by the client/server library); - make scanning tools 'smarter' - (e.g. there's some efforts in golang around a scanning tool that only detects vulns in code it can tell is reachable from static analysis) - e.g. I wish i could declare to a scanner "you are scanning a CLI that does not and cannot start a persistent webserver" -- there _might_ be room in the industry for a concept like SBOM but for behaviors - SBOB? - a consulting firm selling the fortune 500 type co.s on a more nuanced CVE stance?

Unfortunately I don't think there's any money to be made solving this problem, and in general the incentives of CVE scanners are misaligned, much like how anti-virus software thrives when it tells you how many viruses it just blocked....

Like others here I feel poor documentation is the most painful issue. Languages, IDEs, operating systems, and frameworks all have major problems with this. There is a very old joke that goes: "When they finally teach computers to understand English, they will realize that programmers can't speak English." There are reasons for this. To succeed, programmers must reduce complex ideas to mental symbols that can be manipulated without articulation. It is hard to achieve this ability and painful to go in the reverse direction.

There are times when programmers evade the responsibility to document their efforts and even times when so-called documentation is a patent fraud, a pretense at documentation. In general failure to adequately document your work is un-professional and degrades the profession. Just coding is not professional it is a subprofessional technical career.

For me, the biggest pain point is usually setting up a working development environment and other infrastructure, which is often hampered by poor documentation. Sometimes the documentation is really good for one of the ways to use some library/framework/service, but not so good if you have a slightly unconventional use case and then you get stuck.

Programming an application in any random programming language isn't usually too hard when you're handed a perfectly working environment and just need to build the business logic. Most websites don't take some crazy LeetCode skills to build. But getting to the stage where you have a working environment isn't always trivial even in this age of containers and all kinds of build tools.

I am a founder and also a software engineer. When I have my founder hat on, our dev team doesn't always like it because I will be like "people, we need to build this feature fast. Sorry I can't give you the whole wireframe. let's figure this out together based on the high level scope I can provide for now and we will figure it out". That's tough but in a startup, we gotta ship. The worst part: we will sometimes de-prioritize the whole thing after coding for a week. It is suddenly not that important.

I try to not do it all the time but it happens and I would rather do it than not. Thoughts ?

isn't that kind of like asking a heart attack patient besides the heart attack how are you feeling?

Every one else is not particularly interested in automating their work (away). Serious, schools/hospitals/gov/etc, everything else is slow and manual.

Discovering tribal knowledge. The frameworks provide a "framework", but the actual codebase is where the meat is. It's not just about knowing c# or PHP but learning the business, then how to solve the business problem with the technology.

For example. You have a flower delivery service. Programmers you understand flowers, types of packages, schedules, customer interactions will have an edge over everyone else.

Micromanagement and programming by remote control. No trust and respect that developers know what they're doing.

I see why managers act like this, though. If you're joining a dysfunctional project and try to fix it, they have no way of knowing that you aren't just blowing hot air and won't repeat the same mistakes as the previous devs.

Ever-changing requirements, client influence in software development that ultimately leads to unnecessary and often disposable code.

To me it’s when clicks have formed. And discussing choices/tech options becomes a debate group of A vs B. And whoever screams the loudest will win.

Some of my coworkers have opted to use the git-flow workflow :(

Dealing with transient errors. Nothing better than spending an hour debugging something only to find out that it’s caused by someone else’s change and you just have to sync to fix.

Carpal tunnel and poor posture causing back pain

Shoulder, arm and hand ones...maybe eyes and head as well

I also wanted to know this, looking in comment sections

Poor documentation.

Compliance requirements

Crushing stress

Software bugs