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.
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
>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.
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.
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'
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?
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.
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...
> 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.
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
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.
> [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.
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.
> 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
> > 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
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.
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".
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).
It sounds like your main problem is that you cant get your callers prioritize making changes.
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
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.
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.
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.
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.
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.
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".
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.
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.
> 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.
> 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 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.
Yeah, knowing when to ask questions is itself a skill. I didn’t mean to insinuate in my comment anything negative towards junior engineers or imply I hate when they ask questions. But I’d say knowing how to read code and understand it on your own vs recognizing when something is almost unknowable without asking someone is a hallmark of a more mature engineer. But I stand by my insinuation that people aren’t deliberately hoarding knowledge, they just learned what they know effectively (via primary sources and doing) rather than through hearsay or lectures. Or they “know how to know”, they seemingly know everything because they know how to find answers to any question.
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.
> I didn’t mean to insinuate in my comment anything negative towards junior engineers or imply I hate when they ask questions.
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.
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.
>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.
> 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
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 work alongside a principal engineer who refuses to learn anything beyond what they learned 5+ years ago. It seems they got to the Senior level and just gave up learning. Makes no sense to me and is a detriment to all the more junior engineers in our team.
if your team relies a lot on senior engineers knowing things, there's a problem with your technical architecture. The knowledge should be look up-able, and tied in a clear way to the functionality.
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 dunno about 10x engineers, but there definitely tends to be a person who knows everything on many teams. I noticed over time that if I need to ask a random question about project A, I always ping the same 1-2 people from team A for most As... then I feel bad that I'm always bothering them, start asking someone else, get vague/incorrect/lazy answers, and go back to the same person anyway ;)
I don't think it is always a senior person though... it's often a junior engineer who's been there a while.
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.
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.
> 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?
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.
> 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.
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.
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.
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 anyone can think this situation isn't toxic.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
>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.
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.
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.
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...
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.
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”)
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.
Let's play a game. Imagine you're s senior dev and interviewing another Dev today. They do well technically, but write comments in their codebase that critique your decisions (such as choice of tool, questions asked, framework used, etc). What's your thoughts on this person?
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.
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.
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.
For the record, I went through a "boot camp", though it was the longest one I could find that was feasible (9 months), and I've been hired as a developer.
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.
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.
>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?
> "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.
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.
115 comments
[ 2.4 ms ] story [ 217 ms ] threadI 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.
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.
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
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."
https://news.ycombinator.com/newsguidelines.html
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.
Assaulting someone is a crime, don't call HR, call the damn police.
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.
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.
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.
> 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.