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

In-demand tech skills are the last thing to look for in IT hires

netsuite.com

Post reply on HN
Print view View original

71–80 of 116 posts

Re: In-demand tech skills are the last thing to look for in IT hires

#71

Post by Oddskar »

nawgz wrote: post #46
Oddskar wrote: post #23

Earlier quoted context omitted.

REST? Didn't you get the memo? We've all moved on to GraphQL because Facebook use it and that means we all should use it. It also enables our UI components to easily fetch data themselves . Because that's a great architectural pattern that we've discovered.

It's unironically true that GraphQL in combination with database introspection & query tools like Hasura is a far superior pattern to REST-based CRUD. Additionally, as a UI developer, I understand you are trying to make it seem like GraphQL promotes anti-patterns, but being able to make a single query which is deeply nested and therefore can maintain state for an entire sub-tree of your app is a really good state man…

I'm not praising REST at all. REST as it was de-facto used was in my opinion a hot mess that was poorly understood and had developers focus on the wrong things (e.g. pretty urls).

I still don't think GraphQL as state management is a good idea for anything surpassing moderate complexity. And yes I've worked with both GraphQL and Apollo. I can see the merits for sure; for instance discoverability and being able to generate types from the API are great. I don't like overcommitting to Apollo though and using the overly sized client. Something is wrong when your state management is bigger in filesize than the SPA framework you're using.

Re: In-demand tech skills are the last thing to look for in IT hires

#72

Post by jrochkind1 »

Jensson wrote: post #58
jrochkind1 wrote: post #45

Earlier quoted context omitted.

Equating "He will respectfully probe for intent in a way that doesn’t put the requester on the defensive" with "tip-toeing around issues" seems... not right to me.

You took out a part, why would a developer ever need to say this except to calm a toxic manager? > He will make it clear that this is a partnership, and that getting the job done is high on his list of priorities

Well, I think one reason a developer would need to make that clear, is so many people have so much experience working with developers like you who make the opposite clear, that they assume the worst.

Re: In-demand tech skills are the last thing to look for in IT hires

#73

Post by wvenable »

Jensson wrote: post #65
wvenable wrote: post #62

Earlier quoted context omitted.

You have a strange idea of what talking normally is. Fears, concerns, having different priorities, working under their own deadlines, and so on are all normal for other people.

But a manager dumping those feelings on their developers is still toxic. They are coming from a position of power, asks the technologist to solve a problem, all the while demanding the technologist assures the manager that the technologist will do the job and that now the technologist will ask questions so the technologist can perform the job well instead of just wasting the managers precious time. I don't see how an…

I don't think the in-article example is a good one. However, the sentiment that developers need to have good soft skills if they work with end users is an important one. It doesn't matter how good you are building software if you build the wrong software.

Re: In-demand tech skills are the last thing to look for in IT hires

#74

Post by bob1029 »

Jensson wrote: post #69
bob1029 wrote: post #47

Our interviews for tech hires have gradually evolved into an interrogation regarding a person's attitude towards work/peers more so than their knowledge about how to do specific tech things. Teaching a willing participant how to do virtually anything with a computer is feasible in 2021. We need people who are willing to engage difficult, fast-changing things substantially more than smart-asses who think they know eve…

> Teaching a willing participant how to do virtually anything with a computer is feasible in 2021 You could become a billionaire in the coding bootcamp space if you know how to do this.

The coding bootcamp space is largely a scam in my experience. I have never seen someone go through one of those and then go on to become an employed developer.

The idea that you can cram programming into someone's head in a matter of hours/days/weeks is ridiculous. It is a natural exploration that takes time to stick. You will notice I did not describe any time constraints in my post. We have no problem investing years into individuals who posess the right attitude. Learning by example and exposure over time is the best way to become a master.

Re: In-demand tech skills are the last thing to look for in IT hires

#75

Post by handrous »

nawgz wrote: post #61
handrous wrote: post #55

Earlier quoted context omitted.

Hasura is great. GraphQL on its own, unless you're offloading all of it to something well-maintained and capable like Hasura which will (hopefully) automagically save you from the time cost and risk of GraphQL, is almost always a bad idea.

"Using a protocol you don't understand without a tool that implements it is a bad idea" Listen, I get it, we all want to hate on NIH and cutting-edge stuff, but what you've said is not an objection. GraphQL is a complicated protocol, but it offers a very clean interface between clients & servers, and when you put in a strong implementation you can generically access data that before you needed to specifically access.…

> what tips GraphQL into a superbly expensive and risky area

