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....
Urgh, there are lots of box-ticking tools like that in the industry like blackduck, sonarqube, coverity, etc that scan for problems of various kinds.
Like you say a lot of what they actually find is theoretical and not useful, often it's like "If a tree falls in a forest and no one is around to hear it, does it make a sound?", yes it's theoretically an issue... but actually that code path is not reachable, the vulnerable part of the library is not used, etc - there is some external information that the tool lacks that makes the results incorrect and not useful.
These things are just driven by senior management needing to do "something" about bugs/security, so they buy something that can do scans and produce reports and stuff, but the cure ends up being worse than the disease.
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.
> 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.
I wonder if I never achieved that ability, which is the reason that I pretty much always articulate coding ideas, in English, in my head. Maybe that's why I document so much better than other devs I've seen. ;p
It's sometimes obvious that it isn't the best approach to thinking through some things though. Cue paragraphs of explanation for a one line math formula.
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 ?
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.
Yes and no. Building is great. I actually think that code is disposable, but products are not, at least within a healthy delta T. Code review, refactoring and the eventual full re-write is one of the most satisfying activities IMHO.
However, software suffers from badly managed customization, hard-coding, due to pressure and functionality that may not be necessarily good to all users in the system - that's what I'm referring to. =)
Well structural issues will almost always cause suffering regardless of if its software, or management/organizational. They are all systems, and antipatterns creep-in sometimes regardless of how good you may happen to be. Flexibility is what makes or breaks things.
If you can't get a good handle on the specific business requirements, or lack the power to enact necessary changes; any solution is going to be a poor approximation and potentially cause negative production value with someone.
Imo, Products are just a collection of processes that fulfill requirements. Documenting those processes and requirements is 80% of the battle, most of the issues I've run into were only issues because they weren't documented (i.e. edge-cases that are surprisingly common).
Many times, the people and processes involved don't share/get documented because they often view this implicit knowledge as job security. This often takes a really rare/gifted person with knowledge in both IT and psychology to get what you need.
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.
What about it, exactly? You can't stand 8h a day and also standing comfortably is not possible beyond 30m and that shouldn't be done more than 2-3 times a day because it's tiring, as in, it drains your energy and you can't do anything else even after work.
I do have a standing desk and I love it that I can adjust the height and wouldn't replace it with a stationary one but it's not the magical fix for the extremely destructive effects of prolonged sitting that many pretend it to be.
Standing desks are, at best, something that reduces those extremely destructive effects of sitting by something like 5%. Which doesn't matter one bit because the nature of the health destruction by sitting is that it kicks in after you go past certain time of sitting. Taking a break from sitting doesn't help much. 5-30 minutes later you're back on the chair and the cumulative negative effects from the sitting for the day are more less the same as a result.
Let's not dance around it: you should apply a non-negotiable maximum amount of sitting at the computer per day (depending on your health that is basically 3 to 5 hours) or else you'll need electro-stimulation and vibro-massage every day just to reduce the chromic tiredness by a little but still end up rapidly losing health from one point and on anyway.
From my experience unless you have some undelining conditions you can stand for most of the day. I got used to it in a few weeks time and got ridden of my lower back pain.
Perhaps stand as a default and take sitting breaks as needed?
Anecdotal evidence. I've known security guards that were athletes before the job and they all said the same: "I could do various sports (or hike in the mountains) for 14-15h before needing to sleep but stand around guarding a shop for just 1h and I am more tired compared to what I was doing those 14-15h in the past".
Be grateful for your health, seriously. A lot of us aren't elves with unlimited energy.
Also I don't want to be mean but your advice is super shallow and practically ignored everything I said in my previous comment.
More generally, poor communication of technical information. Poor communication of requirements. Poor communication of architecture. Poor communication of design. Poor communication of intent in code.
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....