7 ms·

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. Onc

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) they move to some columnar DB no one has heard of. Nevermind that postgres and a reasonably priced DBA and a little thought put into their data model/queries could probably handle all their issues. Sorry for the snark, cheers on a successful product.

matte_black 8y ago
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.
- Reedx 8y ago
  The difference between mySQL and Postgres is that significant? What makes up the difference?
  - jjeaff 8y ago
    Hardly. And in general, MySQL outperforms Postgres. But you will have more options to tweak Postgres to work better for you in edge cases.
quest88 8y ago
Why isn't MySQL serious? It has powered many popular sites.
- attaboyjon 8y ago
  You are right. It is a solid DB. I was more pointing out that if you have to move off Mysql, there are excellent options other than adopting a new columnar datastore.
- zimpenfish 8y ago
  > Why isn't MySQL serious? It has powered many popular sites. As has PHP. "popularity" isn't really evidence for it being a "serious" tool, is it?
  - eeZah7Ux 8y ago
    Why the downvotes? Popularity != quality.
peburrows 8y ago
Overall, I agree with the sentiment of your comment, but the assertion that MySQL isn’t a serious database is just flat out wrong.
- attaboyjon 8y ago
  You're right. I started using mysql in 2000 when it was still a toy. It's an outdated bias :) I was more flabergastered they would choose 'InifiniDB' when there are so many other great options out there.
- dijit 8y ago
  I disagree with your assertion that MySQL /is/ a serious database. The questions I usually ask myself when evaluating database solutions is: * Does it accept invalid data? * Does it change data on error? * Does the query planner change drastically between minor versions? * How strong is transaction isolation? can I create constraints, columns or tables in a transaction? * Does it scale vertically above 40~ CPU threads and 1M IOPS? The answer to all these questions, for MySQL is "No". You could argue the value of some of them, but a lot of them highlight architectural or development procedural misgivings.
  - jjeaff 8y ago
    Considering many, many of the world's largest tech companies use MySQL or MySQL compatible databases, it's rather absurd to say that MySQL isn't a serious database. Regardless of whether it matches yours or someone else's personal list of capabilities.
    - poooogles 8y ago
      One true Scotsman fallacy at work is what it is.
    - dijit 8y ago
      To be perfectly fair with you, you can make bad choices and still get something useful done. Most companies are not alive "because they chose mysql over something else" they're alive because they have "good enough" tech to get the job done. The job that they're trying to accomplish is the thing that makes them successful. Uber isn't super huge because it used a specific database technology. It's huge because it's good at marketing, it's providing some value to people.
davidp 8y ago
I like to trot out this old gem[1] when people wonder why there's so much hate for MySQL. Nontransactional DDL alone is sufficient to classify it as a toy DB for me. Yes, I've been personally bitten by it. [1]: https://grimoire.ca/mysql/choose-something-else https://grimoire.ca/mysql/choose-something-else
- cdubzzz 8y ago
  This talks a lot about 5.5 and mentions that 5.6 is “due out soon”. The current release series is 5.7. How much of this is outdated and how much has stayed the same?
  - dsp1234 8y ago
    "Some statements cannot be rolled back. In general, these include data definition language (DDL) statements, such as those that create or drop databases, those that create, drop, or alter tables or stored routines." [0] [0] - https://dev.mysql.com/doc/refman/5.7/en/cannot-roll-back.html https://dev.mysql.com/doc/refman/5.7/en/cannot-roll-back.htm...
  - lstamour 8y ago
    Some things are improving — for example: https://dev.mysql.com/doc/refman/8.0/en/atomic-ddl.html https://dev.mysql.com/doc/refman/8.0/en/atomic-ddl.html And https://mysqlserverteam.com/new-defaults-in-mysql-8-0/ https://mysqlserverteam.com/new-defaults-in-mysql-8-0/ Previously on HN: https://news.ycombinator.com/item?id=5122299 https://news.ycombinator.com/item?id=5122299 Personally, I only use MySQL and derivatives where I have to (basically WordPress.)
- misframer 8y ago
  According to [1] Oracle doesn't have transactional DDL either. [1] https://stackoverflow.com/questions/4711447/oracle-ddl-and-transaction-rollback https://stackoverflow.com/questions/4711447/oracle-ddl-and-t...
