I don't think you and he are in disagreement. Obviously you should do what will give your business an advantage. He is just saying that it is easy to think that certain new technologies will give you an advantage, but then realize later that what they cost you in bugs/complexity/maintainability etc. make it not worth it for the business. So it's usually better to go with tech that is tried and tested rather than always reaching for the latest new thing.
You're talking about two different things. "Technology" in the phrase "don't be seduced by the technology" means, the tech used to build your product. Not the technology of your product itself. Obviously you should innovate when making your product itself, but the tools used to make the product don't need to be bleeding edge for you to do that.
E.g. if you make a website, it should be a unique and engaging website. But you can make a unique and engaging website with Java. Even though it's old tech, your users will not know or care.
This also applies to performance. Nobody cares that the system is nightmarishly slow in bureaucratic corporations where even the simplest software projects take 6 months minimum.
I disagree with the sentiment that because you can study without a laptop, giving the students laptops is pointless. There is a lot of value in becoming familiar with modern technology and learning computer-related skills.
> I was talking online about how much I delegate to my team and I got responses along the lines of "the tech lead or manager should do all of that, why should I be doing their job."
Well, that's because there's a difference between autonomy (e.g. "I'm going to let you approach the task in your own way without micromanaging your efforts.") and responsibility (e.g. "Your job is to do X and Y and Z"). What most people want from their leaders is some degree of autonomy, not necessarily extra responsibilities (unless there's a promotion attached...)
The commenter you're replying to is simply showing how logging and context and other things can be done in conjunction with the question mark syntax sugar. If you don't want to use the question mark at all, you're still free to explicitly pattern match on the Result object and do whatever complex thing you want with the error object before returning it.
All you're arguing, then, is that regardless of whether you use error values or exceptions, you need to write good error messages. Hmm, okay. I agree with you on that. But I don't see how that counts against exceptions. Do you think the error message of an exception cannot contain filenames and variable values? And even in cases where they don't (e.g. you're depending on an external library with poor error messages), do you think it's impossible to add context to an exception's error message after it's been raised?
Also, the performance argument counts against your point, not for it. Exceptions rarely happen (when used properly), and when they are not raised, they cost nothing. Whereas go-style errors require explicit checks every single time you execute an operation which can fail.
One could say the same about plenty of awful programming languages.
If the blog post was titled "Go is unusable in production" then sure, he'd be wrong. But he's simply criticizing the language design. (Mostly, I might add, in the hopes that it will someday improve; the author writes Go professionally, he's not just some random hater.)
It's much simpler than that. The utility provided by arbitrage is that a given security is no longer under- or over-priced in one market relative to other markets. Any buyer/seller of that security will then always be buying/selling for the best available price (rather than losing out on money by not buying/selling in a different market).
The price discrepancy which was corrected by arbitrage is, itself, the compensation the arbitrageur receives. If it weren't, that inherently also means that there still exists a price discrepancy, and thus an arbitrage opportunity.
This is all separate from the question of public policy. Should taxes on income from arbitrage be increased? Perhaps they should. Though that doesn't affect the mechanics of how arbitrage works, it simply decreases the net profit of the firm doing the arbitrage.
Conceivably, you could increase the taxes/regulations/restrictions on such firms to such a degree that they are either no longer allowed to perform arbitrage at all and/or can no longer justify the cost of the high-speed equipment involved. The end result of this would be that the markets become less efficient (there would be greater price discrepancies and they would arise more frequently).
How much does that matter? Well, that's more of a philosophical question. How much does it matter to you that you're buying something for the best possible price (versus knowing it might be available cheaper elsewhere)? Depends on the person.
For anyone else who was struggling to make the leap year work with all the other math: 0 is a leap year.
For anyone else struggling with how to make the country name work with roman numerals or element names, you can lowercase the country name then it doesn't count as a roman numeral nor element.
If your chess move is illegal, make sure you're also notating the effect of the move (Nxe6 for N captures on e6, not just Ne6. Ne6+ if it's a check. Ne6# if it's mate.)
Spaces are also allowed so feel free to break up parts of the password to separate things and prevent them from interfering with each other.
Use XXXV as the roman numeral. Easiest to work with since only V (23) is an element.
Reroll your color if its hex has any numbers in it. You'll thank me later.
I made it to the final challenge (password must contain the current time) and it became extremely difficult because the current time, the length of the password itself, and a pesky 9 that was in my youtube URL were just too much to add up to 25 (even though I tried to overlap things, like 3:383 to cover 3:38 current time as well as 383 prime password length). I would've needed to somehow reupload a video that didn't have any digits in it (or at least one that had a lower digit like 1 or 2) or wait until it was 10:00 pm or something.
Everyone you consider "great" at something had mentors who helped them get there. One of the biggest differences between me now, and me when I was new to software engineering, is that now I ask a lot more questions.
When I was new, I was insecure about seeming like I didn't know certain things and wanted to "prove myself", so to speak, so I would keep my head down and try to figure things out for myself.
Over time I've realized that leaning on others with more expertise than you is how you learn and grow, and asking questions and collaborating with others does not reflect poorly on you as an engineer (quite the opposite in fact).
These realizations are what have boosted my confidence - I know that if I'm ever working on something that I don't know how to do, I can go talk to someone who does know and learn something new. If you don't work somewhere where this is possible (i.e. you're always the "smartest guy in the room", as they say) then your growth as an engineer is going to be limited.
Another day, another blog post by someone who misunderstands the purpose of unit tests and mocks, probably because they've never worked in a huge codebase with complex business logic and lots of precise edge cases.
Testing against real services (probably in some kind of staging environment) is mandatory, IMO, but it is only really useful for verifying the happy path, or some simple failure modes. Unit tests can verify the system's logic is correct in the face of complex edge cases that are difficult to replicate in integration or end-to-end testing.
Unit tests also allow you to add new functionality to the codebase with confidence, as you can know that your modifications did not break some specific edge case or cause some bug regression. If you're in a dynamic language they also help ensure your refactoring did not introduce some type mismatch somewhere.
Which is why I draw the conclusion that anyone who thinks unit testing and mocking boils down to `response = "derp"; assert response == "derp"`, must not have much experience working in such codebases.
You state unit tests and mocks do not catch all bugs. I absolutely agree with you.
But the answer is not, to not do it at all. The answer is to test in multiple ways. Unit, integration, E2E, manual - how much of each you need depends on what kind of system you're building.
I'd be curious how the output of your approach compares to merely classifying based on what keywords are contained in the text (given that AFAICT you're simply categorizing rather than trying to extract precise meaning).
People who say this are never able to produce a single actual search query for which Google returns acceptable results but other engines do not. Perhaps you can be the exception.
The business model makes perfect sense to me. This is essentially a modernized version of what most big companies are already doing to shore up engineering needs at low cost (they will go to some overseas consulting company and say "hey we need X devs with Y skills, we can pay them Z per hour. project will last T months.").
Because Scala 3, as great as it is, has fractured the community and caused a lot of churn.
Twice, just in my recent job history, have I worked for companies that were using Scala 2 for a long time but are now deciding to develop new projects in Java and/or Kotlin instead.
I also cannot understand how people develop that way.
That being said, better workflows do exist. I imagine IDE-integrated LLM tools like Copilot and CodeGPT are much more productivity-enhancing than copy-pasting code between a browser and an editor.
Citation needed? I'm unfamiliar with what metric or data you could be referring to in order to conclude that the US is the worst country in the West for prisoner mistreatment.
No, "lack of good tooling" is a completely different argument.
The argument put forth by the comment I replied to is that there is basically no point learning a new language, because to work with existing code you still have to know the old language.
Which I think is a massive fallacy. Yes, Kotlin programmers still have to understand Java to be effective. That doesn't make Kotlin useless.
I got the question wrong because I misunderstood the options. I interpreted them as:
1. Linda is a bank teller and is not active in the feminist movement.
2. Linda is a bank teller and is active in the feminist movement.
If these were the options, then it's entirely possible for option 1 to be less likely than option 2. But the options are actually:
1. Either Linda is a bank teller and active in the feminist movement, or Linda is a bank teller and not active in the feminist movement.
2. Linda is a bank teller and is active in the feminist movement.
Framed this way, anyone can clearly see that option 1 cannot possibly be less likely than option 2, since option 1 includes option 2 as a possibility.
Indeed, even the Wikipedia article describing this problem[1] illustrates this very misconception:
> I am particularly fond of this example [the Linda problem] because I know that the [conjoint] statement is least probable, yet a little homunculus in my head continues to jump up and down, shouting at me—"but she can't just be a bank teller; read the description." - Stephen J. Gould
That homunculus in Gould's head seems to have misread the statements in exactly the same way. Nowhere in statement 1 does it say she is "just" a bank teller. But that's how it naturally reads to most people when placed next to statement 2.
Do most people have a poor understanding of conditional probability? Yes, of course. But I don't really buy that this "Linda problem" illustrates that.
That tripped me up, too. I was often reading the prompt and confusing it for the evaluation criteria, when they are actually two separate things. The prompt stated the flag must be perfectly accurate, yes, but the evaluation criteria allowed the flag to not be quite right.
Well, you're right that most people don't care about fonts. But people do appreciate good design, and fonts are a big part of that. Similarly, most people don't know, or care about, anything related to music theory, yet people do appreciate good music. People don't care about color theory, but they appreciate good art. You get the drift.
Someone liking or disliking Comic Sans is just a matter of taste. Fonts are not design, they are just fonts. You can make a good design with Comic Sans, and you can make a bad design with the best font in the world.
"ability to make new stuff", ha! Let's actually see the new stuff, then I'll believe it.
I've seen too many first movers fail to differentiate themselves and eventually fall behind their competition to really believe that resources and talent alone constitute a viable moat.
Some would argue they can even be a hindrance, if they render the company complacent and risk-averse.
Guess it all depends on how you value your company's reputation versus short-term profits. I've personally worked on an API integration with such a company who delivered less than they'd promised. We certainly won't be building anything new in the future with their platform. And even this existing project will probably migrate away when feasible (though that, admittedly, will be quite a while from now, given how busy we are).
The company I worked for in college was in the "VBA for everything" world. It was like the Renaissance when they started experimenting with Power Query for some use cases. (Which, honestly, was still a terrible language. But slightly more maintainable than VBA.)
First thought that came to my mind as well when I read it. This failover system seems to be more designed to mitigate hardware failures than software bugs.
It's not enough to pass a data protection law, you have to actually give it teeth by investigating and suing the companies violating it. The EU has been doing this, California mostly has not.
