HN user
it depends, I noticed that many engineers will input information on a slide following their thought process closely, they rarely think about the audience's perspective, especially if the audience is less technical or not familiar with the domain.
Sure mate, because taking a messy list of confusing statements and turning it into something like: "High risk of failure on re-entry - foam strike more than 600 times bigger than test data - test data unfit to support decision as flight condition is significantly outside of test database" requires a PhD in Materials Science.
If you can't effectively communicate how the results (or lack of results) of your research will impact the outcome of a high-stakes space mission you have no business being in that room from the start.
I can't remember the last time I saw a slide as mangled as the one in the article. It hurts my brain just reading it.
But you are right, most engineers would consider that reasonable, while complaining about the "muggles" that just don't get it.
As a Software Architect, one of my main responsibilities has been to take information presented like above and turn it into something that non-technical people can digest.
Being able to express a complex concept in simple terms is an invaluable skill.
Pretty sure it means that Ruby isn't the bottleneck for your case.
In most WebApps the first performance bottleneck people tend to hit is the DB: missing indexes, n+1 queries, etc.
The magic of cloud is how quickly you can scale things up. If you're a new fast growing business it will give you a competitive edge.
If you drank to cloud kool-aid from the beginning you kind of get used to huge costs for simple services so it's easier for your brain to justify paying 10k a month for a simple web app deployed in kubernetes, using cosmos db and any other number of services.
I've seen many companies that started on the cloud and their core architecture is so interleaved with the cloud that it would a huge investment to reduce that dependency and switch.
Cloud providers will always make their in-house offerings more attractive and easier to use compared to other (open standards) solutions. That's how you get locked in.
Just another example that a free market does not always ensure healthy competition and some times intervention is needed to level the playing field.
I don't think Google is afraid LLMs will "fix" all its issues. I think they're more afraid that their seemingly unassailable moat is suddenly exposed to disruption.
People use search engines to find answers to questions. If ChatGPT can give an answer faster and in a more natural format then people will flock to it. Most won't care that the quality of the response is as low or lower than what a search engine returns.
"Making fiction become fact" - the dream of many present day entrepreneurs.
Sure, this helps by removing some of the bias, if done right. But many times devs end up perverting the original intent of the framework.
Eg: I've seen many scrum teams transforming story ponts into days or vice versa missing the actual purpose.
The people getting paid salaries to have a bird's eye view and veto power over those kinds of changes that could screw with my deliverable should be the ones knowledgeable and accountable for that estimate
But they are accountable to their stakeholders (clients, upper management, etc). They take your estimate and many others from other people in the team and work those into a delivery plan.
A good manager will know how to manage risks and remove blockers in a way that gives a developer the best chance to work within the estimate. A bad manager will usually have no plan and put all the blame on the developers if things go awry.
I expect a plumber to give me an estimate of time and cost for his "tasks" before starting work. Even if he doesn't tell me the exact cost upfront he'll still be able to tell me roughly if he'll be done in 2-3 hours or less/more.
If I have a big project and I'm dealing with a plumbing company I might not be talking directly to the plumbers but to their manager. The manager will usually ask for time/complexity estimates from his plumbers before sending me a quote. The manager will usually factor into the quote any risks plus the company's profit margin.
There's a lot of talk about agile, scrum, no-estimates and so on, but a big part of the software industry still works with time estimates and budgets communicated up front.
Management is punishing waitstaff by underpaying them and then blaming the customers for not tipping enough.
I hate tipping in general, but especially when it's expected or even demanded.
The fact that restaurants or any business relying on the practice use it as a reason to underpay their employees just pisses me off.
500 - the number of employees before your CEO becomes a political figure
1000 - the size of company when you’re at risk of losing accountability
From my own experience and other sources (https://news.ycombinator.com/item?id=35206141) those numbers seem too high. I've seen this happen 2 times in front of my eyes while both companies were in the 100-200 range.
One of them managed to go to the next level and adapt to the new reality the other is still struggling.
Not OP but this definitely rings a bell with me.
I started my career in a software agency, maybe I was unlucky, but in this particular agency I overheard the more senior employees staying after-hours and making fun of the the junior employees (in their absence) and the quality of the code they had wrote. There was no actual code review process but this memory had made me very defensive in regards to my code. I was always trying to push the perfect code in one shot, which led me to overthink solution, and if for whatever reason I had to push a rushed change I felt guilty and tried to find excuses preemptively.
At one time I had to onboard the client's new dev team to a project that I had built alone for about one year. The product had become successful so the client wanted to invest in rebuilding it on better foundations to prepare for accelerating its growth.
Working alone on the code for a year had subdued my fears of public shaming but, once I started going through it with a team of seniors looking over my shoulder, my anxiety went through the roof. For every new file I was opening I started my explanation with an apology about the quality of the code and tried to explain why I didn't have the time during implementation to write that code properly.
After the 2nd or 3rd explanation one of the new guys stopped me and said something like: "You don't have to explain yourself to us. This code is the result of the context it has been written in. We are only having this conversation because the product that you helped build by writing that code is successful. Because of this success we now have the chance to spend time and think about how we can improve the code".
I only realized later, but that was one of the most liberating things anyone has ever told me. It felt like a huge weight had just been lifted of my shoulders. People were looking at my code and discussing it not as a reflection of my quality as a person but as the output of different factors and priorities at a given point in time.
I worked with that team long enough to feel deconditioned from the previous toxic behavior.
did that before: running a single monolithic app inside a kubernetes cluster on a single pod. I still feel dirty after doing it.
My current hobby is to try and run monolithic apps like these on serverless services like cloud run. There's still some pain related to attaching persistent storage to a container but otherwise it feels like a great option.
I'm not an "on-premise bare-metal server absolutist". Of course there are trade offs in terms of convenience but there are also trade offs in terms of cost and performance and vendor lock-in. It all depends on what you need and what are your specific constraints.
Is time to market critical? Will you have daily traffic fluctuation between 10 to 10k users? Will you lose a ton of money/customers for any service interruption? By all means use the latest version of managed kubernetes combined with whatever other cloud service tickles those itches. But don't forget to always keep an eye on your bills and think how can you reduce them by simplifying your architecture.
But if you're just building a corporate intranet for a few dozen users who log in once a week I'm pretty sure a simple VM (even if managed in AWS) would make much more sense.
And if you really want to roll your own there are plenty of options to make your life much easier compared to sending a rocket into outer-space. Yes it's more work upfront but after you do the setup the first time there's little to do.
infra automation & templates: - ansible, docker, etc
log storage: - mount shared storage - ELK - use a paid LaaS or monitoring SaaS
certificate management (on LB machine only): - certbot
access controls: - linux user and groups management
patch management: - enable unattanded upgrades for security patches
health monitoring: - in terms of lb nginx has that built in. - for more advanced use cases use a paid service (new relic) or a free one (nagios)
remote administration: - ansible, etc.
Don't get me wrong I use cloud on a daily basis for work, I'm just sad because most teams don't know how to use it effectively without jumping the gun.
It’s not like you can pull people off the street and have them get away with infrastructure this simple
I know that in many cases simple != easy but I can't help feeling sad while reading this.
When I started my career cloud wasn't yet mainstream bu as a beginner I was able to deploy and configure a nginx proxy and loadbalance between 2-3 backend servers without too much effort. It wasn't some kind of rocket science.
I guess the current issue is that cloud has been marketed so much that nobody who's just starting out in the industry even has a second thought about using it by default. What can I say, great job from the cloud providers in capturing their customers as soon as they get in front of the store.
Agreed, but would most engineers understand that they can keep the simplicity of the solution if the underlying infrastructure is based in the cloud/serverless/etc?
Fro my limited experience many engineers fall in the trap of adding accidental complexity to an otherwise simple architecture just by trying to use the latest/coolest cloud architecture trend.
Monolith in the cloud on kubernetes? Speak no such abomination. Of course we have to do microservices, the more the better. How can we scale otherwise?
SQL DB? What is this, 2010? Of course we're going to use Cosmos DB, how else could we get "single-digit millisecond response times, automatic and instant scalability, along with guarantee speed at any scale".
Of course I'm exaggerating for dramatic effect but I rarely see teams disciplined enough to keep cloud architectures simple and clean.
Good point, for normal executives (whatever that means). In my little bubble most executives I have to deal with believe themselves to be on par with solution/enterprise architects and they like to show this by saying stuff like: "Let's use microservices and kubernetes for better scalability, everybody's doing it..."
Imagine trying to present this kind of architecture to a room full of executives already sold on the "benefits" of kubernetes, big data, serverless, etc.
What a funny perspective, thanks for the laugh. I'm sure there isn't anyone in Europe who enjoys cold water, most of them lost their lives or got deported to the US during the last Tepid Water war /jk.
The fact that you like very cold water and equate that to pleasure doesn't mean that everyone does the same. I don't enjoy cold water with ice in it but I do enjoy very cold beer. Does that mean I don't like comfort or pleasure?
Seems to me that pleasure is linked to personal preferences and also follows cultural lines (regional, national, ethnic, etc).
Funny story, somewhat similar to your ice-water tale. Went to Greece (Crete) on holiday and I couldn't get my hands on a fresh lemonade no matter what. Lemons were literally falling off trees on the side of the road but serving lemonade was just not part of the local culture. Their view was, why would I want to drink water mixed with lemon juice when I could have better things like fresh orange juice.
Does this mean that Cretans don't like pleasure? No, it just means that they find pleasure in different things.
Probably didn't pass the interview. The implementation was rather simplistic and low quality.
Here's a better enterprise version: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
Though the fact that it was written some years ago might be a weakness. Some interviewers might prefere a more modern, distributed solution.
What's interesting is that having a growth mindset also seems to reduce the levels of the stress hormone. So it has a direct influence on your physical well-being, not just the psychological one.
For those who get a 403, like me.
https://web.archive.org/web/20221111060921/https://www.lapha...
I'm curious what relatively slow means for you.
As an example I just made a quick test from my Firefox mobile browser in desktop mode and the switch between PR tabs is not instant but close enough to not be bothered by it.
Honestly github always felt snappy and intuitive to me, more so than many "cool" react fronts I've seen.
It would be great if they wrote an article about this switch to understand some of the challenges they were facing.
I would also be curious if they considered other approaches and stacks.
Ruby sucks in large codebases where conventions aren't well defined
The community is working to improve the outside-Rails ecosystem with efforts like dry-rb or ROM. So you can find plenty of useful non-Rails conventions if you look for them, but if you're doing typical web stuff it is hard to compete with the productivity monster that Rails has become.
I don't see any reason to pick Ruby over Typescript if you're not using a popular framework. Types save an incredible amount of time when you're ramping up.
I guess RBS and Sorbet are trying to cover this point. I don't know how well they scratch that particular itch of yours as I haven't worked with Ruby for quite some time.