The TL;DR is that implementing it without something that automagics away most of the work, does some clever stuff to save you from various pitfalls, and is very heavily battle-tested is approximately as bad an idea as exposing your SQL server directly to the web browser, except that you could do that for free. "Oh no I couldn't, I'd have to do so much work to make sure that access is safe—there's no way that would pay off, and I'd probably still manage to deploy DOS or data access vulnerabilities!" Yep, exactly.

It's also of dubious benefit vs. other options if you fully control both the front-end and back-end and aren't planning to allow lots of 3rd party users of your API—though even in that case Hasura, in particular, may still be a win despite GraphQL, not because of it.

Re: In-demand tech skills are the last thing to look for in IT hires

#76

Post by nawgz »

handrous wrote: post #75
nawgz wrote: post #61

Earlier quoted context omitted.

"Using a protocol you don't understand without a tool that implements it is a bad idea" Listen, I get it, we all want to hate on NIH and cutting-edge stuff, but what you've said is not an objection. GraphQL is a complicated protocol, but it offers a very clean interface between clients & servers, and when you put in a strong implementation you can generically access data that before you needed to specifically access.…

> what tips GraphQL into a superbly expensive and risky area The TL;DR is that implementing it without something that automagics away most of the work, does some clever stuff to save you from various pitfalls, and is very heavily battle-tested is approximately as bad an idea as exposing your SQL server directly to the web browser, except that you could do that for free. "Oh no I couldn't, I'd have to do so much work…

Well, a tl;dr that says implementing a heavy protocol poorly is a bad idea is once again a non-statement.

> It's also of dubious benefit

Laughable. Comparing to the silly comparison of "direct SQL queries", both have lots of dangerous pitfalls, sure, but direct SQL queries give you no wins in-and-of-themself. For implementing GraphQL on the other hand, you get schema definitions, discoverability, strict typing across a network call, a large set of tooling you can plug in that "just works" because GraphQL is a protocol designed to tackle modern web issues, and more. GraphQL is not just "exposing your database directly", I think it shows a lack of experience with it that you think that way

Re: In-demand tech skills are the last thing to look for in IT hires

#77

Post by nawgz »

Oddskar wrote: post #71
nawgz wrote: post #46

Earlier quoted context omitted.

It's unironically true that GraphQL in combination with database introspection & query tools like Hasura is a far superior pattern to REST-based CRUD. Additionally, as a UI developer, I understand you are trying to make it seem like GraphQL promotes anti-patterns, but being able to make a single query which is deeply nested and therefore can maintain state for an entire sub-tree of your app is a really good state man…

I'm not praising REST at all. REST as it was de-facto used was in my opinion a hot mess that was poorly understood and had developers focus on the wrong things (e.g. pretty urls). I still don't think GraphQL as state management is a good idea for anything surpassing moderate complexity. And yes I've worked with both GraphQL and Apollo. I can see the merits for sure; for instance discoverability and being able to gene…

> I still don't think GraphQL as state management is a good idea for anything surpassing moderate complexity

This statement is a bit hard to break down. What is "moderate complexity"? For example, I have implemented layers where GraphQL queries feed into mobx to manage some additional application state that never persists. I didn't even use apollo client for this, I just fired off a REST query.

Apollo client, on the other hand - I don't really know what you mean about "overly sized client", I am under the impression you can get it for 12-30kb, while React+DOM is 100-160kb (sorry not sure which numbers are gzipped here). I additionally think that it's a very light layer in terms of managing state, when I speak of "managing state via GraphQL" what I really mean is knowing when the client-side cache needs to update, and this is way easier than REST or for that matter anything else I've seen. In this regard, you can sync the server-side and client-side data easily and directly, and then use whatever state management solution you wish for your application.

Ok, besides it all, if you're just making fun of everything, that's fair, but it seems strange to mock something new / popular / powerful without any mention that it does things better than the old popular solutions

Re: In-demand tech skills are the last thing to look for in IT hires

#78

Post by opportune »

softfalcon wrote: post #32
blueslurpee wrote: post #7

>Sure, in the ’80s, it might have been possible for one person to do it all: systems administration, database, coding, design. But in today’s world, database administrators, infrastructure engineers, coders, designers, project managers and others — whether on staff, on contract or with a vendor or service provider — must work together to execute projects quickly, securely and reliably. Tech today is a team sport. I f…

I want to preface my thoughts with that I wish the "team sport" mentality was more common in the dev world. Unfortunately, I have to agree with blueslurpee here. I frequently join a team and find there are 1 or 2 devs who "know everything" and it is near impossible to pull the information out of their heads and into mine or someone else. This might be isolated to the areas I work in, but I do find that the "10x engin…

