Eogcloud

the opposite is true. Why would your age ever matter? just start, you could literally be learning right now instead of worrying about your age, it's not relevant.

That's not bad practice, it's a common and useful pattern. When people say functions are "first-class objects" in Python, it just means you can treat functions like any other value. You can assign them to variables, pass them to other functions, or store them in data structures like lists and dictionaries. Not all languages allow this. one clarification is that you're not actually storing the function itself in the dictionary. you're storing a *reference* to it (called a pointer). The function exists once in memory, and the dictionary just holds a way to find it. That's why you write `"start": start_game` without parentheses, with parentheses you'd be *calling* the function and storing its return value instead. Typical use cases: ```python # Command dispatch commands = { "start": start_game, "quit": quit_game, "help": show_help, } action = commands.get(user_input) if action: action() # Now we call it ``` ```python # Replacing long if/elif chains def handle_event(event_type, data): handlers = { "click": handle_click, "submit": handle_submit, "load": handle_load, } handler = handlers.get(event_type, handle_unknown) return handler(data) ``` This is cleaner than a sprawling if/elif block, easier to extend, and the mapping is explicit. You'll see this pattern in CLI tools, event systems, parsers, and state machines. The only things to watch for is to make sure the functions have compatible signatures if you're calling them uniformly, and don't over-complicate simple cases where a basic `if` would be fine

