Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
mjr00
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
39 ms
·
541.
▲
by
mjr00
3y ago
This falls in the "you know that what you know isn't enough to build the thing" bucket, presumably. Even if you're a Rust expert, do you know how to manage game asset content pipelines? Sound and music? Have you done gra
542.
▲
by
mjr00
3y ago
In my experience, fundamentally when you're starting a software project, you need to make a strong up-front decision between two things: 1. I am using technology in order to build this thing. 2. I am building this thing in order to use
543.
▲
by
mjr00
3y ago
Well yes, if you start adding "best practices" that only apply to larger companies with threat models that are completely nonapplicable to your 0-revenue, 2-request/sec startup, you are going to have to pay more money. Adding
544.
▲
by
mjr00
3y ago
> Hell, I would argue that a lot of services at established companies don't actually need to worry about it (and the ones that do, need to worry about it a lot). Tons of stuff inside of $megacorps is running on crummy "non-scal
545.
▲
by
mjr00
3y ago
Most don't, but you can get a t3.micro RDS database and EC2 instance for less than $20/month, to service those two requests per second you're getting. I would assume most startup founders in the US can afford this. If they ca
546.
▲
by
mjr00
3y ago
I kind of agree with the premise, which is essentially "don't overcomplicate things at the beginning" but the article seems to keep conflating requirements. Does your company have a 10-person devops team or are you a solo ent
547.
▲
by
mjr00
3y ago
> I don’t use an IDE, so code completion or whatever you get for it doesn’t apply to me. This is a reasonable take if you're a solo developer working without an IDE. Though I suspect you'd still find a few missing None checks w
548.
▲
by
mjr00
3y ago
> Pay is not status. Software currently pays quite well, but in most companies today a developer is at the very bottom of the status curve. This is your own perspective, and again, it's extremely warped. If you think developers are
549.
▲
by
mjr00
3y ago
> Doctor, lawyer, and athlete are "jock" professions, while software engineering is very much a "nerd" profession. These words represent status and general level of attractiveness and therefore access to attention and
550.
▲
by
mjr00
3y ago
> Reddit is kinda trash these days... it's just full of idiots Reddit is the same as it always has been, but once a social media network reaches a certain scale, you can't really deal with the problems in the same way, or any w
551.
▲
by
mjr00
3y ago
Refactoring and related maintenance activities, like library/framework upgrades, are high risk and low immediate reward. In my experience, they're also one of the hardest overall software development tasks; large-scale refactors w
552.
▲
by
mjr00
3y ago
> Moderately dense development - good > High rise developments enclosed in glass - bad Can you explain why you think this?
553.
▲
by
mjr00
3y ago
This development is being built on the waterfront across False Creek from downtown; it is prime real estate. Given that + being brand new, units will sell far above the Vancouver average. As a guess, studio units in this complex will star
554.
▲
by
mjr00
3y ago
Fracturing happens for any popular, long-lived programming language. It's really no worse than C++, JavaScript, or Java which all have their own idiosyncracies you have to learn if you want to use the language. Use cases evolve over ti
555.
▲
by
mjr00
3y ago
> Some changes are better than others. If your product works in python/MySQL then rust probably isn't a good fit. Maybe Ruby or PostgresSQL would be better fits. [...] Rust and Python are both great tools, but it is never okay
556.
▲
by
mjr00
3y ago
> Did this person get rewarded for this huge effort they put in? You say they already have prodigious yearly compensation, was it at least doubled given that they saved it several times over? When you're getting paid $500k-$1m/
557.
▲
by
mjr00
3y ago
Depends on the nature of your oncall. If your oncall is just following documented restart procedures when your app gets stuck, you won't learn much. If your oncall involves deep investigation into your system and how it interacts with
558.
▲
by
mjr00
3y ago
> Sometimes those veteran teams are heavily invested in existing concepts, tools, and approaches. It makes sense, they have seen these things work and they're proven to some extent. This is very closely related to why these veteran
559.
▲
by
mjr00
3y ago
uh, no, I don't agree with your point. Your example is turning a bugfix into a breaking change by describing the implementation details of a method its documentation, which becomes inaccurate after changing the implementation. Good dev
560.
▲
by
mjr00
3y ago
There's often a reason that you want to encapsulate details of the behavior in a library. What if the definition of valid changes in the future and you need to adjust isValid() to also return false if the data matches some other criter
561.
▲
by
mjr00
3y ago
> Really? You don't think it's a matter of updating the prompt and expanding the context to include more of the code? AI isn't magic. If the "why" isn't in the code, there's no way for it to magically s
562.
▲
by
mjr00
3y ago
Part of being senior is having enough business context to know when to pull late nights and weekends. If you're doing it because the gantt chart some PM created 18 months ago said project X would be done by next month but everything
563.
▲
by
mjr00
3y ago
> it seems to be a proven technology now. Proven to do what exactly? A solution for which problems? Cryptocurrency had billions invested into it and the most valuable product that came out of it was cartoon apes. There's not a sin
564.
▲
by
mjr00
3y ago
Okay. How, specifically, does AI help with any of that?
565.
▲
by
mjr00
3y ago
> At the very least AI can be used to speed up all the paperwork that doctors have to complete. How much do you know about the healthcare/medical system? Where specifically in the process would AI be used to speed up paperwork?
566.
▲
by
mjr00
3y ago
It's much easier to make smaller scope changes at higher frequency than it is to make large changes at lower frequency. This is the entire reason the software industry adopted CI/CD
567.
▲
by
mjr00
3y ago
> You never have the problem of "how do we update the version of Node on 50 microservices?" And instead you have the problem of "how do we update the version of Node on our 10 million LOC codebase?" Which is, in my ex
568.
▲
by
mjr00
3y ago
> I mean, yes, but also management is a wayyy less skilled job that’s far easier to automate. This is a pretty wild take. The job that is 99% dealing with human interactions is easier to automate than the job where you make a computer do
569.
▲
by
mjr00
3y ago
It's easy to imagine because it already happened in the mid-late 00s with the first attempt at software dev cost reduction when companies tried outsourcing to cheap, underqualified labor in India, Bangladesh, etc. Being the person who
570.
▲
by
mjr00
3y ago
yep. People vastly underestimate how difficult the logistics of "pay an employee for services" can be, particularly when you don't have a legal corporate presence in the country where the employee resides. There are services
More ›