HackerTrans
TopNewTrendsCommentsPastAskShowJobs

black3r

no profile record

comments

black3r
·11 hari yang lalu·discuss
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).
black3r
·11 hari yang lalu·discuss
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.
black3r
·11 hari yang lalu·discuss
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...
black3r
·28 hari yang lalu·discuss
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
black3r
·29 hari yang lalu·discuss
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.
black3r
·29 hari yang lalu·discuss
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.
black3r
·29 hari yang lalu·discuss
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.
black3r
·2 bulan yang lalu·discuss
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.
black3r
·2 bulan yang lalu·discuss
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.
black3r
·2 bulan yang lalu·discuss
The difference with AI is that now generating AI slop is much faster than carefully crafted code. So companies began to prefer AI slop.
black3r
·2 bulan yang lalu·discuss
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.
black3r
·3 bulan yang lalu·discuss
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.
black3r
·3 bulan yang lalu·discuss
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...
black3r
·3 bulan yang lalu·discuss
> 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.
black3r
·3 bulan yang lalu·discuss
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.
black3r
·3 bulan yang lalu·discuss
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.
black3r
·3 bulan yang lalu·discuss
I hear sentiments about farming from lots of burnout software developers.

I always wonder what made them become developers at all. Cause my primary motivation for selecting a job was that I explicitly didn't want to ever work manually, I knew that since early childhood and it still didn't change even after 2 burnouts. My secondary motivation was that I liked working with machinery/computers.

Also when I started coding, it immediately felt like my passion. And the thing I love most about coding is that mostly all changes I make have instantly visible results. I couldn't imagine working a job where I had to plant a seed and then wait a week to see if it sprouts.

Also what I love about development is that with modern Docker/Kubernetes setups you can make the environment where your code runs pretty predictable. And with proper backups configured and backup restore testing you aren't really worried about losing the stuff you worked on for months. Meanwhile while farming you can't predict how much sun is gonna shine or how much rain you're gonna get. And you can't prepare for natural disasters which can come anytime and ruin your crops.

So I wonder if it's all just people who never loved software engineering and just went into it for money, and now that they have money after years of working they start looking for their true passion.
black3r
·3 bulan yang lalu·discuss
that's basically how it already works...

extensions choose on which site they're active and if they provide any available assets (e.g. some extensions modify CSS of the website by injecting their CSS, so that asset is public and then any website where the extension is active can call fetch("chrome-extension://<extension_id>/whatever/file/needed.css" if it knows the extension ID (fixed for each extension) and the file path to such asset... if the fetch result is 404, it can assume the extension is not installed, if the result is 200 it can assume the extension is installed.

This is what LinkedIn is doing... they have their own database of extension IDs and a known working file path, and they are just calling these fetches... they have been doing it for years, I've noticed it a few years back when I was developing a chrome extension which also worked with LinkedIn, but back then it was less than 100 extensions scanned, so I just assumed they want to detect specific extensions which break their site or their terms of use... now it's apparently 6000+ extensions...
black3r
·5 bulan yang lalu·discuss
You can have decoupled Controllers from Views using React. That's the basis of the "original" Flux/Redux architecture used by React developers 10+ years ago when React was just beginning to get traction.

A flux/redux "Store" acts as a Model -> contains all the global state and exactly decides what gets rendered. A flux/redux "Dispatcher" acts as a Controller. And React "Components" (views) get their props from the "Store" and send "events" to "dispatcher", which in turn modifies the "Store" and forces a redraw.

Of course they aren't "entirely decoupled" because the view still has to call the controller functions, but the same controller action can be called from multiple views, and you can still design the architecture from Model, through Controller (which properties can change under what conditions) and then design the Views (where the interactions can happen).
black3r
·5 bulan yang lalu·discuss
in theory "maintenance mode" should mean that they still deal with security issues and "no longer maintained" that they don't even do that anymore...

unless a security issue is reported it does feel very much the same...