569 karma · joined April 8, 2019
I wonder if there are statistics about this kind of trend. How many new companies spawn for ever 100 tech layoffs? How many more jobs are created in 1, 2, 4, and 8 years after the layoffs?
Crypto and NFTs are just easier, less risk, less chances of being caught.
Maybe we should talk diamonds. Inherently worthless objects, easy to hide and transport, easy to make part of jewelry, and thus free to transport almost anywhere. Yet that one tiny rock can cost tens of thousands and will allow the corrupt politician to sell for cash money perfectly fine.
Setting all that CI/CD stuff up took me maybe 6 hours. Building the website (front and back-end) took me a few weeks. It's a complicated piece of software, but fun to build.
I avoided using unnecessary tools. I only added what was absolutely necessary. And based on my 22+ years of experience (including some FAANG companies and the likes), in any professional setting, this project would've taken 5 front-end developers, 3 back-end developers, 2 testers, 1 project manager, 1 scrum master, 1 product owner, 1 UX and 1 UI designer, and perhaps one or two interns.
And it would've taken 2 years or longer.
I've done projects with teams like that in the past where trivial work was drowned in red tape, office politics, endless opinions and meetings, weekly time-wasters (Scrum... fuck I hate Scrum!), endless "documentation" that nobody reads...
And I remember being put on a dashboard page. The team was taking 4 hours to plan all the stories. During that time I just started working (remotely, muted, camera off) and I finished the entire dashboard completely to specs, no bugs, in the time it took them to write the stories and tasks and estimate them.
"Done."
"What?"
"I'm done. It's all done. I pulled all 18 tasks to myself, verified them, and the entire story and epic is now done."
"What?"
"I also wrote all the e2e-tests."
"What?"
"Scrum is a huge waste of time."
"Actually, I disagree, because..."
Yeah, consultant who is paid by the hour. It makes perfect sense to pull all 20+ people into a 6-hour long retrospective every single week. Because 12 of those people are from your employer, and that's a lot of money for doing fuck all.
When I worked at Apple, we had a small team and we just did standups on Slack. Just write "I did X, I will do Y, no impediments," and that's it. No scrum bullshit, no sprints, no retrospectives. We just communicated using words (written, preferably) and got shit done.
Now I'm working for a large corporate company that follows all the things by the book. And the book sucks. I counted: 16 hours per week in unnecessary meetings. Then another 10 hours in meetings where most people are unnecessary. And when I speak up against it, people don't trust me. Scrum is their God.
I hate my job so much.
The real question should be: would most developers WANT to use a Mac, if given the choice?
Personally, I think OSX is the superior of the two simply because it's stable as can be, takes no (and allows almost no) tinkering to get working. Controversial opinion, I'm sure.
Now, I just tell Copilot what I need to do, and I simply curate multiple solutions.
ChatGPT also understands what I need to do and changes things based on human instructions. It gets things right much more quickly.
"There are 42 people watching this hotel right now! Only 3 rooms available for your dates! We'll murder ANOTHER puppy if you don't book right now!"
Yes, I worked for Booking.com. They don't do it everywhere, in some places it's illegal, and sometimes they simply change the words slightly to make it suggest urgency.
The best arguments against it:
1. Spamming utility classes causes horrible git commits, git history, git difference checks;
2. Conflicting utility classes aren't clear, and sometimes the order cannot be trusted;
3. Replacing `p-4` with `p-4` will require you to replace its occurrence all over your app, sometimes affecting thousands of matches. And since there is no context to it, it'll be hard to JUST replace them where you would want them to.
Vanilla CSS using `:root` declaration, a fixed base size (using `rem` and `em`), CSS variables and `calc()` are SO powerful.
In almost every single use case, using vanilla CSS or SCSS is far superior. For React projects (and Vue.js, and Svelte, and Angular), I'd recommend anyone to just use (S)CSS modules. It's so elegant and doesn't come with any of the disadvantages.
Except maybe a slightly larger package size. Minimally so. Your framework of choice should be (or allow) code splitting to take place. And a few bytes more or less aren't going to make or break most websites.
<looks at TypeScript>Then again, when I look at old projects I do find it extremely verbose and JSX makes me so much happier.
I jest. But that's kind of the point. SAP is terrible by the nature of the beast. It's a closed off system with specialised developers who require all sorts of expensive certifications. That doesn't make for good developers, that makes for pigeon-holed developers who don't have a lot of competition.
A terrible SAP developer with all the certifications to their name would probably still find plenty of work, because the expectations are low to begin with, as proven by SAP being held in low regard across the industry.
To me, needing expensive certifications to prove your worth (as if...) is a big red flag. I'm a developer who has 20+ years of experience, I recently worked for Apple and other Fortune top 50 companies, I went from startups to enormous companies.
Nowhere did I need certifications. And my past experience was never enough to land a job. I'd have to prove myself in every job application. That's tiresome and feels extremely unnecessary, but it requires me (and my peers) to stay sharp.
Of course, none of the above is very black and white. There are certified developers who are amazing, and there are open-source developers who keep themselves relevant who actually suck at what they do.
But I'd argue that the SAP group of developers have far more developers who aren't very good and grow complacent, oftentimes because of their certifications. That, combined with a closed-off system, bad documentation, a lack of online support, and a much smaller community, will MORE often lead to software that is of lower quality.
"We don't know how to defend ourselves against beasts, and we'll never know."
"We don't know how disease spreads, let's just hug it out, we'll never know."
"We don't know how to fly like a bird, we'll never know."
"We don't know how to land the booster of a rocket, we'll never know."
"We don't know how to cure that form of cancer, and we'll never know."
What a ridiculous defeatist attitude. History has proven that, so far, we've been very reliable at figuring out things that were deemed impossible.
I'd say we already know. It would be infinitely arrogant of us to think we're the originals. We're likely inside an inescapable but observable simulation, inside a simulation, repeat for any unknown number of times. That's probably how "the universe" (our universe) began.
Our parent universes probably have far more complexities to them that have been stripped from ours, for the sake of computational simplicity. Perhaps the actual originals, or any of our parent simulators, know exactly how the universe came to be. We might figure it out, too.
And I don't mean that a company of 10 people depends on each other, their messages are also hashed, seeded, encrypted, etc. on the entire network. Each company and each individual can have their own unique key that's used to make their own messages and content readable again.
Of course, a company should be able to choose to only share messages across their own employees and not to anyone outside, if they are wary of security issues. Messages could have set expirations, too, etc.
We shouldn't need an expensive middle-man. It should be a free open-source project.
But I'm not a networking expert. Is this simply not feasible for other reasons? I'd love to work on such a project as a software engineer, for sure.
Generics are the worst offender, with people often using a single letter to represent something that's both hard to keep track of and impossible to intuitively make sense of.
Any type should be: `TUser` and not `User`.
Any generic should be: `<GPerson>` and not `<P>`.
Any interface should simply not exist because it's TypeScript, not InterfaceScript. The addition of classes into JavaScript was unnecessary sugar and they should just do away with it. So, `type` for everything, no more `interface`.
But that's a whole different subject.
I've also noticed that people over-engineer TypeScript. I had a team mate telling me he wanted to make URLs type-safe. I asked: "But why?" and he had no answer. There was no problem preceding it. There wasn't anyone asking for it. It wouldn't solve something we didn't know. It would just make the codebase more confusing to deal with because, in his solution, there wasn't a single place where routes were defined. Nope, routes would be inferred from Pages and their use of Page props.
It was genius. But it also was over 2000 (two THOUSAND) lines of code that I didn't feel like I wanted to deal with.
I gave him permission to publish it and get the open-source community involved. Once it's tried & tested over the course of many users and lots of time, we could consider it.
He wasn't happy. He was also not very pragmatic. TypeScript seems to do that to people. The "never any `any`"-crowd is so tiresome.
So I worked for 4 years before I got to a university and followed along for a 1-day introduction. They would tell their prospective students what they would learn in the next 4 years, and what jobs they would find when they were done. At the end of the day was a Q&A with some professors.
It was at that moment that I realised: 1. I know more than these professors do; 2. I'm currently a very skilled autodidact software developer; 3. I already know all of what they would teach me in four years; 4. they were working with outdated materials; they taught generics, not specifics.
These professors were academics. Google didn't exist yet. They, mostly, hadn't worked in any professional environment. They weren't pragmatic. They were slow perfectionists but also several years behind on the rest of the world.
And that was saying something: the bleeding-edge books that I was reading took at least 1 year from the start of writing to publication, so even I was behind on reality.
Even today I sometimes wonder what software engineering students learn in 4 or more years. It shouldn't take nearly that long. If you spend 20 hours a week studying software engineering you should be ready to find work in less than a year. And from that point onward, that's where you actually learn how to do it right.
It all makes sense from just the financial point of view. So that means it isn't going away any time soon, unless there's a huge backlash from consumers.
Perhaps the best thing we can hope for is 1 car manufacturer deciding: "Buttons first, touch screen(s) second."
Let consumers decide with their wallets. Though, I wouldn't be surprised that many consumers go for an inferior product just because it looks cool. Because that, unfortunately, is how humans work.
Driving a car with touch screens (new BMW or Mercedes) has left me very unimpressed. My 2016 VW Golf has actual buttons, switches, and knobs to twist and turn and press and flip.
Car reviewers, too, often say it's a shame that car manufacturers are switching to touch screen nonsense. It's such a shameful trend if you think about it. The BMW series of pre-2022 had buttons in the dashboard, but the upcoming new series will do away with those entirely.
Touch screens even find their way onto steering wheels and doors.
Of course, it's easy to understand why:
1. It's cheaper to produce; 2. It looks more expensive, so the price goes up; 3. Testing audiences respond positively to shiny lights; 4. Fossils decided that this is what the young people want.
Honestly, I hope European legislation makes it illegal at some point. For the sake of safety. With touch screens, even the most simple task requires you to take your eyes off the road in front of you; with regular buttons you could do many task just with touch.
What was even more surprising, to me, is that Mercedes had this amazing nice center console unit to control things with your arm in a rested position. They removed that piece of brilliance!
So, now you need to do everything with an outstretched arm in a moving vehicle to operate tiny buttons on a flat touch screen.
Oh, and the touch screen can only barely hit 60 frames per second and often feels much slower. They're even saving costs on GPU power in their fancy luxury cars.
color::hover { ... }
Protected names are commonplace in programming. And I'd argue it leads to better software development by causing less confusion.
If they make it too verbose I'll just stick with SCSS. Honestly, I love vanilla CSS, but nesting is a huge need; it's the only reason I use SCSS to begin with.
It is absolutely ridiculous. This guy was ripped off by a combination of wilful malice and sheer incompetence.
Anyone would be better helped by going onto a website like Fiverr with your pre-selected paid-for Bootstrap template and tasking a designer from India or Pakistan whose work you like with the simple one-price task: "Take this template and personalize it to my product."
The total costs shouldn't amount to more than $1000 to $2000, including taxes. And, honestly, you'd have a far better-looking result than... this thing. It looks like it was designed by amateurs, really.
I could set that entire page up in less than 3 hours. Easily. Responsive and all.
And you can respond to whatever they say with a thinking nod while stroking your chin. And street-kids would say "bet", you simply say "hmhm, very agile."
You'll be CEO in no-time.
Work goes faster if you keep it in small teams and let them self-organise.
When I see "full-stack" engineers do their thing in the front-end I almost always spend an outrageous amount of time on their pull requests. No semantics, unnecessary CSS, no accessibility features, not using the right tag for the job, not familiar with browser APIs, not familiar with cross-browser concerns, nesting tags that shouldn't be nested, not familiar with paint/composite/layout and other performance tools, using `grid` where they should use a `flex` and using 3 layers of nested `div` tags where zero would suffice.
If they suck this bad at the front-end, as a supposed "full-stack" dev, I can only imagine how little they also know of the back-end, let alone the operations side of things, not to mention testing, CI/CD, etc.
Hell, can I even trust them to sign off on PRs?
And that brings me to a topic that's entirely different but also very relevant: job interviews bring interviewer-biases with them.
If you run into an old-school interviewer who would do exactly that "Prius extends Car extends Vehicle, etc." nonsense, but you don't know it, they would rate you negatively.
If you run into someone who is just in love with functional programming, you'll lose any OO implementation.
If you run into someone who doesn't like it when you ask questions, you'll lose. If you run into someone who doesn't like you asking questions they don't know the answer to, you lose.
And if you get sent a 3-hour long Hackerrank or Leetcode algorithmic test, everybody loses.
Tech job interviews are just horribly biased and the game is won if you read your audience correctly. And even then, if the other person is a racist, or just doesn't like your face, or had a bad day, or feels threatened, or disapproves of how you write "Javascript" instead of "JavaScript", you still lose.
Copilot saves me from leaving my IDE for a large amount of situations. It saves me from opening a new tab (tab #1003) and Googling my problem, finding a solution on StackOverflow, scrolling down to the answers, curating the best answers, picking the one I like, copy/pasting it, then tailoring it to my liking (JS to TS, naming conventions, etc.) and testing it.
So I'm probably taking it.
I have two Russian Blue cats, they are smart, fun, playful, and they entertain one another. They are loving, cuddly, and empathic. The biggest benefit cats have over dogs (I also love dogs!) is that I don't have to walk my cats, they simply use the litter box and that's it.
My cats don't go outside because I think pets should be kept inside. Cats that go outside kill birds, they poop in gardens, they walk on cars with their sharp nails, and they get hit by motor vehicles quite a lot.
Keep your pets inside, and when you take them outside, put a leash on them.
When I find myself living in a more rural area (later in life) I will definitely want a dog, though. Without strangers around I would let it run in my enclosed yard without a leash, and it would serve as a guard dog, too.
Still, I'd say I prefer cats for the simple fact that they form their own opinions. Dogs (when raised as such) are typically overly friendly to pretty much everybody, and are easily bribed.
My cats do what they want to do, the dogs I've had in the past would do whatever I want to do and I just dislike that overly subservient behaviour.
Javelin missiles are just one thing, but cheap drones with simple rockets on them should be able to take out a moving force of numerous tanks.
Imagine having an arsenal of 20 tanks storming your city.
Now imagine having about 100 drones ordered from Amazon, outfitted with RKG-3 anti-tank grenades. One each. You can fly low, you can fly through the woods, and you can fly each individually operated drone right up to the top part of a tank, and boom.
No clever software automation. Just a drone that can lift something like 1 kg worth of anti-tank grenade.
You have 20 drone operators. You'll have 5 drones per tank. One after the other. Skip the already defeated tanks. Attack the tanks that will create a barrier when destroyed first, take natural barriers into account.
Your tanks can have all the power and shock and awe you might think they have, but any 12-year old will be able to take you out as if they were playing a video game.