9 ms·

Programming Sucks

127 points by efrafa 8y ago

blastbeat 8y ago
> So no, I’m not required to be able to lift objects weighing up to fifty pounds. I traded that for the opportunity to trim Satan’s pubic hair while he dines out of my open skull so a few bits of the internet will continue to work for a few more days. This is pure comedy gold, thanks!
Waterluvian 8y ago
I'm becoming increasingly convinced that the frustrations found in programming teams are largely because the industry wrongly selects foremost for programming skills and not for people skills. Being a good coder is like 30% of your job. The rest is being a good teammate, which is about diplomacy and communication. My favourite co-workers today and in the past would almost certainly never get a FANG interview but damn do they have the passion to do well and work together. Just my experience.
- nitely 8y ago
  The article is a rant about bad code, not about bad teammates. Maybe they were hired because the manager liked them for having people skills instead of actually being good at their jobs. I agree communication is an important part as well, that does not has much to do with people skills, though. Being a good programmer should be more like 75% of a programmer's job to actually make their temmates life easier.
- NicoJuicy 8y ago
  Joined a code base and all I see are bugs ( eg. Casting bugs are easy to find) + logic errors. I think good programming is how much wtf/ minute you have, when you read the source. I'm normally easy to talk to, but I'm having difficulty for that now because: - fixing a simple bug leads to a rabbit hole of fixing bugs. - no seperation. Something can influence something everywhere. It's nuts, eg. A text explanation on a enum ( state) has been added in the businesslayer and transformed 3 times before it reaches the frontend. ( I removed all those texts to show only on the view with the appropriate conditionals) - code is unreadable -> too much time spend in debugging - a bug was fixed when it did something wrong, instead of looking for the root of the problem. So actually fixing a bug correctly creates a new bug, because it has already been fixed 2 times on different places. Just the root case was never fixed before. - ... All in all, solving a bug is tedious. Fixing it the right way, creates so much bugs, because previous workarounds for probably the same/similar bug everywhere around. I'm pretty sure that good programming leads to better communication. And bad programming leads to a clusterfuck of problems
  - noir_lord 8y ago
    That sounds too much like the code base I inherited, it gradually wears on you.
  - jm__87 8y ago
    Maybe I've worked with bad code for too long, but my opinion is, being the one person who understands some clusterfuck of poorly designed and hard to read code is job security and improving it can be satisfying. Reducing coupling, making a codebase more readable, rewriting code to make it more unit testable, or making a given piece of code run faster I find to be satisfying and educational. You learn from direct experience a myriad of ways in which not to do things and exactly why not to do them, and you can use this information going forward when you write your next feature.
    - slavik81 8y ago
      It can also be incredibly frustrating. There's a human reason the code is a mess, and unless that situation changes, the code will rapidly revert to a mess no matter how clean you make it.
      - jm__87 8y ago
        Not necessarily. At least in my experience, most people want to improve their coding skills and if you build a good relationship with your coworkers and have a track record of putting out good work, then you'll be in a position to offer up suggestions on how everyone can improve.
        slavik81 8y ago
        When the underlying problem is a lack of knowledge in the group, it can be easily fixed by the introduction of someone with the neccessary knowledge. In that case, you are solving the human problem. That's one of many possible reasons for why the code is a mess.
        8y ago
- walterstucco 8y ago
  If you hire software developers they should be good at developing software. "People skills" should not really be the priority when you interview someone for a technical position. Good people, who are bad at what they are hired to do, ruin the team's morale as much as bad people.
marsrover 8y ago
One of my favorite articles. So funny.
enriquto 8y ago
> Every programmer occasionally, when nobody’s home, turns off the lights, pours a glass of scotch, puts on some light German electronica, and opens up a file on their computer. It’s a different file for every programmer. Sometimes they wrote it, sometimes they found it and knew they had to save it. They read over the lines, and weep at their beauty, then the tears turn bitter as they remember the rest of the files and the inevitable collapse of all that is good and true in the world. This file is Good Code. oh my god! this is so much me it is not even funny
- skytreader 8y ago
  Funny thing. I see this article is from 2014 so I may have read it before, or been quoted to me before. But just last December I got into a discussion about clean code with someone who looks at me for some mentorship and I used this "line" (for lack of better term) to drive home my point. It wasn't verbatim of course, but I particularly remember the reference to "light German electronica", and I don't even listen to _any_ electronica to begin with. And today I encounter the actual article where this originated from. This bit is iconic.
- _bxg1 8y ago
  I've come to believe that the only good code is code with no actual requirements.
  - repsilat 8y ago
    I took six months off to sit on a beach and write a bit of code, answer to nobody, and I'm not so sure. (I made https://6gu.nz https://6gu.nz, if it's still up...) I learned that corporate project management isn't the problem. I am the problem. Sometimes I'll take a little short-cut, because an innocuous little hack that adds a constraint or assumption seems like better value than going the long way round. Sometimes the design changes as you figure out new ways the product can/should work to be cooler, and old abstractions are no longer useful, or new abstractions become useful, or data that lives over here now needs to get aaaallll the way over there, God Dammit. All abstractions leak, and the first design is never right. And maybe it's fine, because I wrote it all and I can rewrite it quickly enough, but in the real world we can't just go and rip up that code because we don't have the muscle-memory for it, and because of Chesterton's fence. Maybe good code is code that can be deleted easily, or rewritten without fear. Maybe it is code that has been rewritten enough or has survived long enough to embody some kind of wisdom. I know that it is simple, and that it makes the life of its user simpler.
