Live data from Hacker News

Today’s Top Tech Skills

hiringlab.org

141–150 of 373 posts

Re: Today’s Top Tech Skills

#141

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…

Again, you just pick data as the "one" core business critical technology. I guess you are an SQL export? There are dozens of critical points of failure. Losing your HA gateway during an expensive ad campaign, designing your network/data center wrong such that your SQL cluster goes down etc. etc. Even JavaScript that hides the "checkout" feature. I didn't even go into security (think your domain gets hijacked, or XSS injection on your site etc.).

Re: Today’s Top Tech Skills

#142

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

While a front end bug that gets in the way of sales is bad for a business, a poorly designed or buggy data layer can cause issues throughout the rest of the application. It can lead to things like lack of isolation between users, loss of data, data inconsistency, and scalability issues.

Re: Today’s Top Tech Skills

#143

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

Not when you’re corrupting only a handful of sales, but losing all of them. It still feels arbitrary to say one is more important for developers to be aware of than the other here.

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

#144

Earlier 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

I've found Mybatis[1] to be a better alternative to Hibernate. At least with the version I was using you had to do complex mapping in XML instead of annotations which isn't great but I'll make the trade-off to avoid the ORM. Not sure if this is improved in 3.5. [1] https://github.com/mybatis/mybatis-3

Re: Today’s Top Tech Skills

#145

In 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…

That's because a different database may have different transaction isolation than an another one. Fairly complex SQL queries cannot be used between different major databases.

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

#146
post #138

Earlier 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…

Testing against the real database? Won't keeping a copy of the database just for that be expensive?

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

#147
post #14

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

Realistically skills in one are transferrable as long as you're thinking of the components in terms of abstractions. For instance, use a deployment pipeline to deploy your microservice with a frontend api for queries against your scalable database, subscribe to your event source and create your faas consumers to push data to your next bounded, isolated component.

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

#148

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

...that's assuming there's some sort of meaningful liability in corrupting the data, either legal or from PR backlash, but sometimes it feels like many companies have discovered that's not really the case.

Re: Today’s Top Tech Skills

#149

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…

This argument is entirely arbitrary.

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

#150

In 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…

Other alternative worth mentioning is myBatis.
Post reply on HN