What you're suggesting is just hustle culture nonsense. If you want someone to be invested in your company, give them _equity_. If you won't (and you won't), accept that you're paying for a transactional relationship, not "investment".
I come from a family of contractors (electricians and metalworkers mostly), and every experience I've ever had working with them tell me that they care about understanding. If you ask them to make you a bathroom without any waterproofing they'll ask you if you've gone mad and tell you that you NEED waterproofing, because they understand that you don't want your house to rot. If you say you want a metal frame and you have a drawing. The very first step they will take is to analyze your drawing to see if it makes any sense.
I have never worked with a contractor that just did whatever you told them to, without understanding what you're doing. If they chose to disengage with a problem, it's a conscious choice.
The big differentiator is the ease of understanding. Building a bathroom is relatable. You kinds of intuitively understand why you want a new bathroom, and people understand the sorts of issues a new bathroom can solve. People do NOT understand what new software can solve, and how it solves it. They think software is magic pixie dust that you sprinkle on problems to make them go away. That means we have to do more of the work of helping them map out the solution than a contractor would.
Nowhere did I suggest otherwise.
> I've ever had working with them tell me that they care about understanding.
They care about understanding to complete the task at hand. I have never met a contractor that got emotionally invested in whether the cabinets you picked out were the cabinets of your dreams. I've met many contractors that were, in some ways, invested in the buyer being satisfied with their job, but that's not really the same thing.
> I don't care about the project, I care about writing code
this is like the contractor saying they only care about installing cabinets, not helping you model your bathroom.
The point is that you want someone that's going to look at the plan and say "that's going to rot in 2 years", not just do the exact thing requested by the customer and leave
This depends on who you hire. I recently built a home and dealt with lots of different contractors with different attitudes. Very often when they needed clarification they would come to me, and very often I would ask them "what would you do if it were your home?".
I worked with companies and workers who I would hire again in a heartbeat - they understood what I wanted from my home and how it would be used. They incorporated this into designs and decisions made on site (because I don't care how well you think you've planned, there are ALWAYS decisions to make one site).
The people I would never work with again were the ones who either never even asked for clarification and simply chose the easiest / cheapest solution to a problem (often surprising me - in a bad way) or when I asked them what they would do in their own home were not interested in engaging with that question - they would respond by asking me again what I wanted.
You may not care if your current employer considers you a bad hire or not, and that's fine. In our industry, in this market, you can get away with that. Some of us hold ourselves to a higher standard.
This is just silly. Your argument is that you would care if your employer developed ridiculous and contrived metrics and then assessed your value based on them? I don't really think your holier-than-thou statement makes much sense in that capacity.
As I said, equity drives investment. If you don't own a percentage of the success, you're trading time for money. This is neither new nor controversial. Any suggestions otherwise are, again, hustle culture propaganda.
> Your argument is that you would care if your employer developed ridiculous and contrived metrics and then assessed your value based on them?
No. As I alluded to, I think that a developer who does not care about his or her end user is a worse developer in concrete ways.
Remove developer and answer again.
??
You're just....saying things...? What does "Caring about the end user" have to do with "Believing in your product"?
I've seen this in software too. People push for cheaper and faster, but often that will only come at the cost of quality. There are good reasons to take on technical debt. For example, to get to market without the funds to avoid technical debt, in the hope you can pay down that debt with revenue flowing in. But there are seldom conversations with business people to negotiate on the quality, time, and cost trade-offs.
Hard disagree. There is a place for the developer as product evangelist, and there's a place for the developer as a skilled tradesperson.
The idea that someone needs to be fully invested in your worldview to pipe together a backend is... strange.
There’s a fine line between having to cajole a bunch of disaffected developers into getting work done, and explaining that I can’t give you a raise because it would ruin the company and you really should think about what’s best for the team. Or could you just work late on Friday, or cancel your honeymoon.
Then one of them suggested that we install a bay window instead of the boring thing we'd had planned, and when it costed out reasonably, they got right on it. The tools came out, the enthusiasm was turned on, and a couple of them spent half a day building an absolutely beautiful window that I and our pets value to this day.
Good workers doing stupid, boring jobs are likely a resource that companies are not taking advantage of. People are more capable, and sometimes you should let the reigns loose (maybe most of the time).
It is like med school interviews. Everyone knows the answer to "why do you want to be a doctor?" is "I like science and want to help people." along with an anecdote proving that when tons go to medicine as it is a well paid and stable career.
From my own experience I find that yeah, job interview answers are mostly self-marketing BS. But I do also care about the quality of the end product beyond just having fun with the tech.
I would not encourage anyone to talk to their boss the way GP is talking. But these are peers talking, and if you don’t think convos like this happen, then you haven’t seen them or you’ve dismissed them. If you haven’t seen them, I can only assume nobody trusts you enough to vent.
If you want your workers to care about the success of your business, then pay them with the success of business (e.g. shares). If you are only paying an hourly salary, you're not entitled to anything but their hour's output.
Being now on the donating end of shares, employees know much better how to value the gross pay.
In the same way, when you hire a contractor build you a garage, you look for someone who will use their experience to build a good garage with the best materials and techniques keeping in mind the priorities of the owner, like maintainance, cost, appearance, resalability, etc. You don't want someone showing up who just views your garage primarily as an opportunity to learn about this new construction material they've heard about that doesn't help you.
I'm hiring them because they're the expert - and if they ask some questions about why I want the garage and what I plan to use it for, it'll help them deliver a final product that's a better fit for my needs.
For example, if I say "I want a garage that's 200 square feet and has an epoxy-covered floor", I'd like it if my contractor asked me some questions and came back with responses like "Since you want to do x in your garage, I'd avoid the epoxy floor and go with painted concrete. Also, I've has several clients who were interested in doing x and they ended up wanting a storage loft in the garage. You can add one later if you'd like, but it's much less expensive if you add it during initial construction."
So...maybe not passionate, exactly. But engaged and professional, absolutely.
I'm asking because I see the construction analogy pop up a lot and I just can't reconcile the two things.
To me the development of a new blueprint for a new kind of garage for a new kind of vehicle operated by a never before seen alien species is a bit closer to creating a software product.
I mean, who would ask a contractor to do what people regularly ask software engineering teams to do?
A desire to learn is not a desire to experiment.
> In the same way, when you hire a contractor build you a garage, you look for someone who will use their experience to build a good garage with the best materials and techniques keeping in mind the priorities of the owner, like maintainance, cost, appearance, resalability, etc.
Meatspace contractors try new techniques all the time. You're paying for the ability to accommodate a client, not the ability to do the exact same thing repeatedly.
> You don't want someone showing up who just views your garage primarily as an opportunity to learn about this new construction material they've heard about that doesn't help you.
That's a terrible analogy. Most of the time developers aren't writing greenfield projects, meaning they don't choose the stack. Devs have the leverage to choose by accepting jobs that use the stack we know (or want to know).
As to contractors, if you had already started building a garage with a new construction material, you probably would really want to hire people who were experienced in it. If you couldn't find them, you might want people who were interested in learning to use it.
If you want passion and motivation, consider hiring an actor or prostitute. I'm going to stick with my usual plan of "write good code in exchange for good money".
EDIT: just be clear I'm still actually talking about software
Most businesses that pay salary operate like this:
Worker picks 5000 apples, coworkers picks 300. Business pays them each 1 apple. Both start picking 1 apple, business puts them on improvement plan. (China wants apple pickers to struggle.) Also, please write a 13-page paper detailing how your soul is mine, I'm your daddy, and any food you might try to grow on your own property is actually mine (Google).
Too little of the former, and nothing valuable gets done. Too little of the latter, and you end up drowning in technical debt, preventing the business from adapting as quickly as it needs to
What I see too much are teammates who say they want to be more involved with customers or prioritization but don’t show up for feedback sessions or high level discussions and then later complain about not being involved enough, causing even more headache. The more you accommodate, the more problems they come up with, and never actually get around to doing the actual work.
The reason developers love to work on personal projects is not primarily because it is using some shiny new tech but because they own the vision, they own the decisions, they started the question and they want to build the answer.
While adding in new technologies isn't always a bad thing, having nothing but a desire to do so is classical Resume-Driven-Development. If your firm is in a business position such that having all the latest, greatest tools is a good thing (hard to imagine industries in which this is an unqualified good) then keep on trucking. Otherwise you may find yourself needing to have adult conversations with $RDD_DEV about just what it is that makes the business money, in light of technical decisions that cost additional time, have larger TCO, and so on.