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

221–230 of 235 posts

Re: Software engineers hate code

#221

Post by Silhouette »

goto11 wrote: post #219
Silhouette wrote: post #216

Earlier quoted context omitted.

I don't think that follows at all. I've seen my share of development groups where someone had previously made a bad hire or brought in the wrong consultants and that had left them with a body of code that simply wasn't very good. That doesn't necessarily reflect the overall culture at the organisation and it doesn't say anything about whether the people currently available would make the same mistakes. The assumption…

> They spent far more time and money on the updates than it would have taken to do a clean rewrite Of course this claim assumes you can reliably estimate the time and cost of the rewrite and the claimed improved productivity after the rewrite. It is still unclear to me what kind of improvements cannot be applied to an existing code base through refactoring and gradual improvements, but requires all the code to be wri…

Of course this claim assumes you can reliably estimate the time and cost of the rewrite and the claimed improved productivity after the rewrite.

I almost preempted that counter-argument in my previous comment. :)

Some software development is 90% research and 10% development and it's true that you never really know how long it's going to take and how well it will work until it's almost done anyway. But the tar pits I'm talking about were not that kind of software development. Most of the cases I'm thinking of were the stereotype over-engineered "enterprise" code that had become bloated and excessively interconnected. Others were "clever" code where someone had tried some fancy design patterns or data structures or algorithms, typically with a severe YAGNI complex as well. Either way making simple changes required many times the effort it should. And yet a drop-in replacement for the whole system would have been a low risk project, with very predictable work required that could be done by any mid-senior developer on the relevant team, taking a fraction of the time.

Re: Software engineers hate code

#222

Post by evandale »

bayindirh wrote: post #214
evandale wrote: post #72

Earlier quoted context omitted.

> That code also has been written by a human, and it's disrespectful to approach somebody else's work with this prejudice. Small piece of advice: it is much better to learn how to take criticism of your code as exactly that - it's criticism of your code. People will always be unkind when reviewing code. Even if it's the best code ever written someone will have a different opinion and express it in a seemingly unkind…

You're right, one needs to be able to take criticism, not about the code, but in everything, however being able to give criticism correctly is equally important. This is not about style (kind or to the point, or in any style), but again about keeping in mind that you're talking with a human being. You can say "This doesn't work (because of this), so do it this way", in thousand different intonations, and you can add…

Your handling of the PHD situation sounds perfect and it seems like we're in agreement.

I want to reiterate you will never be in a situation where everyone is respectful even if it's a professional setting. You also can't control what other people do so there's no point expecting people to give criticism respectfully or trying to teach people how to do so - you can't correct someone's behavior if they don't want to change it.

Every time I catch myself wanting to say "people should act like xyz" I stop myself and think "I will react a different way when someone acts like xyz" instead if I'm not happy with how the situation went. Especially if I've already expressed my feelings and someone has ignored them and still acts in a way I don't like.

Re: Software engineers hate code

#223

Post by berniedurfee »

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 like greenfield projects, but I love tearing down and refactoring old code to make it better.

I also spend a lot of time repairing and maintaining old cars, houses and fixing up stuff to be better and stronger than it was when I found it.

It’s very difficult for me to leave well enough alone. If it ain’t broke, it could certainly be better!

Re: Software engineers hate code

#224

Post by whstl »

austin-cheney wrote: post #168
whstl wrote: post #112

Earlier quoted context omitted.

When I was a developer I hated it. I was almost always the #1 in LOC, Jira Tickets, Scrum Points, you name it. I was naturally good at it, but the environment was always very competitive and the other top performers would brush it off as just me being lucky with "LOC Heavy" tasks. And it would piss me off that I would get paid the same as a guy who wrote 200 LOC a month and wasn't doing much more than those lines. Be…

As a developer I don't mind that other people don't do work. If they want to stagnate in their career that is their problem, but it certainly isn't a problem for me... until they make it my problem. This typically happens when entitlement sets in and the baseline lowers so dramatically that not doing work becomes a mandatory expectation only shattered by the crying when conveniences are peeled away. Worse than that a…

Agreed.

I think the biggest risk with the people who work their asses off more than they should (doesn't matter if it's good or bad code) is that they end up with a non-sustainable output. Productivity is artificially high, and often achieved by overtime, working weekends, and overworking themselves. Eventually that leads to burnout, lower quality, and it becomes hard to replace. When it's people working too much and delivering bad code it's probably not as bad, though.

At my current company we have someone in this situation, with work affecting their day-to-day stress levels very much, to the point of damaging their personal relationships. Their manager is young and inexperienced, and doesn't see the issue, but he was flagged by HR and I hope something gets done.

