Von_Broheim

joined 3 years ago
[–] Von_Broheim@programming.dev 1 points 1 month ago

90% of the time the garbage spat out by AI agents takes longer to turn into respectable code than it'd take to code it by yourself. There's also the prompt black hole where by the time you've written a spec and prompt air tight enough for the bots to produce what you want, the effort is almost equivalent to doing the coding yourself and using the LLM just for boilerplate generation. But the benefit of having done it yourself is that you have developed a better understanding of the issue and have been able to make all the compromises and adjustments as you were working. Unlike with agent code where the whole thing was written purely based on your assumptions you made in the prompt and now you have to discover any issues those assumptions caused and rectify retrospectively. Overall not only is the agent generated code process less flexible, it is not any faster for anything that's not the simplest case, it will obfuscate bad design and assumptions in design, you will be less likely to catch mistakes or unwanted side effects, and you will overall have poorer understanding and intuition about the final solution.

[–] Von_Broheim@programming.dev 2 points 2 months ago

I wanted to use TheFuck on latest Linux Mint so I had to download the source and make some upgrades to make it work.

Another small project was a small app for extracting file differences between two folders, the idea was that I can mod games in windows, make a diff between vanilla and modded versions, then copy the diff onto my Linux machine and extract it into the game root installed there. Works great.

[–] Von_Broheim@programming.dev 1 points 1 year ago

There's no magic in lombok, they're just meta annotations for class generation, no different than having each end every class implement some very specific interface exactly the same way every time. It's for reducing copy pasting. Debugging it is not a problem, especially that you can see the generated classes in the library files. Spring on the other hand is a black box, because it does too much and has become very bloated over the years, the goal of Spring is not to avoid using new the point is simplifying dependency injection and composition. The most fried part is the transaction management imo, because it's too delicate in the way it has to be configured.

[–] Von_Broheim@programming.dev 1 points 1 year ago* (last edited 1 year ago)

I thought that the whole point of Lombok is that it's not reflection based, they explicitly refuse to use reflection as a design principle. Afaik lombok statically generates methods and classes at pre compile. That's why for example lombok does not support constructor inheritance or overloading.

[–] Von_Broheim@programming.dev 1 points 2 years ago* (last edited 2 years ago)

Last 2 job changes I told the recruiters my current company is not paying competitively and the annual raises are below inflation. Then we agreed on my expected salary range. They got back to me within a day or two with offers and both times I was signing a new contract within a week.

They respected my bluntness and aimed to meet my expectations. I'm in the UK and I find that outside the hipster businesses or blatant venture capital scam startups, in tech, people respect being to the point and honest.

Sadly both times my existing employers couldn't afford to meet my new salary range when I got the counter offers, I would've stayed if they matched or exceed.

I'm also honest and to the point when interviewing and my interview to offer ratio is about 1/3. The other times they find someone cheaper or they're one of those companies that expect a full stack senior dev at mid tier salary. I never got ghosted or declined, it was always that I asked for too much money and I declined the counter offer.

Also, never complain about your current job. Instead say what you want/expect and mention that you're not getting it in the current role. I find that recruiters and interviewers address these expectations very early in the process.

[–] Von_Broheim@programming.dev 26 points 2 years ago* (last edited 2 years ago) (2 children)

Yeah, that's great, until you need to conditionally compose a query. Suddenly your pre baked queries are not enough. So you either:

  • create your own shitty ORM based on string concatenation
  • create your own shitty ORM
  • or use a well supported ORM, those almost always support query composition and native queries

You write like it's ORM vs native. ORMs let you write native queries and execute them while also doing all the tedious work for you such as:

  • mapping results to model objects
  • SQL injection safety
  • query composition
  • connection builders
  • transaction management

So if you love native queries write native queries in an ORM which will do all the tedious shit for you.

[–] Von_Broheim@programming.dev 2 points 2 years ago (1 children)

Serverless will forever be stuck as a tech that's only good for majority async stuff because of cold boot speed, scaling costs, and general latency.

[–] Von_Broheim@programming.dev 4 points 2 years ago

I'm learning Scala, is that close enough?

[–] Von_Broheim@programming.dev 2 points 2 years ago (1 children)

Language absolutely is a marketable skill because most companies are looking to hire someone who can start working day one not someone they'll have to train for weeks or even months in a new language that heavily relies on some specific framework.

[–] Von_Broheim@programming.dev 17 points 2 years ago

Jira is a pain, slow, bloated, and ugly.

Trello okay is for student projects, too basic.

ClickUp was decent when I used it professionally, I still use it for personal project management.

Azure DevOps is baby's 1st JIRA, but somehow Microsoft made it worse in every way.

[–] Von_Broheim@programming.dev 2 points 2 years ago

I find that code written towards fulfilling some specific database design is usually a nightmare about 20minutes into the project. You end up with garbage semantics and interfaces because you're building an entire app for the sake of storing stuff in a database. It's an ass backwards approach to software development imo, software is about solving a human problem and data persistence is just one of the steps in the solution. Instead figure out what data your consumers need, then figure out what domain objects can be extracted from that, then plan how you will persist those domain objects. You'll end up with less boilerplate, better naming of entities and services and you'll also find that the words your team uses to talk to each other make sense to your business people not just your dba.

[–] Von_Broheim@programming.dev 1 points 2 years ago

Just do TDD instead

view more: next ›