Software craftsman
Fart sniffer detected
this post was submitted on 23 Mar 2025
266 points (98.2% liked)
LinkedinLunatics
6540 readers
2 users here now
A place to post ridiculous posts from linkedIn.com
(Full transparency.. a mod for this sub happens to work there.. but that doesn't influence his moderation or laughter at a lot of posts.)
founded 2 years ago
MODERATORS
Am I wrong or does that title he's given himself directly contradict his dislike of code ownership? Or is it just he assumes he deserves credit for the code written by any of his subordinates?
that particular point likely refers to the fact that he prefers shared ownership: ie nobody should be “the one you go to for X part of the codebase”
Yeah, I threw up in my mouth a little when I read that.
Lol. Let’s ban accountability, refactoring, and debugging, never work alone, never coordinate, avoid productivity, and refuse ownership—then scream when things break, don’t integrate, and fall behind schedule.
"This is all your fault!" built-in. Why didn't you intuitively know what myX is supposed to do and how it's used?
Provocation just for "engagement" really. 102 comments so, to some degree, it works.
E: Guys, it's satire. Lol.
load more comments
(1 replies)
This might be my type of job. I ssh into a server and build the backend using bash scripting in nano. HTML and CSS is also done using nano on the live server. No SCRUM needed. We have a large group of testers we refer to as "customers", and they pay for the privilege.
Real devs write each http response by hand. If you use a server you're a filthy casual soydev
That's great! I wouldn't want to work for him anyway.
Code Ownership
Lol did someone try and make him maintain the shitty code he wrote
Individual accountability
more likely a reference to someone being the 1 person you go to for a particular part of the codebase like they own it
Just build whatever you want on prod and disappear after the deadline so they can never ask you to update your code
Sorry the developer you are calling is out of scope.
load more comments
(1 replies)
There are two types of software engineers: those who are anxious and those who are narcissistic and grandiose. This guy is easy to place in the latter category.
I was so happy when I got a job working with a guy who was super chill and a genius to boot, such an impossible combination to find.
Our mantra was pretty much do the best possible thing to reach the widest possible audience, nothing is off the table and no user is left behind completely. I learned such a wide variety of skills there. It went great for nearly a decade before everything went to shit because my guy had left and I was left to deal with a 3-1 managerial hell.
Whatever this guy supposedly architects, it ain't software.
- ORM's
- Place ALL of the business logic in stored procedures.
- Eliminate the backend.
- Make the front end connect directly to the database.
- ~~Profit~~
- Introduce tons of bugs and terrible performance.
- Database is compromised within five minutes of going live.
I have for years been pumped to create a sql only side project or sql + frontend
load more comments
(3 replies)
I'm confused. Are you saying all of that is a consequence of not using ORMs? Because if so, that's absolutely not true. ORMs truly are complete trash.
Sounds like you were hurt by an ORM.
One huge benefit of an ORM is that it does type checking. it makes sure your tables exist, relationships are valid, etc, and it makes easy things easy. If you add a column, it'll make sure it gets populated, give you decent error messages, etc.
As long as you use a proper repository pattern setup and isolate DB interactions from the rest of the code, how you construct the queries is completely up to you. I try to use DTOs to communicate w/ the repo layer, so whether an ORM is used or direct SQL queries is largely an implementation detail.
https://github.com/launchbadge/sqlx
Not an ORM, but uses Rust's compile time macros so you can write raw SQL and it will type check everything against either a real database connection or a JSON cache of the database's schema.
Absolute best of both worlds.
load more comments
(1 replies)
When you don't have a downvote button, all you get is an echo chamber
In an effort to make the post full of engagement bait, the dude ironically made it less engaging.
Remove every bullet point except Lombok, and you got yourself a proper flame war.
Hating on Lombok and setters simultaneously seems contradictory.
Lmao ok ill just follow best practices and end up inadvertently writing an orm from scrach then 🙆♀️
This feels like a facetious post because what. There’s no way he’s serious
load more comments
(1 replies)
NGL I was on board at the first line. He lost me quickly after though
Good riddance.
No mutable types? So like.. no lists? no for ... i++?
I get that there are alternative approaches, but I don't quite see why you'd want to go to that extreme with this idea? It's useful for some applications but even for a simple video game it's likely not helpful.
It's perfectly possible to work without mutability.
Is it desirable to be entirely without it? Probably not, but leaning immutable is definitely beneficial.
load more comments
(1 replies)
Pure functional programming is often like this.
Erlang/Elixir doesn't have muteable variables/types. Appending to a list would just create a "new" lists.
Ideal situation: single guy working from home, no pets. Neighbors describe him as "pretty quiet" or "I dunno."
Which is why he doesn’t have a company of his own. He’s a terrible leader.
view more: next ›