There are so many closed source frameworks developed internally at large companies, for AI to be useful to those enormous customers, it needs to work on systems it wasn’t trained on…
This is a bit of an overreaction. The OP didn’t mention they were depressed, just unfulfilled.
Manual labour can be quite fulfilling compared to white collar work, as progress is much clearer and it can be a nice mental break compared to an office job.
Of course it’s not for everyone, but at the very least it makes you appreciate the privilege of working in an office
Office work can be just as good/bad/meaningful/useless/hard/easy etc. as manual or almost any type of work these days.
It's very ignorant (and outdated by 50 years in a first world country) to look down on software engineers like they are spoiled children whining about their little naive problems.
I have done both physical labor and software engineering, so I’m speaking from personal experience. If your experience differs, what can I say - everyone is different.
I have done too. And obviously individual cases can vary dramatically. I was trying to average my observations not only from my experience, but all the people I observed throughout my life and my career. I am yet to meet a burnt out electrician.
The different mindsets exist, but I agree these are bad words to differentiate them. Back when I started in software in the 80s a common expression was: there are two types of programmers, nerds and hippies. The distinction falling along similar lines - nerds needed to taste the metal, while hippies were more interested in getting stuff done.
There may never be a perfect taxonomy of programmer archetypes.
I imagine most of us here can agree that some elevate the craft and ritual to great effect while others avoid such high-minded conceits in favor of shipping whatever hits the expected target this week.
I’ve been both at different points in my career. Usually it’s a response to my environment.
What about those two vs. the concept of "software engineering"? - there, the "code" or "program" is even _less_ important, just a tool in an ecosystem where you are asking bigger questions like "is this maintainable / testable / readable / etc.?" "is this the right language / framework for my org / others to use" and so on and so on. These questions and context quite literally represent billions of context tokens in LLM world and why I continually do not worry about 99% of the fear mongering of them replacing anybody who writes code.
Yes, however there’s circumstances for when it’s most effective. For example:
Large systems benefit from clear architectural patterns, whereas small systems see little benefit
Performant code is often obscure and messy, it shouldn’t be forced into a “clean pattern” for the sake of it
Clean architecture greatly affects how changes are made in the system. If 20 places need to be updated to add a feature, and that’s something that needs to be done often, then maybe refactoring it would improve this workflow.
At the end of the day it’s a tradeoff that programmers need to make
“will cleaning this up make it better or worse for us”
I don’t think that analogy works well, a subdomain that is not published is more like hiding the key to the front door in the garden somewhere… does a fine job of keeping the house secure until someone finds it…
Why not use letters and packages which is the literal metaphor these services were built on?
It's like relying on public header information to determine whether an incoming letter or package is legitimate.
If it says: To "Name LastName" or "Company", then it's probably legitimate. Of course it's no guarantee, but it filters the bulk of Nigerian Prince spam.
It gets you past the junk box, but you don't have to trust it with your life.
reply