Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software engineers hate code

dancowell.com

Post reply on HN
Print view View original

101–110 of 235 posts

Re: Software engineers hate code

#101

Post by hinkley »

jvans wrote: post #81
andix wrote: post #77

Earlier quoted context omitted.

Im a big advocate of rewriting code from scratch. Because on a rewrite you have a much better starting point. You have a (mostly) working solution, you understand the problem much better than on the first attempt, you have some tests and some data. Most of the time you don't rewrite it 100% from scratch, often you can copy a lot of code from the old solution. To utilize all those benefits you can't rewrite everything…

The incrementally part is extremely important and often overlooked. I have seen project after project attempt some major big bang rewrite that always takes way longer than expected, delivers less value than promised, and causes problems in areas that used to work fine. We often understand some big picture things better as time goes on but there's a thousand small decisions baked into the existing code that are very e…

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 much more valuable to all parties for you to attempt it.

The only reason for a rewrite is when you have a language or framework that’s dead, and there are often other dynamics that put you in that spot in the first place.

There are a bunch of common mistakes people make with trees that take years off their life expectancy. The worst guarantee the tree will be dead in twenty years (and potentially dangerous before that). Software has similar phenomenon, on a much shorter time scale.

Re: Software engineers hate code

#102

Post by YZF »

JohnFen wrote: 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…

Most of my early career was "greenfield". I really loved doing that. Sometimes that meant me doing everything. Guess where the buck stops? There's no way to disconnect the final result from the work. Keep in mind though that green field pretty quickly turns into maintenance. You ship something, guess what, there's bugs to fix. You want to add a feature, you have an existing code base. The nice thing is that there's no one else to blame. Is it really hard to add a feature? You (or your team) messed up. Does the quality suck? You (or your team) messed up.

Even in well established code bases there can always be "green" new pieces. These are choices to make: should we refactor the code, should we fix the old code, should we rewrite pieces of it. There is no one answer that always works. The problem is when you look at something and your answer is always a rewrite just because you didn't write the original code. I've seen people/team rewrite perfectly good code for no business reason, just because they want to.

In terms of code written by others, sometimes that's a thing of beauty, a piece of art. Sometimes it's just garbage. I'm sure we've all seen some code where we go wow, this is incredible. And then we've all seen code where we go wtf. I don't really see the need to dig too deep there, what's great is great and what's garbage is garbage and then a lot is somewhere in the middle. I sometimes look at code I've written in the past and I think it's really great; and sometimes I go wtf. Usually the latter is where I was not familiar enough with the problem space or the code base I was working in. Questions to ask are: does it work? what's the cost of maintenance? Ugly code that works well, doesn't need to be touched, can be fine.

Re: Software engineers hate code

#104

Post by HeyLaughingBoy »

BossingAround wrote: post #41
bayindirh wrote: post #25

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…

The funny thing is when you get used to someone's coding style, you can tell if they were stressed or under time pressure or not.

Re: Software engineers hate code

#105

Post by zer8k »

ranting-moth wrote: post #83

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…

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 unenforced wall. The contractor was never aware of what was in the wall and assumed he could find a stud. What he thought was a stud was actually the stud finder pinging on a water pipe. The construction workers didn't have time to run any tests with stud finders so they just wired everything up at the behest of management and hit the wall a few times with a rubber mallet to see if it held up. The project was behind by a week already due to the plans getting to the job site late.

He pounds in the nails, hits the water pipe, collapses the wall and floods the house. The on staff construction crew lose their jobs, the VP gets a promotion for showing they did something about this egregious error, and they are replaced with contractors.

Re: Software engineers hate code

#106

Post by snickell »

jacurtis wrote: post #87
austin-cheney wrote: post #73

Earlier quoted context omitted.