- jjeaff 8y ago
  Well, you should school those fools at Google, Facebook, Twitter, Pinterest, Amazon... and tell them how they are wasting time with their toy MySQL databases.
coldtea 8y ago
The snark is OK. The lack of any substance tho -- besides the dubious claim that a move to a "serious" db like Postgres would have saved them...
bufferoverflow 8y ago
Can you demonstrate that Postgre is significantly faster than MySQL on average? Highly doubt so. The problem is in the way data model was architected and implemented.
- zaarn 8y ago
  PG isn't usually faster than MySQL on any naive database (which is 90% of database in the world I suppose) Most E-Shops will be fine running MySQL or MariaDB. The one thing PG excels at however is that you can tune it much more to your workload and it allows tuning the workload much more finely than MySQL/MariaDB. That and the ability to extend PG arbitrarily (try adding native functions to mysql without recompiling) via the C-FFI offered. You can write and define your own index methods that let you use an index that is perfect for the workload or you can add a new data type to support a new input with validation. You can sink a lot of work into getting the most out of a PG database, MySQL not so much. But again, for most people MySQL will provide the same (or even better) performance than PG. (I still trust PG over MySQL after MySQL nulled out all entries of a table with only NOTNULL columns after a nasty crash)
- LoSboccacc 8y ago
  apples to oranges. you need to compare PostgreSQL with other database that don't take shortcut around ACID for performances (for example DDL forcing implicit commit in transactions)
  - carterehsmith 8y ago
    So this is true, but I find that it does not matter much. Like, how often one needs to rollback a DDL statement? I did that like... never. And, what is the use case? Like, you added a column to a table by accident? Well, that will not break anything, so no harm done. That is way different from regular dml rollback which may recover 1bn records and save your life :)
    - astura 8y ago
      Seriously? You don't need to do DLL operations in day-to-day use but you'll need to when you're doing development work. For example, you had a "color" column on a table, for a new feature youre now adding the ability to have multiple colors. You're going to create a new column, create a new table, populate that table, and drop the old column. If anything fails during that process you'd like to be able to roll back.
ksec 8y ago
If I ever be a CEO of the company / Startup, that one criteria I made is either I decide on all the technologies we use, or there is no CTO so i make those decision. And that criteria of technologies could be summed into one sentence. Use something boring. No Hyped programming languages / DB / tools allowed. Of course some would argue you would be doing it wrong even if it was using old tech / programming / tools. Well yes, but you have a sea of recourse and expertise there to ask for help. Instead of spending energy and time doing figuring it out. Of course if your company is all about tech innovation, AI or something cutting edge there surely you will have to tried something new. But 80% of those startup aren't.
- aaronbrethorst 8y ago
  I'm a fan of taking a 'one new technology' approach. When I'm building something new, I get to choose zero or one new technologies to play with, depending on whether I want to get shit done or learn something new. By choosing at most one new thing, you can better control for how your stack should work and how you expect it to respond to certain unexpected circumstances, which means you should be able to more effectively solve issues as they crop up than you'd be able to if you were using multiple new technologies.
- shoo 8y ago
  Quoting Dan McKinley's "choose boring technology" [cbt]: > Embrace Boredom. > Let's say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. You might get a few more after you achieve a certain level of stability and maturity, but the general tendency is to overestimate the contents of your wallet. Clearly this model is approximate, but I think it helps. > If you choose to write your website in NodeJS, you just spent one of your innovation tokens. If you choose to use MongoDB, you just spent one of your innovation tokens. If you choose to use service discovery tech that's existed for a year or less, you just spent one of your innovation tokens. If you choose to write your own database, oh god, you're in trouble. > Any of those choices might be sensible if you're a javascript consultancy, or a database company. But you're probably not. You're probably working for a company that is at least ostensibly rethinking global commerce or reinventing payments on the web or pursuing some other suitably epic mission. In that context, devoting any of your limited attention to innovating ssh is an excellent way to fail. Or at best, delay success. [CBT] http://mcfunley.com/choose-boring-technology http://mcfunley.com/choose-boring-technology