Re: Software engineers hate code

#226

Post by hinkley »

Silhouette wrote: post #217
goto11 wrote: post #213

Earlier quoted context omitted.

Browsers discontinuing Flash support is indeed a good reason for porting an app to a different platform. But this is also a very different scenario than the grandparent example, where the cost of maintenance due to bad code quality is supposed to justify a ground-up rewrite. In the Flash example there is a clear business case for porting, even though it is understood the porting will expensive. The fallacy is believi…

There is no reason to think a ground-up rewrite of existing working code will lead to better and more maintainable code. As with almost every argument in this area that depends very much on context. A substantial rewrite might be an opportunity to use better tools and improved techniques that have been developed since the original was written. In some cases that could represent a huge improvement in things we actuall…

A substantial rewrite is developers asking for a do-over, which is infantile behavior (or as GP more kindly put it, delusion).

This is a hill I will die upon: The people who don't deserve rewrites ask for them, early and often. The people who deserve a rewrite rarely mention them, and in fact they likely already have done it, bit by bit as a sibling comment mentioned by way of example. I will say that I've often surprised myself with features I never would have hoped for on the refactoring road. Things that would have been entire Epics become six weeks of work, sometimes less.

Refactoring is the Ship of Theseus scenario. You replace the ship bit by bit, until it's both a new ship and the same ship. Yes, it's a titanic pain in the ass, but it's also atonement for your past bad decisions. Which are heavily populated with cut corners you will be able to spot the next time.

All worthwhile learning is effortful, and greenfield is the lowest effort path to anything. You don't learn much from greenfield except why greenfield is not a panacea.

Re: Software engineers hate code

#227

Post by Silhouette »

hinkley wrote: post #226
Silhouette wrote: post #217

Earlier quoted context omitted.

There is no reason to think a ground-up rewrite of existing working code will lead to better and more maintainable code. As with almost every argument in this area that depends very much on context. A substantial rewrite might be an opportunity to use better tools and improved techniques that have been developed since the original was written. In some cases that could represent a huge improvement in things we actuall…

A substantial rewrite is developers asking for a do-over, which is infantile behavior (or as GP more kindly put it, delusion). This is a hill I will die upon: The people who don't deserve rewrites ask for them, early and often. The people who deserve a rewrite rarely mention them, and in fact they likely already have done it, bit by bit as a sibling comment mentioned by way of example. I will say that I've often surp…

That is the calculus of a project that has been running for 1-2 years.

The calculus of a project that has been running for 10-20 years is often different.

I've explained why - and why in some cases the approach you advocate is literally impossible - in my other comments in this discussion, which I invite you to read if you haven't already.

Re: Software engineers hate code

#228

Post by [deleted] »

hinkley wrote: post #107
usrbinbash wrote: post #70

Earlier quoted context omitted.

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

[deleted]

Re: Software engineers hate code

#229

Post by usrbinbash »

hinkley wrote: post #226
Silhouette wrote: post #217

Earlier quoted context omitted.

There is no reason to think a ground-up rewrite of existing working code will lead to better and more maintainable code. As with almost every argument in this area that depends very much on context. A substantial rewrite might be an opportunity to use better tools and improved techniques that have been developed since the original was written. In some cases that could represent a huge improvement in things we actuall…

A substantial rewrite is developers asking for a do-over, which is infantile behavior (or as GP more kindly put it, delusion). This is a hill I will die upon: The people who don't deserve rewrites ask for them, early and often. The people who deserve a rewrite rarely mention them, and in fact they likely already have done it, bit by bit as a sibling comment mentioned by way of example. I will say that I've often surp…

> A substantial rewrite is developers asking for a do-over, which is infantile behavior

That depends entirely on the reasons why they ask for a rewrite.

"I like this tech better", "I don't want to work with this tech", "This new tech is shinier": I agree with you, those are not solid engineering reasons.

"This doesn't interface well with the rest of the system because...", "This is going to cost us in the future because, ...", "This won't scale well because..."; I strongly disagree.

You may notice that the operative difference here is the term "because". If someone can give a quantifieable, technical, verifieable reason for a rebuild, then management should at least hear the guy out. They can still say no. But then the engineer did his job, and if the whole show goes haywire later because the 14 year old Java backend fails to scale up and the company loses money over that, nobody can say he didn't warn them.

Re: Software engineers hate code

#230

Post by readerbaza »

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…

Those who like greenfields only are probably those "upgraded" to PMs and the reason is they turn green into brown _very_ quickly.
Post reply on HN