Hacker News Reader

Comment by CM30 | Hacker News Reader

Honestly, the truly 'smart' programmer isn't someone who does or doesn't use a bunch of techniques or best practices, it's the one who can look at the situation and do what's right for that particular project/job.

Most of the things in this post could be the right answer if the project is a weekend side project that's going to get a few hundred views a month, or a website for a small business. Bob's Restaurant doesn't need a Google scale website built with microservices, Docker and SPAs hosted on AWS and S3.

But something like Google or Amazon or Netflix would. Use the right tool for the right job.

Plus, even a 'stupid' or '0.05x' programmer can be a rockstar at a small company or organisation where a lot of complexity isn't required.

View on HN

Yeah, I read this post as a dig at "cargo cult" programmers who read up on google-scale programming and best practice and unthinkingly apply those constructs to their own Bob's-Restaurant-scale task at hand where they are often at best an unneeded time and complexity overhead.

I've worked in a number of projects where they decided to move to microservices for reasons they wish they had, while not fully understanding microservices or applying basic litmus tests to where to split off services.

So we ended up with great puzzles like how to link an order service with an inventory service to check if there's enough inventory to fulfill an order, all through a central event bus. Then of course the order service has to update the inventory if the order is confirmed. But of course, the order service also has to talk to the pricing service, and since the price of products varies by day, they'd have to remember the price at the time the order was made. Whose responsibility is that? No idea, that's someone else's service.

There is a youtube video for that https://www.youtube.com/watch?v=y8OnoxKotPQ

We had a dev in my last work pushing to microservice everything (small company, only a few developers). I could tell that it was going to cause more pain than it was going to solve. Plus, every service that you add makes setting up a development machine even more difficult.

Not to mention testing all of this. Its an absolute nightmare.

Replacing function calls with network calls is only going to make things more difficult.

Unfortunately it's not a popular belief anymore, but [asynchronous] central event bus is a terrible idea on it's own, and it goes against what [micro]services are about.

If you want microservices to work you shouldn't have anything central in them, and you should avoid async as much as possible.

That's not at all what I learned from working with microservices. The worst thing you can do is make sync calls between services, then you end up with high aggregate failure rates, and/or large request latency from retries as well as low uptime due to dependency couplings.

One-way async dataflows work much better. That way each microservice is up with all the (potentially delayed) data it needs to respond to requests.

If you have services with lots of dependencies on other services, then you probably ended up the worst of two worlds - distributed monolith.

Typically one-way or two-way is not a choice you can make as an engineer, most processes in your business require two-way, because they are initiated by a user and user wants a definitive response.

The "potentially delayed" approach is very tempting for engineers, but it should be exception rather than the rule.

- dilutes responsibilities between services (who is responsible for delays? is service A producing too many messages or is service B too slow to process them?)

- makes your SLA vague (message was processed 3 days later, do we treat it as downtime or not?)

- requires more infrastructure & processes (every service has a queue, dead-letter queue, and a process to deal with dead letters)