endymi0n 8y ago
Can't help but also think "WTF are they doing there..." - we're doing exactly the same (user segmentation, targeting and campaign execution for cinema & movie users, disclaimer: we're more or less their only competitor, albeit indirect), but our solution is running at ~30k/year total at 10 times their user base. No magic in there, just good architecture and solid Computer Science. Boring technology (Go/Redshift/Postgres/S3). The only thing I'd fully agree on is that using Go saved us a lot of resources as well. It's an awesome choice for stuff like this that needs to be reasonably performant as well as being simple, understandable and reasonably fast built.
indigochill 8y ago
Well, a problem in tech certainly. An alternative possibility (and another problem in tech) could be some mid-level developer could have figured out the problem at the start but because of artificial time pressure to deliver they didn't have the time to, so went with the first bad idea that popped into their head without taking the necessary time to evaluate it. The fact this had to happen in a hackathon suggests a typical disconnect between management and development (and probably poor prioritization by management). Because development knew this was a problem and how to fix it (evidenced by the fact they fixed it), but it took removing management (aka a hackathon) to give development the space to fix it. And now the company pats itself on the back for having the vision to host a hackathon instead of structuring and prioritizing correctly in the first place so this would just get fixed on the clock. I do think the author's takeaway about the value of simplicity and pragmatism are on point, but that applies not just to code but to management as well.
- colde 8y ago
  It is worth noting that on their website, their management team doesn't include a CTO, even though their main product is basically a software solution. They have a few sales people represented though, so management might not be great techwise.
  - maddiez 8y ago
    CTO has moved to another company with not so shiny tech stack, as far as I know they were the main adopter of Go and other solutions to replace Java and then Scala. Perhaps Movio did not yet find the best fit for the company.
- _pmf_ 8y ago
  Typical prototype-gone-live scenario. A.k.a. 90 per cent of projects where prototypes are used at any stage ...
wimdetroyer 8y ago
What's wrong with mySQL?
stplsd 8y ago
>Instead of migrating from Mysql to something serious (Postgres) This is just trolling
slx26 8y ago
To be fair, we used to die at 40. Now you can get a CS degree at 21 or 22, and you still "have no idea what are you doing". Maybe it's just that technology is really complicated, the world is really complicated, and everything is changing fast. I don't mean it to be conformist, but it's easy to forget some things are actually hard when you are very clever or old enough to forget how it was like when you were still learning too.
- foepys 8y ago
  But at the same time it's easier than ever to find information on nearly everything. Asking experts also is easier than ever before. I don't think it's feasible to dismiss GP's claim with yours.
  - slx26 8y ago
    Sorry if it came across like that. Not trying to dismiss his claim, just trying to give a wider perspective. Similarly, in the same way you are right saying it's easier to find information on nearly everything nowadays, it might also be relevant to remember that we still have limited time and attention spans.
w8rbt 8y ago
"In June 1970, E. F. Codd of IBM Research published a paper [1] defining the relational data model and introducing the concept of data independence. Codd's thesis was that queries should be expressed in terms of high-level, nonprocedural concepts that are independent of physical representation." The key, the whole key, and nothing but the key so help me Codd. Also said as... "In Codd we trust." If none of these DB jokes mean anything to you, take a DB concepts class at a CS university. There's a lot of great research going back 50 years and you can learn a great deal about why things are the way they are (tuple algebra and calculus). And before changing anything for something you think may be better, you should fully understand what you are giving up. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.86.9277&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.86....
StreamBright 8y ago
I barely ever see an engineer knowing everything that happens from the top to the bottom on any platform. Very few companies are forced to get to know their stack in depth, usually they throw more money to the problem.
kevin_nisbet 8y ago
> 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. Not that I disagree, but to be fair, I've seen plenty of tech ignorance with experienced and older engineers as well that has been pretty crippling.
smoe 8y ago
I think it is not necessarily the age but the mindset of focusing on solutions instead of understanding the problem first. It often goes like this: Oh snap, we encountered a problem! Lets find a tool, framework, language that promises to solve a similar sounding problem. Now we have a problem with a layer of abstraction on top. Soon to be two problems. Lets find a tool, framework, language to solve both of them ... It is a spaghetti to the wall approach, where you just throw a bunch of things at your problem hoping that something sticks. And who cares how long it will stick. Secondly as a developer I think in start-ups dedicated db experts are way underrated. Sure your fullstack devs can cobble together some tables, changing them 15 times a day to accommodate business requests and slap indexes on everything that gets slow. That is also the way to get into trouble once you scale, and instead of reflecting why this is, people reach for the bowl of pasta. I was no different, when just starting out. I thought my biggest strength was, how quickly I can come up with easy "solutions" for any problem the company had. Took me years to realize how silly of an approach this is.
- pm90 8y ago
  Somewhat related: I've seen this problem exacerbated by the presence of "architects" who don't seem to have implemented running systems in a long time, and especially have no experience with running newer technologies; or limited experience which breaks at scale. Not saying this applies to all software architects, but I've seen this often enough. e.g. I remember using a dedicated jenkins environment to run continuous, scheduled integration tests for my service. When the architect found out, he immediately sent me links to software packages that are dedicated to running continuous tests. I asked whether he had any experience running these new packages and if he would be willing to set it up/maintain it.... radio silence.
- vram22 8y ago
  Right. That second paragraph of yours, i.e.: >It often goes like this: Oh snap, we encountered a problem! Lets find a tool, framework, language that promises to solve a similar sounding problem. Now we have a problem with a layer of abstraction on top. Soon to be two problems. Lets find a tool, framework, language to solve both of them ... is absolutely real, I've actually seen in happen both in projects I was in, and heard or read about. This Rich Hickey video is somewhat relevant, IMO: Tech Video: Rich Hickey: Hammock-Driven Development: https://jugad2.blogspot.in/2016/03/tech-video-rich-hickey-hammock-driven.html https://jugad2.blogspot.in/2016/03/tech-video-rich-hickey-ha... You have to watch it at least part way through to get some of the better points in it, although the whole thing is good.
collyw 8y ago
Agreed. I have 15 years of experience and can built a decent clean system using "boring" technologies. But all the decent paid work where I live is maintaining big balls of mud with tech that was obviously peak hype when it was chosen, and nothing done according to best practices because of that would require sticking with a tech and learning it properly. Its quite frustrating. Then we have the interview process where people expect me to give up my weekend for their coding test and can't even be bothered to give you feedback afterwards. Or some ridiculous algorithmic nonsense that has no relevance to the job. Getting bored of it all.
dboreham 8y ago
Agree. I'm not sure per se this is an age thing: the field is just so big and apparently (but perhaps less so in reality) in a constant state of tech churn, that it is hard to anchor to consistent proven techniques and practices.

matte_black 8y ago

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.

Reedx 8y ago
The difference between mySQL and Postgres is that significant? What makes up the difference?
- jjeaff 8y ago
  Hardly. And in general, MySQL outperforms Postgres. But you will have more options to tweak Postgres to work better for you in edge cases.

quest88 8y ago

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

attaboyjon 8y ago
You are right. It is a solid DB. I was more pointing out that if you have to move off Mysql, there are excellent options other than adopting a new columnar datastore.
zimpenfish 8y ago
> Why isn't MySQL serious? It has powered many popular sites. As has PHP. "popularity" isn't really evidence for it being a "serious" tool, is it?
- eeZah7Ux 8y ago
  Why the downvotes? Popularity != quality.

peburrows 8y ago

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

attaboyjon 8y ago
You're right. I started using mysql in 2000 when it was still a toy. It's an outdated bias :) I was more flabergastered they would choose 'InifiniDB' when there are so many other great options out there.
dijit 8y ago
I disagree with your assertion that MySQL /is/ a serious database. The questions I usually ask myself when evaluating database solutions is: * Does it accept invalid data? * Does it change data on error? * Does the query planner change drastically between minor versions? * How strong is transaction isolation? can I create constraints, columns or tables in a transaction? * Does it scale vertically above 40~ CPU threads and 1M IOPS? The answer to all these questions, for MySQL is "No". You could argue the value of some of them, but a lot of them highlight architectural or development procedural misgivings.
- jjeaff 8y ago
  Considering many, many of the world's largest tech companies use MySQL or MySQL compatible databases, it's rather absurd to say that MySQL isn't a serious database. Regardless of whether it matches yours or someone else's personal list of capabilities.
  - poooogles 8y ago
    One true Scotsman fallacy at work is what it is.
  - dijit 8y ago
    To be perfectly fair with you, you can make bad choices and still get something useful done. Most companies are not alive "because they chose mysql over something else" they're alive because they have "good enough" tech to get the job done. The job that they're trying to accomplish is the thing that makes them successful. Uber isn't super huge because it used a specific database technology. It's huge because it's good at marketing, it's providing some value to people.

