Live data from Hacker News

Woodworking as an escape from the absurdity of software

alinpanaitiu.com

201–210 of 545 posts

Re: Woodworking as an escape from the absurdity of software

#201

Earlier quoted context omitted.

At a level or two down from the abstraction of company size, crafting hobbies are also a reprieve from the tyranny of linters. So many programmers today believe that code is always better when it all looks identical. Consistency is a good thing, but not when it's expected to be absolute. Programming should actually allow for creativity, and where you decide to add spaces and newlines can actually add subtle but impor…

I curse the inferior linter formatting and at the same time would not have it any other way because why? Some diva would come in and put up a MR reformatting half the code base to their preferred way, mixed in with the actual change they are making and I would have to hunt for the actual changes in the reformatting noise. And then we would spend half a day arguing about it like in the good old days. Fast forward six…

Why not just set up a rule to auto-format the code before it is committed so that nobody wastes time discussing formatting trivialities and the repo stays consistent?

Re: Woodworking as an escape from the absurdity of software

#203
post #11

Earlier quoted context omitted.

But sorting issues according to their rough size is precisely what makes at least basic sense. A scale of trivial (can make many of those in a day), simple (several of those a day), medium (roughly a day of work) or large (days) makes it possible to have at least basic conversation around work planning. I’m not extra sold about calling those by shirt sizes, but I’m sure we’re on the better end of the absurdity scale…

At that point, you are estimating EFFORT, not time. Software engineers are REALLY GOOD at estimating effort. The fact that they translate to time (simple == several days) is ephemeral.

>Software engineers are REALLY GOOD at estimating effort.

The most common problem with estimates is hidden or forgotten complexity, which makes both time and "effort", whatever that means, go up.

Re: Woodworking as an escape from the absurdity of software

#204

Earlier quoted context omitted.

I curse the inferior linter formatting and at the same time would not have it any other way because why? Some diva would come in and put up a MR reformatting half the code base to their preferred way, mixed in with the actual change they are making and I would have to hunt for the actual changes in the reformatting noise. And then we would spend half a day arguing about it like in the good old days. Fast forward six…

Why not just set up a rule to auto-format the code before it is committed so that nobody wastes time discussing formatting trivialities and the repo stays consistent?

It would be fantastic if there was a good normal-form formatter I could use for local work, and let automation format the code back to lint style. Unfortunately with something like IntelliJ/Java the commit-time reformat is not reversible. Maybe google's Java formatter is, hmm.

Re: Woodworking as an escape from the absurdity of software

#205
post #68

> Even my last team leader sent me a message out of the blue saying “I think I’ll run a bar. I want to be a bartender and listen to other people’s stories, not figure out why protobuf doesn’t deserialize data that worked JUST FINE for the past three years”. I worked at a bar when I was young, listened to the stories; the most annoying protobuf deserialization issues or 'Agile meetings' are freaking fun compared to th…

The nicest part of working at the bar is when you leave the bar you're done working. Also, you don't need to get your drink pouring approved by another bartender that nitpick small details of what you did to boost their own ego.

Have you worked in a bar? Both of those things can be untrue, lol.

Re: Woodworking as an escape from the absurdity of software

#206
post #68

> Even my last team leader sent me a message out of the blue saying “I think I’ll run a bar. I want to be a bartender and listen to other people’s stories, not figure out why protobuf doesn’t deserialize data that worked JUST FINE for the past three years”. I worked at a bar when I was young, listened to the stories; the most annoying protobuf deserialization issues or 'Agile meetings' are freaking fun compared to th…

Anything you do 40 hours a week gets tiring eventually.

Which is why my primary career goal is working less at this point. Not because I hate software engineering, but because I love it...

Re: Woodworking as an escape from the absurdity of software

#207
post #49

Earlier quoted context omitted.

HN loves to make this claim but it just doesn't match my experience, from several teams. Estimates are not precise, obviously, but that doesn't mean that they are impossible to make or that they add no value.

I mean I've routeninly seen estimates be 3-5x longer that projected. It's up to you if you thing that's an accurate enough estimate or not.

Sure, so have I. I don't think estimates are good for determining a date for a contract or anything like that. I think they provide data about the tasks when prioritizing, which is valuable. Code coverage is also a really low quality indicator of test quality, but it is still useful.

Re: Woodworking as an escape from the absurdity of software

#208
post #165

Earlier quoted context omitted.

Maybe I'm not articulating my point very well. I absolutely agree that consistency, in principle, is usually a very good thing. My objection is to the idea that it's always a good thing, which it's not. Treating code formatting as rules rather than suggestions, in my experience, is a waste of time and unnecessarily tyrannical. In terms of mere code formatting, I don't buy that there's a meaningful difference between…

> My objection is to the idea that it's always a good thing If everyone doesn't follow the standards all the time then there are no standards. Code is not art, it's instructions. If you can't write instructions without adding your own avant garde whitespace brush strokes to it then yes coding for a professional company may not be your jam.

> Code is not art, it's instructions.

I'll slightly disagree here because code needs to be read by a computer and by your human teammates.

There are times when I'm frustrated because prettier is making a necessary but unintuitive choice and causing my code to become harder to read. But those are rare, and I would never trade them for the guarantee of readable code the other >99% of the time.

Re: Woodworking as an escape from the absurdity of software

#209
I don't understand why it has to be exclusive or comparative or even complimentary.

I do a lot of programming, some wood working (a little fine stuff but also timber framing), stone work, and (ornamental) gardening. I find all of these things very similar. Building, guiding things that I don't quite control towards an end I want. Open-ended and creative. I find all of them very relaxing.

> software dev as we know it is about to disappear soon

circa 2006 my father begged me to not pick Computer Science as a major. He was certain by the time I graduated there would be no jobs left.

> And I got so tired of everything being online, immaterial, ephemeral and lonely, like indie development tends to be.

Ah well, it's good he's not gardening!

Re: Woodworking as an escape from the absurdity of software

#210
I reached this point after the small company that I work for had a terrible 2023 and I realized I hadn't been having fun or looking forward to going to work for probably years. Now I'm actively looking to get out of the industry. I haven't had an interesting problem to solve since I can remember, and all the other absurdities mentioned in this thread apply. I turned 40 in December, maybe that has something to do with it. Early midlife crisis or something.
Post reply on HN