Live data from Hacker News

Today’s Top Tech Skills

hiringlab.org

241–250 of 373 posts

Re: Today’s Top Tech Skills

#241

Earlier quoted context omitted.

Fascinating statement which I feel is probably agreed upon by many. I can see how that can be true; but once again,I feel, demonstrates that HN has a specific subset of "developers"/"techies"/"enthusiasts". In any "Enterprise" environment I've ever been in - core back-office enterprise resource planning apps or similar - SQL is right there front and center. "Should" it be? I don't know, I'm not a theoretician; but al…

I think the phenomenon you're describing is exactly what led to the rise of no-sql dbs. SQL allow you to do too many things, a lot of things that could happen in programming. From a design point of view, that's not a good thing, you want a data store to do just what it is - a data store, all joining and such can happen somewhere else - just make sure it's in the same transaction. I see many of the problem stem from a…

>>From a design point of view, that's not a good thing, you want a data store to do just what it is - a data store, all joining and such can happen somewhere else - just make sure it's in the same transaction.

See, that's exactly why I indicated I'm not a theoretician and do not feel comfortable making such a sweeping "Should" statement (much as I would've made an opposite one:).

Immediately my question is "Why?" and "What data do you have to back it up?". I understand model-view-controller etc is a design pattern, but are we certain that it's always the right one?

From my trenches perspective: relational RDBMS has been around for neigh half a century. It's an INCREDIBLY mature, optimized, understood (by experts), common, standardized (for all the individual RDBMS differences), safe technology. I have team members who have been doing hard-core SQL for 20+ years, and a market full of similar, serious, hardened experts. And it'll survive changes in the higher-up stacks - in my own meager career of ~20 years, relational RDBMS has been the most stable part of the stack.

I can get a 3-5 year 'expert' on a particular programming stack, or a 20-year expert on SQL, who has seen things and will safeguard customer's data and business priorities with their life. Again, a very personal experience, but the dozens of clients I've been with, have broadly similar priorities, objectives and concerns on database level; and occasionally vastly different ones on layers above. It's a brilliant unifying common denominator.

Without a fun discussion over a drink and whiteboard, and it could be my inability to see forest for the trees, but I'm just not convinced that "all joining and such should happen somewhere else" :-\

[note, I didn't downvote your comment - I don't necessarily share the same conclusions, but I think it contributes to discussion :-]

Re: Today’s Top Tech Skills

#242

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…

There is nothing about Nosql databases that force you to have eventual consistency or lack Transactions. As far as forcing the correct schema, if you are using a statically typed language, it can enforce a “schema”. For instance with C#, LINQ and the standard Mongo driver, you work with strongly typed MongoCollection and perform LINQ queries with IMongoQueryable.

Amazon’s DynamoDB for instance supports transactions and optionally consistent reads. With Mongo you can set your WriteConcern to force strong consistency. Mongo also supports transactions.

Re: Today’s Top Tech Skills

#243

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…

Even if you are using an RDMS it doesn’t help to protect you against many business rule violations. Your data may be relationally correct, but that’s about it.

Re: Today’s Top Tech Skills

#244

Earlier quoted context omitted.

It depends on the person interviewing you. It's common enough for them no to be technical at all, such as a scrum master or project manager, it's also common enough for the first person on site (those working for really low remuneration and a lottery ticket) to just not be that good.

This is crazy to me. Any reasonable certification to qualify someone for an AWS specific role will cover IaC in depth. I guess it explains a lot about the number of cloud antipatterns I see on a day to day basis though.

I've seen people with certs who are fairly crazy too, and heard comments like "$foo is good in theory, but it's not really possible in practice".

I'm afraid its a large part of the market here, but you're more exposed to the different parts of the market when you're contracting and thus moving around on a semi-regular basis.

Re: Today’s Top Tech Skills

#245

I got back into java recently and am appreciating how you can define an interface reference type super class then swap out the different data structure subclasses as their implementation. E.g. make a queue refer to either PriorityQueue or LinkedList. Or make a Map a HashMap or TreeMap. It kind of provides an "aha!" moment in deeper understanding of why there are so many Datastructures and why it actually matter to pi…

That's my contender for both biggest pro, and biggest con, of Java. Because where it breaks down is where the implementations are not clear, the tradeoffs are not clear, and the interfaces are not abstract enough to switch between (for instance, this useful library gives you a Future, and this other one requires a CompletableFuture).

Re: Today’s Top Tech Skills

#246
post #164

Good applications tend to get the database right first - since you can always re-write the mid-tier code relatively easily. It's pretty much essential to any developer. Further it's a ridiculous superpower if you're not a developer - it's so empowering for anyone on the business side with questions to just go look in the db.

Weird, this is completely opposite to what a lot of people I've worked with have said. What do you think about having business logic in the DB layer too? I saw someone on another post recommending that which, again to the people I have worked with, is an antipattern.

Somewhat related quote:

Linus Torvalds: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships."

IMO proper database design is extremely important. Code is fluid. You can replace it. Data is not that fluid, it's much harder to change it. Database should contain checks to ensure that bad data won't be saved.

I don't think that complete business logic should be in database. Keep data in database, keep your code in your application. Database is responsible for data storage and some data validation to prevent misbehaved apps storing obviously bad data. Application is responsible for everything else.

Re: Today’s Top Tech Skills

#247
post #114

Good applications tend to get the database right first - since you can always re-write the mid-tier code relatively easily. It's pretty much essential to any developer. Further it's a ridiculous superpower if you're not a developer - it's so empowering for anyone on the business side with questions to just go look in the db.

I actually fully disagree. I find it much easier to "fake" the DB in the first stages (like just store shit in memory) where you explore and understand what your system must do, the questions it should answer with data from the DB, etc. Then, just replace your fake repo with an actual DB and you're done. And it goes with what you're saying: changing a schema is not as easy as changing the code. So start by really und…

I agree and especially with C#, your LINQ expressions will be the same whether you are working with in memory lists, Entity Framework for RDMS’s or Mongo for Nosql. Your queries will be translated appropriately either way.

Re: Today’s Top Tech Skills

#248
I don't understand why java wins?

despite:

- the mess with ".equals()" and "==".

- arrays don't accepts generics.

- no (non-verbose) partial application

- awfully verbose syntax that clutters the screen with unimportant things making important things hard to spot.

- the confusing leaky abstraction with Integer and int.

Re: Today’s Top Tech Skills

#249

Java is still undisputed in the enterprise. Node.js was a contender but lost steam. May be .net once it becomes truly platform neutral have a chance to take on Java. Until then most probably it will remain widely popular.

Is it really your experience that node was ever a contender? In what context or application? Also enterprise is almost all windows on the client and on the server still has lots of traction; I don't see why .net needs platform neutrality to take a big piece of this.

I find the numbers reported here pretty flawed; ".net" is down while "C#" is up about the same amount. I realize this data is based on keywords, so maybe this just means clueless HR posts are finally stoping the practice of saying "must have .net, C# and ASP.NET"

Stating "SQL" is the top skill is also pretty pointless; I've rarely met a developer who will say "I don't know SQL" because most think this means "can write simple SELECT statment", which a lot of the time is enough.

Re: Today’s Top Tech Skills

#250

I don't understand why java wins? despite: - the mess with ".equals()" and "==". - arrays don't accepts generics. - no (non-verbose) partial application - awfully verbose syntax that clutters the screen with unimportant things making important things hard to spot. - the confusing leaky abstraction with Integer and int.

Because there are programming languages people hate and programming languages people don't use.
Post reply on HN