androidgirl 8y ago
This is absolutely my favorite programming rant, of all time. It gets me through the day. When management asks something nonsensical, or I'm forced to push a hack to prod to fix things.
hcarvalhoalves 8y ago
Old but gold. > Composed on the 27th of April in the year 2014 5 years later, and it still sucks.
_bxg1 8y ago
Always a classic. I keep this one bookmarked.
holografix 8y ago
“Most people don’t even know what sysadmins do, but trust me, if they all took a lunch break at the same time they wouldn’t make it to the deli before you ran out of bullets protecting your canned goods from roving bands of mutants.” this got me Lol’ing pretty loud
- redsavagefiero 8y ago
  Actually 10% of the sysadmins make the other 90% look pretty good in this respect. I've woken many mornings at 4 am without an immediate rationale to realize a moment later that there could be a problem and it could be mine. The SA mind is the best arbiter of possibility within the open domain unrealized by data learnage.
hjk05 8y ago
I’ve worked in industrial production in the semiconductor industry and have friends who work building large housing projects, and I have to say that their example of “wouldn’t it be stupid if bidgebuilding was like software!?” Is a bad one. You get the exact same stupidities and inefficiencies everywhere else. People bikesheading over trivial design elements, forcing their specialties into each project and so on. It’s not a software specific thing.
- cafard 8y ago
  I once quoted to an architect Gerald Weinberg's dictum that "If architects built building the way programmers build programmers, the first woodpecker to come along would destroy civilization." She said, "But that is the way architects build buildings.
LifeLiverTransp 8y ago
The problem is when you get high on your own genious- and create something that seems to improve performance, and breaks the architecture- then you return years later- and the optimization has become the limitation for all after you. Yet nobody wants to rip it out, because - its beautifull. Stick to the plan Stan. Even when it could be better steven.
platform 8y ago
90% of commercial programming, is really invoking somebody else's APIs. In my experience, most problems and frustration comes from working the APIs (or somebody else's interpretation of the business need) -- not programming language.
- serpi 8y ago
  My. primary frustration is working with Javascript data structures after using Clojure maps for 4 years. I sometimes write something taking several lines and then for shits and giggles write the same in Clojure and just weep for the armies of programmes who just have no idea...

127 points by efrafa 8y ago

> So no, I’m not required to be able to lift objects weighing up to fifty pounds. I traded that for the opportunity to trim Satan’s pubic hair while he dines out of my open skull so a few bits of the internet will continue to work for a few more days. This is pure comedy gold, thanks!

Waterluvian 8y ago

I'm becoming increasingly convinced that the frustrations found in programming teams are largely because the industry wrongly selects foremost for programming skills and not for people skills. Being a good coder is like 30% of your job. The rest is being a good teammate, which is about diplomacy and communication. My favourite co-workers today and in the past would almost certainly never get a FANG interview but damn do they have the passion to do well and work together. Just my experience.

nitely 8y ago
The article is a rant about bad code, not about bad teammates. Maybe they were hired because the manager liked them for having people skills instead of actually being good at their jobs. I agree communication is an important part as well, that does not has much to do with people skills, though. Being a good programmer should be more like 75% of a programmer's job to actually make their temmates life easier.
NicoJuicy 8y ago
Joined a code base and all I see are bugs ( eg. Casting bugs are easy to find) + logic errors. I think good programming is how much wtf/ minute you have, when you read the source. I'm normally easy to talk to, but I'm having difficulty for that now because: - fixing a simple bug leads to a rabbit hole of fixing bugs. - no seperation. Something can influence something everywhere. It's nuts, eg. A text explanation on a enum ( state) has been added in the businesslayer and transformed 3 times before it reaches the frontend. ( I removed all those texts to show only on the view with the appropriate conditionals) - code is unreadable -> too much time spend in debugging - a bug was fixed when it did something wrong, instead of looking for the root of the problem. So actually fixing a bug correctly creates a new bug, because it has already been fixed 2 times on different places. Just the root case was never fixed before. - ... All in all, solving a bug is tedious. Fixing it the right way, creates so much bugs, because previous workarounds for probably the same/similar bug everywhere around. I'm pretty sure that good programming leads to better communication. And bad programming leads to a clusterfuck of problems
- noir_lord 8y ago
  That sounds too much like the code base I inherited, it gradually wears on you.
