Earlier quoted context omitted.
I think the point to be made was that if you screw up your browser rending to the point of it being unusable on old devices, that could be just as business critical as the data integrity issue. Making either of those your line in the sand for what a developer should and shouldn’t know is arbitrary. I don’t know a ‘Scala’ full-stack developer that could do advanced optimisation on React render times, or a ‘React’ deve…
The difference is that if you screw up your browser rendering, you're not messing up your data integrity at rest and creating compound technical and potential business debt. If anything in the critical path from pricing to payments that talks to your data store makes a mistake, you can risk anything from not recording your transactions properly to charging the wrong amount or not enough at all. It's very expensive to…
Today’s Top Tech Skills
141–150 of 373 posts
Re: Today’s Top Tech Skills
#142Earlier quoted context omitted.
It's not arbitrary because screwing up your data integrity is far and away one of the most painful and business critical mistakes you can make as an engineer. Your product isn't finished if it looks like it works, but is either storing data improperly at rest or doing the wrong thing with it.
Again, arbitrary. You could also argue a JavaScript bug on your site preventing a shop checkout is the worst, because you lose Cash by the minutes.
Re: Today’s Top Tech Skills
#143Earlier quoted context omitted.
Again, arbitrary. You could also argue a JavaScript bug on your site preventing a shop checkout is the worst, because you lose Cash by the minutes.
You have got to be kidding. Corrupting data for a sale already made is far worse than losing a sale because of an outage.
As long as you have both covered to a reasonable degree within your company/team it’s a waste of time arguing who’s got the most important info in their brains.
Re: Today’s Top Tech Skills
#144Earlier quoted context omitted.
I agree. Use the right abstraction and the right number of them: I’ve yet to find an ORM that didn’t kick you in the face In terms of performance to only hold your hand with queries. SQL queries can be done in code in a sane way to avoid sql injection or you could implement stored procedures and functions to make operations more ORM-like but not pay any of the ORM tax. It’s just annoying to see the DB treated so flip…
I think HugSQL[1] (Clojure library) has really opened my eyes to what DB interaction should be like. It’s not exactly an ORM, but it protects you from SQL injection and makes it convenient to leverage the capabilities of your SQL database. Also, his name is Usain Bolt[2]. [1] https://github.com/layerware/hugsql [2] https://en.m.wikipedia.org/wiki/Usain_Bolt
Re: Today’s Top Tech Skills
#145In the recent two or so years I was surprised to see how many people don't _really_ know about SQL. Sure they can write a simple insert and update query and maybe a join, assuming they can just ignore that there actually are different types of joins. But if you ask them about other _still fundamental_ knowledge like a _rough_ idea about what the different transaction isolation level are/mean/imply for you, they fail…
I am one of those who don't care about SQL, I assume it will fail and in general avoid transaction as much as possible.
Re: Today’s Top Tech Skills
#146Earlier quoted context omitted.
TBF, sql queries is something you _don't_ want to have in your code stack. It should be abstracted away in some kind of DAO, and no one should be worrying about SQL queries when they're developing new features.
I strongly disagree. For many backends/purposes, SQL is really the thing doing all the real work and the backend's just some fancy authentication and validation layer. Stick close to the technology doing the heavy lifting. If people abstract away SQL too much they just start reimplementing things in buggy underperforming code, using 1000 lines of Go or Java or whatever what should be done in 20 lines of SQL. Also, do…
Also, should devs really be seeing potentially sensitive data?
On a side note, "I use SQL so I can change the backend language" is the hottest take I've heard in some time heh.
Re: Today’s Top Tech Skills
#147It remains weird and disturbing to me that "AWS" is treated as a skill. Not "cloud system management", but " AWS ". Edit: I do understand why it can be lucrative to have expertise with a specific cloud provider. It's just the status quo of these services being their own unique silos that disturbs me: I would personally be wary of making "ability to effectively use Amazon's servers" a pillar of my career.
This is something you can do with any provider, the names are irrelevant.
Some features are lock in, but this lock in can be seen as tech debt prior to delivery.
Being able to architect cloud systems is just being able to architect distributed systems. Specializing in one isn't a huge problem.
Re: Today’s Top Tech Skills
#148Earlier quoted context omitted.
Again, arbitrary. You could also argue a JavaScript bug on your site preventing a shop checkout is the worst, because you lose Cash by the minutes.
You have got to be kidding. Corrupting data for a sale already made is far worse than losing a sale because of an outage.
Re: Today’s Top Tech Skills
#149Earlier quoted context omitted.
I think the point to be made was that if you screw up your browser rending to the point of it being unusable on old devices, that could be just as business critical as the data integrity issue. Making either of those your line in the sand for what a developer should and shouldn’t know is arbitrary. I don’t know a ‘Scala’ full-stack developer that could do advanced optimisation on React render times, or a ‘React’ deve…
The difference is that if you screw up your browser rendering, you're not messing up your data integrity at rest and creating compound technical and potential business debt. If anything in the critical path from pricing to payments that talks to your data store makes a mistake, you can risk anything from not recording your transactions properly to charging the wrong amount or not enough at all. It's very expensive to…
What about security? Your business won't succeed if you're hacked daily.
What about monitoring? If you're losing data and don't even know it, you're creating compound technical and potential business debt.
What about performance? Once you have a perfect data model, no amount of trying to optimize it will improve your business further. Optimizing other parts of the application can.
Basically everything is important, saying that just because someone isn't an expert in one phase that they're not as good of a developer is myopic.
Re: Today’s Top Tech Skills
#150In Java I'm a big fan of using SQL directly versus ORM. To that end I highly recommend JOOQ. I library that allows for object oriented SQL. Its not ORM, so you still compose SQL, you just get a lot objects and methods to allow you to construct your SQL in an OO, and functional, programming type way. It also is a DB first approach. Where you construct your DB schemas and tables first, then use JOOQ to create objects t…