Ask HN: Anybody else exhausted by code discussion? | Hacker News Reader

Ask HN: Anybody else exhausted by code discussion?

19 pointsvolkk10 comments

I don't mean discussing the logic of algos or the business logic, but the code cleanliness, the tech debt, the endless refactorings, etc is really getting to me.

I'm fast approaching a place where I'm going to implode if I have another argument around whether service A talks to service B and it should instead be talking to service C because of magical boundaries that we've setup. I'm so tired of dependency arguments and what should be exposed and what shouldn't. Even more tiring: arguments about process and story points/estimation and what should be the ideal workflow and people whose entire jobs it is to facilitate these arguments further.

I just want to build cool stuff.

Every company is the same, with the same problems and the same arguments made by the same personalities. You'd think all of the accumulated human hours we've spent arguing about the perfection of code over the decades of computing we'd have arrived at something decent by now, but spaghetti is spaghetti and it's everywhere. Is there a world where we just embrace it all and save our breaths? Can we build something new that will ultimately remove these discussions? I want to go to a place where people are passionately arguing about the direction of the product and what to build next, not mindless code structure arguments that will happen all over again in a month when someone leaves and someone new joins and shoves a new dependency into the mix.

Before everyone starts furiously typing that thinking about clean code for the future is critical for a good engineer, I'm well aware. I'm just so exhausted by it all. I don't know how to phrase it properly about the dichotomy of "I understand, but...ffs" that I'm feeling

Yes, totally exhausting.

Most of what you describe are people issues / classic bike shedding.

You should be able to find some ways to shut this down fairly efficiently.

"A talks to service B and it should instead be talking to service C":

* Yes, I agree! Let me know when you have a PR to look at!

* Yes, it really should! Please create a work item for it, and we can prioritize it in the context of our other initiatives!

* Should it? What problem does that solve? How will our customers tell the difference?

* Let's review our product roadmap and mission statement and see which heading this falls under?

* This is our daily standup where we briefly touch on all of our work in progress, please set up a dedicated time for a deep dive on your idea!

Those are some polite ways to shut this stuff down and move onto whatever you want to talk about. They might work, and if they don't, you can be sure you have some major personality problems to contend with.

I'm no psychologist... but I think a lot of people that indulge in this stuff just want to be heard, and in some cases want to rearrange deck chairs so it looks like they're taking action and getting stuff done.

Ultimately you need to find a way to move the discussion whatever you find important and stimulating, and not let these folks set the agenda.

Sounds like you're more interested in "solving the business problem" and less interested in "solving the problems of the code that is solving the business problem."

Hillel Wayne recently wrote about this distinction:

> New Newsletter! An exploration of a core difference between "programming" and "software engineering": how much you work on "solving the business problem" versus "solving the problems of the code that is solving the business problem."

https://twitter.com/hillelogram/status/1486079674795143170

https://buttondown.email/hillelwayne/archive/software-artifa...

And sounds like you enjoy "product engineering" more than "infrastructure engineering."

Michelle Lim wrote a post about it, which was discussed on HN.

> Try using the "Product/Infrastructure" axis as the first axis to understand your career preference.

> Broadly speaking, there are 2 types of engineers: "Product-first" engineers are obsessed with using code to solve a user problem and they see code as just a means to an end. "Code-first" engineers are obsessed with the abstractions, architecture, tools and libraries in the code. Elegant code is the end.

https://news.ycombinator.com/item?id=28476538

https://www.michellelim.org/writing/stop-using-frontend-back...

> I just want to build cool stuff.

Then work on your own stuff. Companies don't pay the big bucks for working on pleasant tasks only. If you are an employee you: play good with others pushing stuff to production while keeping the business happy and the kitchen (code) clean. If you work on your own stuff: do whatever you want.

To clarify: I feel like you as well. I think almost everything in software engineering is subjective... but I'm a professional: I do my best and get paid.

This is a common problem when working at large companies. Most of the time, the job is no fun. I think one of the reason we are paid so much is that at large companies, we need to do a lot of things. We need to navigate multiple services, communicate to different stakeholders, wait long time for approvals, check with the legal team for compliance when releasing a new product, check with other teams before doing a deployment on a service with multiple dependencies, etc. Coding is just a minor part.

My question is what cool new stuff is there to build? It feels like all the low hanging fruit was picked between the 60's and the 90's (maybe into the 00's) and now software development is a black hole that just gobbles up any resources we throw into it and leads to enormous burnout.

However, I tend towards a pessimistic nature, so hopefully I'm wrong.

That's what wage work does to creativity.

When I have a question or feel curious about something, I write it down. I'll then try to seed an app around the idea when I can. I have a bunch of little sandcastles I mess with stochastically.

I really hate taking solutions from others. I'm perpetually yak shaving. I don't care though. I'm coding to satisfy my requirements. I don't usually intend to show people these things, but some will probably make me a millionaire soon. That means I'm intentional about reflective and deliberate practice to avoid ruts and inefficiencies and to continue improving.

Here are some ideas: - Build a parser for a language you don't know yet

- Create a vscode plugin that helps you code more in line with how you think about code

- Play with huggingface API's

- Browse through Show HN's and pick an idea to clone

- Screen record your phone or computer usage and try to spot inefficiencies. Is there a way to address that with code?

I am unsure how people grow in this industry by just relying on pre-concocted guides/tutorials/patterns. There's a superpower in code. It's ok to flex it, even if it's just for your own amusement.

I'm not tired of discussing code at work (I actually find that healthy). It's these web developer types you see on social media who talk about Javascript all day, but rarely, if ever, build anything with it. It's very meta. Imagine being so focused on 'what you can do now with code' that you don't even leverage it for side projects or side hustles? It annoys me no end.

You sound like you belong at a seed or pre-seed startup. No one is around to have these discussions with, you just build it the way you think is best.

Isn't it you are exhausted with people rather than code?

A bit. from one point, i wouldn't mind passionately discussing mechanics of a feature, or the strategies of what to build in the next few quarters/years. but every time i enter a discussion about which way the code should be setup, i just can't enter a state of caring anymore. i'm starting to come to the opinion that when presented a path of A vs B, humans aren't well equipped to really understand that even though A seems okay now, it can be a terrible decision for what's to come in 2 years. Same goes for B. So it all just becomes moot. I've seen it happen time and time again

Reply on news.ycombinator.com