davidp 8y ago

I like to trot out this old gem[1] when people wonder why there's so much hate for MySQL. Nontransactional DDL alone is sufficient to classify it as a toy DB for me. Yes, I've been personally bitten by it. [1]: https://grimoire.ca/mysql/choose-something-else https://grimoire.ca/mysql/choose-something-else

cdubzzz 8y ago
This talks a lot about 5.5 and mentions that 5.6 is “due out soon”. The current release series is 5.7. How much of this is outdated and how much has stayed the same?
- dsp1234 8y ago
  "Some statements cannot be rolled back. In general, these include data definition language (DDL) statements, such as those that create or drop databases, those that create, drop, or alter tables or stored routines." [0] [0] - https://dev.mysql.com/doc/refman/5.7/en/cannot-roll-back.html https://dev.mysql.com/doc/refman/5.7/en/cannot-roll-back.htm...
- lstamour 8y ago
  Some things are improving — for example: https://dev.mysql.com/doc/refman/8.0/en/atomic-ddl.html https://dev.mysql.com/doc/refman/8.0/en/atomic-ddl.html And https://mysqlserverteam.com/new-defaults-in-mysql-8-0/ https://mysqlserverteam.com/new-defaults-in-mysql-8-0/ Previously on HN: https://news.ycombinator.com/item?id=5122299 https://news.ycombinator.com/item?id=5122299 Personally, I only use MySQL and derivatives where I have to (basically WordPress.)
