In-demand tech skills are the last thing to look for in IT hires
netsuite.com
netsuite.com
I find actually the opposite to be true. The leverage of individual engineers is only growing with the advent of SaaS and the proliferation of API's. Then of course there are the stories of small engineering teams with Unicorn exits, e.g. Instagram, WhatsApp, etc.
I agree with the article. As we build more complex products we need to be more specialized and work together.
Maybe not the case if one is working at a startup trying to cobble something together that looks like a working product by customers and investors.
There are services that will give you everything, from a managed DB to distributed CDN around the world, to one-command deploys... I feel like, if I only knew a business idea that didn't totally suck, I could create a whole new product that could scale to millions of users on a weekend.
The 2021 version is REST/gRPC for SaaS products.
It also enables our UI components to easily fetch data themselves. Because that's a great architectural pattern that we've discovered.
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 management pattern. Less coupling, separation of concerns, and usually significantly reduced network activity since you just need to keep the GraphQL state aligned, which is actually specified unlike how to sync a REST resource.
Do you actually have any experience with this tool?
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.
I don't even know what else to say. There's a time cost and risk of every single thing you'll implement, you haven't given any insights into what tips GraphQL into a superbly expensive and risky area... Especially because Hasura is completely free and open-source...
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.
> 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
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.
I literally brought in Hasura, and completely replaced my REST interfaces with it. There is no "large stack of supporting tech", I added a docker container to my small set of services (which already included PostgreSQL). Again, Hasura is free and open-source, and incredibly powerful while still easy-to-use. Setting up authentication is also a breeze.
Further, to imply that a query GENERATOR is in any way comparable to a query RUNNER is just foolish. Cut it out. You can't claim that it's a "sucker's bet" the whole ecosystem is just exposing unsecured databases, especially not without a single link supporting this having happened.
To conclude, I guess I find that I would strongly disagree with your approach to things and your reasoning behind it, and I find your claims like "JSON and other non-statically-typed boundary-crossing data structures are practically always god-awful" hilarious when I just told you I can treat GraphQL data as a statically typed boundary-crossing data structure thanks exactly to the GraphQL & implementation thereof you rail against.
Take care, good luck with whatever solutions you are using.
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.
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
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.
> 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?
Yes, I kind of botched it, but it's my point - GraphQL as state management can mean a lot of things. It can mean Apollo, client-side cache invalidation, use of subscriptions, etc.. I think that I found your statement of GraphQL breaking down above moderate complexity confusing because it was unclear to me what way you meant this in.
RE: apollo client, it's interesting to see that it's large, I agree that contrasted to XState or Mobx or especially Redux it is quite large, I would be happy to see that number come down, but I also am not so scared of 40KB I can serve from cache given I'm rendering "dataflow editors" of some complexity
Finally, I agree I barely use Apollo, I find its graceful property to primarily be cache management but greatly prefer mobx for true application state management because it is blazing fast / the most efficient rendering strategy
For instance, assume the future of IT looks like it does today, only ramped up x10. Imagine the majority of business value is driven disparate API's/Services managed by companies or organisations, with numerous and diverse clients that can "plug in" for their respective needs.
GraphQL essentially allows you to simplify the work that any client (internal or external) needs to do to tap into your interface, provided that you invest the appropriate resources on the backend. (which you would, if that were your core business proposition and a piece of your competetive advantage)
If companies continue to digitalize (is there any doubt) then a company's value will be encompassed and driven by the quality of its API, and importantly, it's relative use of connecting with many diverse clients. Therefore backend API's that support and interface to digital products the best will win.
I see GraphQL supporting this in that it trades simplicity and a uniform mono-interface on the front-end for complexity on the backend. I think a lot of firms will look at that trade and call it a great deal.
We wanted to make schema changes on the back-end, but the front-end queries were tied to it. Those queries were in apps run by different groups, with different goals and timetables, but we couldn't break them. If we had a defined API, we could be free to modify any back-end implementation details that weren't directly exposed. We couldn't because every detail was baked into consuming apps. What was our API, and where did it end? Now it was the entire database!
When we had to source data from elsewhere, or provide it via logical abstraction, we ended up piling hacks on top of the data structure's "API" from the back end that was now replicated in the front-end in order to "maintain it". Maintaining it really meant "providing an API that was the haunted ghost of our previous database schema "API" because now other apps/clients expected that "API".
(I am in no way a GraphQL evangelist btw)
None of your points apply directly to grapple, all apply to a REST based architecture. More so, I’d say.
Using rest doesn mean you can stop supporting a call pattern because you feel like it. Somebody else still needs to do work before you can drop your translation layer
We even got stuff like Bizztalk and BPEL to orchestrate API calls with graphical workflows.
The circle of IT fashion.
Ten years ago these companies would have been playing around with these things for sure, but not using them for their core business. This is creating demand for generalists within that huge section of the economy that isn't a top-tier pull for talent because the demands are different. These demands can't sustain frontend devs who could be working at Facebook. Eventually they will need specialized folks, but for now that continues to come from outside consultancies, just like it always has for this set of companies.
Are there others? Seems to be a common theme with those 2.
I think most devs just haven’t had a good product manager. It can be shockingly effective, but only when they care about you, rather than managing you.
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 engineer" myth seems to live on and prosper in far too many teams I've worked on. Despite how discouraging it is for the rest of us who want to play a "team sport".
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.
Depends on the shop.
The trend is toward people trying to standardize and automate as much of the development process as possible (so that they can get rid of domestic employees who cost to much and fetch it all over to people in exploitable-countries with less valuable currencies).
People who ask questions, push less ambitious changes, push buggy stuff that barely squeaks past the unit tests and then go back and improve it later if someone complains.. all of that leaves activity metrics that check boxes on the reports of people who don't care whether devs read and understand the existing code or not.
As a junior, this is a problem for me too. I don't know when it's the right moment to ask something. "When I've been stuck for an hour to half a day" seems to be a good heuristic, but it's not perfect. I don't really know what's the best option for me. If I ask later, I learn more by myself, and improve my skills in figuring out a codebase. I also let senior engineers be more productive. If I ask earlier, I'm more productive. But I take more of the senior engineer's time.
Another heuristic I tend to use is "for code stuff, try asking later, for business stuff, try asking earlier", since business stuff is often harder to figure out. We have code that describes the behavior of our product, that I can read and try to understand, but we don't have code that describes the behavior of the business.
Same dilemma when adding comments. We code in a relatively "plain" style, so "how" comments are mostly useless. "why" comments are more useful, but people tend to not really update them.
I think a way of solving partially that would be to be clear about the meta stuff. For example, I could ask if I'm asking too much or not enough questions, if my productivity seems okay. The senior engineers could also communicate about that. Even sharing how they do themselves stuff would be useful. For example "I tend to look at the code for X minutes before asking someone.". As a junior, I could multiply this time by 2, 3, 4 and do the same. Or ask the seniors about how they did things when they were new to the codebase.
To give a bit of context, we have more than 10 MLOC at work on a 30+ years old codebase, ~200 engineers and half of them are there since 3 years or less.
What you say about business logic is definitely true. In general the more something is an “emergent” property or itself only a high level concept (eg “Why do we use Mesos?” “How do we implement load shedding?”) the better it is to ask. The more implementation specific (“Why won’t this compile? What does this error mean?”) the worse it is. It’s not only about the time to find something out but also how it can be found out - whether it’s a web search or codebase search away, or not. The other problem is the senior people you ask may not always know the answer of the top of their head, and in answering your question will have to answer it themselves - typically you want to avoid that too.
For one I would always be more than happy to truthfully answer a mentee’s question regarding if they are asking too much.
That's not how I took it, sorry if this wasn't very clear but my point is that it's difficult on both sides, and it's interesting to share our struggles to see if we can find better ways to transmit knowledge.
> . In general the more something is an “emergent” property or itself only a high level concept (eg “Why do we use Mesos?” “How do we implement load shedding?”) the better it is to ask. The more implementation specific (“Why won’t this compile? What does this error mean?”) the worse it is. It’s not only about the time to find something out but also how it can be found out - whether it’s a web search or codebase search away, or not.
That's a great heuristic.
> The other problem is the senior people you ask may not always know the answer of the top of their head, and in answering your question will have to answer it themselves - typically you want to avoid that too.
I think that may be a good thing in some cases, as long as you don't demand/need the answer now and the question is good. If there's something that even senior people are not clear on, that's an opportunity to clarify things for everyone. I think that's what people mean when they talk about the value of new hires being able to see surprising stuff that feels normal to the people inside.
> For one I would always be more than happy to truthfully answer a mentee’s question regarding if they are asking too much.
That's great!
So if an org doesn't value mentoring and growing engineering talent, you'll end up with a few engineers doing most of the work and an org that magically can't scale.
Then you'll see the hiring side buying in on the cargo cult and trying to hire seniors with resumes matching their existing devs, then whining they can't hire them for cheap. At this point the business velocity has reached it's top speed.
This is a classic defense mechanism for engineers trying to shore up their position.
There's a tug o' war going on between many companies and their employees wherein the companies are trying to make the employees expendable and the employees are trying to make themselves indispensable.
I found it mostly went away when I worked in companies where most people treated their current job as a stepping stone to the next rather than as their final destination but in companies in 2nd/3rd tier cities where everybody is married with kids and looking for stability....yea
The worst offender was a guy who was massively in debt, paid a shedload of child support, was not a great programmer and didn't interview well. He was sometimes openly hostile to my attempts to get information out of his head.
My experience of this, is that working with colleagues with families meant things were more stable and predictable.
In comparison, the people treating the job as a stepping stone developed things for their CV, rather than for the good of the organisation.
I can see how your experience can also be true however.
I'm one of the folks with lots of knowledge atm, and there's a corollary that the moment you teach somebody enough that they know things, they leave the team. Putting that knowledge into databases, code, and config files is much more durable, and can have new things built off of it
I don't think it is always a senior person though... it's often a junior engineer who's been there a while.
However the premise of their statement is that it used to be more feasible for one person to "do it all", whereas now things have transitioned towards a more team-oriented environment.
I observe this trend patently in reverse.
> Then of course there are the stories of small engineering teams with Unicorn exits, e.g. Instagram, WhatsApp, etc.
I'm surprised the author didn't consider these as well. Some of these stories are almost a decade old at this point, they should be well known by now.
There was an interview I was on last week where the candidate gave a ~3/10 response to an important technical question, but because their attitude and other soft skills were obviously excellent, we made a unanimous hire decision. It was clear to us that we could coach this individual to get them to 10/10 on the areas they need to be.
At this point, we are no longer requiring any certificates or college education. If someone happens to have a degree in a hard engineering field we are happy to have that, but it's no longer something we gate-keep on.
You could become a billionaire in the coding bootcamp space if you know how to do this.
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.
I think the program definitely bootstrapped me into this role. But I'm quite confident I only got it because I had a good attitude and was relatively humble, and the hiring manager had an attitude similar to yours.
Do you work for a large company?
Iny my world it means:
We want full stack developer (backend+frontend) which also knows "cloud/devops", databases, UI/UX?
I found that the best predictor of willingness and ability was... a STEM major from a good school.
I have almost nothing in my Github repo and I code for 20 years. Neither do most of my colleagues. Artists might have portofolios, programmers most likely won't have.
My profile is a grab bag of forks for PRs and library side projects people might (and have!) found useful.
I got my first professional coding job a year later. I lucked out by finding an employer who not only looked at my GitHub, but was also willing to take a risk on hiring a 49yo junior.
The side-project is still on-going: developing it keeps me entertained when the grind of regular work drains my enthusiasm for coding.
So many red flags here.
It's true that some of the best devs in the world are active on GitHub. So what I started seeing are bootcamps trying to emulate that by having their grad work on (basically their homework) on github and the whole bootcamp becomes structured around building this "portfolio".
Then when you interview more than one candidate from said bootcamp and actually pay attention to the repo they show you, you realize it's 80% similar. Actually, everyone from that bootcamp has almost the same code checked-in...
They put you trough leetcode or hackerrank.
Unfortunately, this ability is not really what many employers want; if the technologist figures out that the real goal is to commit fraud or something unpleasant like that. Or how about being asked to implement a user complaint system with a deliberately unfriendly user interface? "I see you want me to build something crappy to limit complaint reports, is that it?"
> "You’ve heard the maxim: Don’t hire… we’ll go with "jerks." I’ll expand that to include prima donnas, misanthropes and garden-variety narcissists."
Yes, you want to reserve these types for the executive suite, where being willing to screw over the employees and your customers so that the shareholders can reap big quartery profits is a job requirement (rewarded with large executive bonuses). Narcissitic jerks with no empathy for others are ideal for this role.
I would really like to see more tech businesses where the scientists and engineers, not some crew of shareholders and their pet executives, are the ones making the business decisions.
Sounds like a very toxic environment. What would put the tech worker that much on their toes, what would happen if they stepped out of line? Would the manager get angry because it looks like the tech worker tries to be lazy? Do people get angry when you ask questions unless you make it absolutely sure those questions are to help solve their problem? I'd really hate to work in such an environment where tech workers needs to tip-toe around issues because people gets angry if you don't.
Maybe it would be easier if you focused on hiring managers with soft skills first instead of putting in so much effort hiring tech workers with much better soft skills than those managers?
Knowing how to talk to people to get your project done is a great skill.
Right, so why would your company hire people who are so bad at talking to people that the developer has to go to such lengths to save that persons project? I wouldn't want to work there.
But as a consultant I guess his job is to help toxic managers hire people they can work with, if that is the case he doesn't have a choice to change the manager.
What would you say characterizes a "toxic" discussion style, or "being so bad at talking to people"?
> What would you say characterizes a "toxic" discussion style, or "being so bad at talking to people"?
People who can't talk normally due to some of the following reasons, if these are issues you have to deal with at your job instead of they dealing with it themselves then you work with people who lack social skills:
> People are people and many don't understand or are actively afraid of technology. They have jobs to do and if they don't know you, they may be skeptical about what you can do for them. They might even have been burned in past by developers who promise but don't deliver.
I don't see how anyone can think this situation isn't toxic.
Many software projects directly involve fundamentally changing someone else's work (hopefully for the better). You might not think that's a big deal but I can assure you it's a big deal for them. And for your project to succeed, you're going to need to recognize these factors and deal it.
I consider it like training -- anyone who've I already successfully completed a project with me knows how these things go and is perfectly comfortable. People I've not worked with before often need a softer approach until they've gone through a full successful project.
However, I was really just replying to that sentences that you quoted and disagreed with. In my opinion, those two sentences are perfectly valid.
One possible alternative is that people are suspicious/defensive (sometimes justifiably) when techies ask questions about "what problems are you having?" and "what do you typically do when ___?" To them, it might seem like they are being interrogated by someone ostensibly below their rank.
To be fair, this is sometimes exactly what is happening. A techie is sent in to investigate automating a bullshit job, but neither the techie or the person is told this in clear terms.
In my experience, people are very happy when I automate some bullshit part of their job. However, you are going to waste their time getting that automation done. So you have to sell them that it's worth making their job worse in the short term to make it better in the long time. If you're a terrible communicator, they're not going to trust that it's worth it.
> He will make it clear that this is a partnership, and that getting the job done is high on his list of priorities
> Many business folks begin by asking for a specific feature or function. For example, maybe you want your billing system to send out customer payment reminders as text messages. Sounds straightforward. But a good technologist, before rolling up her sleeves, flexing her fingers and firing up a text message cloud service and a windowful of code, will ask questions.
If every company is now really a tech company as the article claims, why is it only the responsibility of the developer to extract requirements/intent? I am not saying that developers should not try to clarify problems but why is the onus of clarity on the implementer instead of the requester? Should business folks not be expected to clearly communicate the business goal that they are trying to accomplish?
> One bad actor can do more damage than you can imagine. I have seen a multimillion-dollar, high-stakes initiative almost derailed by one jerk who didn’t think he needed to prioritize a colleague’s project above his own and masterfully exhibited passive-aggressive behavior for weeks before getting called on it.
A single point of failure in a multimillion-dollar, business-critical project sounds like a management issue to me.
> Hiring a developer? Check out the GitHub “repository,” which is essentially the portfolio site for coders.
That is going to be a mixed bag. My GitHub account is a graveyard of half-finished toy projects in different technologies I felt like trying out. I would not say it is representative of my proficiency.
I was turned down recently after a well-executed technical interview because the company was concerned that I might be a jerk, which is actually great feedback. They based this on a "vim-mode sucks" comment I left in the notes section of online editor they were using to conduct the technical round when it froze up. Whoops.
I’ve definitely been a jerk sometimes in the past, and it’s something I work on frequently with a psychiatrist. I’ve also worked for some very successful narcissists in the past, so I don’t have a lot of great examples to reference. And my socialization skills sometimes come off as stilted since one of my parents is on the spectrum. Emotionally it can be hard to tamp down on frustration, but I’ve gotten a lot better since I started seeing a psych a few years ago.
I really hope people can get back to treating each other like human beings rather than labels.
I'd not say jerk, but I would think they're not taking the process seriously. A technical test certainly isn't a place to make jokes as you don't know how they'll be perceived. Play it safe.
Anyway, your third paragraph ... It reads to me like you're passing blame on others rather than reflecting and acknowledging your choices. For example, " since one of my parents ...". No. _your_ social skills and decisions are yours. Likewise, you blame past narcissists you've worked for for not having good role models? You should know right from wrong, and making such comments during an interview is wrong.
I think the same about the products of antisocial or unempathetic companies. Hence my “no Oracle” policy.
Or they come in via acquisition, or Oracle was simply the only job which would take them at their current pay - or they were ignorant of the reputation.
Assaulting someone is a crime, don't call HR, call the damn police.
Pretty much the definition on an "entrepreneur".
"Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."