black3r

you can keep them on a VPN and connect to that VPN yourself from anywhere, without exposing them to the possibility of anyone connecting to them directly from the internet.

the company I work for is literally pushing one new feature behind another, the whole product is a mess now thanks to it, all of the features just get developed, hyped by marketing team, and then abandoned and we work on new ones... the features we developed 2 years ago untouched are beaten by competition, nobody cares, cause only thing we care about is user acquisition...

and of course we have no long term plans and vision, cause we just jump on hype waves and if something is marketable we need to develop it ASAP without really thinking it through to get as much new users as possible...

I hate it here, the only reason why I haven't quit yet is I'm scared of finding a new job given the current state of job market.

I'm in Slovakia. We have 4 networks here and they basically have hidden non-compete agreements where no-one launches new tech for masses without at least one other providing it launching it too, sometimes they even coordinate the launch so that all 4 of them launch at the same time...

This same shit happened with launches of 5G NSA, eSIM, Apple Watch eSIM, RCS, and lots of other telco technologies...

At this point all the operators have 5G SA networks up and running for parts of Slovakia (Telekom even claims it covers 99% of Slovak population with 5G SA), but it's only available for business customers in private networks...

They all claim the same stupid reason for this - "most customer phones don't support it, and there are additional benefits for businesses"...

And there are rumors from all of them that they plan to launch it for regular customers by the end of this year...

I mean come on... In a fair market competition the first one to upgrade its network would launch first and heavily claim that they're the fastest innovator in marketing...

And when the network is up and running, why not open it up to regular people? And why it's always the same bullshit type of excuse that's basically trying to say "people don't want/need this"?

yes, and the fact that it runs a phone chip is the reason why it only has one 10Gbps USB-C port and the other only supports USB 2.0 speeds...

my first iPhone was the original SE (which was essentially iPhone 4 expanded to 16:9 screen) and I'd say it was the perfect size of a phone, the reason why I opted for a larger screen even though my hands are kinda small for a man is that website and application design has completely shifted towards those large screens and small screens are unusable (and for me this has been true since 2019 when I switched to a larger screen)

it is kinda annoying, but apparently the consensus of modern design includes both lots of useless horizontal margins (lots of them just for the sake of visible rounded corners) and lots of vertical space taken by ads (iPhone 17 is actually 19.5:9, not 16:9, so ads take less vertical space on such a screen)...

and after a few months of using a larger screen I learned how to use it with one hand so it is possible - I rest my phone on 4 fingers and use thumb to interact, I only use two hands when typing (well two thumbs, but whatever)... but I still agree that the bigger the phone the more I'm worried it will fall down from my hand when operating it with one hand... the Max versions of iPhone do seem too large for me...

> 3. End with one concrete next step.

I mean maybe I have ADHD idk i'm not diagnosed, I don't generally have issues understanding Claude's output (even though I do think it's unnecessarily verbose), but I think this one is a general good advice which Claude ignores for some reason, and is especially annoying during debugging sessions, where it asks for 3 outputs, I paste one for it to process while getting the others, and then it immediately forgets it wanted the 2 others, and starts cooking up some wrong conclusions...

commits are local, so they're okay to me, I draw the line at pushing them... I either want to check its work while it's working, or let it finish and then check it all at once -> if it splits it work into smaller commits its easier for me to review it before pushing than if it was just uncommitted hundreds (or thousands) of lines of code all across the codebase.

I never want Claude or any AI to post messages as myself..., if I'd wanted Claude to send a message to Slack, I'd want him to identify as Claude, or use some bot token, where it's clearly visible I'm not the one posting it (while I can still instruct Claude to say that the message was prompted by me).

Honestly, the worst thing about App Store rating system is that the ratings and reviews users see are country specific. So if you are in a small country and you try to use an app that is not really popular in your country, you see very few reviews, even if the app has thousands of reviews on the USA App Store.

Apps can only show you the Apple's dialog for rating three times a year. Many apps first show you their own popup/dialog asking stuff like "Do you like this app?" and only if you click "yes" there then they show you Apple's dialog. And they can show you their own dialog as many times as they like...

washing is okay but dropping it in a pool destroyed my charging port on iPhone 14... the phone kept working and was rechargeable wirelessly though...