- requires a ton monitoring overhead (what delay is acceptable? how do we even measure delay? what if you have different SLA for different messages? we'll have a monitor per message type?)

- introduces a lot of unnecessary complexity and rules (how do you deal with TOCTOU, e.g. admin deactivates a user, but by the time the message gets processed he's no longer an admin)

- ruins user experience (we received your payment information, but we won't immediately tell you that it's wrong).

Despite it's downsides, potentially delayed approach can be a fine tradeoff when it saves you 7-8 digits per year. Most companies never reach this phase.

A lot of this depends on implementation and infrastructure which is of course an additional detail. In an example I'm recalling it was for a communications app that had services for content, users, groups, sending, and receiving. Sending a message would save content with an id, include user/group recipient ids and write to the send service with them. Each service if it accepts the request completes it unless the service is actually down. The user/group service seems like it could be a sync service, but actually the client caches a list of users/contacts or can search for them.

By abstracting content the only thing that needed to change for new types of content was the content service and clients. Abstracting recipients which can be users/groups, meant that the only service that needed to care about this detail was the one that replicates sent to inboxes in the receiving service. Because of the use of content ids and user/group ids, this is all small idempotent/immutable metadata. The system was complex (yet became manageable over time) and onboarding onto each service was immediate.

I think few have seen well-bounded microservices' contexts leading to the idea that it's a bad distributed monolith. Also worth remembering that advantages of microservices 'done right' is large scaling of developers and isolate failures.

> I've worked in a number of projects where they decided to move to microservices for reasons they wish they had

I've advised engineers to rewrite code before, mostly for resume building to help jumping ship to somewhere better. Basically, use the current job as a way to train on the stack the company you really want to work for is using.

If a company doesn't have a stock-based comp and sticks to prevailing wages/CoL there's no incentive to help the company succeed. Especially with non-technical management, the best thing to do for ICs is often to aggressively rewrite (in the language that's trendy right now and that better companies use) and get promoted by showing off a significant output. Then jump to a better company having spent a year training on their stack at the previous company's expenses.

It's unprofessional to do this in conflict with your company's interests. Use your own hobby projects to learn instead of leaving a maintenance project for your coworkers.

It also creates an invisible bias towards worse companies in your next position, because smart companies are wary about this kind of behavior, and will be savvy to filter out candidates that have displayed it.

> It's unprofessional to do this in conflict with your company's interests.

Great work happens at the intersection of employee's and company's interests!

Why not simply align the two? Compare the Xerox Alto with the Macintosh...

this might come as incredibly cynic for some, but illustrates an important point - languages/frameworks/whole marketed stacks like ELK are merely tools for you to accomplish the task, which in the end is either to reduce costs or increase revenue

so naturally it doesn't matter (in long term) what you should learn to get a first job, change jobs, change domains - prioritize ROI the tool would give you in future, a job market, and your sanity :)

This is a good point. The other side of the coin is that by not moving to a modern day stack, the company slowly finds it harder and harder to attract staff to maintain it. So, keeping up with trends is not just good for the ICs.

Well, they do what's right according to how they learned, which may only be a local 'right' and not a global 'right'. There's so many ways to put things together that you can make it work in a lot of different ways. It becomes more art than engineering or science. Then whether your peers accept whether it was the right thing is up to their preferences too.

All that comes down to the large variety of training everyone in the field gets, from university to youtube tutorials.

It's noisy out there

> It becomes more art than engineering or science.

The opposite.

> All that comes down to the large variety of training everyone in the field gets, from university to youtube tutorials.

A big problem is that a lot of the youtube/bootcamp ecosystem focusses on "teaching what they do at the FAANG" to lure people into thinking they could get a job there by enrolling/buying whatever training they are selling. And then these people repeat what they have been told are "the best practices".

Proper engineering degree teaches about gathering requirement and analyzing the problem space to understand what really needs to be done.

> Proper engineering degree teaches about gathering requirement and analyzing the problem space to understand what really needs to be done.

This. I don't even think you have to bring a degree into it, honestly. This is just at the heart of all engineering (software or otherwise).

>And then these people repeat what they have been told are "the best practices".

And then they get jobs which serve to validate their learning paths (maybe not at FAANG), which gives them confidence about what they learned being the right way to do things.

>Proper engineering degree teaches about gathering requirement and analyzing the problem space to understand what really needs to be done.

Well sure, but a lot of non-engineers do that too. Where's the real distinction at?

> Well sure, but a lot of non-engineers do that too. Where's the real distinction at?

A lot of non-lawyers can discuss law principles and explain laws pretty well; but someone who passed the bar I know for a fact are familiar with certain concepts.

Same for engineers.

That's a great point. Good engineering, from a distance, can look awfully like bad engineering from the point of view of a Youtuber or Blogger focused on trends.

There's also the fact that those complex solutions aren't engineered by a solo developer but by teams, typically even multiple teams each working on a compartmentalized piece of the whole thing.

That too. It's a lot easier to work on a complex project if you've got a large team working on it. Like the teams that the 10s of thousands of devs at your average FAANG company can staff.

Well, that and how most complex projects didn't start that way. A lot of the time, these things were built in a much simpler way, and dealing with increasing demand over the last decade or two caused them to balloon in complexity.

Id venture to say that as this is implemented in the authors post this could scale to many many thousands of QPS by just bumping VPS resources. Funnily a lot of these 'simple' techniques actually speed things up like writing to a local disk, or static binary.

Theres no High Availability so in the chance it went down theyd be screwed and have no failover but makes you wonder if its cheaper just to lose traffic for a few minutes while theyre upscaling VPS resources or pay for all the HA scaling stuff running around the clock.

That last point is key. I’m a fan of SaaS solutions but I also wonder if more organizations could unlock more value by just having a 1x programmer (with well defined _objectives_) on staff.

> I also wonder if more organizations could unlock more value by just having a 1x programmer

They probably already have such programmers. Actual 10x programmers are exceptionally rare. Having an entire team of them is extremely unlikely.

I think it depends on a situation where no problems occur. Often, once a problem arises, we (at least me) begin to reflect on why we didn't follow best practices initially.

OP makes the same mistake that those chaps who use Kubernetes to run an app with 10 lines of code: thinking that there is one right solution for every kind of problem.

OP's approach might work for a personal project or a small company, but when you need to work in a large and complex system you start to appreciate the beauty of tools like Docker.

It's cool to question cargo cult, but don't throw the baby with the bathwater.

I work at a very large company with very complicated systems. Fighting unnecessary complexity at every opportunity is the only way to keep things near comprehensible. A lot of the articles rules are even more important in complex environments.

Ive experienced this at work as well, even at a more modestly sized company.

You should always be chasing the simplest solution for your problem because no matter how smart you are today and how much you understand the problem and the abstractions, a year or two from now you’ll be a different person.

You might have new team members, or fewer, new management, marketing goals etc etc etc. Complexity is inherently difficult to change. My chasing simplicity, you are optimizing for potential change.

Me too, and I wouldn't apply most of OP rules to my day job. They just aren't a good fit. Sometimes using the right tool (e.g. Docker) actually decreases the overall complexity of the system, even if it raises it locally.

How would you host the Bob’s Restaurant website?

I never used them, but Neocities seem well worth of consideration for simple sites.

https://neocities.org/

Facebook seems to be the ultimate in simplicity for small restaurants. Has a number of advantages, like built in chat, picture hosting and a feed of posts.

You'd hit up GoDaddy for hosting and FTP your webpage files to it. And it'd work just as well as other website.

Yeah, this would be the way. This hypothetical restaurant would probably only need the following pages:

- Home page - About Us - Menu - [Maybe 1 or 2 info pages] - A contact page (with or without a form)

That's something that can be easily done with static HTML and CSS, and hosted on just about any random shared hosting service you can imagine. Assuming it doesn't become a major viral hit, it'd probably use a couple of megabytes of space on the hard drive and under a hundred megs of bandwidth.

Maybe up that number a tiny bit if Bob decides he wants to run a blog on the domain and you decide to just do the whole thing in WordPress or Drupal or whatever else.

Either way, a site that small could be built like its 1980 and it'd be perfectly fine.

I've made several "Bob's Restaurant" websites for clients. Early on I thought just that. "This can be statically implemented using the core web technologies HTML and CSS" - It wowed the client visually at first and they signed off on the product agreeing that the simple site was enough for them. Then the client wanted their Facebook, Google Maps, and Instagram integrated throughout the site over time. Now the site has JavaScript in its stack and external code running on it via APIs.

Early on the client wanted to make changes to the menu, and have a feed of events from their Google calendar. I implemented a Google Calendar feed script. Enter the world of dates in JS and learning how to use OAuth to hook into their feed. The client was getting confused as to why all this work had to be done for such simple little features and there was extra cost associated, and at the same time requested that they can CRUD menu items. I told them we need a CMS for that. They didn't like hearing the was more time and cost associated. By this time the statically implemented, elegantly designed Home | Menu | About site delivered the purpose of a visual mockup rather than a website that will help the business retain and add growth.

It could be said that this story is one of not planning and getting the spec right with the client, which in part is true. The part that was wrong is that the site could be this simple CSS HTML static site when in fact, even for a small business lacked the features and flexibility needed. Initially, the client and I decided that we would have me make the changes and updates to the static food and drink menu pages. This turned out to be very inefficient for both parties. Small businesses often don't want to pay hourly rates to have minor updates done on their website, which was the case because I don't work for free.

In the end the HTML/CSS site had a CMS, Database, and multiple external services. I learned from this moving forward and came up with the right stack for the scale of business I work with. However, in the late 2010's I noticed more small businesses opting into products like Squarespace and Wix, and selling clients with certain small businesses (nick nack shops and local bars restaurants) on custom site builds was getting harder.

Back to the original post. I get the point of the blog was to make a statement against unneeded complexity. Sure, however, it's important to remember that the work of producing digital products is inherently technical and complex. Developers should strive to be a smart programmer and spend time picking the right tools for the job.

Godaddy's free website builder would do that fine, too.

Bob's restaurant doesn't need to rent a VPS either one would hope.

Reply on news.ycombinator.com