[HN Gopher] In-demand tech skills are the last thing to look for...
___________________________________________________________________
In-demand tech skills are the last thing to look for in IT hires
Author : ohjeez
Score : 54 points
Date : 2021-10-27 15:42 UTC (7 hours ago)
(HTM) web link (www.netsuite.com)
(TXT) w3m dump (www.netsuite.com)
| [deleted]
| blueslurpee wrote:
| >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 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.
| nonameiguess wrote:
| It specifically says in what you quoted "or with a vendor or
| service provider." If you're able to get away with only hiring
| people who don't understand the intricate details of filesystem
| drivers, overlay networks, and hardware virtualization because
| you just consume your infrastructure from a cloud provider,
| you're included in "team sport," where your team includes the
| cloud provider who hires a whole bunch of people with expertise
| totally different from your company. WhatsApp didn't stand up
| its own networks or build its own phones. It stood on the
| shoulders of giants who knew how to do that.
| blueslurpee wrote:
| Well said, I agree with you.
| hadsed wrote:
| i agree. the overhead of teams and external dependencies is
| often just too high--you're far better off if you can keep
| things small but mighty
| softfalcon wrote:
| 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 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".
| daemoncoder wrote:
| I have the opposite problem: colleagues who don't want to
| learn how to do anything new.
| opportune wrote:
| 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.
| riskneutral wrote:
| I share my screen and do an initial source code walkthrough
| of the overall structure of the project / component, and
| make sure they can build and run the code, before asking a
| junior team member to read the code themselves and figure
| the rest out on their own. It's worked really well, in my
| experience.
| RNCTX wrote:
| > 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.
|
| 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.
| rowanG077 wrote:
| Why do you feel a "10x engineer" is problematic in a team?
| You can have different types of players in team.
| 908B64B197 wrote:
| The issue is, it's faster to build a feature yourself than to
| coach a new hire to build it.
|
| 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.
| pydry wrote:
| >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 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.
| 908B64B197 wrote:
| Any article that uses the terms "coders" and "IT" is a red flag
| to me. I've never seen that terminology inside organizations
| that are actually capable of shipping software.
|
| > 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.
| blueslurpee wrote:
| Some interesting & fruitful replies in here. There is
| definitely some nuance that deserves to be unpacked. Yes, a
| well-oiled team with competent leadership and an effective
| culture can do more than an individual alone.
|
| 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.
| Oddskar wrote:
| We didn't have APIs 10 years ago?
|
| 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.
| zerkten wrote:
| It's not that we didn't have APIs, but it's the reality that
| they have penetrated every sector beyond early-to-medium
| adopters. Even regulated companies are moving to the cloud
| and using public web services at this point.
|
| 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.
| coding123 wrote:
| Yes, this is more accurate. 10 years ago most of the stuff
| was JSPs / JSFs and other UI+Backends that were fused by
| it's platform.
| brabel wrote:
| We can build very complex products today so much more easily
| than 10 years ago.
|
| 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.
| pjmlp wrote:
| Somehow it feels like a marketing leaflet for a CORBA/DCOM
| based product.
| isaacgreyed wrote:
| "I could create a whole new product that could scale to
| millions of users on a weekend." Sounds like an extremely
| appealing business idea.
| pjmlp wrote:
| We had APIs since Sun RPC, they just keep being rebooted.
|
| The 2021 version is REST/gRPC for SaaS products.
| Oddskar wrote:
| 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.
| pjmlp wrote:
| Yeah you're right, silly me.
| theshadowknows wrote:
| I was on a call just yesterday about how we should
| consider moving from one solution to another simply
| because the new one 'uses graphql which is so much easier
| and so much more powerful'
| nawgz wrote:
| 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
| 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?
| handrous wrote:
| _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.
| nawgz wrote:
| "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.
|
| 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...
| handrous wrote:
| > 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.
| nawgz wrote:
| 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
| handrous wrote:
| 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.
| nawgz wrote:
| > [I assert 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
|
| 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.
| Oddskar wrote:
| 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.
| nawgz wrote:
| > 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
| Oddskar wrote:
| > 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.
| nawgz wrote:
| > > 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?
|
| 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
| blueslurpee wrote:
| I haven't read enough about GraphQL (or even used it) to
| debate its relative merits, but I find it very
| interesting from "business architecture" point of view.
|
| 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.
| pjmlp wrote:
| We don't need to imagine, that was the scenario being
| sold for CORBA/DCOM, then it was sold for SOAP/XML-RPC
| webservers,...
|
| We even got stuff like Bizztalk and BPEL to orchestrate
| API calls with graphical workflows.
|
| The circle of IT fashion.
| ericb wrote:
| Ugh, no. The problems of just exposing your database
| really come out after you try living with it.
|
| 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".
| littlestymaar wrote:
| You're not exposing your database though (or at least you
| shouldn't be): you're exposing _views_. The set of views
| that you expose are your API. But it 's not tied to your
| database schema than any kind of API (not less either
| though, if your database schema really doesn't match your
| API, your performances are likely to suffer sometimes,
| but that's true with any kind of API).
|
| (I am in no way a GraphQL evangelist btw)
| orf wrote:
| Who's exposing their database? Why? You're exposing a
| view over your data that may or may not live in a
| database.
|
| None of your points apply directly to grapple, all apply
| to a REST based architecture. More so, I'd say.
| soperj wrote:
| >stories of small engineering teams with Unicorn exits, e.g.
| Instagram, WhatsApp, etc.
|
| Are there others? Seems to be a common theme with those 2.
| sillysaurusx wrote:
| Found the engineer that needs a project manager. :)
|
| 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.
| deviaan wrote:
| Going to echo this sentiment. The project I'm on now is the
| first time I've worked with a PM that gets whats going on and
| actually manages the product instead of just sending PMs
| after hours asking for some "small" feature to be squeezed
| into the sprint. It makes a HUGE difference, and I can
| honestly say I'm much less stressed out now than in previous
| projects.
| lowercased wrote:
| interesting. i've cycled through some projects with and
| without PMs. I've not found 'good' PMs to make a huge
| difference compared to 'without', but definitely 'bad' PMs
| impact things negatively. It's hard to define what the
| 'bad' is, but micromanaging, forcing process where it
| doesn't need to be, arbitrarily enforcing rules when
| convenient, etc are all just negative impacts. It would be
| more beneficial to just not have that person at all. I've
| had some good PMs, and while _I_ didn 't notice much
| difference in my own performance/delivery/stress/etc, I
| think it gave some other folks somewhat more
| confidence/assurance.
| [deleted]
| dep_b wrote:
| > Entrepreneurs need to guard against the temptation to hire an
| antisocial or unempathetic talent, no matter how brilliant
|
| I think the same about the products of antisocial or unempathetic
| companies. Hence my "no Oracle" policy.
| lumost wrote:
| People work at companies for a variety of reasons. You never
| know if you're hiring someone who hated the culture of Oracle
| but wanted a job in their region working on DB technology.
|
| 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.
| DeathArrow wrote:
| I think the poster is saying he wouldn't work for Oracle.
| the_only_law wrote:
| I think GP was meaning they don't use Oracle products
| pjmlp wrote:
| I guess he keeps his own custom Linux kernel clean from
| Oracle paid commits, and doesn't use any product that might
| have Java underneath.
| [deleted]
| runnerup wrote:
| I think the poster you replied to may have meant "no B2B
| contracts with Oracle, etc"
| [deleted]
| Jensson wrote:
| > A good technologist has grace. He will respectfully probe for
| intent in a way that doesn't put the requester on the defensive.
| He will make it clear that this is a partnership, and that
| getting the job done is high on his list of priorities -- it's
| just that he needs some information in order to do a good job for
| you.
|
| 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?
| jrochkind1 wrote:
| 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.
| Jensson wrote:
| 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
| jrochkind1 wrote:
| 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.
| hluska wrote:
| I see your point but I'll caution you that I don't think this
| cat has any experience building software, so his concept of how
| things flow is a little off. I'd completely ignore this entire
| paragraph and just focus on becoming an active listener and
| learning how to ask questions.
| wvenable wrote:
| 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.
|
| Knowing how to talk to people to get your project done is a
| great skill.
| yobbo wrote:
| > People are people and many don't understand or are actively
| afraid of technology.
|
| 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.
| wvenable wrote:
| Also these people are the experts and often you're the
| novice in their domain. Understanding that part of the
| relationship is important.
|
| 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.
| Jensson wrote:
| > 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.
| wvenable wrote:
| So your argument is companies should hire people who good
| at communication so they can hire a developer who isn't?
| Jensson wrote:
| My argument is that you can meet them halfway rather than
| dumping all the responsibility on the developer like this
| guy does.
|
| 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.
| jrochkind1 wrote:
| Would you say your discussion style in this thread is
| "meeting halfway", and typical of your discussion style
| at work?
|
| What would you say characterizes a "toxic" discussion
| style, or "being so bad at talking to people"?
| Jensson wrote:
| No, I am much more aggressive online since I want to
| point holes in things. I doubt many people talk the same
| way online as they do at their job. It isn't like you
| expect a sales person to be all happy when he is at home.
|
| > 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.
| wvenable wrote:
| 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.
| Jensson wrote:
| 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 anyone can think this situation isn't
| toxic.
| wvenable wrote:
| 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.
| wvenable wrote:
| Nowhere does it say all the responsibility is on the
| developer. But being able to ask questions without
| putting people on the defensive is hugely important.
|
| 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.
| Jensson wrote:
| Doesn't sound like any of the tech jobs I've had. But I
| agree if your job is to replace people with technology
| rather than build new products for end users then your
| social skills will matter much more, but this article
| didn't made it clear that he wanted to hire engineers for
| that specific purpose.
| wvenable wrote:
| If you never talk to your end users obviously you don't
| need social skills for talking to end users. Lots of
| development/tech jobs don't require talking to users.
| Jensson wrote:
| Btw, you might not have realized but the article was
| talking about a manager going with a request to
| developers. So it is absolutely the managers fault here,
| nothing you say can convince me otherwise, a manager
| shouldn't demand this from developers.
| wvenable wrote:
| The example is too vague to really make a conclusion.
|
| However, I was really just replying to that sentences
| that you quoted and disagreed with. In my opinion, those
| two sentences are perfectly valid.
| bob1029 wrote:
| 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
| everything coming in the door.
|
| 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.
| Jensson wrote:
| > 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.
| Daishiman wrote:
| You need to put a lot of energy into teaching a candidate to
| fit into a job. That's Ok. You don't get that in a bootcamp
| with a bootcamp grad teaching 150 equally clueless students.
| You get it through hours of hands-on experience with
| veterans.
| bob1029 wrote:
| 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.
| tester756 wrote:
| >We need people who are willing to engage difficult, fast-
| changing things substantially more than smart-asses who think
| they know everything coming in the door.
|
| Iny my world it means:
|
| We want full stack developer (backend+frontend) which also
| knows "cloud/devops", databases, UI/UX?
| kickopotomus wrote:
| You could sum up this whole article to "don't hire assholes" but
| I am not sure why that should be limited to tech? You probably
| don't want assholes in your business/ops side of the organization
| either. Most of the gripes in the article sound like
| management/culture issues as opposed to developer issues.
|
| > 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.
| whoomp12342 wrote:
| unfortunately, its hard to spot an asshole cross business. Lots
| of assholes are smart enough to not be an asshole to the right
| people
| ryanmarsh wrote:
| I'll hire the crazy yet brilliant people any day of the week.
| It's a leadership challenge and the work output is worth the time
| investment.
| SamoyedFurFluff wrote:
| Genuinely asking what do you mean by crazy, because I think
| there's a level of toxic that no leadership should be
| tolerating. (I'm thinking HR violating stuff like "can't resist
| assaulting co workers")
| macrowhat wrote:
| Says... Netsuite...
| zabzonk wrote:
| > I'll expand that to include prima donnas, misanthropes and
| garden-variety narcissists.
|
| Pretty much the definition on an "entrepreneur".
| dang wrote:
| " _Don 't be snarky._"
|
| " _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._"
|
| https://news.ycombinator.com/newsguidelines.html
| rl1987 wrote:
| I.e. a lot of the people doing the hiring?
| [deleted]
| photochemsyn wrote:
| > "Generally, your best technologists are those who are really
| good at listening. They're also insufferably curious, which makes
| them really good at asking questions after listening. They're the
| best at ferreting out the real intention behind your stated
| intention, if you will."
|
| 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.
| abadger9 wrote:
| on a tangential note, i was fortunate to work at netsuite early
| in their development (00-10) and it was the best professional
| experience of my life. Their low attrition rate speaks to the
| caliber of their leadership
| DeathArrow wrote:
| >Hiring a developer? Check out the GitHub "repository," which is
| essentially the portfolio site for coders.
|
| 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.
| dehrmann wrote:
| I suspect most profiles are either toy projects people
| desperate to get into the industry wrote or prolific open
| source developers who are only a fit for a handful of roles at
| a big company (think Linus or Guido) and will continue doing
| essentially the same work, but for a patron. A handful of
| companies develop in the open (Gitlab), and some roles work on
| public SDKs.
|
| My profile is a grab bag of forks for PRs and library side
| projects people might (and have!) found useful.
| rikroots wrote:
| I first started with GitHub because a recruiter told me I
| needed a portfolio of some sort to demonstrate my skills to
| potential employers. Given that I'd been applying for
| graduate/junior roles in the industry for over three years
| with frustratingly little success at getting to face-to-face
| interview stage, I decided to build some side projects to
| show people what I could do.
|
| 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.
| 908B64B197 wrote:
| > portfolio site for coders
|
| 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...
| donretag wrote:
| Companies still do not know how to interview for hard skills,
| what makes you think they can do it for soft skills? Previous
| workplace disagreement? Easy to hide during an interview.
| DeathArrow wrote:
| >Companies still do not know how to interview for hard skills
|
| They put you trough leetcode or hackerrank.
| throwaway19170 wrote:
| I sometimes worry that I'm somehow becoming _more and more_ of a
| jerk as my career progresses, instead of less. Maybe I 'm just
| sick of this career.
| breckenedge wrote:
| I hate the term "jerk". It's really just not specific enough to
| categorize, or correct, bad behavior. I am always concerned
| about coming off as a narcissist or elitist.
|
| 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.
___________________________________________________________________
(page generated 2021-10-27 23:02 UTC)