my first apple watch (6th gen) died when I was using it on a water slide ending in a pool on a holiday... since then I'm wary of using it in water...

So much this. When coding I use my LLM to hone the code to perfection before sending it to review, including running AI reviews on it multiple times and fixing obvious bugs so that reviewers have less work to do. I also test all my code manually (LLM can be helpful by giving me a list of test scenarios to consider). When reviewing PRs I carefully read the AI reviewer output, consider which points are relevant, which are irrelevant and only post the relevant issues when requesting changes.

I have coworkers who routinely post PRs with comments stating "all tests green, ready to review" and then I actually start the application, test it manually and it doesn't work. And don't get me started on reviewers who post the raw AI output of their "reviewing skill" and then I have to read through 30 paragraphs of "findings" most of which are irrelevant (just today I got the "valuable" feedback of "View is @api_view(["POST"]); no test asserts GET/PUT/PATCH/DELETE → 405")...

How LLM usage affects your thinking process entirely depends on the workflow you use with them.

I can honestly say that while using LLM my thoughts are as sharp and as fast as they were before, if not sharper and faster. But my workflow is that I watch the LLM as it rips, have verbose output turned on so I also read Claude's thinking process (and lots of interesting information is hidden there).

This helps me learn new stuff I wouldn't think of. Helps me stop Claude if he's veering off track. Makes it easier to proofread what's Claude doing and why step-by-step and easier to spot any mistakes (because they often come from wrong assumptions you wouldn't see if you didn't see the thinking process).

If you just let your agent write thousands of lines of code, reviewing them is painful. If you also run multiple agents for multiple tasks at the same time, your focus is divided, so you aren't spending all your brain power on the task at hand.

I have one like that and so do my parents. But they're much less effective than classic split AC with an outside unit. A regular split can cool a bigger room to 24 even when it's 38 outside and is basically completely quiet. A portable AC cools down smaller rooms to ~27 when it's 38 outside and is noisy (50-60 dB).

It's not that expensive. There are other reasons why people can't install one in Europe than money. Mostly for people living in apartments. In an apartment building you need the approval of other apartment owners to "modify the building facade". And some people have terrible neighbors. Another thing that happens in Europe is that if the building is 100+ years old, it's facade may be protected as a "historic building" and then you need another approval from some bureaucrats which are responsible for protecting historic buildings. And of course if you're renting, you need to convince your landlord if you want a proper AC not a portable one.

my guess is that the outdoor AC unit reached its maximum working temperature...

since we're not that used to extreme heat in EU, units with max working temperatures of 45 degrees Celsius are pretty common and the air around the AC unit is warmer than regular outdoors air, doubly so if they're placed on the ground and the glass from the building reflects some additional heat from the sun.

the risk of this was broadcasted in our local news for home AC owners when the forecast reached 40, as lots of apartments have the AC on partly glass-encased balconies, or on walls facing direct sunlight...

the sentiment "AI couldn't code last year, but now I use it for everything!" rings true for me... but I didn't flip cause AI is now better than me... I flipped cause now I am faster with AI than without it...

A year ago the AI output was so bad that getting it up to my standards took more than writing it myself from scratch. And nowadays it is faster for me to start with AI output and iterate from there to reach quality submission.

The ninety-ninety[0] rule was a thing talked about 40 years ago, long before anyone thought of AI coding. AI can nowadays make the first 90% of the task very fast and good enough. The last 10% is still the hardest part of coding by far.

[0]: https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule

Majority of the things I've mentioned don't need QA. Improving performance of an existing code is fine as long as it passes the existing test suite. Dev tooling / Monitoring is for devs only. Unused code is unused, just needs review from another dev to confirm. Documentation is for devs only.

And I work on the backend in a smaller company these days. Our backend code doesn't pass through QA, we just write tests and another backend coder reviews the tests if new tests are written. QA only handles frontend.

I probably spend even more than 20% of my time away from the computer these days. AI is great for this. I task Claude with something and while it's working I have the time to think about next steps, I can take a walk outside, have a coffee, talk with coworkers about my ideas, ... I'm paid to think, not to sit behind a computer.

There are people who say it's better to have multiple claude code instances crunching different stuff at the same time, and using the waiting time to prompt up another one. This might result in opening up more PRs faster but in the end it's not more productive. Context switching takes time, it divides your attention so your work is more sloppy and less thought through, and driving your brain too much makes you tired which again results in more mistakes. Having to compensate for this negates the productivity gains by finishing more grunt work faster.