How much of that is because those people aren’t being team players vs them learning things differently?

In my experience the people who “know everything” either wrote the code from scratch (thus understanding it at a deeper level than the quick summaries people would use to describe it) or just read.the.damn.code. This is a problem I also deal with working with junior team members who would rather ask a question about how something works rather than read the source. Even if I do try to explain it, I can’t explain it to the fidelity and nuance encapsulated in the actual code. Nor can I explain the context as well as clicking “find references” does.

As such I am not sure those people who know everything are secretly zealously guarding their information. Any brief explanation of something technical is simply too low-res compared to reading its implementation. So even if that person is super nice and tries to help as much as they can, I doubt anybody would learn as much as them just from secondhand information, as opposed to reading/writing/modifying the source themselves.

Re: In-demand tech skills are the last thing to look for in IT hires

#79

Post by Oddskar »

nawgz wrote: post #77
Oddskar wrote: post #71

Earlier quoted context omitted.

I'm not praising REST at all. REST as it was de-facto used was in my opinion a hot mess that was poorly understood and had developers focus on the wrong things (e.g. pretty urls). I still don't think GraphQL as state management is a good idea for anything surpassing moderate complexity. And yes I've worked with both GraphQL and Apollo. I can see the merits for sure; for instance discoverability and being able to gene…

> I still don't think GraphQL as state management is a good idea for anything surpassing moderate complexity This statement is a bit hard to break down. What is "moderate complexity"? For example, I have implemented layers where GraphQL queries feed into mobx to manage some additional application state that never persists. I didn't even use apollo client for this, I just fired off a REST query. Apollo client, on the…

> For example, I have implemented layers where GraphQL queries feed into mobx to manage some additional application state that never persists.

Not sure what you want to say with this because it sounds like you used Mobx for state management in that case. Or do I misunderstand you?

> I additionally think that it's a very light layer in terms of managing state

According to bundlephobia:

React + DOM = ~42KB Gzipped

@apollo/client = 39KB Gzipped

For reference redux + redux thunk is like 2KB

Xstate is less than 20KB

> what I really mean is knowing when the client-side cache needs to update

Aha, and that sounds sensible. I agree. There are lots of other things in Apollo though that you apparently aren't using.

Re: In-demand tech skills are the last thing to look for in IT hires

#80

Post by handrous »

nawgz wrote: post #76
handrous wrote: post #75

Earlier quoted context omitted.

> what tips GraphQL into a superbly expensive and risky area The TL;DR is that implementing it without something that automagics away most of the work, does some clever stuff to save you from various pitfalls, and is very heavily battle-tested is approximately as bad an idea as exposing your SQL server directly to the web browser, except that you could do that for free. "Oh no I couldn't, I'd have to do so much work…

Well, a tl;dr that says implementing a heavy protocol poorly is a bad idea is once again a non-statement. > It's also of dubious benefit Laughable. Comparing to the silly comparison of "direct SQL queries", both have lots of dangerous pitfalls, sure, but direct SQL queries give you no wins in-and-of-themself. For implementing GraphQL on the other hand, you get schema definitions, discoverability, strict typing across…

My assertion, broadly, is that GraphQL is incidental to the good things that have grown up in its ecosystem, that GraphQL is per se not especially good or interesting, and that attempting to replace a traditional REST interface with it, without also bringing in a large stack of supporting tech that you didn't need before, is almost certainly a bad idea that will end in tears, because it is heavily dependent on those things to not-suck. Nonetheless, the hype has companies burning money on it, as is always the way with hype.

I would agree that it's really, really easy to improve on JSON, which is a curse on our industry.

And yes, I have experience with GraphQL. I think it has very little useful or cost-justifiable place unless you buy in to a heavy and very capable 3rd party system to manage at least the server-side portions for you, automagically. It's similar to buying into Rails. Absent that, yes, it's very much comparable to letting browsers supply SQL queries to your server, in that only with incredible effort could you avoid creating a vulnerability gold mine when implementing such a thing, because you're starting at a scope of "everything" and narrowing it down, rather than starting at a scope of "nothing" and building up from there.

[EDIT] and on the topic of vulnerabilities, given what it does, it'd be a sucker's bet that several popular implementations aren't just waiting to be a key player in "someone downloaded the entire database of 100 major sites that use this library/framework" hacks in the not-so-distant future. It is very much a "use with care, only if you need it, and with both eyes wide open" sort of thing. Again, I agree that Hasura's temptingly-handy, and that JSON and other non-statically-typed boundary-crossing data structures are practically always god-awful.

Post reply on HN