- jm__87 8y ago
  Maybe I've worked with bad code for too long, but my opinion is, being the one person who understands some clusterfuck of poorly designed and hard to read code is job security and improving it can be satisfying. Reducing coupling, making a codebase more readable, rewriting code to make it more unit testable, or making a given piece of code run faster I find to be satisfying and educational. You learn from direct experience a myriad of ways in which not to do things and exactly why not to do them, and you can use this information going forward when you write your next feature.
  - slavik81 8y ago
    It can also be incredibly frustrating. There's a human reason the code is a mess, and unless that situation changes, the code will rapidly revert to a mess no matter how clean you make it.
    - jm__87 8y ago
      Not necessarily. At least in my experience, most people want to improve their coding skills and if you build a good relationship with your coworkers and have a track record of putting out good work, then you'll be in a position to offer up suggestions on how everyone can improve.
      - slavik81 8y ago
        When the underlying problem is a lack of knowledge in the group, it can be easily fixed by the introduction of someone with the neccessary knowledge. In that case, you are solving the human problem. That's one of many possible reasons for why the code is a mess.
        8y ago
walterstucco 8y ago
If you hire software developers they should be good at developing software. "People skills" should not really be the priority when you interview someone for a technical position. Good people, who are bad at what they are hired to do, ruin the team's morale as much as bad people.

marsrover 8y ago

One of my favorite articles. So funny.

enriquto 8y ago

> Every programmer occasionally, when nobody’s home, turns off the lights, pours a glass of scotch, puts on some light German electronica, and opens up a file on their computer. It’s a different file for every programmer. Sometimes they wrote it, sometimes they found it and knew they had to save it. They read over the lines, and weep at their beauty, then the tears turn bitter as they remember the rest of the files and the inevitable collapse of all that is good and true in the world. This file is Good Code. oh my god! this is so much me it is not even funny

skytreader 8y ago
Funny thing. I see this article is from 2014 so I may have read it before, or been quoted to me before. But just last December I got into a discussion about clean code with someone who looks at me for some mentorship and I used this "line" (for lack of better term) to drive home my point. It wasn't verbatim of course, but I particularly remember the reference to "light German electronica", and I don't even listen to _any_ electronica to begin with. And today I encounter the actual article where this originated from. This bit is iconic.
_bxg1 8y ago
I've come to believe that the only good code is code with no actual requirements.
- repsilat 8y ago
  I took six months off to sit on a beach and write a bit of code, answer to nobody, and I'm not so sure. (I made https://6gu.nz https://6gu.nz, if it's still up...) I learned that corporate project management isn't the problem. I am the problem. Sometimes I'll take a little short-cut, because an innocuous little hack that adds a constraint or assumption seems like better value than going the long way round. Sometimes the design changes as you figure out new ways the product can/should work to be cooler, and old abstractions are no longer useful, or new abstractions become useful, or data that lives over here now needs to get aaaallll the way over there, God Dammit. All abstractions leak, and the first design is never right. And maybe it's fine, because I wrote it all and I can rewrite it quickly enough, but in the real world we can't just go and rip up that code because we don't have the muscle-memory for it, and because of Chesterton's fence. Maybe good code is code that can be deleted easily, or rewritten without fear. Maybe it is code that has been rewritten enough or has survived long enough to embody some kind of wisdom. I know that it is simple, and that it makes the life of its user simpler.

androidgirl 8y ago

This is absolutely my favorite programming rant, of all time. It gets me through the day. When management asks something nonsensical, or I'm forced to push a hack to prod to fix things.

hcarvalhoalves 8y ago

Old but gold. > Composed on the 27th of April in the year 2014 5 years later, and it still sucks.

_bxg1 8y ago

Always a classic. I keep this one bookmarked.

holografix 8y ago

“Most people don’t even know what sysadmins do, but trust me, if they all took a lunch break at the same time they wouldn’t make it to the deli before you ran out of bullets protecting your canned goods from roving bands of mutants.” this got me Lol’ing pretty loud

redsavagefiero 8y ago
Actually 10% of the sysadmins make the other 90% look pretty good in this respect. I've woken many mornings at 4 am without an immediate rationale to realize a moment later that there could be a problem and it could be mine. The SA mind is the best arbiter of possibility within the open domain unrealized by data learnage.

hjk05 8y ago

I’ve worked in industrial production in the semiconductor industry and have friends who work building large housing projects, and I have to say that their example of “wouldn’t it be stupid if bidgebuilding was like software!?” Is a bad one. You get the exact same stupidities and inefficiencies everywhere else. People bikesheading over trivial design elements, forcing their specialties into each project and so on. It’s not a software specific thing.

cafard 8y ago
I once quoted to an architect Gerald Weinberg's dictum that "If architects built building the way programmers build programmers, the first woodpecker to come along would destroy civilization." She said, "But that is the way architects build buildings.

LifeLiverTransp 8y ago

The problem is when you get high on your own genious- and create something that seems to improve performance, and breaks the architecture- then you return years later- and the optimization has become the limitation for all after you. Yet nobody wants to rip it out, because - its beautifull. Stick to the plan Stan. Even when it could be better steven.

platform 8y ago

90% of commercial programming, is really invoking somebody else's APIs. In my experience, most problems and frustration comes from working the APIs (or somebody else's interpretation of the business need) -- not programming language.

serpi 8y ago
My. primary frustration is working with Javascript data structures after using Clojure maps for 4 years. I sometimes write something taking several lines and then for shits and giggles write the same in Clojure and just weep for the armies of programmes who just have no idea...