I love having no task assigned. Means I finally have time to do code maintenance. Upgrading dependencies, fixing bugs (there are always some), clearing TODOs left in code, improving performance, improving dev tooling or monitoring configuration, cleaning up unused code, improving documentation, ...

And the best part is that since it's not an assigned task, nobody is waiting for it, so I'm under zero pressure.

Sadly it doesn't happen that much as we're always pushing for more new features out.

We have 257 python dependencies in our production app (over half of them are direct dependencies). We don't have any upper bounds in our pyproject.toml and we just run `uv lock --upgrade` every 2 weeks through GH actions.

We have good test coverage so if anything breaks the tests fail + we have AI assisted review process for this -> when GH action creates the upgrade PR, an AI workflow uses a python script to list major and minor version updates, finds and links changelogs, summarizes them, and makes the risk factor analysis for each package based on how we use it in our codebase.

It's mostly painless and we don't have to deal with upgrading packages one-by-one, checking which packages are outdated, or having outdated packages. Very rarely something breaks in a way it can't be fixed in our code and we need to wait on a fix from the dependency author (maybe once a year?). And in the past 3 months only one such upgrade required some changes to our code, there were 18 major version bumps in that period.

I wish we could do this on the frontend as well (I'm a full stack dev), but we don't have enough tests on frontend for this to work safely. Tests on the backend are easier to write and are more important so I believe every codebase should have them. And if you do, you can just auto-upgrade everything.

It really is far easier than you'd think if you haven't tried.

Different countries use different definitions of what "small business" or "micro business" is. And people usually use their own local expectations they're used to. I'm not from the US and a company with 100 million revenue is far from a small business to me.

In EU where I'm from the micro/small/medium business sizes are tied to both employee count AND revenue. Micro is below 10 employees and below 2 million € revenue, Small is below 50 employees and below 10 million € revenue, Medium is below 250 employees and 50 million € revenue.

So if you had 100 million revenue you would be a large business even if you had less than ten people.

The difference with AI is that now generating AI slop is much faster than carefully crafted code. So companies began to prefer AI slop.

Also this doesn't just mean more disk space usage, but also longer local build times... for the app I'm working on `exporting to image` takes 71.5 seconds with containerd, without containerd it's 4.3s (the rest of the build takes ~180 seconds). And that's just a 5.76GB image.

Depends on the complexity of the task. That's what I tried to hint at by also mentioning college-level math. For the high-school level tasks yeah, couple of hours and I'd be as fast as I was in high school again. For the number in another base it could be as quick as less than 1 hour as again that's a simpler task than the other two.

For derivations/integrations it'd take more time. Less than what it took me to learn them in the first place, for sure. But still a lot more than 1 hour.

Cause I forgot how to "do them" in the first place, which is what the discussion was about in the first place. I still know the "theory" behind, so I can "figure it out" if needed without needing anyone to "instruct" me, or needing "classes" to learn how to do them. But essentially all the "practice" I had back then is forgotten.

And again the same goes for code and technology knowledge, which is what the discussion was about in the first place.

As a senior developer with 10+ years of experience I've already encountered situations where I needed knowledge I knew I had at some point, but already forgot. In my case as a backend developer working for the same company for 5+ years my favorite example is payments processing. There are tons of special/edge cases - e.g. how a failed recurring payment during a subscription is processed. That's something you set up once, then don't touch for years, and suddenly need to study again if a change is needed. How a subscription goes "past due", what you can do in that case, what your code actually does, how it reverts to correct state once a retried payment follows through, what options you offer a customer if his payment method expired and he wants to switch it, ...

And this is also a good example why "domain knowledge" and "code ownership" is a good thing in larger companies. Because under usual circumstances I don't have to deal with these, cause we have a dedicated person who's maintaining the payment-related code. I only fill in in urgent cases happening when he's on vacation.

And juniors designing stuff like this AI-first without properly thinking about all these cases won't learn all the edge cases this flow can contain. So if something goes wrong, you end up with nobody who has the "maintainer experience" for that code - you don't have the one person who is knowledgeable about that topic - everyone in your company is in the same spot as me - having to research the topics again to understand them enough to be able to debug the incident which happened.

What the actual fuck? Customers' expectations shouldn't matter at all if the things they expect is illegal.

And this is already a solved problem.

The city I live in (Bratislava, Slovakia) has some pedestrian-only zones in the "old town", and if you're in one of them, calling an Uber/Bolt forces you to pick a pickup spot where cars can go...

(arguably this still has issues with Uber/Bolt allowing you to choose bus stops as pickup spots, which is explicitly illegal - only buses can stop on bus stops, but it's still better than driving onto a road which does not allow cars in the first place).

EDIT: i mistakenly thought this was about driving on dedicated bike paths, idk why, but this is still a solved problem, the applications already allow to designate some roads as places which can't be picked as pickup/dropoff points...

> Knowledge comes basically from manual trial/error almost daily.

This is the important statement, although I'd swap the word "knowledge" for "experience" here. You can gain "knowledge" from books, but only trial & error will give you experience to know "which" knowledge to use in which situations.

And what's important about this in the context of working with AI is the "error" part.

You have to experience errors to become truly experienced. And part of the experience is to recognize when you're about to make an error - to avoid it.

AI-driven processes mess up our natural trial & error learning curve in multiple ways:

- the AI push forces us to ship features faster (cause if we don't, our competitors will), reviews are sloppier, we discover errors later on, the feedback loop gets longer...

- using AI to debug and fix errors means we spend less time understanding what the error was about, which means we learn less about how to avoid the error in the first place...

- AI itself sounds overly confident, so reading its outputs without previous experience you may be less likely to recognize when it's making an error, which makes it harder for you to recognize when you're making an error trusting it...

On the other hand, this last point I tried to make is also why I don't think avoiding AI completely is a good strategy. Whether we like it or not, AI is becoming a part of developer's workflow. And as such, we also need to learn the trial & error process of using AI - what makes AI make errors and how to prompt it to avoid that.

Multiplication is elementary school math which doesn't require any thinking and the learned approach is simple. You can't really compare the simple stuff that's taught to kids, like basic multiplication or riding a bike with stuff that requires domain-specific knowledge and experience.

Think more stuff like "find the angle of lines defined by (x-4y-1=0) and (x-y-2=0)", "write the number 2026 in base 7", "solve an equation sin^2(x) - sin(x) = 0".

I plucked these from our country's high school final exam from this year. Back when I was in high school, I did mine in 60 minutes without an error when the time limit is 150 minutes and I intuitively immediately knew how to approach each task since the moment I saw it. Also all needed formulas are supplied, you don't need to remember any of them.

I plucked these because for these I don't have the immediate "know how" now, I still understand the topics, and could solve them with enough time, but it would require some thinking and thus I would be slower at solving them than when I was in high school, even though I'm pretty sure I could still ace it in the 150 minute time limit.

But reality goes beyond high schoool... College-level math, like derivations/integrations, sums, algebraic proofs, is even harder and solving some of them could take me hours when I could do them in minutes when I was in college.

With code it's the same. I could solve simple Python/Pascal/C++ high school level tasks as fast or faster than when I was in high school, even if I didn't write any code for a couple of years. But we also had assembly class in college, and I would struggle at assembly if I had to code it now, 10+ years later, even though I didn't struggle with it back then.

For me AI mostly reduces time effort. AI types code faster than I do, looks up stuff on the internet faster than I do, debugs faster than I do, but doing those never required much "brain effort" from me.

What does require "brain effort" from me is making educated decisions. Mostly during planning to figure out which pros/cons of each possible approach are actually relevant for our situation - AI does this poorly, makes lots of wrong assumptions if you don't steer it correctly, and noticing these + correcting AI on them requires "brain effort" too. Then the part of code review where you think about what can go wrong. AI still sucks at figuring out edge cases. It doesn't "know" the entire codebase like I do, its context only has "the parts of codebase deemed relevant".

Before AI I could jump from 30 minutes of hard thinking into an hour of coding during which my brain essentially rested, before returning to hard thinking again. Nowadays those hour-long coding sessions turn into 5-10 minutes of watching AI do something.

So for me using AI doesn't "free up brain juice", it instead makes me use my "brain effort" more, and in a workplace environment gives me less time to rest and makes me more tired, cause nowadays bosses expect us to work faster + colleagues working faster means more review requests.