What's up with the title?
Looks like it references the wrong article? This[0] one has the same name as op's [0] https://habr.com/en/post/456568/
Great article, thanks. I bet this is the one the OP meant to submit.
You are not Google. You are not Netflix
11–20 of 58 posts
Re: You are not Google. You are not Netflix
#12Earlier quoted context omitted.
I don't believe I'm familiar with JIT in this context? Just in time development?
I haven't heard it either, but apparently it's another name for the Toyota system/'lean manufacturing': https://en.m.wikipedia.org/wiki/Just-in-time_manufacturing
Sorry. No, I wasn't referring to JIT Manufacturing...
It was merely a tongue-in-cheek to mean just build what's needed right now in front of you, then get it working at scale once there's an actual needs to scale. This is in contrast to starting from day one spending most of your time thinking of scale, then building everything so that it can infinitely scale (along with the complexities that come with it), only to find out that you have 8 users and your data can fit entirely in memory.
Re: You are not Google. You are not Netflix
#13Earlier quoted context omitted.
I haven't heard it either, but apparently it's another name for the Toyota system/'lean manufacturing': https://en.m.wikipedia.org/wiki/Just-in-time_manufacturing
Sorry. No, I wasn't referring to JIT Manufacturing... It was merely a tongue-in-cheek to mean just build what's needed right now in front of you, then get it working at scale once there's an actual needs to scale. This is in contrast to starting from day one spending most of your time thinking of scale, then building everything so that it can infinitely scale (along with the complexities that come with it), only to f…
That sounds more like JDI / JGID -- just do it / just get it done.
Sometimes "make it so" from ST-TNG.
Re: You are not Google. You are not Netflix
#14Earlier quoted context omitted.
I haven't heard it either, but apparently it's another name for the Toyota system/'lean manufacturing': https://en.m.wikipedia.org/wiki/Just-in-time_manufacturing
Sorry. No, I wasn't referring to JIT Manufacturing... It was merely a tongue-in-cheek to mean just build what's needed right now in front of you, then get it working at scale once there's an actual needs to scale. This is in contrast to starting from day one spending most of your time thinking of scale, then building everything so that it can infinitely scale (along with the complexities that come with it), only to f…
Oh, okay, sorry.
(Fwiw searching 'JIT development' does net first page results of people talking about JIT/lean manufacturing in a software development context.)
Re: You are not Google. You are not Netflix
#15What's up with the title?
Looks like it references the wrong article? This[0] one has the same name as op's [0] https://habr.com/en/post/456568/
What's going on, it keeps switching between 'You are not Google. You ate not Netflix', and 'Developers are now measured in hits and views and it's not okay' or something - different articles on different sites even.
Some comments here seem to reference one, some the other...
Re: You are not Google. You are not Netflix
#16A related issue is also focusing so much on the tech (and often how well the product/service can scale) that you forget to do much marketing and end up delaying the product/service for months as a result. Or worse still, never actually finish building it at all. Definitely follow the old get it working, then correct, then fast methodology, at least for projects without many billions of dollars in resources.
> follow the old get it working, then correct, then fast methodology
And eventually realize there is no correct then fast after get it working, only more iterations forever.
Re: You are not Google. You are not Netflix
#17Earlier quoted context omitted.
I haven't heard it either, but apparently it's another name for the Toyota system/'lean manufacturing': https://en.m.wikipedia.org/wiki/Just-in-time_manufacturing
Sorry. No, I wasn't referring to JIT Manufacturing... It was merely a tongue-in-cheek to mean just build what's needed right now in front of you, then get it working at scale once there's an actual needs to scale. This is in contrast to starting from day one spending most of your time thinking of scale, then building everything so that it can infinitely scale (along with the complexities that come with it), only to f…
there's a vast middle ground between 'astronaut architecture' and 'common sense necessities', and knowing where a good cutoff point is is hard without experience.
I've met more than a few folks who consider web templating systems to be 'overkill', and have 0 understanding of the risk of xss. Same with sql/db escaping - "I just write the SQL and run it, using all those libraries is just a waste of time", etc.
Many of the projects I've come in to over the years were doing with a "JGID" mentality. And they did "get it done", "it" was just a steaming pile of crap when it was done. "Why is this taking weeks to do - the previous guy was so much faster?"
Had this one last year:
"This was never slow before when X worked on it, you've made changes what have you done? We need to call X back in to the project".
X just "got it done". And X was a db admin who was writing code. And X decided it would be good to have views join against other views which joined against other views, and have some queries which used those views run in triggers.
When X was on the project, and there were 40 users, it was fine. They hit 1000 users, and things were 'slow', so they upgraded to a larger EC2 instance. X left, and I came in, and several months later they hit ~30000 users (not active, just ... user account records). The system was dying with more than 5 active users, because of all the views joining other views on 30k+ records.
Unravelling that meant deciphering all the views, all the queries, all the code that touched all of it, and rebuilding a moderate portion, without tests, known 'good' data, or anyone on the project knowing what 'right' was - they just knew when things looked 'wrong' (or slow).
BUT... 18 months earlier, it was "JGID", and it got done. I'm still a bit perplexed why a professional DB admin thought views joining against multiple other views was a good approach.
We've all got horror stories, I'm sure, it's just that the "JGID" mentality is often preached by competent experts as a good approach, but picked up by beginners as the approach used by experts, and has bad consequences.
Re: You are not Google. You are not Netflix
#18Having seen the inside of both good and bad product organizations, culture beats process any day of the week. Get the core values right, hire smart people and everything will fall into place.
A corollary is that cargo-culting well-developed processes generally means you’re copying from a company with a culture that couldn’t address those functions organically. So you may actually just be lifting an over-engineered process designed to address a cultural weakness at the original company.
Re: You are not Google. You are not Netflix
#19Earlier quoted context omitted.
Sorry. No, I wasn't referring to JIT Manufacturing... It was merely a tongue-in-cheek to mean just build what's needed right now in front of you, then get it working at scale once there's an actual needs to scale. This is in contrast to starting from day one spending most of your time thinking of scale, then building everything so that it can infinitely scale (along with the complexities that come with it), only to f…
there's a vast middle ground between 'astronaut architecture' and 'common sense necessities', and knowing where a good cutoff point is is hard without experience. I've met more than a few folks who consider web templating systems to be 'overkill', and have 0 understanding of the risk of xss. Same with sql/db escaping - "I just write the SQL and run it, using all those libraries is just a waste of time", etc. Many of…
Out of curiosity - Which database is this? and is it really taboo to have views joining against multiple other views?
If the underlying views were performant- I'd assume the query optimizer would do the right thing(at least 90% of the time).
EDIT: I guess it depends - Just did more research and found this [1]. As long as the views don't do unnecessary heavy lifting or joining unnecessary tables, it should be fine.
[1] https://dba.stackexchange.com/questions/151169/are-views-har...
Re: You are not Google. You are not Netflix
#20Earlier quoted context omitted.
Looks like it references the wrong article? This[0] one has the same name as op's [0] https://habr.com/en/post/456568/
That was much more interesting article than the submitted one.
As an old(?) person who does everything by the book in C++, I couldn't really relate to it.
At least at my company it's hard to get hired to a programming position on soft skills alone. I've interviewed some very nice people who ended up not getting hired due to trouble whiteboarding.
As far as I can tell no one I work with is a an influencer on insta-twit. Some coworkers are better than others, but on the whole they all know the front end of a for loop from the back and are willing to learn.
And I end up spending way more time not writing code than writing it.