Live data from Hacker News

Software engineers hate code

dancowell.com

171–180 of 235 posts

Re: Software engineers hate code

#171
post #105

Earlier quoted context omitted.

A follow up analogy is more typical in my experience. The foreman says that we should reinforce the walls. The PMP certified 6 sigma ninja Project Manager insists that the reinforced walls aren't necessary because no one is going to put anything on the wall. We will revisit the wall later when we the city tells us to enforce new wall codes. No more than 6 months later a contractor tried to add a shelf to the unenforc…

this is also not a good analogy because building codes will often just require 20" O.C or 16" O.C studs and those are in the plans- drafted by a person that designed the home (self, architect, drafter). Reinforcements for shelves or cabinets are also part of the code for kitchen walls. Those are not to be expected in every location in the house. The framers are locked into the house plans as far as stud distances and…

I'd say it's a pretty good analogy, the details aren't perfect, but it gets the point across.

https://www.youtube.com/watch?v=FfEX6GUxfZM

Here's an example of an arguably good builder who had one team install a in-wall tank toilet, then another team drills right through the tank causing a leak. The repair work essentially meant ripping out everything and doing it over, even though there should have been mitigations in place to prevent it and having the plans/documentation available to everyone.

While construction has more standardization, planning, and inspections, it still relies on implementation and is going to have failures.

Re: Software engineers hate code

#172

Earlier quoted context omitted.

Filching from Nietzsche, scriptwriters are lazy bums.

Pieces of art are repurposed all the time, I am sure Nietzsche took it from somebody living even further back in the past.

“What happens once will never happen again. What happens twice will surely happen a third time.”

Re: Software engineers hate code

#173

Using a house analogy, I don't hate other people's houses. I hate it when other people blow a hole in the side of my house to put in a new window. They blasted a hole through two walls because it was the quickest way. Then just taped some plastic over the second hole. The project manager said it's still summer and we don't really need that wall at the moment. I know who will have to fix the wall when the winter comes…

In the same tone:

Someone put fake shutters on the sides of the windows - the wrong size at that. This was accepted as a good solution because no one tried to close them. Would be impossible anyway, because there are no hinges.

This happens more often than it might seem.

Re: Software engineers hate code

#174

Earlier quoted context omitted.

Filching from Nietzsche, scriptwriters are lazy bums.

Pieces of art are repurposed all the time, I am sure Nietzsche took it from somebody living even further back in the past.

Ecclesiastes 1:9

“The thing that hath been, it is that which shall be; and that which is done is that which shall be done: and there is no new thing under the sun.”

Re: Software engineers hate code

#175

Earlier quoted context omitted.

Filching from Nietzsche, scriptwriters are lazy bums.

Pieces of art are repurposed all the time, I am sure Nietzsche took it from somebody living even further back in the past.

Plus ca change, plus c’est la meme chose

Re: Software engineers hate code

#176
post #110

Earlier quoted context omitted.

The main value a big bang rewrite has is that for six to eight months the dev team gets a break from being asked a lot of uncomfortable questions. By the time the questions get properly uncomfortable again, you’ve worked there long enough for it to be reasonable for you to leave. Incremental improvements require more skill. The sorts of skills that make you a better developer. So even though it’s more difficult, it’s…

I am sure there are good reasons for it, the postgres proposal for switching concurrency models[1] comes to mind. I actually just posted this question to see what people come up with: https://news.ycombinator.com/item?id=36646299 My knee jerk reaction to rewrites is so negative I actually would like some counter evidence on when it worked out. [1] https://www.postgresql.org/message-id/4658520e-5cd0-6242-e54...

We're in the midst of a couple rewrites that are going/have gone well. Perl to golang and angular1 to react.

The common factor is doing it gradually, basically page by page. There is no big switchover, new code goes live as it is ready. We have some very competent people with long tenures which surely helps.

Re: Software engineers hate code

#178
post #133

Earlier quoted context omitted.

Not just infra. It’s the tests, it’s the crud, its getting clients and config setup, it’s banal decisions around copying existing patterns or trying to refine them for next gen copy pasting. It’s fun early in career, but gets boring fast IMO. These are good things to have junior and mid eng cut their teeth on.

The sweet spot is for someone with deep experience to lay down the skeletal structure of the tests, rpc, infra, lifecycle, etc… then hand it off to a broader team who could learn the intention behind the decisions.

> who could learn the intention behind the decisions

If people did learn those intentions we wouldn't have the problems we have.

I inherited a project like this once as the third generation to take it over. The (evidently, I never met them) well trained and experienced first developers laid down a foundation using a textbook OO style with a few little tricks needed to make that work in a language where OOP support was bolted on. The code was not perfect, but it was professional work and I would put it around the 80th percentile in terms of code quality.

These tricks caused the virtues of that foundation to be overlooked entirely, and so the project was essentially reimplemented in spaghetti style over time with various ad hoc stovepipes to pass data back and forth between the two sides when the original had functionality that wasn't understood well enough to be reimplemented.

The importance of training, communication, and retention can not be overstated.

Re: Software engineers hate code

#179
post #40

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

> when the predictions say, that, forseeably, the company will lose money down the line because we waited to long for a rebuild, it may be time to pitch that to whoever allocates resources. Only developers who love greenfield or need a new framework on the CV would suggest a company could lose money by not rebuilding. If the developers are not competent enough to write maintainable code or maintain existing code, the…

If the developers are not competent enough to write maintainable code or maintain existing code, then you will have exactly the same difficulties after the rebuild.

Why assume the same developers would be doing the rewrite as the original? Maybe the reason for the rewrite is because the original is hopeless and most of the people who worked on it are no longer around.

Also everything usrbinbash said in a sibling comment - but if something like a changing environment forces a big rewrite of an otherwise successful code base then having the original developers still around can dramatically increase the chances of success IME.

Re: Software engineers hate code

#180
post #27
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…

Indeed! This phenomenon has been a great source of freelancing customers for me. Startups naturally thrive on an early team that loves building new things, but the flip side is that they rarely seem to go back to fix existing stuff. That leaves a gap for people like me, who prefer to take something that works poorly and make it bulletproof. For some reason this quite often seems to involve db access patterns but ther…

Out of curiosity, how do you go about finding clients for this kind of work?
Post reply on HN