misframer 8y ago
According to [1] Oracle doesn't have transactional DDL either. [1] https://stackoverflow.com/questions/4711447/oracle-ddl-and-transaction-rollback https://stackoverflow.com/questions/4711447/oracle-ddl-and-t...
jjeaff 8y ago
Well, you should school those fools at Google, Facebook, Twitter, Pinterest, Amazon... and tell them how they are wasting time with their toy MySQL databases.

coldtea 8y ago

The snark is OK. The lack of any substance tho -- besides the dubious claim that a move to a "serious" db like Postgres would have saved them...

bufferoverflow 8y ago

Can you demonstrate that Postgre is significantly faster than MySQL on average? Highly doubt so. The problem is in the way data model was architected and implemented.

zaarn 8y ago
PG isn't usually faster than MySQL on any naive database (which is 90% of database in the world I suppose) Most E-Shops will be fine running MySQL or MariaDB. The one thing PG excels at however is that you can tune it much more to your workload and it allows tuning the workload much more finely than MySQL/MariaDB. That and the ability to extend PG arbitrarily (try adding native functions to mysql without recompiling) via the C-FFI offered. You can write and define your own index methods that let you use an index that is perfect for the workload or you can add a new data type to support a new input with validation. You can sink a lot of work into getting the most out of a PG database, MySQL not so much. But again, for most people MySQL will provide the same (or even better) performance than PG. (I still trust PG over MySQL after MySQL nulled out all entries of a table with only NOTNULL columns after a nasty crash)
LoSboccacc 8y ago
apples to oranges. you need to compare PostgreSQL with other database that don't take shortcut around ACID for performances (for example DDL forcing implicit commit in transactions)
- carterehsmith 8y ago
  So this is true, but I find that it does not matter much. Like, how often one needs to rollback a DDL statement? I did that like... never. And, what is the use case? Like, you added a column to a table by accident? Well, that will not break anything, so no harm done. That is way different from regular dml rollback which may recover 1bn records and save your life :)
  - astura 8y ago
    Seriously? You don't need to do DLL operations in day-to-day use but you'll need to when you're doing development work. For example, you had a "color" column on a table, for a new feature youre now adding the ability to have multiple colors. You're going to create a new column, create a new table, populate that table, and drop the old column. If anything fails during that process you'd like to be able to roll back.

ksec 8y ago

