In the ideal world a specification file should be committed to the repository and then linked to the PR/commit. But it slows you down and is no longer a vibe coding?
Soon only implementation details will matter. Code can be generated based on those specifications again and again.
I agree, and am so captivated with the idea that I decided to build a whole toolkit around it. Would be very keen to get feedback if anyone wants to try it when it’s ready.
So far this workflow is the only way I’ve been able to have any real success running parallel agents or assigning longer running tasks that don’t get thrown out.
In the meantime, as you say, we’re now going through and evaluating other vendors for each component that CF provides - which is both unfortunate, and a frustrating use of time, as CF’s services “just worked” very well for a very long time.
I have many things dependent on Cloudflare. That makes me root for Cloudflare and I think I'm not the only one. Instead of finding better options we're getting stuck on an already failing HA solution. I wonder what caused this.
There are no alternatives, and those alternatives that did exist back in the day, had to shut down due to either going out of business or not being able to keep a paygo model.
Not everybody needs cloudflare, but those that need it and aren't major enterprises, have no other option.
Their WAF isn't there yet, the moment it can build the expressions you can build with CF (and allows you to have as much visibility into the traffic as CF does), then it might be a solid option, assuming they have the compute/network capacity.
L7 DDoS protection and global routing + CDN, there is not a single paygo provider that can handle the capacity CF can, especially not at this price range (mitigated attacks distributed from approximately 50-90k ips, adding up to about 300-700k rps).
We tried Stackpath, Imperva (Incapsula back in the day), etc but they were either too expensive or went out of business.
I would bet money that most people who use CF now are already hosting their endpoints at a single provider. I don't think most people care until it actually becomes enough of a problem.
There's a corollary to that question: why would China choose not to block Mullvad? We know every large nation with a capable online force maintains a fleet of ORBs, so maybe they consider Mullvad more useful for them as a functioning system?
Some of their own contractors may well depend on Mullvad. Perhaps as long as the overall "civilian" volume and user count remains acceptably low, the cost-benefit estimate may well be in favour of letting it slip by. (And for the civilians that do use a working variant, subject their connections to fine-grained traffic analysis.)
Photoshop was basically done at CS6 (which was less than 15 years ago), so why not? I know the copy I'm keeping around to avoid Adobe rent-seeking is eventually goong to stop working on new OS versions.
Worked with some of the teams making the first iPhone and bringing the Internet to everyone in a pocket sized slab was way more than a job it was a dream. Didn't turn out quite as expected, but this idea that work is only that is in my opinion dangerous. Millions are made selling sugar water and there is a famous multimillionaire with warehouses full of nickles, but business can be much more than that and it is up to all participants to build, man, and steer the boats.
> All joking aside, we fledgling mathematicians understood that the single most important thing was not raw intelligence or knowledge (Americans tend to lag behind in the latter compared to all international students). What mattered was passion. The way to become successful in mathematics, like almost every endeavor, is to care about it, to love it, to obsess over it.
This is the most important point from the article. My theory is that if you are not obsessed with something, you won’t be good enough with it, wether it’s a math, coding, business or something else… Thats how most of us got started in tech from the early ages.
It depends on what you mean by “good enough”. Most developers today aren’t particularly passionate about it, and certainly not obsessed, but the demand for them is high enough so they still are “good enough” to have relatively cushy jobs.
That's a good point, but it can also be that the employer is satisfied with the "good enough" results.
While it is true that the current high demand on a job market allows many to have "good enough" skills for employment, I would argue that passion, curiosity, and obsession are the driving forces that lead to better outcomes both for individuals and the industry as a whole. These qualities inspire deeper engagement and lead to more quality work. For routine tasks, basic competence might suffice. However, for solving complex problems, it won't...
Passion/curiosity/obsession often leads to voluntary, extensive practice and learning. This typically results in faster skill acquisition and a deeper understanding of the subject matter. While becoming competent without any of these is possible, the path is often slower and limited.
Also, both the tech industry and the job market are evolving rapidly. Passionate/curious/obsessed developers are more likely to keep up with new technologies and methodologies, potentially leading to better long-term career prospects and adaptability. The pace of change in our industry demands a continuous hunger for knowledge and a relentless pursuit of excellence.
In the end, if you don't want to be a mediocre developer with a mediocre career, such stuff matters.
Awesome! I love seeing kids play around with code. Curiosity is very important at any age.
That’s how I started too. Back in the days of Internet Explorer, I used to click View -> Source and mess around with the HTML in Notepad. I’d change the content, blocks, colors...
About 25 years later, I’m still coding, but right now I’m deploying the data transformation pipeline (T in the ELT) on production server to calculate business KPIs.
Very true. There’s a huge difference developing in a well known vs. new domain. My mantra is that you have to first be experienced in a domain to be able to craft a good solution.
Right now I am pouring most of my time in a fairly new domain, just to get an experience. I sit next to the domain experts (my decision) to quickly accumulate the needed knowledge.
Soon only implementation details will matter. Code can be generated based on those specifications again and again.
reply