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

Being Slow to Criticise

solipsys.co.uk

Post reply on HN
Print view View original

11–20 of 76 posts

Re: Being Slow to Criticise

#11

Post by is_true »

trabant00 wrote: post #7

I delivered crap multiple times during my career. Sometimes I was forced to by external factors, sometime I was not in a good mental shape, sometime there was no time to do anything more than pile some garbage on top and duct-tape it together. Sometimes I didn't even knew it at the time, I thought I was doing fine. Sometimes I delivered a good thing that aged bad and turned to garbage or the environment in which it f…

I had to write garbage a couple of times. The important thing is wrapping it very well so the client can't smell it.

I usually leave comments on garbage so later when I'm doing something else I try to fix it.

Re: Being Slow to Criticise

#14

Post by awkward »

lmm wrote: post #5

So how do you avoid getting nerd-sniped when something really is just bad? There's an analogue of the Bullshit Asymmetry Principle here; any of us could slap out some code in half an hour (no doubt many of us have, myself included) and then any of us could spend days or weeks trying to understand why we did it that way. Taking the time to understand bad software is, like up-front planning, one of those things that so…

The same way you avoid getting sucked into anything - go in knowing how much time and effort you're willing to expend and cut your losses when you hit the limit.

Re: Being Slow to Criticise

#17

Post by Foobar8568 »

angarg12 wrote: post #13

The Principal Engineer community in Amazon has a list of tenets. I think one of them puts it very eloquently. Respect What Came Before

>Respect What Came Before

When I was junior, I didn't respect much what came before...As I got experiences, I understood this need. I respect what came before, often people are surprised when I take that line.

The only problem is when people continue to do shit (even when hand carried through everything) and still have Pikachu faces when things go wrong, well these people and projects don't deserve respect.

Re: Being Slow to Criticise

#18

Post by sillyquiet »

in my opinion, this tendency to label anything less-than-ideal as 'garbage' is an outdated leftover of a time when assholish (and unrealistic) perfectionism was admired in software engineering, or at least looked up to as 'good engineering'.

This binary outlook is what leads to people who don't understand the reasons behind why existing code is the way it is to criticize. Frankly, when someone does it (and I have done it, lots of times, to my chagrin now) its a pretty good marker of engineering immaturity.

This is different than looking at something and identifying ways it could be better, btw. The latter is value-neutral and judgement-free.

Re: Being Slow to Criticise

#20

Post by michaelrpeskin »

lmm wrote: post #5

So how do you avoid getting nerd-sniped when something really is just bad? There's an analogue of the Bullshit Asymmetry Principle here; any of us could slap out some code in half an hour (no doubt many of us have, myself included) and then any of us could spend days or weeks trying to understand why we did it that way. Taking the time to understand bad software is, like up-front planning, one of those things that so…

Sometimes, it helps to just put in the comments why you did something that you know is not optimal. Often you'll write "bad" code just because it makes sense. I had to update something last week where the requirements changed dramatically from when they were written. It's nobody's fault. When the requirements were written, we did really understand the problem. After the customer got the code in their hand, they wanted to extend it in a way that wasn't obvious to us or them. I could have done a multi-month refactoring to make it clean and pretty, but that didn't make any business sense, so I did some surgical changes. To avoid someone coming back next year and thinking WTF, I added this to the comment (most of the details left out for anonymity)

//...Not how I would design it from scratch, but a nice evolutionary change.

Now next year when someone else looks at it (or even next-year me), we won't waste time thinking if we should refactor it, because it's obvious that we already looked at the pros and cons and decided not to.

Post reply on HN