Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Today’s Top Tech Skills

hiringlab.org

Post reply on HN
Print view View original

131–140 of 373 posts

Re: Today’s Top Tech Skills

#131

Post by xrisk »

Aperocky wrote: post #105
dathinab wrote: post #25

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…

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.

You can't optimize well enough if your abstraction layer is too far away from your application layer.

Re: Today’s Top Tech Skills

#132

Post by NikolaNovak »

sidlls wrote: post #54
bsaul wrote: post #41

Earlier quoted context omitted.

because price ( aka salary / fee) is a function of supply and demand and it grows the more the skill is in demand. As simple as that. Let’s say you want to start a career as a freelance for example : what skill to you put forward ? You may say « but jobs requiring elixir are probably more interesting than sql/java ». I agree, but that is if there’s one position open at the time you’re looking , in the area you’re loo…

It isn't that simple. Most "Java + SQL" jobs are run of the mill cost-center type jobs at companies that aren't tech companies. Their salaries, benefits, and locales are generally poor relatively to other software engineering jobs. The demand is high, and so is the supply of labor, but that isn't the whole picture.

I would agree with that picture. In other comments on this thread, I've indicated Java & SQL are the #1 demands on any project I've ever worked on.

At the same time though, none of those people have earned anything remotely what I tend to see on HN in general, and SF area in particular. From my limited experience, it feels like a good, experienced, hardened, senior Java developer in Toronto, Canada (not a tiny/cheap place), makes about half what a hot-startup-technology intermediate makes in SF :-\

Re: Today’s Top Tech Skills

#133

Post by jugg1es »

dathinab wrote: post #25

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…

My company is in the midst of a modest hiring blitz and it is really eye-opening how few applicants are actually writing SQL in the coding exercise as opposed to using a highly-opinionated ORM. More damning - in my opinion - is that they mostly have blinders to how much time they are spending working around ORM limitations on a day-to-day basis.

Re: Today’s Top Tech Skills

#134

Post by coldtea »

momokoko wrote: post #61
taffer wrote: post #55

Earlier quoted context omitted.

I wouldn't say so. Concurrency bugs, like lost updates, can be very subtle and hard to debug, and common databases don't prevent these kinds of bugs by default.

If someone on my team was writing a web app and spending time meddling around with transactions outside of whatever abstraction layer we were using on top of the DB without an incredibly good reason, we'd definitely be having a coaching moment, and if it continued, I'd likely help them find a role with another org where they might be a better fit. Any quality database abstraction provides fairly simple means to perfo…

>If someone on my team was writing a web app and spending time meddling around with transactions outside of whatever abstraction layer we were using on top of the DB without an incredibly good reason, we'd definitely be having a coaching moment, and if it continued, I'd likely help them find a role with another org where they might be a better fit.

And most people with knowledge of DBs should run, not walk, away from a team that operates like that...

Re: Today’s Top Tech Skills

#135

Post by mpartel »

bradleyjg wrote: post #110
mpartel wrote: post #60

Earlier quoted context omitted.

It can seem that way, but the consequence of not knowing them is lots of subtle race conditions. Granted, most webapps probably don't have enough users to trigger them too often, and the impact is often limited e.g. because the kinds of inconsistencies you can introduce don't actually matter that much in many cases. For the majority of webapps, I'm not sure the default isolation level of MySQL and Postgres is an appr…

> Granted, most webapps probably don't have enough users to trigger them too often It isn't purely a matter of number of users. You can have a billion users, but if your access pattern is embarrassingly isolated you are still probably okay. (And sharding is going to work great to boot.)

True, though even a single user triggering two actions quickly can cause issues if unlucky.

Re: Today’s Top Tech Skills

#136

Post by ThrowawayR2 »

littlecranky67 wrote: post #101
yowlingcat wrote: post #86

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.

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

#137

Post by ellius »

jmartrican wrote: post #83

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…

My team (Spring Boot / Angular greenfield app in an enterprise) has a guy that transitioned over from .NET and is totally new to the Java ecosystem. He has 30+ years experience with SQL and can't stand entity frameworks or make them do the best-practice stuff he knows we should be doing, but with JOOQ he's had a lot of success bringing his extensive knowledge base to bear on our project.

Re: Today’s Top Tech Skills

#138

Post by dagss »

Aperocky wrote: post #105
dathinab wrote: post #25

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…

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, don't get med started on people thinking they can abstract away tye database for testing. The automated test suite should always include the real database you are working against and all queries executed. I will never write a backend again without testing against the real database (whether sql or nosql).

Some people justify abstracting away the database saying "one needs to be able to switch to an arbitrary storage engine". Well..storing things is probably the main purpose of your backend. I sometimes turn that around and say, "I want to write things in SQL so that I can easily change what language the backend is written it".

Re: Today’s Top Tech Skills

#139

Post by nostrebored »

chaostheory wrote: post #71
dathinab wrote: post #25

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…

I’ve used both relational DBs and nosql professionally. While in super specific use cases, NoSQL does shine; it’s a giant mistake to use them as a generic, general data store like with a traditional SQL database. You end up doing a lot more avoidable work in the long run especially if you’re doing reporting ie something that SQL can easily handle, you end up having to replicate it in your own code base

Why is making a materialized view for reporting hard? Shouldn't components be aware of what they need to enable analytics?

I don't see how adding logic to a service at runtime is any different than fiddling with queries and optimizing them

Re: Today’s Top Tech Skills

#140

Post by geitir »

mmsimanga wrote: post #122
dathinab wrote: post #25

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…

Some months ago I sat in a meeting to discuss design and implementation details for a medicine delivery system. The fact that it was about medicine I thought it would be obvious to everyone that we would have to use a relation database with ACID properties. Last thing we want is to send medicine at best effort, I assumed everyone would be on the same page on the need to use transactions, foreign keys and all other da…

So they went with a non relational?
Post reply on HN