Hacker News Reader

Comment by naringas | Hacker News Reader

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.

View on HN

The 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.

The 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.

Unit 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.

Yeah 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.

>If you have the discipline to thoroughly test your code

This isn't the issue. I, and I suspect many others, simply don't have time to thoroughly test code.

It's the age-old issue of "Business doesn't rely on good code. It relies on delivering the product of that code." Up until the ship is both on fire and sinking - nobody cares about sailing a good ship. They'll settle for the shoddy lake boat and ride it out as long as it will last.

The trick is to get off the boat before its final voyage. Or if you're really smart, the penultimate voyage, so nobody thinks you were involved.

I think that's one area where executives and salespeople have acumen that us poor plebs lack in spades. I'm not saying it's a good thing, I just think we get left holding the bag.

I believe even in the short term, tested code gets done faster than non tested code, simply because you tend to waste so little time in trivial mistakes when you test. But it takes time to get to that point, and you don't get to practice testing because it's a new thing and learning it takes time you simply don't have, it looks like it will slow you down.

Walk away. Life is far too short to have to deal with that crap.

About a year ago, I came across an off-topic quip on Reddit that was supposed to be a humorous reference to the phenomenon where beginner programmers first discover they're unable to understand the code they'd written weeks or even days before. It made me realize that I haven't had a WTF moment like that in something like 5+ years, and I'd forgotten the phenomenon even existed.

Some time before, I set out to outline a disciplined approach for writing code that resembles the practices in the article and commit to following it, regardless of whatever strain of laziness I'm afflicted with in the moment telling me to just break the rules and let it slide.

Contributing to Mozilla in a time before GitHub was a big part of my coming-of-age story, and I credit exposure to the Mozilla code review process and a lot of the other good practices as the number one reason for this—as well as the source of my annoyance when I try digging into some project that I'd like to contribute to, only to find that the maintainers are basically flying the thing by the seat of their pants.

This is why programming is one of the hardest professions. You always carry your work home inside your head. Even doctors and lawyers don't have that much of a memory load (for example, in the case of doctors: medical records are mostly sufficient).

It'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. :-)

Happens 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.

When 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.

Usually it's not my code :/

You 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.

Yeah. It's a balance between "build as little 'framework code' as possible;" and "build the framework as you go."

I say 'framework code' but it could be called structural code, or glue code or something, too.

That'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.

Then settle for making the code better than it was when you started working on it.

I'm not that good to pull that off with other people's code. :-)

Nah, you're good enough. If the code is bad, change your goal to "make it better than it was when I got here." That's something you can do.

I was having this dilemma on my walk home. I try to write good idiomatic Django code, and know how to make it efficient in the ways described in Two Scoops (a book about Django best practices). I have inherited an app, parts of which are exactly the opposite of Django best practices (thin models fat controllers being the most obvious one - the application's documentation says that's the philosophy , while Django encourages, and works better the opposite way).

So do I spend more time refactoring and bringing this application to a decent state, or do I just keep on hacking more crap on to it? No one except for me seems to give a shit as long as it seems to be working.

A rewrite is a different animal than writing new code. The problem with rewrites is the marginal utility is a diminishing return. Unless the code is really bad, or will require very frequent revisits.

I think the best practice is to just refactor the bits that you need to touch. At a minimum avoid leaving them worse, and in an ideal world leave each piece you touch better for your having looked at it.

Thats my plan, assuming i get the chance to.

> 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.

While we do have a good amount of power, they still have the ultimate power in that they write the checks.

If 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.

"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.

In 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.

Isn'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.

The 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.

Have 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.

Part 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.

A 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.

Good point. It's similar to the fallacy of measuring coder productivity by "lines of code written."

Reminds me of the anecdote about Bill Atkinson: His manager required a "productivity" form that asked "how many lines of code did you write this week?" Having just refactored QuickDraw, with vast gains in speed and simplicity, answered "-2000."

http://www.folklore.org/StoryView.py?story=Negative_2000_Lin...

That's quite poetic. But I assume you mean "amoral"?

Being a pessimist I consider it immoral.

Think we all got different experiences there. My main problems have been with people who insist on just churning out features in the most straightforward way without doing any kind of upfront thinking. You end up with reams of copy past coding, code duplication and so much code that it is very hard to keep track of what is going on.

Like e.g. if you are parsing a file, and it is complicated you can save a lot of time and give a lot more clarity if e.g. you use some form of state machine or look into a little bit of theory of textual transformations and representations.

I mean I have seen people managing a forrest of state variables and who have never heard about regular expressions or any kind of methodology on how to deal with text formats.

You end up with a crap load of messy unmaintainable code.

But of course it is also a problem when people turn every operation into a ceremony involving factories, command objects and any design pattern you can think of. In the Java world that seems like a common problem. I think my own philosophy aligns more with how Go libraries are written. They are pretty simple and straight forward. They use smart approaches were needed but don't insist on adding indirections, encapsulation etc everywhere.

I am jealous of you. It is fairly straightforward to clean up quickly written, first version code. (In fact, this is probably the best way to develop, if you don't shirk the responsibility to refactor it yourself.) But if you have an over-architected, obfuscated mess, where do you even start? You should appreciate your fellow developers more. Maybe buy them a fruit basket or something?

The 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.

That'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.

I'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.

There 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.

Where I work, all the devs are lazy and incompetent... So I have to rush and overwork to get something that works.

Get out of there as soon as you can.

...did you just call yourself lazy and incompetent?

Most of the bad code was made by very productive developers.

Because productive developers write more code or because productive developers write worse code?

Perhaps 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.

It'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.

This 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.

What 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.

That's simply because the non-productive programmers don't write very much code, good or bad.

Less code is better code.

Not in the context of "I don't build anything."

One 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.

Wouldn't they just be doing everything code-related 10x faster?

It seems to make sense:

N * (debt factor) = debt

10N * (debt factor) = 10 * debt

I think the reality is a mixture of both, the lazy, incompetent programmers are under pressure to ship too!

I 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.

So 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.

It is probably about half. Some programmers are new, or don't care, or a mix.

Not all programmers are "good" programmers.

Reply on news.ycombinator.com