Your boss is wrong. To me it comes across as someone who's read or heard things they didn't quite understand, and his take reveals fundamental misunderstandings. Exceptions exist to deal with things entirely outside your control like network timeouts, files that don't exist, disks running out of space, permission denials, malformed external input, database connections dropping mid-query. No amount of careful programming prevents a user's network from failing mid-request, and you need a mechanism to handle that gracefully. There are legitimate critiques your boss MIGHT be poorly articulating. Using exceptions for control flow is genuinely bad practice, for example, catching a KeyError to check if something exists in a dictionary instead of just using .get(). Similarly, "Pokemon exception handling" (gotta catch 'em all) where you wrap code in a bare exception, is terrible because it swallows real bugs. In some architectural contexts, heavy exception use makes code harder to reason about since error paths aren't visible in function signatures. There are also languages that genuinely minimize exceptions by design. Rust and Haskell use Result/Either types that force you to handle errors explicitly. Go returns error values alongside results. These approaches make error handling visible in the type system, which is a real advantage. BUT in languages designed WITH exceptions, (Python, Java, C#, JavaScript) avoiding try-catch entirely means fighting the language itself. Your instincts are correct. Use try-catch properly, catch specific exceptions, catch at boundaries like API handlers or CLI entry points. let unexpected exceptions propagate and crash loudly, and don't catch anything you can't meaningfully handle. I'd ask your boss what they would do when a database connection fails mid-transaction, because "wRiTe cOdE wItHoUt eRrOrS" isn't a real answer.

I am not against illegal software, this take is laughable.

Fair, but they're very against any kind of software cracking, cos it falls under piracy so you'd be lumped in immediately with that and get nuked. They purgeds like all the torrent subs a while ago for example.

How is adove CC relevant to Linux gaming, in fairness?

Godspeed GOG!

Genuniely not your fault if you're able, as a junior dev to just log into prod on your own and run whatevery you like.

sigh Anthropic are hiring more than ever though. If you OWN the product that maqkes software engineering and humans obsolete, why are you paying for so many of them?

So a modern case that's gonna cost 3x cos RGB knobs?

You're conflating "a story involving AI" with "an AI success story." Those aren't the same thing. Yes, OP describes their coworker's skill repeatedly, that's MY point. The coworker is excellent. But you're ignoring the part you didn't bold: "whip cursor back into shape when it starts deviating." That's not AI succeeding. That's AI failing and a human fixing it in real-time. The productivity gain comes from someone skilled enough to catch and correct the mistakes faster than the mistakes slow them down. If the "success story" requires constant expert intervention to prevent the tool from producing bad output, then the success is the expert's skill at intervention, not the tool's capability. A calculator that gives wrong answers but works great for mathematicians who can spot the errors isn't a calculator success story, it's a story about mathematicians being good at math despite their broken calculator. The tool only generates net-positive value because of the human's expertise. That's the opposite of the tool being the source of success.

But that's exactly the point - he's not "supercharged by AI." He's supercharged by his 20 years of experience that lets him use AI without it tanking quality. You described him having to "whip cursor back into shape when it starts deviating." That's not the AI succeeding, that's him constantly course-correcting the AI's mistakes. The tool requires expert-level supervision to be useful. If a junior used the same AI, they'd ship broken code because they can't recognize when it hallucinates or suggests antipatterns. Your dev ships great code because he already knows what great code looks like. The AI is just faster autocomplete for someone who doesn't need it to be smart, he's already smart. The "supercharge" isn't coming from AI capabilities. It's coming from him being skilled enough to filter out the bad suggestions in real-time. That's a fundamentally different thing than AI being the source of the productivity gain. I'm not saying AI isn't useful, clearly it is for him. But calling this an AI success story misses that the success requires the exact expertise people worry AI might replace. The tool only works because he's irreplaceable.

Successfully incorporated a tool? so has everyone with a linter installed. That isn't a valid metric of anything. OP's whole post is "our senior dev is good because they have enough experience to fix the AI when it screws up." That's not an AI win, that's just... a senior dev being senior. If you still need 20 years of experience to use the tool effectively, the tool isn't revolutionary. It's another thing experienced people can leverage. A junior with the same AI would ship garbage. The senior ships gold. The difference is the human, not the AI.

That's not an AI success story. That's experince and hard work over a long time. That's why he was your best dev before AI too.....

Sell the old tech super overpriced to the peasnts for pocket money, save all the modern stuff for the billionaires so they control you!

Using and llm to write your hiring post for Reddit, to hire someone in c-suite is…..interesting

What do you mean "replace"? Do you mean more market share? Do you mean windows goes to 0%? It's hard to answer the question with a clear definition, but answering more generally, you are at this moment living through the most amount of people switching to desktop Linux than has happened ever before due to the enshitification of windows. on the gaming side, valve have been a huge part of this.

The point he’s making is the context doesn’t matter, your outlook fundamentally does. He’s trying to tell explain that the only way out is to not try to compete.

I hadn’t thought of that complexity, it’s a great point!

This is good advice that I also should take on baord!

IF I SAY SORRY IN ALL CAPS MAYBE THAT CANCELS IT OUT!?

I posted what a micro front end was, because you only sued the acronyms and half the posts were asking wtf an MFE is, it wasn’t for you. But yknow continue on your crusade and all, by all means.

As you can’t give useful answers to stupid questions.

So something you could’ve googled?

You can find examples of success/good stories from smaller organisations than those, too though. for example: https://medium.com/ing-blog/micro-front-end-architecture-rapid-development-in-a-startup-environment-10270dca1d5b So it's no exclusively about the org size, but you are correct that many of the success stories, do tend to come from the large/every large orgs in general.

If you read what I wrote carefully, you'll note that I'm pointing out that the premise of the question, is silly. you don't just "use" things because they exist, which is sort what I interpert OP is asking. MFE's are a niche solution to a niche problem, applying an abstraction that was been realtively successful in a backend context, to the front end instead. It comes with pros and cons, if "using it" means you only get all the cons and none of the pros, then it's fucking stupid. They aren't inherintly "bad" or "good", those are terms that are relative to YOUR CONTEXT.

Micro frontends, like microservices, are an architectural pattern that should be adopted to solve a specific set of scaling and complexity problems, not treated as a universal "best practice" or a default choice for every project. If you don't have these problems, then you're literallyt taking on baord all the bad and none of the good. THE BAD: - Requires a more complex container application, multiple independent build/deploy pipelines, and dynamic loading mechanisms. - Ensuring a consistent look, feel, and accessibility across modules built by autonomous teams is difficult without strict governance and robust shared component libraries. - Can lead to code duplication (e.g., loading multiple framework runtimes) and increased bundle sizes if dependency sharing and optimization are not meticulously managed. - Sharing data, state, or orchestrating complex user flows between different modules is more complicated than passing props in a monolith. - The initial architectural setup is significantly more time-consuming and requires specialized expertise compared to starting a standard SPA. so TL;DR Like everything, it's a big trade-off and your context has to have specific traits and problems, to get any benefit out of bothering to do this, as there are significant downsides also.

It's a fake reality creaed in these peoples heads, therough their own inherint ignorance and the crazy money and hype.

“How can I make my team despise me immediately”

The core problem is that management is optimizing for feature throughput without accounting for the cost of context-switching and the delay in feedback loops. Making that cost visible and proposing WIP limits are your best levers here, IMO. *Push back:* When asked to start new work while multiple features await testing, explicitly state the risk: "I have 3 PRs in testing. If bugs are found simultaneously, my capacity to fix them quickly will be severely limited." Frame this as a delivery risk, not a personal complaint. Management may not realize the compounding effect. *Limit work-in-progress:* Propose a WIP limit for yourself. "I won't start feature N+2 until feature N is fully merged." This creates backpressure that makes the bottleneck visible to management. If they override you, at least you've documented the concern. *Front-load quality: * Even without formal unit tests, you can be more rigorous. Spend extra time on manual testing before handoff. Write detailed test notes for QA showing what you verified. The goal is to reduce the discovery rate during QA testing, which reduces context-switching later. *Context documentation: * When handing off to QA, write extremely detailed notes: key decisions, edge cases you're aware of, areas of uncertainty. When bugs surface weeks later, this helps you reconstruct your thinking faster. *Ask about the regulations: * Are unit tests actually prohibited, or just not mandated? Sometimes "we don't do X" is cultural rather than legally required. If automated tests are permitted but not required, you could write them anyway to catch issues before QA.

the dependency still exists with option #2, you’ve just moved it. The billing domain still needs specific user data either way. The question is whether that dependency should be explicit or implicit. With the orchestrator, yes it’s another layer, but that layer is literally documenting what the billing domain needs from the user domain. That’s valuable information. With a shared repository, that dependency is hidden inside the implementation, you have to read the code to figure out what billing actually uses. On the “user domain needs to keep data it doesn’t need” point, that’s a feature, not a bug. If billing needs certain user data, then by definition the system as a whole needs that data. The user domain doesn’t get to unilaterally decide to stop tracking subscription tier just because it doesn’t personally use it anymore. That’s a cross-cutting business concern that requires coordination between teams/domains. The real issue you’re highlighting is about ownership and contracts. In proper DDD, if billing needs user data, there should be an explicit published interface or contract that the user domain maintains. The user team can’t just break that contract without coordination. The orchestrator makes this explicit, it calls a specific API that the user domain has committed to maintaining. With option #2, you’re saying “the repository’s job is to provide data to other domains” but whose repository is it? Who maintains it? If it’s owned by the user domain, you haven’t actually solved the problem, they can still change it and break billing. If it’s a separate shared thing, now you have a third domain that’s really just a distributed data access layer, which brings its own problems. I think the real answer is that cross-domain dependencies are inherently crap in any architecture. DDD doesn’t eliminate that, it makes it explicit and forces you to manage it deliberately through published interfaces and coordination between teams.​​​​​​​​​​​​​​​​ Not a magic bullet just a tried and tested method that people have had success with.

Pattern #1 is the proper DDD approach. Pattern #2 breaks bounded context isolation which is a core DDD principle. The problem with #2 is you’re sharing infrastructure between two domains that should be independent. Yeah it might seem convenient, but you’re creating hidden coupling. What happens when the user domain needs to change how it stores data? Now you have to worry about breaking the billing domain too. The whole point of bounded contexts is that each one can evolve independently. Pattern #1 works because you’re keeping the domains separate and doing the translation work in an application service or orchestration layer. The application service fetches data from the user domain, transforms it into whatever shape the billing domain expects, then hands it off. This is explicit and clear, so anyone reading the code can see exactly where the boundary crossing happens and what transformation is being done. In practice I’ve seen pattern #1 work much better for this reason. When you need to change how user data is structured, you update the transformation logic in one place. The billing domain doesn’t know or care about the user domain’s internal structure, and vice versa. There’s also a middle ground you might want to consider, putting an anti-corruption layer inside the billing domain itself instead of using a separate orchestrator. The billing domain would have its own adapter that calls out to the user domain and translates the response. This keeps all the billing-related logic including the translation within the billing context.

Genuinely no there isn’t any concrete proof anyone can point to other than hearsay and fuzzy anecdotal experiences. For anyone who’s telling you it’s great, they’re focusing on the times it works. When it doesn’t you go down oromot hell rabbit holes. And in many cases lose a lot of time. Now don’t get me wrong I’m lazy and use LLMs but I don’t think it’s a productivity gain in any kind of serious or profound way.

No, it's all fake.

I use LLMs a lot for this kind of work and the biggest mistake I see people use is actually bothering to use local tooling/agents all you need is copy/paste and the web interface, this seperation where it doesn't have direct access to your code is a feature, it prevents the scenario where you're basically allowing it to directly modify things. In my experience it's just not good enough to be able to do that effectively, it always requires massaging. In the web based chat you can do all that massaging, and you are the quality gate, you don't add or chnage what you don't like or approve of. I've found this to be the best process, that gets vbalue from the LLM but doesn't give up your agency or control over the repo itself.

This guys post history is full of objectively insane and bad takes just like this. 😂

Bruh fire these losers

Thank you that makes way more sense! Two hours struggling with a LeetCode problem doesn't say a damn thing about your worth or competence as a developer, especially not with 8 years of real experience under your belt. LeetCode-style problems are a very specific skill set, kind of like cardiovascular fitness. You could be a strong, seasoned powerlifter, but if you haven’t been jogging regularly, a 5k run is going to wreck you. Doesn’t mean you’re weak, just that it’s different. What makes it extra frustrating is that the industry treats these algorithm puzzles like some universal measure of engineering talent, when in reality, you can grind them to death, get good at passing interviews, and still be pretty useless on the job. It's a game, and like any game, it rewards practice, not necessarily insight or real-world problem-solving ability. So don’t conflate the pain of the moment with “I suck.” You don’t. You’re just doing an activity you haven’t trained for recently, That’s all. I would also have bombed that question without a couple of weeks of daily practice leading up to the challenge.

Echoing everyone else it sounds like you're depressed. "So I started this challenge on coderbyte of given an array of integers, the first position is the total number of desks and the next integers are the desk positions that are occupied. And then need to return the possible desk combinations for assignment." I have 10 years experience and I don't even comprehend what this challenge is asking. Why would you store the total number "IN" the same array? Why is it an integer array when the other positions only indicate binary state? (occupied or not) possible desk combinations for assignment? assignment of what? you just have indexes (the desk id) and someone is either at it or not? shouldn't this just be an array of booleans where the index is the desk id, the value is the if its occupied or not? the array count/size is the number of desks and the solution is just to return all the false indices? the question sounds dumb as fuck, it doesn't even make sense in its premise to me.

But the rest of us have to read you whining about it over multiple comments?

“ I’m the big boss but nothing is my responsibility and nothing is my fault”

What about talking to your employees, managing and doing your job? Oh right you’re a CEO who’s more useless at your job than they are at theirs.

What you're describing isn’t really a problem with AI, it’s a problem with how you’re choosing to use it. The core issue here is passive dependency. Tools like ChatGPT or Gemini aren’t designed to think for you, they’re designed to assist you while you think. If you’ve reached a point where you can’t code without an AI tool holding your hand, that’s not because the AI stole your skills, it’s because you stopped doing the hard parts yourself. That’s a discipline issue, not a tech one. Learning to program takes active engagement, struggling, debugging, understanding why something works, and making mistakes. If you skip all that by outsourcing the thinking, of course your skills will atrophy. Reframe how you use AI, not to do the work, but to support your effort to get better.

get out now while you can.

There are no silver bullets. It's unfortuntaely not as simple as picking a process and then go for it. These are all just abstractions and mechanisms to organise people and work, in groups. There's a million variations of each. As /u/gfivksiausuwjtjtnv said, the actual people and their experience and charecteristics is probably why more important that what "flavour" of "how to run and organise", that's picked.

Yeah this is why it feel exploitative and unfair to me, it’s always work that gets thrown away too

Spend an hour extra with them, pairing, instead of making them do unpaid work on their own free time, and you could have the same outcome. Is it a red herring, to think the fact that they did it alone without you is why you get good outcomes, no?

Man, take-home assignments in interviews are pretty much the worst. Seriously, how are you supposed to know if the person actually did the work themselves? They could have just copy-pasted some open-source project, gotten a buddy to help, or even paid someone to crank it out. At that point, you’re just guessing whether they actually know their stuff or can barely spell C# without Google. And don’t even get me started on the time commitment. One person might plow through your toy problem in two hours, slap together the bare minimum, and call it a day. Another might obsess over every detail for twenty hours, tweaking tests and edge cases. Which one do you hire? The over-engineer who can’t ship features, or the speed demon who leaves your codebase full of holes? Without any clear time guidelines or checkpoints, you’ve got zero clue about their working style. Honestly, demanding all that free labor screams “we have no idea how to interview.” If your team had better structured live coding sessions or behavioral questions, you wouldn’t need to make people bust their asses at home. It’s a huge red flag when a company leans so hard on take-homes—especially for folks juggling full-time jobs or family responsibilities. It just feels like you’re saying, “Hey, do our work for free, and maybe we’ll give you a job.” Instead, try pairing up for a quick 45-minute session, run through a targeted whiteboard challenge, or do a mini project together in real time. You’ll get authentic insight into someone’s skills—and you won’t burn bridges by trampling over people’s time and trust. It has always felt like a bottom feeder recruitment behaviour to me, I hate it.

I think people overthink this a lot. I did the switch last year from kotlin/boot to C#/.net small adjument period for sure but it's pretty much all the exact same shit with different branding and names.

this is not a recruitment subreddit, how about you go elsewhere?