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

171–180 of 373 posts

Re: Today’s Top Tech Skills

#171

Post by Aperocky »

NikolaNovak wrote: post #119
Aperocky wrote: post #105

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.

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 undesirable design of the tables - not splitting them when you can, having too many foreign keys, and generally being a interconnected mess. Having dealt with nosqls, I attest that it is much better in that it forces you to design things in an atomic way, preventing many of the potential problem you might have down the line from the beginning.

Re: Today’s Top Tech Skills

#172

Post by ownagefool »

nostrebored wrote: post #157
ownagefool wrote: post #108

Earlier quoted context omitted.

I think the biggest problem with hiring an AWS or Azure consultant, is you might not get someone who actually does infrastructure as code (at least this happens a fair bit in London). I'd rather hire someone who knows terraform and another cloud, than somebody who'll click on the GUI for my preferred cloud, and make excuses around not being able to follow process.

This is insane -- how do these people pass through an interview?

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.

Re: Today’s Top Tech Skills

#173

Post by yowlingcat »

littlecranky67 wrote: post #141
yowlingcat wrote: post #115

Earlier quoted context omitted.

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…

I never said there was only "one" core part of business critical technical competency. What I'd say is that there are several of them in high priority that have an out-sized effect on long term project success. One of them (security) probably has a similarly outsize effect, but everything else you're describing is operations. It doesn't have an effect on how you design your software, and whether it exhibits correct behavior.

At the most basic conceptual level, the business of software rests on reading inputs correctly, processing them, and writing the right outputs with strong guarantees. SQL is historically the most sophisticated, powerful, common and cross platform way to do that in a structured manner that is easy to reason about for a vast majority of use cases. You can layer an application on top of the foundation of an appropriate data model, but the appropriate data model is a root requirement to even get to a passable prototype. That is why gradual mastery of it yields such outsize payoffs compared to mastering other skills.

Re: Today’s Top Tech Skills

#174

Post by daxfohl »

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…

Blech, the worst thing I've noticed after moving to document databases even when scale does matter is the loss of the relational data model. A nice ERD that shows relationships between your entities makes everything so simple. You could have one for document database as well but people stare at you strangely. So now it's just a random collection of collections of stuff, and it takes 10x more words to describe your design.

Re: Today’s Top Tech Skills

#175

Post by mmsimanga »

wehrkeoruw wrote: post #162
mmsimanga wrote: post #122

Earlier quoted context omitted.

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…

There are lots of ways to interact with folks who don't understand something that get your point across without making them feel bad. I'm guessing you didn't employ any of those strategies.

The truth is probably somewhere in between. I was firm but polite. I was called in because I was going to be analyzing the data. Build data warehouse and import other data. I had to be firm because I know how much time it takes to clean up data before you can analyse it.

Re: Today’s Top Tech Skills

#176

Post by nostrebored »

ownagefool wrote: post #172
nostrebored wrote: post #157

Earlier quoted context omitted.

This is insane -- how do these people pass through an interview?

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.

Re: Today’s Top Tech Skills

#177

Post by apta »

SlowRobotAhead wrote: post #37
_bxg1 wrote: post #16

Earlier quoted context omitted.

I figured that was mostly due to legacy code at this point; is it undisputed for new code too?

I can only speak from experience, but I know two large corporate entities that used Java and have over the years dropped it in favor of Go and websites. Edit: i like how my first hand experience is disagreeable and should be hidden. This site gets STRANGE with facts that users just don’t want to see.

Basically fad driven development.

Re: Today’s Top Tech Skills

#178

Post by davidjnelson »

itronitron wrote: post #99
MatekCopatek wrote: post #68

Earlier quoted context omitted.

What would you say is the special thing about this particular bit of knowledge that made you point it out? To be perfectly honest, it seems quite arbitrary to me. I could say I'm surprised to see how many people don't know anything about the browser rendering pipeline and consequently produce badly performing interfaces. Someone else would complain about people's inability to do even the most basic Linux administrati…

>> many people don't know anything about the browser rendering pipeline if you can recommend a good source for learning the browser rendering pipeline please post it here, everyone I have asked just shrugs it off and says that no one really knows.

This one is quite good. I posted it to Hn 6 years or so ago but it didn’t get upvotes:

https://www.html5rocks.com/en/tutorials/internals/howbrowser...

Re: Today’s Top Tech Skills

#179

Post by darkerside »

jackcodes wrote: post #143
ThrowawayR2 wrote: post #136

Earlier quoted context omitted.

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.

You are potentially corrupting ALL of your data, not just a handful. Sure, in the two scenarios you chose to provide (speaking of arbitrary), the JS error is clearly worse. If you take the worst case scenario in both cases, one is much more likely to cause an existential threat to your business.

Re: Today’s Top Tech Skills

#180

Post by yowlingcat »

arcticfox wrote: post #149
yowlingcat wrote: post #115

Earlier quoted context omitted.

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

I get the sense that you and other commentators are putting a certain binary in place, and I'm not sure it's in good faith. Nobody ever said that you have to pick one particular place to be an expert in, and if you're not an expert there, you're not a good engineer. That's an absurd argument, but it's also not what is being said.

The truth is, you need to be good enough at all of the high priority parts of technical competency. Security, monitoring, performance -- sure, all of those are also extremely important. They're all places where unforced errors can be introduced that can and do hurt the business -- sometimes catastrophically or fatally.

With that said, to not recognize the evergreen utility of domain design skills is ignorant. You will never get the luxury to worry about security, monitoring, or performance if you don't build the state machine that makes the right outputs out of the right inputs because you will either never sell it to a customer, or lose that customer when they choose a competing solution which actually does what it's supposed to do.

It's not true that everything is equally important. I think that's a myopic way to look at software development without considering the business impact of key crucial areas where software design and maintenance intersect with stakeholders.

Post reply on HN