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

Woodworking as an escape from the absurdity of software

alinpanaitiu.com

Post reply on HN
Print view View original

121–130 of 545 posts

Re: Woodworking as an escape from the absurdity of software

#121

Post by Shacklz »

vbezhenar wrote: post #106
makerdiety wrote: post #93

Earlier quoted context omitted.

> Most places I've worked in the last 6 or so years are obsessed with tooling and add so many lint rules that it's often impossible to merge your pull request if you decide to format your code in a way that violates the rules in some trivial way. Shouldn't all the lines of code uploaded in a pull request be automatically formatted into the coding style preferred by the reviewer anyway? It should be like an automatic…

What bot? You create a branch, you push button in github UI, merge request is created. There's no bot.

It's not a bot but formatters like prettier for example make it very easy to set them up as git-hooks, where the formatter is applied on commit. Meaning, unless you specifically commit without hooks, all committed code should comply with the formatter.

For linting (e.g. eslint in the JS-space), this is also possible, however, most linting-processes tend to run just long enough to be annoying when run on every commit. In the monorepo I work on we created a command "prep-pr" which specifically addresses this issue - run it before creating a PR, and the CI-pipeline will mostly be green, at least in terms of linting/unit-testing.

Re: Woodworking as an escape from the absurdity of software

#122

Post by zmgsabst »

withinboredom wrote: post #15
XorNot wrote: post #6

Earlier quoted context omitted.

I've always felt this is because estimation never gets treated as an exercise which might involve actual software engineering. You get handed a task you've never seen before, for a system you've never seen before, and asked "how long would implementing this take?" You never get handed a task which is "write as much of a prototype of a system which would do this, so we can estimate how much more work we think is invol…

It's not just that, but also we tend to estimate in the context of "if I were sitting at a computer working on just this problem, this is how long it would take." The reality is that there are meetings, high priority bugs for unrelated systems, interruptions from the business, coworkers and life, code reviews for other team members, rediscovering what you were doing before being interrupted, etc. Using time tracking,…

When I was at Amazon, I read the SDE guidelines from HR, where they describe their view of the role.

An SDE1 was expect to spend 4hr coding a day; an SDE3 about 2.5hr coding a day.

That’s normal for a job, eg, apartment maintenance (my college job) would have us actually wokring about 4 hours a day, between setup, cleanup, breaks, travel, miscellaneous tasks, etc.

Convincing other SDEs to assign points to stories based on that (4hrs of coding per point) was surprisingly hard.

Re: Woodworking as an escape from the absurdity of software

#124

Post by rvense »

m_eiman wrote: post #9
withinboredom wrote: post #4

Earlier quoted context omitted.

It's quite ridiculous for a number of reasons, well documented by research and experience: software engineers can't estimate how long something will take with any kind of accuracy.

> software engineers can't estimate how long something will take with any kind of accuracy. Sure we can, it's always one of: - A couple of minutes - Today - A week or two - Probably around a month - I have no idea, could be any of the above or more

At my work "It'll take half a day" has become slang for "I have no idea"

Re: Woodworking as an escape from the absurdity of software

#125

Post by azemetre »

smackeyacky wrote: post #119
usrnm wrote: post #56

Earlier quoted context omitted.

What's wrong with doing a boring job for a lot of money and then getting all the fun elsewhere? This actually seems to be the best way to do it to me

Because it’s soul destroying knowing your talents are wasted for 40+ hours a week

It’s only soul destroying if you let it be. As someone who grew up in poverty and spent most of my 20s working at a call center and pawn shop, I feel like the luckiest person in my family with my soul destroying corporate job.

It sounds cliche but happiness is truly a state of mind. You don’t have to wait for something in the future to be happy now.

Re: Woodworking as an escape from the absurdity of software

#126

Post by Shacklz »

ravenstine wrote: post #52
sukruh wrote: post #35

Most of the people I know who pursue creative/crafting hobbies alongside a software development job have chosen to work for well-known big companies, for prestige and safety, and ended up unfulfilled in their jobs. Most big companies are not good if you want to solve problems and build stuff. Especially "the enterprise", where software is seen as a cost center so the less of it the better. The effort of managing up e…

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…

If there's a small team, individual freedom can be perfectly fine, as everybody knows everyone and it's easy to talk with each other in case there are discrepancies.

For larger projects however, not having tooling set up that enforces certain consistency is an absolute showstopper for me. I'll either introduce it or I'll quit; I simply do not want to waste my time with developers squabbling over arbitrary formatting-choices or irrelevant coding-style-details that can easily be enforced by some tooling.

Of course, developer-experience is paramount. Meaning, the tooling must be easy-to-use and generally not stand in the way. Otherwise it can indeed create a lot of friction which will annoy everybody. But once this has been set up (properly!), it will make a lot of silly discussions and choices obsolete.

Re: Woodworking as an escape from the absurdity of software

#127

Post by swader999 »

ravenstine wrote: post #52
sukruh wrote: post #35

Most of the people I know who pursue creative/crafting hobbies alongside a software development job have chosen to work for well-known big companies, for prestige and safety, and ended up unfulfilled in their jobs. Most big companies are not good if you want to solve problems and build stuff. Especially "the enterprise", where software is seen as a cost center so the less of it the better. The effort of managing up e…

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'm just happy to have gone six years without wasting half a day a month debating about formatting or whims.

Re: Woodworking as an escape from the absurdity of software

#128

Post by jhanschoo »

mhaberl wrote: 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…

> 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 the most of the stories you can hear.

I'm assuming that by this you mean that most stories you hear around the bar are just the same stories with different characters and protagonists?

Re: Woodworking as an escape from the absurdity of software

#129

Post by swader999 »

sokoloff wrote: post #105
makerdiety wrote: post #93

Earlier quoted context omitted.

> Most places I've worked in the last 6 or so years are obsessed with tooling and add so many lint rules that it's often impossible to merge your pull request if you decide to format your code in a way that violates the rules in some trivial way. Shouldn't all the lines of code uploaded in a pull request be automatically formatted into the coding style preferred by the reviewer anyway? It should be like an automatic…

That desire is in conflict with a desire for the reviewer to see only the changes and many of the diff tools don’t diff this reformatted code against that reformatted code but rather work on the pre-reformatted. It could obviously be done, but involves a yak shave that isn’t clear that it brings enough value to be worthwhile.

That's my main concern, I want to review the changes, not formatting opinions.

Re: Woodworking as an escape from the absurdity of software

#130

Post by happymellon »

dartos wrote: post #103
meijer wrote: post #98

Earlier quoted context omitted.

My theory is that excessive linter rules might be a symptom of trying to compensate for the weaknesses of a programming language. I see it a lot in Python and JavaScript projects where the language gives very litte guarantees about anything. If you use a programming language that affords some guarantees like Haskell or even just C#, people seem to be less interested in linters.

Linting reduces the expressiveness of a language so that a large team can have some consistency. It’s not necessarily a weakness of the language. Languages like Haskell, C#, and Java don’t have the same amount of expressiveness as js, python, or ruby, so they don’t benefit as much from a linter, though I know places that use one for C# to prevent usage of the ‘var’ keyword

I have that at my current place with var in Java.

And enforcing new lines on else or catch after the brace, completely different to the language guides.

It looks a fucking mess.

Post reply on HN