Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming

Developers Are Quitting To Escape From Your Bad Code (zdnet.com) 160

Posted by BeauHD from the survey-says dept.
An anonymous reader shares an excerpt from a ZDNet article, written by Liam Tung: [A] survey has come up with another reason why your engineers might want to quit -- their fellow developers' terrible code. Software engineers have long struggled with 'technical debt' created by past coding practices that might have been clever but also were undocumented and exotic. At a high level, technical debt is the price paid by supporting legacy systems rather than overhauling them or implementing a better, new system. The term can span everything from a major IT implementation, such as a core banking system that requires a decade of bug fixes, to the choice of programming language to build backend systems. In the latter case, subsequent language updates can require today's developers to rewrite old code written by long-gone developers who wrote under different conditions and who might not have documented what they did and why they did it. That's a big problem for companies that have millions of lines of code written in a language.

Stepsize, a firm that focuses on technical debt by tracking development issues in major code editors such as VS Code, conducted a fairly small survey of 200 software engineers to find out why they leave their jobs. The company said that 51% of engineers in its survey have considered leaving or left a job because of technical debt. Of that group who feel irked by technical debt issues, some 20% said that type of debt is the main reason they left a company. The results should be taken in context: the company's key selling point is trying to solve technical debt challenges that organizations face, but at the same time, technical debt could be one area worthy of attention considering how hard it is to hire and retain software engineers.

Technical debt, or 'code quality and codebase health', was the fourth most important issue cited by respondents. Salary still trumped it, with 82% citing it as one of the "most important factors" when interviewing for a new role. The survey allowed respondents to choose several primary factors. "Technical challenges and growth opportunities" was the second priority, with 75% choosing it as the one of the most important factors. Some 68% of respondents said remote work was the most important actor, while 62% put said 'code quality and codebase health' was one of those prime factors. Slashdot reader ellithligraw first shared the report, adding: "Yet another reason developers are quitting... to escape the technical debt, or schlock code, or code rot. COBOL anyone?"
This discussion has been archived. No new comments can be posted.

Developers Are Quitting To Escape From Your Bad Code More

Developers Are Quitting To Escape From Your Bad Code