Sure. Of course there are actually software developers out there in the world that read and write code. After all, that's where all this software in the world actually comes from. But for the other 85+% of people in the profession its basically a game of AdLibs. Fill in the blank. That's why there is such heavy reliance on things like frameworks, dependencies, and Invented Here Syndrome (people who don't trust their…

> But for the other 85+% of people in the profession its basically a game of AdLibs This is so true. I work at a fairly small organization (~35 devs). Large enough to see roles form but small enough that I can tangibly see everyone's contributions. I work SRE, so I see lots of code from all the teams and ultimately talk to almost all the devs. In our impressive enterprise-level codebase (our SaaS product has average…

Sounds like SRE has afforded you a unique "who's writing what code small-org-wide" semi-impartial perspective. Thanks for sharing!

I'm curious if the ~three devs that "wrote 80% of the codebase" mutually recognize one another? i.e. do you think they think of themselves as in a "writes a lot of code" category along with the other ~two devs? Do they think of themselves as "writes a lot of code"? Does management recognize this and/or plan around it?

I've sometimes been one of the "people writing a lot of code" in a small org. When I'm in that mode/context, I find myself daily appreciating the types of contributions made by the larger body of folks less deep in the woods. They do a different and complementary type of work, and I've found both types bring something valuable (and different) to the codebase.

Re: Software engineers hate code

#107

Post by hinkley »

usrbinbash wrote: post #70
goto11 wrote: post #40

Earlier quoted context omitted.

> 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 Or if the old system simply doesn't work with modern environments. Or if it depends on long abandoned frameworks. Or if the business grows but the old implementation scales badly or not at all. Or if it depends on components that incur licensing fees that become prohibitively expensive when it's scaled up. Or if there ar…

You say that as if these events are unfortunate accidents instead of lack of technical leadership.

I’ve met quite a few “unlucky” people in my life and what nearly all of them had in common was the inability to connect their actions and inactions to consequences. They were blindsided by predictable outcomes over, and over, and over again. Eventually the people who could actually help you get tired of your drama and move on, and then you’re left in an echo chamber where your narrative makes sense.

I’ve spent a lot of time on this job thinking about the thoughts and plans of the people who have left. If our vertical were more compelling I believe we could make a better product with the people who have left than with the people who stayed. Even considering the lack of depth in domain knowledge. There’s a lot of things that don’t change because they were the right thing to do ten years ago. That’s an explanation for how we arrived here, not a reason to stay.

Re: Software engineers hate code

#108

Post by antigonemerlin »

parineum wrote: post #95
JohnFen wrote: 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 culture thing in SV/VC//startup world and I think that group is very public, outspoken and sure that they speak for everyone. Most if us aren't that but we just continue about our business developing new features and squashing bugs. I like greenfield projects but the choices and freedom they present come with a lot of non-coding and missing infrastructure. A nice brownfield project lets me check in cod…

I mean, there are badly designed brownfield projects with tight coupling, bad documentation, and, where you have to spend half an hour to figure out why a simple change broke everything.

Funnily enough, personally, I can handle badly designed projects as long as I was part of the team designing it. At least then I understand it enough that changing things isn't too much of a pain, and I can pretend my refactors will eventually make the codebase look good (or if that fails, I can write enough documentation to at least mitigate the problem). It's a pain in the ass for new maintainers though.

But goddamn, working in a good established project where other people have done the hard work of figuring out non-coding project management stuff is a fricken breeze. No arguments there.

Re: Software engineers hate code

#109

Post by easeout »

In this thread: Software engineers also love to point out when their counterexample has been glossed over by an intentionally simplistic thesis.

(In this comment: Software engineers also love to sass one another)

Re: Software engineers hate code

#110

Post by jvans »

hinkley wrote: post #101
jvans wrote: post #81

Earlier quoted context omitted.

The incrementally part is extremely important and often overlooked. I have seen project after project attempt some major big bang rewrite that always takes way longer than expected, delivers less value than promised, and causes problems in areas that used to work fine. We often understand some big picture things better as time goes on but there's a thousand small decisions baked into the existing code that are very e…

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

Post reply on HN