Live data from Hacker News

Software engineers hate code

dancowell.com

41–50 of 235 posts

Re: Software engineers hate code

#41
post #8

> This is the best-kept secret of the software engineering profession: engineers hate code. Especially code written by other people. It's why they love working on greenfield projects so much. No code, no maintenance, no headaches! Except that I've met lots of engineers who were the opposite. They hate greenfield projects and prefer maintaining existing code. I noticed this broad division of personality early in my ca…

I think it's a spectrum. For example I like writing new code and designing new things, but I don't hate or dislike my or other people's old code. That code also has been written by a human, and it's disrespectful to approach somebody else's work with this prejudice. It might not be good code, by our standards, but who knows how it was written. Was the author under stress, under time obligations, or happy, or somethin…

> That code also has been written by a human, and it's disrespectful to approach somebody else's work with this prejudice.

Not only has it been written by a human, but one should also remember that they're missing the context in which the code was written. Was the author stressed about their latest children being born? Fearful of possible layoffs? Under time pressure? Tired?

I've definitely written code myself that came to bite me later, and I marveled at how badly written that was.

We're all human, which, among others, means that we're all inconsistent to a large degree.

Re: Software engineers hate code

#42

> Don't write new code when you can use, improve or fix what already exists. If you must write new code, write only what you need to get the job done. While the article resonates with me alot, I would like to, in the best spirit of the article, propose an addendum to that line: When modifying existing code, do a very careful cost-benefit analysis; On the one side is the cost of a rebuild. On the other side is the pro…

>On the other side is the projected cost of keeping this thing and maintaining it, not just for this change, but for changes in the forseeable future.

That's going to be very difficult, especially when you then also have to consider that the changes you could do could REDUCE the cost of maintaining it. If you're only ever appending code, then the cost to maintain can quickly skyrocket. If you're also diligent about removing the features that you don't need, there should be no significant difference at the limit.

Basically, assuming you are properly maintaining the existing system, you should be continually refactoring it to be what you would build if you started from scratch. In that view, the cost of maintaining it will be identical, and the only cost that matters is the cost of bringing the existing system into alignment with what you would build now.

Re: Software engineers hate code

#43
post #8

> This is the best-kept secret of the software engineering profession: engineers hate code. Especially code written by other people. It's why they love working on greenfield projects so much. No code, no maintenance, no headaches! Except that I've met lots of engineers who were the opposite. They hate greenfield projects and prefer maintaining existing code. I noticed this broad division of personality early in my ca…

[flagged]

Oh please. By your definition no greenfield project has ever existed in thousands of years.

Re: Software engineers hate code

#46
post #34
post #8

> This is the best-kept secret of the software engineering profession: engineers hate code. Especially code written by other people. It's why they love working on greenfield projects so much. No code, no maintenance, no headaches! Except that I've met lots of engineers who were the opposite. They hate greenfield projects and prefer maintaining existing code. I noticed this broad division of personality early in my ca…

I am one of those who prefer working on existing code. I like making things better, understanding how a code works is thrill, adding new features on existing premises. I am also an amateur fiction writer, and I notice the same thing in it. I like planning, but the first draft writing is a chore to me. An effort to vomit all my ideas as words. Then, I love rewriting. Revisiting what I wrote and improving it, fixing it…

hah humans are interesting! I'm the opposite. I love starting a codebase, I also make music and it's way easier for me to make 100 cool unique sketches live and improvised but not finish anything. it really takes all kinds

Re: Software engineers hate code

#47

I've been a software developer for almost 10 years and during that time I've questioned many times why I keep on going. A while ago I realized that the biggest thing that I like about software development is the simplicity within it's complexity. What I mean by this is; software either works or it doesn't. In many other professions this is not the case. So while there are many things that could be done better and mor…

My high school computer science teacher (almost 30 years ago that is) used to say: "A program that 'almost works' is like a plane that 'almost flies'".

Re: Software engineers hate code

#48
The people who truly hate code work in upper management. Coders are expensive, hard to hire, and tend to say no a lot.

You can make so much money selling hoax ”zero code” solutions, as management is very happy to drop money into projects that promise to replace coders with Magic Product(tm)

Re: Software engineers hate code

#49

Earlier quoted context omitted.

I think it's a spectrum. For example I like writing new code and designing new things, but I don't hate or dislike my or other people's old code. That code also has been written by a human, and it's disrespectful to approach somebody else's work with this prejudice. It might not be good code, by our standards, but who knows how it was written. Was the author under stress, under time obligations, or happy, or somethin…

> That code also has been written by a human, and it's disrespectful to approach somebody else's work with this prejudice. Not only has it been written by a human, but one should also remember that they're missing the context in which the code was written. Was the author stressed about their latest children being born? Fearful of possible layoffs? Under time pressure? Tired? I've definitely written code myself that c…

Also important is Chesterton's fence and the history lesson when touring existing code. What were the business requirements the first time around that were thrown out the window for version two, but there was no time for refactoring so version three has this known wart that version four tried to refactor but that wasn't complete until version five which had this new feature that needs another refactor.
Post reply on HN