If I ever be a CEO of the company / Startup, that one criteria I made is either I decide on all the technologies we use, or there is no CTO so i make those decision. And that criteria of technologies could be summed into one sentence. Use something boring. No Hyped programming languages / DB / tools allowed. Of course some would argue you would be doing it wrong even if it was using old tech / programming / tools. Well yes, but you have a sea of recourse and expertise there to ask for help. Instead of spending energy and time doing figuring it out. Of course if your company is all about tech innovation, AI or something cutting edge there surely you will have to tried something new. But 80% of those startup aren't.

aaronbrethorst 8y ago
I'm a fan of taking a 'one new technology' approach. When I'm building something new, I get to choose zero or one new technologies to play with, depending on whether I want to get shit done or learn something new. By choosing at most one new thing, you can better control for how your stack should work and how you expect it to respond to certain unexpected circumstances, which means you should be able to more effectively solve issues as they crop up than you'd be able to if you were using multiple new technologies.
shoo 8y ago
Quoting Dan McKinley's "choose boring technology" [cbt]: > Embrace Boredom. > Let's say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. You might get a few more after you achieve a certain level of stability and maturity, but the general tendency is to overestimate the contents of your wallet. Clearly this model is approximate, but I think it helps. > If you choose to write your website in NodeJS, you just spent one of your innovation tokens. If you choose to use MongoDB, you just spent one of your innovation tokens. If you choose to use service discovery tech that's existed for a year or less, you just spent one of your innovation tokens. If you choose to write your own database, oh god, you're in trouble. > Any of those choices might be sensible if you're a javascript consultancy, or a database company. But you're probably not. You're probably working for a company that is at least ostensibly rethinking global commerce or reinventing payments on the web or pursuing some other suitably epic mission. In that context, devoting any of your limited attention to innovating ssh is an excellent way to fail. Or at best, delay success. [CBT] http://mcfunley.com/choose-boring-technology http://mcfunley.com/choose-boring-technology

endymi0n 8y ago

