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

Goodbye, Clean Code

overreacted.io

Post reply on HN
Print view View original

581–590 of 599 posts

Re: Goodbye, Clean Code

#581

Post by useragent86 »

bjourne wrote: post #513
woutr_be wrote: post #373

Earlier quoted context omitted.

I need to disagree with you, I've been in a few positions where one engineer suddenly decided to rewrite parts of the code base without any input from other engineers. It's a huge blow to team morale, and it gave me a fear of writing code in this team. Every time I wrote a piece of code, I wondered how long it would be there for, I understand that code evolves, but seeing your code being rewritten after a week is no…

> Every time I wrote a piece of code, I wondered how long it would be there for, I understand that code evolves, but seeing your code being rewritten after a week is no fun, and it's a huge blow to your confidence as well. Here's some tough love. If people frequently rewrite code that you write it is because they are stronger developers than you are. You, the junior developer, can either sulk about it and feel misera…

> Here's some tough love. If people frequently rewrite code that you write it is because they are stronger developers than you are. You, the junior developer, can either sulk about it and feel miserable or realize what an amazing opportunity you have to improve.

Why is this condescending tone and unfounded assumption acceptable here?

It's like, Well, lookie here, a stranger with a generic opinion! What an amazing opportunity for me to assume specifics and talk down to him! You're welcome!

Re: Goodbye, Clean Code

#582

Post by useragent86 »

kazinator wrote: post #488
woutr_be wrote: post #373

Earlier quoted context omitted.

I need to disagree with you, I've been in a few positions where one engineer suddenly decided to rewrite parts of the code base without any input from other engineers. It's a huge blow to team morale, and it gave me a fear of writing code in this team. Every time I wrote a piece of code, I wondered how long it would be there for, I understand that code evolves, but seeing your code being rewritten after a week is no…

> Every time I wrote a piece of code, I wondered how long it would be there for. The fix for that sort of thing is to have a satisfying, enduring side project where you're the boss: nothing is upstreamed that you don't like. Then you can stop caring if your code at work gets replaced, and how fast.

Reading this made me smile. TXR is obviously that for you, and I wish all software were developed with such care.

Re: Goodbye, Clean Code

#583

Post by vonseel »

Fanmade wrote: post #375
vonseel wrote: post #362

Earlier quoted context omitted.

I’m just wondering where you draw the line. As with everything, it often becomes a big grey area on what is acceptable and what is not. Example: my (fictional) company sells a B2B platform which provides companies with an online marketplace or some other type of online application. Each installation requires different, though often similar, integrations with the customer back-ends - think Postgres vs MySQL, but some…

Ironically, we're handling this with the concept called "clean code". We do have a core, which does implement the base logic. Everything in there is domain driven, but only using DTOs and providing interfaces for input and output, using repositories and presenters. When the data source changes, we only need to add the new repositories and set those within the context. If we have to implement some specialized logic ju…

That’s pretty much the approach I would suggest and think works best. Thanks for your reply.

Looking back, I think the place I worked had a lot of issues with how code was actually stored and maintained - different repositories for each client and each feature, for example, meant a lot of common code was simply copy/pasted when reused and that obviously made sharing bug fixes much more difficult or even impossible. Real dirty stuff. The solution isn’t all that complicated but when you’re on a services team with several hundred clients and hundreds of issues in your backlog, management focuses less on paving the way for the future and more on getting things done immediately. A few of us did implement a single code-bass / configurable framework for one big feature, but it was hard to get buy-in and convince people to use it - even if it reduced the workload from days or weeks to hours. The concepts from that were eventually re-packaged by management and sold by a more creative manager as an “SDK”, but I didn’t have the privilege of working on that team.

Re: Goodbye, Clean Code

#584

Post by kelnos »

AlexCoventry wrote: post #163
kelnos wrote: post #138

Earlier quoted context omitted.

The downside I see with go's error handling is that you can forget to check. With rust, if the function being called returns Result, you have to deal with the error (even if dealing with it just means propagating it out). Missing error handling is such a common source of bugs that go really turns me off here.

> you can forget to check Linters can help with this.

Sure, but given a choice, I'd rather work with primitives that are correct-by-construction, not correct-if-I-use-an-extra-tool-and-actually-act-on-its-advice.

If you do use a linter and have it set up so linter issues are fatal to the build, then you run into the issue that if the linter throws false positives, you have to add exclusion rules (if the linter even supports that) or downgrade linter issues back to warnings, and lose the benefit entirely.

Re: Goodbye, Clean Code

#586

Post by BalinKing »

klyonrad wrote: post #448
BalinKing wrote: post #288

Earlier quoted context omitted.

Sandi Metz's blog (and book) are an absolute gold mine. I'm a junior developer ( If there was a required reading list for professional developers, I would put her work on with zero hesitation, I feel it to be that important.

You call devs Junior until they have over 5 years experience? Wow, that’s harsh

One of the big reasons I realized I still _was_ a junior developer was because of Sandi Metz's content showing me how long of a journey I still have to go :-P

I don't personally think it's strictly about the time one's been programming, although in my experience that can be a good benchmark for e.g. how good one's abstraction, API design, etc. skills are.

Re: Goodbye, Clean Code

#587

Post by vgrafe »

latchkey wrote: post #543
vgrafe wrote: post #439

Earlier quoted context omitted.

Are you suggesting that a dev acting like this without consulting the team should be considered normal/expected? Not sure how to address a move which is unproductive in its nature "in a productive manner" unless being proactive and preventing those rewrites to happen, unless needed and discussed with the team. But in my personal experience the team's decisions were always ignored by the coder in question. edit: I sho…

Since this is a fairly common dev experience (rewriting code), that the team meet together to set a policy as a group. Similar to code format standards, why not talk about code maintenance standards?

I get you now, and this is definitely an approach I agree with. I guess I was ranting about my previous experiences... since the last departure I encourage the rest of the team to plan and discuss such changes.

Re: Goodbye, Clean Code

#588

Post by abrax3141 »

DataWorker wrote: post #479
abrax3141 wrote: post #456

Earlier quoted context omitted.

Hmm. I wonder if he got that from Simon while he (JB) was at CMU. He (HS) once said to me, jokingly, I think, “One makes an observation, two makes a generalization, three makes a proof”.

Sounds good but is wrong. Sometimes you need more than 3. Maybe 3 is for those who need to move fast and break things though.

Yeah. I think he (HS) was joking. He had a Nobel, and (co)invented AI. I’m pretty sure he knew what a proof is.

Re: Goodbye, Clean Code

#589

Post by jariel »

lleolin wrote: post #502

When I look at his example I still sense a compelling sense to create some kind of abstraction. It's just that the example abstraction he chose to make is somewhat esoteric and arguably over-solves the problem. The author isn't suggesting a different, perhaps simpler abstraction, but forgoes abstractions entirely.

I tend to agree.

To me, this is a good fit for some kind of 'fairly simple abstraction' - even the abstraction used is fine.

So long as everything worked, I think this might be a better solution.

I'm fine with 'don't just refactor because' but this looks like a fairly clean cut opportunity.

Social considerations aside.

Re: Goodbye, Clean Code

#590

Post by jariel »

theshadowmonkey wrote: post #515

One similar experience i had when I was starting out was when I created a PR and my colleague instead of suggesting changes, made the changes himself, approved and merged my PR. I told him directly that it’d be nice if he’d have suggested the changes instead of making them himself. He thought I was being protective of my code. I was never able to have a good working relationship with him anymore and eventually left.

Maybe consider that it's not 'your code'.
Post reply on HN