Live data from Hacker News

We saved $50k/year with a Go microservice coded in a hackathon

movio.co

81–90 of 264 posts

Re: We saved $50k/year with a Go microservice coded in a hackathon

#81

I've come to the conclusion that the problem in tech is that all the people doing the work are in their early twenties and have no idea what they are doing. Once they get some experience they are quickly promoted to the CTO position. Rinse and repeat. What we have here is a classic dbms problem and no one at Movio seems to know how to deal with that. Instead of migrating from Mysql to something serious (Postgres) the…

Agreed, I’m sure if this is the kind of problems they are having I could probably be saving them even more than $50k a year if they were on Postgres.

Re: We saved $50k/year with a Go microservice coded in a hackathon

#82

This is cool but it seems strange (to me) that this was a “Hackathon” project as opposed to just a stand-alone problem to be addressed as a normal course of doing business. It doesn’t make the solution less cool. It just seems like a strange distinction on what a Hackathon is.

A hackathon is something that used to be a cool party for geeks (i.e., a Mathletics competition or an ACM programming contest) until the corporate overlords bastardized it and converted a good thing into unpaid overtime with free beer.

While simultaneously "proving" that all projects could get done in one tenth of the time.

Re: We saved $50k/year with a Go microservice coded in a hackathon

#83
post #68

Earlier quoted context omitted.

If they don't know how to look at a query plan and craft a solution can you really call them full stack?

The stack has to bottom our somewhere and it's usually at the application code

If that’s where they bottom out they should be called “mid stack” rather than full stack.

If you are claiming to be full stack you better be prepared to go all the way.

Re: We saved $50k/year with a Go microservice coded in a hackathon

#84

Earlier quoted context omitted.

A hackathon is something that used to be a cool party for geeks (i.e., a Mathletics competition or an ACM programming contest) until the corporate overlords bastardized it and converted a good thing into unpaid overtime with free beer.

While simultaneously "proving" that all projects could get done in one tenth of the time.

Well, what would be the argument against that - if in fact it does deliver code that solves a problem in a short period of time? Why can't you just do that all the time?

Re: We saved $50k/year with a Go microservice coded in a hackathon

#85
post #29
post #8

I don't quite get this. How fast was running this query: Select loyaltyMemberID from table WHERE gender = x AND (age = y OR censor = z) Why the random complexity with individual unions and a group? Of course that's going to be dog slow. Sure, the filters can be arbitrary but with an ORM it's really really simple to build them up from your app code. The Django ORM with Q objects is particularly great at this. Obviousl…

The user data is most likely in rows instead of columns. Instead of having id, name, age, gender 1213, fake, 60, female they would have property_id, user_id, value 1 (assume age), 1213, 60 2 (gender), 1213, female This gives them the freedom to add more properties to the user without always having to add a column to the users table. When querying the database you'll have to do unions or joins.

If they are using some sort of middleware orm, which they may well be because of their model, they are most likely using an EAV[0] schema which, although flexible for writes, is horrendous for reads. The join plus pivot is a disaster on virtually any relational system.

[0]https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80...

Re: We saved $50k/year with a Go microservice coded in a hackathon

#86

Earlier quoted context omitted.

While simultaneously "proving" that all projects could get done in one tenth of the time.

Well, what would be the argument against that - if in fact it does deliver code that solves a problem in a short period of time? Why can't you just do that all the time?

Same reason you can't drug up or taze the special goose to produce more golden eggs.

Long term high intensity output will lead to burnout, even if the salary is 10x people would struggle and crash. Pushing at 100% full enthusiasm is like sprinting, it is not possible to maintain that intensity for very long. It can be fun, it can be productive, but the wiser approach has the long-term and end in mind.

Re: We saved $50k/year with a Go microservice coded in a hackathon

#87

I've come to the conclusion that the problem in tech is that all the people doing the work are in their early twenties and have no idea what they are doing. Once they get some experience they are quickly promoted to the CTO position. Rinse and repeat. What we have here is a classic dbms problem and no one at Movio seems to know how to deal with that. Instead of migrating from Mysql to something serious (Postgres) the…

Why isn't MySQL serious? It has powered many popular sites.

Re: We saved $50k/year with a Go microservice coded in a hackathon

#88

Earlier quoted context omitted.

While simultaneously "proving" that all projects could get done in one tenth of the time.

Well, what would be the argument against that - if in fact it does deliver code that solves a problem in a short period of time? Why can't you just do that all the time?

Having a fairly small, well defined problem, working in a small self-selected team, with no outside interference and typically no clients outside the team. No managers, no PMs, no bug reports. This is not how day-to-day projects get done.

Regardless of all of that, in my experience a typical impressive hackathon project is still just a barely working demo that benefitted from a significant amount of research and planning beforehand, and will require an even greater amount of hardening and polish afterwards.

There is no magic, it's just a vastly different kind of work environment with both inputs and outputs incomparable to day-to-day work.

Re: We saved $50k/year with a Go microservice coded in a hackathon

#89

I've come to the conclusion that the problem in tech is that all the people doing the work are in their early twenties and have no idea what they are doing. Once they get some experience they are quickly promoted to the CTO position. Rinse and repeat. What we have here is a classic dbms problem and no one at Movio seems to know how to deal with that. Instead of migrating from Mysql to something serious (Postgres) the…

Overall, I agree with the sentiment of your comment, but the assertion that MySQL isn’t a serious database is just flat out wrong.

Re: We saved $50k/year with a Go microservice coded in a hackathon

#90

I've come to the conclusion that the problem in tech is that all the people doing the work are in their early twenties and have no idea what they are doing. Once they get some experience they are quickly promoted to the CTO position. Rinse and repeat. What we have here is a classic dbms problem and no one at Movio seems to know how to deal with that. Instead of migrating from Mysql to something serious (Postgres) the…

Agreed, I’m sure if this is the kind of problems they are having I could probably be saving them even more than $50k a year if they were on Postgres.

The difference between mySQL and Postgres is that significant? What makes up the difference?
Post reply on HN