Can't help but also think "WTF are they doing there..." - we're doing exactly the same (user segmentation, targeting and campaign execution for cinema & movie users, disclaimer: we're more or less their only competitor, albeit indirect), but our solution is running at ~30k/year total at 10 times their user base. No magic in there, just good architecture and solid Computer Science. Boring technology (Go/Redshift/Postgres/S3). The only thing I'd fully agree on is that using Go saved us a lot of resources as well. It's an awesome choice for stuff like this that needs to be reasonably performant as well as being simple, understandable and reasonably fast built.

indigochill 8y ago

Well, a problem in tech certainly. An alternative possibility (and another problem in tech) could be some mid-level developer could have figured out the problem at the start but because of artificial time pressure to deliver they didn't have the time to, so went with the first bad idea that popped into their head without taking the necessary time to evaluate it. The fact this had to happen in a hackathon suggests a typical disconnect between management and development (and probably poor prioritization by management). Because development knew this was a problem and how to fix it (evidenced by the fact they fixed it), but it took removing management (aka a hackathon) to give development the space to fix it. And now the company pats itself on the back for having the vision to host a hackathon instead of structuring and prioritizing correctly in the first place so this would just get fixed on the clock. I do think the author's takeaway about the value of simplicity and pragmatism are on point, but that applies not just to code but to management as well.

colde 8y ago
It is worth noting that on their website, their management team doesn't include a CTO, even though their main product is basically a software solution. They have a few sales people represented though, so management might not be great techwise.
- maddiez 8y ago
  CTO has moved to another company with not so shiny tech stack, as far as I know they were the main adopter of Go and other solutions to replace Java and then Scala. Perhaps Movio did not yet find the best fit for the company.
_pmf_ 8y ago
Typical prototype-gone-live scenario. A.k.a. 90 per cent of projects where prototypes are used at any stage ...

wimdetroyer 8y ago

What's wrong with mySQL?

stplsd 8y ago

>Instead of migrating from Mysql to something serious (Postgres) This is just trolling

slx26 8y ago

To be fair, we used to die at 40. Now you can get a CS degree at 21 or 22, and you still "have no idea what are you doing". Maybe it's just that technology is really complicated, the world is really complicated, and everything is changing fast. I don't mean it to be conformist, but it's easy to forget some things are actually hard when you are very clever or old enough to forget how it was like when you were still learning too.

foepys 8y ago
But at the same time it's easier than ever to find information on nearly everything. Asking experts also is easier than ever before. I don't think it's feasible to dismiss GP's claim with yours.
- slx26 8y ago
  Sorry if it came across like that. Not trying to dismiss his claim, just trying to give a wider perspective. Similarly, in the same way you are right saying it's easier to find information on nearly everything nowadays, it might also be relevant to remember that we still have limited time and attention spans.

w8rbt 8y ago

"In June 1970, E. F. Codd of IBM Research published a paper [1] defining the relational data model and introducing the concept of data independence. Codd's thesis was that queries should be expressed in terms of high-level, nonprocedural concepts that are independent of physical representation." The key, the whole key, and nothing but the key so help me Codd. Also said as... "In Codd we trust." If none of these DB jokes mean anything to you, take a DB concepts class at a CS university. There's a lot of great research going back 50 years and you can learn a great deal about why things are the way they are (tuple algebra and calculus). And before changing anything for something you think may be better, you should fully understand what you are giving up. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.86.9277&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.86....

StreamBright 8y ago

I barely ever see an engineer knowing everything that happens from the top to the bottom on any platform. Very few companies are forced to get to know their stack in depth, usually they throw more money to the problem.

kevin_nisbet 8y ago

> 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. Not that I disagree, but to be fair, I've seen plenty of tech ignorance with experienced and older engineers as well that has been pretty crippling.

smoe 8y ago

I think it is not necessarily the age but the mindset of focusing on solutions instead of understanding the problem first. It often goes like this: Oh snap, we encountered a problem! Lets find a tool, framework, language that promises to solve a similar sounding problem. Now we have a problem with a layer of abstraction on top. Soon to be two problems. Lets find a tool, framework, language to solve both of them ... It is a spaghetti to the wall approach, where you just throw a bunch of things at your problem hoping that something sticks. And who cares how long it will stick. Secondly as a developer I think in start-ups dedicated db experts are way underrated. Sure your fullstack devs can cobble together some tables, changing them 15 times a day to accommodate business requests and slap indexes on everything that gets slow. That is also the way to get into trouble once you scale, and instead of reflecting why this is, people reach for the bowl of pasta. I was no different, when just starting out. I thought my biggest strength was, how quickly I can come up with easy "solutions" for any problem the company had. Took me years to realize how silly of an approach this is.

pm90 8y ago
Somewhat related: I've seen this problem exacerbated by the presence of "architects" who don't seem to have implemented running systems in a long time, and especially have no experience with running newer technologies; or limited experience which breaks at scale. Not saying this applies to all software architects, but I've seen this often enough. e.g. I remember using a dedicated jenkins environment to run continuous, scheduled integration tests for my service. When the architect found out, he immediately sent me links to software packages that are dedicated to running continuous tests. I asked whether he had any experience running these new packages and if he would be willing to set it up/maintain it.... radio silence.
vram22 8y ago
Right. That second paragraph of yours, i.e.: >It often goes like this: Oh snap, we encountered a problem! Lets find a tool, framework, language that promises to solve a similar sounding problem. Now we have a problem with a layer of abstraction on top. Soon to be two problems. Lets find a tool, framework, language to solve both of them ... is absolutely real, I've actually seen in happen both in projects I was in, and heard or read about. This Rich Hickey video is somewhat relevant, IMO: Tech Video: Rich Hickey: Hammock-Driven Development: https://jugad2.blogspot.in/2016/03/tech-video-rich-hickey-hammock-driven.html https://jugad2.blogspot.in/2016/03/tech-video-rich-hickey-ha... You have to watch it at least part way through to get some of the better points in it, although the whole thing is good.

collyw 8y ago

Agreed. I have 15 years of experience and can built a decent clean system using "boring" technologies. But all the decent paid work where I live is maintaining big balls of mud with tech that was obviously peak hype when it was chosen, and nothing done according to best practices because of that would require sticking with a tech and learning it properly. Its quite frustrating. Then we have the interview process where people expect me to give up my weekend for their coding test and can't even be bothered to give you feedback afterwards. Or some ridiculous algorithmic nonsense that has no relevance to the job. Getting bored of it all.

dboreham 8y ago

Agree. I'm not sure per se this is an age thing: the field is just so big and apparently (but perhaps less so in reality) in a constant state of tech churn, that it is hard to anchor to consistent proven techniques and practices.