Comments Filter:

  • How interesting (Score:5, Insightful)

    by NaCh0 ( 6124 ) on Thursday September 30, 2021 @07:05PM (#61849581) Homepage

    It's interesting that a company specializing in technical debt found that technical debt is considered a problem by 75% of developers.

    Has the C-Suite of your company heard of this growing problem yet? Perhaps the same company who identified the problem can supply a solution.

    • came here to say this

      'Article' is an Ad.

      • I wondered who coined the term "slash retirement"? It reminds me of the time I went to work for a startup. We got stuff published in industry trade rags, tech news sites, and Web 2.0 sites. I found out we paid money to a PR firm, and they made all that stuff happen. All we had to do was provide them with a draft of what we wanted published.

    • Re:How interesting (Score:5, Funny)

      by BeerFartMoron ( 624900 ) on Thursday September 30, 2021 @08:45PM (#61849763)
      I'm hoping their next article is, "98% of Windows Admins are raging alcoholics".

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      Even though the article seems like an ad, I've been at places where they had insane amounts of technical debt. The Scrum master was the product manager, so the dev team has been in a sprint for years on end, and the PM felt that not in a sprint was like not hitting the gas pedal on a car. Nothing was done about technical debt, very little was documented, and the code had things like Rosary prayers, "Don't touch this, we don't know how this works" comments, duplicate tables in the backend database because

      • A language I used to program in / support was COBOL and there were a couple of cases which really stank.

        One particular programmer would have variable names such as I1-V1, I2-V1, I1-V2 and so on. I had to work on a suite he had written - after he had left - and ended up doing global changes on variable names to make them less ambiguous. He would also have PERFORM S1. and then S1. PERFORM T1. That took quite a bit of restructuring. Once this new version was running ok I could start on the real changes.
        In my

      • the PM/Scrum master would threaten them with a pink slip
        An example where Scum went wild. Neither the PM nor the Scrum master has any authority over the team doing the programming.

        But I'm sure: someone will blame Scrum :P (or "agile")

    • Re: (Score:2)

      by tlhIngan ( 30335 )

      It's interesting that a company specializing in technical debt found that technical debt is considered a problem by 75% of developers.

      Has the C-Suite of your company heard of this growing problem yet? Perhaps the same company who identified the problem can supply a solution.

      I'd be interested in solutions, because the C-suite almost always isn't. Make it work now, fix it properly later. Except "later" never gets planned in - if you're not working on the next great revision, you're not being a profitable deve

    • It's not wrong to leave a job for tech debt. There are plenty of companies or managers out there who want to squeeze the last dime out of there software investment. A friend is mine works at small, but global food-logistics company who warehouse floor systems run on PDP emulators. His job was stressful for other reasons, but I could imagine quitting if upper management demands frequent enhancements to those systems.

      On the other hand, I've wanted to leave companies that chose to solve tech debt with The Big

  • The best way to learn to avoid technical debt is to put in the effort to fix some technical debt. Then you won't make those mistakes again (or you will catch them quickly).
    These people who quit because of technical debt go from company to company, leaving behind a trail of ugly Webpack.config files and Makefiles. Learn to fix it once and you've got it.

    • Re:The best way to learn (Score:5, Informative)

      by tepples ( 727027 ) <tepplesNO@SPAMgmail.com> on Thursday September 30, 2021 @07:56PM (#61849671) Homepage Journal

      The best way to learn to avoid technical debt is to put in the effort to fix some technical debt.

      Provided your employer gives you time to engineer a fix rather than just bandaging it over and over in order to have the new feature done yesterday.

      • Then open-source shouldn't have any "technical debt" since as the saying goes, "it's done when it's done".

      • Re: (Score:2)

        by Jeremi ( 14640 )

        Provided your employer gives you time to engineer a fix rather than just bandaging it over and over

        As the old saying goes, if you don't have time to do it right, you won't have time to do it over either.

        Sometimes you just have to nod and smile to your employer, and then go in and do the right thing anyway. Your near-future self will thank you (and if you get fired for doing the right thing, your near-future self will still thank you, for extracting yourself from a bad work environment).

      • If your employer does NOT allow you to work in a manner you find satisfying, now is a very good time to find another employer.
    • Better practices will help some, but the basic fact is that learning somebody else's code is unpleasant and the tendency to think the previous guy was an idiot and the desire to rip everything out and redo it in a way intuitive to yourself is more or less universal.

      • If the other guy was a good programmer, he simply wrote the code as I would have had. Hence nothing unpleasant or unreadable. And yes: that is actually a very universal standard amoung programmers/developers.

        desire to rip everything out and redo it in a way intuitive to yourself is more or less universal
        Only if the code is:
        a) incomprehensible bullshit -and -
        b) you have the original speccs

        Because without speccs you have no real clue by what/how to replace it.

  • Sounds about right (Score:5, Insightful)

    by quonset ( 4839537 ) on Thursday September 30, 2021 @07:18PM (#61849615)

    Developers have to have some reason to justify their existence, so why not blame someone else?

    It's clear that in many cases the reason for pushing out a new version of software is for the eye candy. There is very little under the hood which is different from the previous version so the only other way to claim they're needed is for developers to make rounded corners, make things transparent or remove critical clues for where to click or drag something. And this doesn't include the newest fascination with hiding something until you happen to mouse over it, and then making it a full two pixels wide to grab onto.

    This is also prevelant in web "design". Something as simple as displyaing a picture now requires several different scripts. And don't even think about displaying a video if you have less than 10 different scripts. Why make something simple when you can show off your coding instead?

    • Re: (Score:3)

      by Jeremi ( 14640 )

      It's clear that in many cases the reason for pushing out a new version of software is for the eye candy.

      Yes, but the eye candy is just a means to an end. The real reason for pushing out a pointless new version is that the company needs to sell software in order to keep paying salaries, therefore they need to come out with new versions periodically, whether the anyone will actually benefit from the new version or not.

      That's one reason so many companies are pushing "software as a service" subscriptions lately; if it catches on, it frees them from having to choose between ruining their own software with unneces

    • Re: (Score:3)

      by AmiMoJo ( 196126 )

      That's not really what technical debt is about.

      When looking at new jobs I always ask if they have a lot of old code to maintain or if I'll be creating stuff from scratch. A mountain of old code is a big red flag, and if they specifically ask if I am happy to work with an existing code base there's no way I'm taking that job.

      Might get lucky and the code is well documented and well designed so that making changes is easy, but more likely it's a giant pile a technical debt that the last person quit to get away

    • Re: (Score:2)

      by gTsiros ( 205624 )

      I _think_ w10 window border is *one* pixel thick?

  • But where do I go that doesn't have it? I suppose a very new startup, but the risk from a job like that is probably going to make my life worse than dealing with a bit of technical debt.

  • All too often, you need to burn it to the ground (Score:5, Informative)

    by unfortunateson ( 527551 ) on Thursday September 30, 2021 @07:31PM (#61849645) Journal

    One of the first projects I worked on, 38 years ago, was a nightmarish piece of Fortran, that looked reasonable, but had truly awful performance due to the use of a BACKSPACE command -- worked effectively on tape drives, but for disks it would go back to the beginning of the file and read forward one fewer records. I rewrote it (in VAX Basic, which at times was indistinguishable from VAX Pascal, but that's another show), and it was dozens of times faster, just by avoiding the BACKSPACE.

    And years later, I was asked to help the Word Processing support group with some WordPerfect macros, was horrified at the half-recorded/half-authored mess, and said, "give me that, and don't touch it ever again!"... which eventually led to my being an expert in several generations of Microsoft Word VBA.

    But I know there's stuff I wrote that I'd never want anyone to fix, only rebuild (some '90s cookie-driven shopping cart Perl code comes to mind).
    It's not just "tech debt", it's learning, it's changing of standard ways of doing things, it's just getting better.
    That works for utilities, small projects, but is obviously a nightmare for million-line projects.

    • In my 2nd or 3rd assignment I had to work on an MMI implemented in C using FORTRAN thinking. Shared global variables. No structs, no use of pointers, just arrays.

      Surprisingly it did not use gotos as much as you would have expected.

      Maintained that code for a few years.

      • Re: (Score:2)

        by HiThere ( 15173 )

        In many case arrays are much better than pointers. There's less chance of wild addressing, and it's feasible to decide in the code if the index is within bounds without adding lots of complexity.

        Pointers are drastically overused by many C programmers. At one point there was a decent reason to do so (optimization for speed), but that time is long past.

        Yeah, I started out in Fortran. But when I have a choice I still prefer to avoid pointers. They're dangerous in anything except a really small piece of cod

  • "coding practices that might have been clever but also were undocumented and exotic."

    Describes every javascript "guru" ever. Why write code that's logical, straight-forward and readable when I can put everything in 1 line that only makes sense to me, who cares if anyone can debug it in 5 years.

  • it should be hard to understand.

    The fun part is when the code is exquisitely commented by one of the subsequent generations of engineers, but every single comment is something to the tune of, "this looks like it gathers the coefficients" and "Fred was the only one who understood it."

    The last bit I found in some publicly released code from NASA. Closer inspection and research identified "Fred" as a staff scientist at JPL in the early 1960s.

    • Re:If it was hard to do (Score:5, Informative)

      by theshowmecanuck ( 703852 ) on Thursday September 30, 2021 @08:02PM (#61849677) Journal

      Debug code, comments lie.

    • It's rare that code does something hard these days. Most of us are just building scaleable websites or integrating APIs, we're not doing hard stuff. JPL might be a cool exception.

      • Re:If it was hard to do (Score:5, Insightful)

        by kmoser ( 1469707 ) on Friday October 01, 2021 @12:37AM (#61850075)
        Yeah, but today's stacks abstract everything to the nth degree, so instead of a straightforward path, you end up with a Byzantine collection of brittle components that effectively makes for an environment that is difficult to learn and even harder to change without breaking something. So while the actual application may be simple, it's the surrounding components that are complex.

        • Yeah, but today's stacks abstract everything to the nth degree, so instead of a straightforward path, you end up with a Byzantine collection of brittle components that effectively makes for an environment that is difficult to learn and even harder to change without breaking something.

          That's up to you. If you write code like that, then you'll end up with code like that. Don't write code like that, you don't need to.

    • Re: (Score:2)

      by Tablizer ( 95088 )

      That's often better than no comments, because you have clues to go on.

      • That's often better than no comments, because you have clues to go on.

        Maybe. Sometimes the comments are misleading and send you down a rathole. Inline comments are a code smell.

  • Rather odd timing:
    Automated Testing of Gameplay Features in 'Sea of Thieves' [youtu.be] You sure YT isn't hooked into Slashdot?

  • Breaking changes are a language failure. (Score:5, Informative)

    by Myself ( 57572 ) on Thursday September 30, 2021 @08:30PM (#61849735) Journal

    "subsequent language updates can require today's developers to rewrite old code"

    That's the definition of a failure by the language, and it's now a new language. It may share some semantics with the other language, but anyone trying to push breaking changes in the language itself should be seen as the enemy.

    Sure, this keeps programmers employed, but everyone knows when they're doing a "bullshit job" that shouldn't even exist. Rewriting working code to satisfy a language wanker's vanity is the most bullshit job I can imagine. No wonder people quit over it.

    • *cough* Python *cough*

  • "past coding practices that might have been clever"

    You say that like it's a good thing.

  • Here's a new saying (Score:5, Insightful)

    by DontBeAMoran ( 4843879 ) on Thursday September 30, 2021 @08:43PM (#61849761)

    "Clever code is the enemy of maintainable... erm, code."

    Somebody should probably rephrase that into something better, but you get the general idea.

    Stop writing clever code for your own ego, write easy-to-read code that any idiot can read - and don't forget that this includes yourself in a few months.

    • "Clever code is the enemy of maintainable code."

      A specific case of a more general principle:

      Efficiency comes at the expense of resiliency.

      • In my career there has been many times when I've run across code in one language that looks like idioms in another language--C++ that looked like Assembly (yes, 'oops' was the only comment), and Perl that looked like PHP are two examples. The code worked but was awkward and didn't take advantage of language features. In most cases it doesn't make sense to touch working code, but it some cases the code was sometimes copied and used elsewhere and had subtle errors on edge cases. Allowing this to spread is

      • Re:Here's a new saying (Score:5, Interesting)

        by zmooc ( 33175 ) <zmooc@@@zmooc...net> on Friday October 01, 2021 @07:29AM (#61850483) Homepage

        The problem here is setting priorities. A lot of that clever code you're talking about is the direct result of people trying to adhere to other rules such as code duplication being bad, configurability being good, magic values being bad etc. These things are almost without exception solved by making things more generic/abstract/configurable. So instead of Firing an Employee, they're now Deactivating an Agent and instead of creating an employee, they now need to create an AgentFactoryFactory that will yield a PersonFactory that can then be used to instantiate an Employee. But there's no code duplication so it's great!

        It's a matter of priorities. And priority number one should be: write code that idiots can understand because we're all idiots.

        • Priority number one should be: write code that idiots can understand because we're all idiots.

          That about sums it up nicely, but it's hardly a corporate-friendly way of saying it.

      • The real problem here is that so-called clever code is not always more efficient at all, but young coders who need ego boosts will write things in the most convoluted ways that seem clever at the time of writing, that takes minutes to understand by others instead of being near-instantaneously understood.

        Experienced coders try to avoid clever code knowing full well that compilers will end up with optimized code in 99% of the cases, and that readability is more important than cleverness.

    • This is not a new idea. Kernighan's law: “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

    • Re: (Score:2)

      by k6mfw ( 1182893 )

      Stop writing clever code for your own ego, write easy-to-read code that any idiot can read - and don't forget that this includes yourself in a few months.

      I was thinking of many systems (code and hardware) developed by an expert, the kind so brilliant they never document. It's all great but it can only be maintained by that one person. If that person not available, then that system is unmaintainable.

  • I have yet to work in a place, ever, where people are happy with the choices their predecessors made in coding style, methods, idioms, whitespace, tabs, build systems, source code repositories, desk chairs, wall color, etc.

    You are happy to take the paycheck and work with what you've got, or you don't like what you're doing and move on. You don't join an established company to make really excellent code from scratch. And if you join the kind of company where you are making code from scratch, you're probably

    • Re:Seriously? Tabs!!!? (Score:4, Informative)

      by VeryFluffyBunny ( 5037285 ) on Friday October 01, 2021 @07:47AM (#61850503)
      What do you mean 'tabs'? They have no place in well-written code. ALL good programmers use spaces, not tabs! :-P

    • There are degrees to this.

      Yes, some places it's just "ugh, this looks ugly". Some places are real problems.

      Like the place I worked where the product was originally written in VB6 in the '90s. They had outsourced to the lowest bid in the 2000s, and it is now the late 2010s and they aren't allowed to use VB6 anymore...since it was more than a decade out of support.

      They continued to outsource to that lowest bid, where apparently they only still knew VB6. So their "developers" wrote the code in VB6, changed

  • Orâ¦. (Score:3)

    by zkiwi34 ( 974563 ) on Thursday September 30, 2021 @08:47PM (#61849775)
    The current crop of developers are largely rubbish and not good enough to understand solid code.

  • My code? (Score:5, Insightful)

    by Jeremi ( 14640 ) on Thursday September 30, 2021 @09:00PM (#61849791) Homepage

    My code works well, because I made sure that it does, because I know I will have to live with it going forward, and I don't want my life to be hell.

    In my experience, (some) developers quit to escape from their own terrible code, and those of us who are left at the company are then called upon to triage their abandoned spaghetti for the rest of its miserable existence. The quitter, meanwhile, has moved on to another company, presumably to make another plate of pasta for them :)

    • Re: (Score:2)

      by k6mfw ( 1182893 )
      Or maybe you want it to work well (provide documentation?) so don't have to be called at 2 AM when things go wrong. I'm thinking of facilities that run during the night. When things break down, it is always at 2 AM. Not 12 midnight when if after fixing you is same as staying up very late. Or at 4 am when it is like getting up very early. It is always 2 AM the worst time between the two.

  • Incompetent + agile (Score:3)

    by sdinfoserv ( 1793266 ) on Thursday September 30, 2021 @09:02PM (#61849799)
    What other results would you expect from a decade of “teach everyone to code” mantra multiplied by “just frack’n code something!” agile. incomprehensible, undocumented garbage

  • Bad code or not allowed to fix it? (Score:3, Informative)

    by OneOfMany07 ( 4921667 ) on Thursday September 30, 2021 @09:22PM (#61849839)

    Priorities are dictated by management. There is a difference between a system you're afraid to try to fix, and not being allowed to spend time to truly fix it. Both could be labeled "technical debt" by the buzzword focusing survey.

  • It's also a favorite result of new managers who have manpower available to rewrite popular tools they way they think they should be written, and re-invent very basic tools. Software packaging is a popular one. Switching working software to use a distinct language is another. The result is a new mortgage on new technical debt with variable interest rates and balloon payments due in a few years. It's similar to the business of flipping houses: the managers gain some short term successes, sell off their projec

    • the managers gain some short term successes, sell off their project, and take on the next project

      Because that's how they build their reputation. And eventually make it to the executive suite where they don't have to produce any more.

      If you want quality code, go to work for an organization that has responsibility for operation and maintenance as well as development. Its up to your management to spend money on proper code vs hand-ho.ding the customer every time it breaks. And if you are the person who has to fix what you originally wrote ,you are more likely to comment it properly.

  • Not all technical debt is real (Score:3)

    by quantaman ( 517394 ) on Thursday September 30, 2021 @09:32PM (#61849863)

    For sure, a lot of code bases have serious technical debt problems. But I've also seen a lot of devs see 20% of the problem and accuse the current solution of being a pile of technical debt while proposing a worse solution.

    Of course, do everything you can to avoid and eliminate technical debt, but also remember that sometimes when the code is doing something seemingly weird it's because it's handling a problem you're not aware of.

    • Of course, do everything you can to avoid and eliminate technical debt, but also remember that sometimes when the code is doing something seemingly weird it's because it's handling a problem you're not aware of.

      This is true, but on the other hand, I shouldn't be unaware of a problem the code handles. For me, this has been the largest source of frustration - I often don't know what's safe to touch because I try to go in assuming that my co-workers aren't idiots (some days it's easier than others), and that

  • ... on the other side of the fence.

  • I've always hated working on other people's code. I far prefer projects small enough to solo - during which at some point I invariably have to refer back to something I've forgotten writing, can no longer remember the logic behind, and sometimes didn't adequately document.

    Then I hate working on my own code... but I've been through that cycle enough to mostly beat me into compliance on following standards and documenting my work.

  • I do consulting for SMB/MB.

    Most of the initial consultation comments are that there is too much tech debt.

    After several rounds of discussions it means "Code I did not write."

  • sign of the times (Score:3)

    by doom ( 14564 ) <doom@kzsu.stanford.edu> on Thursday September 30, 2021 @11:30PM (#61850005) Homepage Journal

    There's a bunch of kids around who think it's some sort of killer argument to shout "COBOL!" when they want to "move fast and break things".

    When your fave language has survived as long as COBOL you might have a right to sneer at it.

    And when you're done moving fast, try coming back in five years and see how people feel about the code you came up with.

  • There will ALWAYS be some technical debt, even with software lovingly crafted, taking onboard all of the principals of good software development.

    It comes down to culture, that when the developers say "we have to iron out the problems with this legacy software, before starting 'the new shiny'" - and the company understanding this as being, in the long run, a time saving and thus money saving exercise.

    If you are building new software on top of a shaky foundation, the technical debt just grows and grows.
    The co

  • You know the cycle of software design. Or, rather, the cycle of any technical solution. And therein lies the problem.

    Something gets developed. Be it software, a system configuration, a firewall setup, a web presence. It does not matter. Some technical "thing". I will even go as far to assume that it isn't that different for hardware either. It gets designed, implemented, documented. Let's be generous and assume that it didn't get later than late and we actually didn't have to rush it out the door, but it wa

  • Always code as if... (Score:4, Funny)

    by devslash0 ( 4203435 ) on Friday October 01, 2021 @01:43AM (#61850143)
    ...the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

  • The never ending demand for new features leaves no time to deal with tech debt. And the longer this goes on the harder it is to implement new features. I blame management. They ultimately decide the priorities. If you complain enough, they'll schedule a tech debt week, which is slapping a bandaid on a gaping wound.

  • I'm surprised that know one knows this one.

  • The perils of a full rewrite (Score:3)

    by hackertourist ( 2202674 ) on Friday October 01, 2021 @03:30AM (#61850247)

    At a high level, technical debt is the price paid by supporting legacy systems rather than overhauling them or implementing a better, new system.

    Implementing a new system just gives you an opportunity to make the same mistakes all over again [joelonsoftware.com]. A gradual overhaul of the existing system lets you keep the good parts of the old system (including the years spent finding all the corner cases and fixing ever more obscure bugs), while replacing the bad parts one at a time. This has to be done right, no bandaids that will fail again in 3 months.

    • Re: (Score:3)

      by DrXym ( 126579 )
      More often than not though you end up with a partial refactor with some bodge layer that calls the old code. I've seen this first hand so many times.

      I worked for an investment firm that had a C++ trading platform for registered investment advisors. It worked but it was old fashioned and hard to maintain. So they decided to rewrite it with .NET, replacing chunks of C++ until it was all ported. In the interim, the .NET front end would host C++ views and each iteration would replace some of them. Except we d

  • They are all hacks that are extremely overconfident because they live in their own filter bubble of circle jerk, and product only the worst spaghetti code.
    I mean the fact that they are still in aggressive denial of the inner-platform effect that they built their entire world on should tell you all you need to know. And so should the oxymoron "living standard" (aka Google starving ALL the competing browsers.)

    I switched to Haskell and real software. (With a bit of low-level code wherever necessary.)
    Much bette

  • I had to go through two scripts at work. One is causing an ongoing problem, but, with a manual work-around to fix the issue after it runs. The other the work-around was to create a special stand-alone job to run outside the process after the script runs and documented the hell out of it. Both scripts were way too clever and relied on tricks I wouldn't touch with a 10 foot pole and nothing was documented and absolutely no comments in the script to describe what the script did let alone the functions defin
  • ...something that everyone agrees should be dealt with but will eternally be below the funding line for company priorities.

  • I maintain several legacy products that were written in an idiosyncratic style, then embellished by a group who thought they were smarter than everybody else and wrote their code accordingly.

    One notorious product was designed to do one thing, then they decided at the last minute that it needed to do something else. I've discussed a ground-up rewrite with my boss but there's no business case. We pulled this off with another product, replacing a gig of unreadable spaghetti code that tried to be all things t

  • Kernighan or Ritchie (Score:3)

    by aRTeeNLCH ( 6256058 ) on Friday October 01, 2021 @10:58AM (#61851059)
    Either Kernighan or Ritchie supposedly said: it takes more to debug code than to write it. So if you write code as clever as you are, by definition, you won't be able to debug it.

  • and other "rich" languages. Rich languages allow for dozens of different ways a particular function can be written. Put another way, sure you know C++, but do you know that programmer's dialect? Put on a contest to write a simple bubble sort. I guarantee there will be submissions you will swear are in a different language altogether. Clever? Ooooh great, you get a cookie, but as a maintainer, I don't want to have to jump thru your cleverness hoops.

  • I used to work at a company who had a few developers with the worst coding practice in the World.

    So you guys know how we use these all the times: com.company.object.method.etc....
    So this guy has ObjectName.a, .b, .c, .d, .e, .f. And only he knows what each of those things do because there's no comments in the source.

    So when we did a troubleshooting session in an S1 situation and I said:
    ObjectName is "b"ing like this because the other object is busy "f"ing the database and they depend on each other.

Slashdot Top Deals

Almost anything derogatory you could say about today's software design would be accurate. -- K.E. Iverson

Close