471–480 of 704 posts
I've come to associate the expression "best practices" with "a set of unwritten/badly documented rules which accumulated over the years and which we apply manually and thus inconsistently, even though we could automate this at least in part".
Sometimes I wonder what would happen if my "best practice evangelists" from various projects I've been in met.
Earlier quoted context omitted.
The problem with NoSQL is that your simple model inevitably becomes more complex over time and then it doesn't work anymore. Over the past decade I've realised using a RDBMS is the right call basically 100% of the time. Now pgsql has jsonb column types that work great, I cannot see why you would ever use a NoSQL DB, unless you are working at such crazy scale postgres wouldn't work. In 99.999% of cases people are not.
There are specific cases where a non SQL database is better. Chances are if you haven't hit problems you can't solve with an SQL database you should be using an SQL database. Postgres is amazing and free why would you use anything else.
Generally this is true, but with the caveat that what actually matters is 90th percentile (or maybe even 99th percentile) complexity. If you have a choice between spreading low-grade complexity across the codebase or having one module that is nearly incomprehensible but that provides an abstraction that makes the rest of the code very simple, the latter is almost always to be preferred. Once you've distilled out the evil into one place and gotten it working reliably, chances are you're never going to need to touch it again, and if you do need to, at least you only need to deal with it in one place.
Earlier quoted context omitted.
ACID transactions, validations & constraints, and the ability to debug/log by dumping your data to disk which can then easily be queried with SQL. All of the same reasons you would store relational data in a dbms...
>ACID transactions, validations & constraints There is no D from the ACID. For the D to happen, it takes transaction logs + write barrier (on the non-volatile memory). Doing Atomic, consistent and isolated is trivial in memory (esp. in GC setup), and a lot faster: no locks needed. Validations and constraints are simple if-statements, I'd never think of them as sql.
You also have to do backup and recovery. And for that, you need to write to disk, which becomes a big bottleneck since besides backup and checkpointing there is no other reason to ever write to disk.
Then, you have to know that even in mem database, data needs to be queried, and for that you need special data structures like a cache aware B+tree. Implementing one is non trivial.
Thirdly, doing atomic, consistent and isolated transaction is certainly trivial in a toy example but in an actual database where you have a high number of transactions, it's a lot harder. For example, when you have multiple cores, you certainly will have resource contention, and then you do need locks.
And last thing about gc, again, gc is great, but there has to be a custom gc for a database. You need to make sure the transaction log in memory is flushed before committing. And malloc is also very slow.
I'd suggest reading more into in mem research to understand this better. But in mem db is certainly not the same as a disk db with cache or a simple Hashmat/B+tree structure.
This is the most important part. Most companies don't have a mindset of doing research and analysis before taking a decision. No training is provided around this. Most "engineers" want to play with shiny toys without being held accountable for any decision.
True especially when you get a project manager with no CS/IT background at all (pretty common in consulting for some reason). Then the project is really doomed from minute one.
> After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better. This has been my gut feeling for a long time, and in the last year, I finally took the time to write down my thoughts on the topic. Every week since February 2020, I wrote about some aspect of interviewing that could be improved [0], and I now feel confident there are actionable improvements…
> Individually, we as interviewers can shift our mindset towards looking for strengths instead of weaknesses, accommodate different backgrounds Virtually each time I've been interviewed myself the attitude was not to find out what my strengths are, but to discover gaps in my knoledge and skills. I think that's the standard in our industry. Sadly, this is exactly the oposite of what companies should be looking for. Th…
There's a cultural obsession in this industry with testing things that supposedly correlate (usually poorly) with ability to do the tasks we actually want people to do and not the actual task itself.
I think it's probably rooted in goocargle culting.
> Code coverage has absolutely nothing to do with code quality
> TDD purists are just the worst. Their frail little minds can't process the existence of different workflows.
Amen!
I have skipped the Monolith one because I'm not "that sold" onto it, but I'm certainly not on the side of "put your monolith on a cheese grater and leave with thousands of services"
Earlier quoted context omitted.
>ACID transactions, validations & constraints There is no D from the ACID. For the D to happen, it takes transaction logs + write barrier (on the non-volatile memory). Doing Atomic, consistent and isolated is trivial in memory (esp. in GC setup), and a lot faster: no locks needed. Validations and constraints are simple if-statements, I'd never think of them as sql.
It sounds like you're talking about toy databases which don't run at a lot of TPS. Let me point out some features missing from your simple load a map in memory architecture. You also have to do backup and recovery. And for that, you need to write to disk, which becomes a big bottleneck since besides backup and checkpointing there is no other reason to ever write to disk. Then, you have to know that even in mem databa…
The original talk was explicitly about SqlLite and in-memory databases, no idea where you got the rest of.
Earlier quoted context omitted.
> If a good developer you know, recommends someone they worked with: It's almost an instant hire. But for the rest, yeah, it's incredibly tough. A talk I watched recently by Ijeoma Oluo made a point I had never considered before: statistically, most people refer friends, and most friends are of a similar background, race, culture, gender, etc. It's not intentional- people aren't going out of their way to only refer p…
What is the upside of a higly diversified worksforce? Where I work we're all white males age 20-60 except accounting, they're white females around age 30. What's bad about this? What value does it bring to diversify, what should we look for and why is it important? Or are we too small to need diversifying yet with only about 30 employees?
Your competitors will read that research.
edit: carlhjerpe is right- this is super condescending. Downvote me.