15 ms·
I used to think that a lot of bad code out there was made by lazy, incompetent programmers... But then, after a certain job, I realized that this is probably n
by naringas 11y ago
I used to think that a lot of bad code out there was made by lazy, incompetent programmers...
But then, after a certain job, I realized that this is probably not the case.
Now I belive that most bad code out thare is made by overworked and tired programmers in a rush to deliver something that works.
- phpnode 11y agoI think the reality is a mixture of both, the lazy, incompetent programmers are under pressure to ship too!
- reacweb 11y agoMost of the bad code was made by very productive developers.
- gahahaha 11y agoBecause productive developers write more code or because productive developers write worse code?
- mmebane 11y agoPerhaps being a "productive" programmer requires understanding the requirements well enough to quickly write working code, then moving on to the next problem. Personally, I usually find that it takes two refactorings/rewrites to go from initial working code to something that I honestly believe is understandable/maintainable, and I don't always have time to do that.
- mreiland 11y agoIt's more subtle than that. People act as if developers are all a clean slate, which isn't true. developers have personalities with differing values. That super productive developer may just not value the flexibility of the code due to his personality coupled with that developers personal experience. That developer will absolutely shine in some environments and be abysmal in others since there are absolutely environments where flexibility isn't an overriding concern. As you get more experience you learn to be more explicit about your decisions, but you'll still have your preferences and your defaults and it takes a certain threshold for you to move away from said preferences and defaults.
- maze-le 11y agoThis leads to the question what 'productive' really means. If a productive programmer writes a lot of code that isn't maintainable at all, can you really call that person productive? Maybe... but the poor sob tasked with maintaining the code later, will certainly not be called productive. Maybe productivity should not be regarded isolated from other metrics and/or certain style-considerations.
- bcheung 11y agoWhat is the true measure of productivity? If you include things like maintenance and other developers' time are they really being productive? There's individual productivity and team productivity. Also a quick one time job is different than something that needs to be maintained. Everything is relative to the goals.
- PaulHoule 11y agoThat's simply because the non-productive programmers don't write very much code, good or bad.
- arcticbull 11y agoOne of my co-workers likes to say that 10X engineers produce tech debt 10X faster than the average engineer :) Definitely been true in my experience.
- mod 11y agoWouldn't they just be doing everything code-related 10x faster? It seems to make sense: N * (debt factor) = debt 10N * (debt factor) = 10 * debt
- Can_Not 11y agoWhere I work, all the devs are lazy and incompetent... So I have to rush and overwork to get something that works.
- mathattack 11y agoIt's both. Some of my worst code was to look at someone else's code after a manager shouted "FIX THIS NOW!!!" with some kind of quick and dirty hack, and then never going back to get it done right. I'm pretty sure this happens independent of whether or not I am any good. :-)
- mtbcoder 11y agoHappens to the best of us! Also, it's very difficult to keep entropy at bay in something that requires so much abstract thought and effort as programming, especially with how broad software's reach has gotten.
- ktRolster 11y agoWhen you're really good, you learn to FIX IT NOW while also not making a hack. Your code becomes flexible enough to handle that kind of change.
- st3v3r 11y agoThat's assuming it's your code. Most of the time it's not your code. While one would hope that the rest of the team writes flexible code as well, that's not always the case.
- ktRolster 11y agoThen settle for making the code better than it was when you started working on it.
- szatkus 11y agoUsually it's not my code :/
- chimprich 11y agoYou can't anticipate every emergency change required to the codebase. Sure, you can make some intelligent predictions about certain points in the code and encapsulate possible changes but it's impossible in the general case. Trying to code to future possible requirements is often far more harmful because of over-abstraction than occasionally having to perform a quick hack and then fix it later.
- hbt 11y agoThe main thing most programmers overestimate is their own working memory i.e the number of things you are retaining when writing a piece of code. Problem is: working memory is short term. After a few days, you revisit that code and you realize how much it costs to load it all in your head again. Basically, we need code reviews of code we wrote last week as opposed to code we wrote yesterday.
- hinkley 11y agoThe code I'm working on now, and the code I worked on before that, was designed to be memorized. I suspect the only reason the team is productive is that they are working from long term memory most of the time. The insidious things about this are twofold. First, it makes all new team members look like idiots. These other guys are getting work done, what's your problem? Our problem is we can't figure out wtf is going on without breaking things to do it. Second, everyone doing work to fix the problem is a threat, because they are moving code that is memorized. I honestly don't know how to fix this problem, I used to just walk away but I feel like I should be able to do better than that. Boiling that frog is a long term commitment.
- Fargren 11y agoUnit tests tell you what that small thing you did ages ago was meant to do, and what it does in different circumstances. If you have the discipline to thoroughly test your code(and the knowhow to not write brittle tests), it can really pay off.
- hinkley 11y agoYeah people who rely on rote memorization tend not to be too keen on unit tests. Thankfully the Old Ways are dying, but there are still pretty huge pockets of holdouts. Sometimes it can be hard to tell from the interview process where your prospective employer is at on the continuum. Both [of the last two, big enterprise] places asked me about testing, and I wrongly assumed that meant they knew and cared. At the former they neither knew nor cared (in fact their dependency graph was so very broken that I couldn't write tests even though I wanted to, and I wasn't going to be able to unwind 250k lines of Big Ball of Mud in the time I had. Hated it). At the latter they care a bit, but are only beginning to understand what kind of trouble they've gotten themselves into.
- protonfish 11y agoIn my experience, most bad code is written by dogmatic cargo cult programmers that are more interested in writing code that adheres to their pet development philosophy or framework instead of programming to solve a problem in the simplest way possible.
- JoeAltmaier 11y agoIsn't that just another philosophy? Lets be more charitable. Engineers are given limited time to do any job (time == money). So they do what they can. Mostly on a budget.
- protonfish 11y agoThe bad code I see isn't because someone was in a rush - it's because somebody spent a lot of time and effort to make it a mess. I swear 80% of developers don't know the difference between clear, elegant, readable, and modular code and a giant pile of mess. This is why I've stopped encouraging team members to refactor; the end result is most often worse.
- Fargren 11y agoHave you tried doing code reviews? If a refactoring sucks you should be able to catch before it goes into master(or however your main branch is called), and educate the programmer. Teaching our coworkers to write better code is part of our jobs.
- st3v3r 11y agoPart of that is that any 3 developers will have 4 different opinions on what is clear, elegant, and modular, and what is a giant pile of mess.
- koder2016 11y agoA fashionable framework on your CV will get you an interview, while claiming that the code was simple won't. It's as immoral as objective reality is.
- njharman 11y agoThe difference between two programmers one producing great to read/maintain code is not lazinesss, incompentence or one being overworked. It is discipline. The disciplined developer will produce better code.
- ball_of_lint 11y agoThat's like saying the more fit person will run faster, regardless of how tired they are. Discipline will help you write better code, but it is far from the only factor.
- wpietri 11y ago> Now I belive that most bad code out thare is made by overworked and tired programmers in a rush to deliver something that works. I would agree. But I think putting up with those conditions is a different sort of laziness, and agreeing to produce garbage is a different sort of incompetence. Looking back on the times I've done that myself, I deeply regret it. Programmers have a lot more power to shape process than they realize. There is a giant deficit of good programmers right now. Few managers understand what we're doing anyhow, so if we say, "Nothing gets marked as done until the code is up to professional standards, which includes sufficient unit tests and a well factored design", we can frequently make it stick. Sure, they will still push you to go faster, but they will always push you to go faster. I think there are better ways to respond to that. E.g., by redirecting their "go faster" energy to breaking units of work down into smaller lumps so they can do better scope control. Or by having them get feedback on new systems early and often, so their decisions about what to make next are informed decisions, not just executive fantasies expressed in bloated 300-page Word documents.
- st3v3r 11y agoWhile we do have a good amount of power, they still have the ultimate power in that they write the checks.
- wpietri 11y agoIf that's how you measure power, the ultimate power is in the hands of the customers, as they're the ones footing the bill. And a given check only has power over you to the extent that you let it. Most programmers will have little trouble finding a job if they have good professional networks or are otherwise willing to work at having options. If you are confident that a just-as-good job is easily available, you can be much braver in the one you have.
- jimbokun 11y ago"so if we say, "Nothing gets marked as done until the code is up to professional standards, which includes sufficient unit tests and a well factored design", we can frequently make it stick." Or don't even say it, just do it and don't tell the manager, while incorporating into your estimates. Overall time to deliver working software with acceptable performance and bug count will still be faster, anyway.
- ap22213 11y agoI've seen code readability decrease linearly since the 90s. This makes sense since there were around 3-4 developers to do the work of every 1 today. But, I think this is just a symptom of a lack of capacity and resource management. Contrary to popular belief, it was actually possible to do iterative and incremental 'agile' development prior to 1999. Most engineers back then used the term 'waterfall' to describe a well-known anti-pattern.
- odonnellryan 11y agoIt is probably about half. Some programmers are new, or don't care, or a mix. Not all programmers are "good" programmers.
- BurningFrog 11y agoThere are many reasons for bad code. Much of it is decent code that was then altered several times, without anyone taking a fresh look to clean it up. But I'd guess the biggest factor is that most programmers can't tell good code from from bad very well, when writing it.
- collyw 11y agoI constantly tried to get the same problems (a "temporary solution") fixed in my previous job, but it was always put off until next month, as something more urgent came up. I wasted around 1/4 of my time cleaning data as a result, and that led to really low productivity because of all the interruptions it caused - I hardly ever got into the flow. Three years on, and I realised it was time to leave. It would have only taken me 3 -4 weeks to replace the crap code with something better, but instead my developer productivity was probably around 1/4 of what it could be for 3 years because of constant firefighting and dealing with unvalidated data going into the database and the firefighting / cleanup that it required.
- JoeAltmaier 11y agoSo common! My friends gave notice. In his remaining time he rewrote the data-onboarding-and-sanitizing code for performance (something that there was never time to do) and reduced it from 2 days to 2 hours. Which probably had a larger impact than anything else he'd done in his entire time there.