Hacker News Reader

Comment by LordN00b | Hacker News Reader

As a dev in a business environment, I don't care about your project. At all. It's going to be run-of-the-mill business app, storage, front-end, logic. There will be nothing exciting or interesting for me whatsoever. I don't care about your case management, insurance leads, or Teams Governance. Becuase I'm a human with human interests (writing code, and dreaming of a decent Transformers movie before I die), your projects are not interesting, and they will not invest me.

However for every project I take on, there will always be something I have never done before, or a maybe some new technique I want to try, could be a new language. That's where the engagement comes from.

I don't care about the project, I care about writing code (and exploring writing code) to the best of my ability (and to the best of the project constraints).

If I've done my job well, that means I learned something new/had fun and the project will never burn my screen pixels ever again.

View on HN

One of the first bits of paid work I did was for a printing company that made business cards among lots of other things. They would manually create a CorelDraw document with a page full of cards for each employee, taking the contact information from an excel spreadsheet. The data entry for making cards for 100 people would take several days.

I was able to automate this for them with a pretty simple VB.net script. Several days of boring mind-numbing work per month were reduced to a couple button clicks and a few seconds of CPU time. It also eliminated all typographical errors on the part of the printing company.

I never touched vb.net again after that. I had no interest in the technology at all and there was nothing particularly interesting about the work itself. However saving people from having to do a bunch of boring work is extremely satisfying. And it saved the owner money which feels great too.

I find that being empathic towards my users not only makes the work more fulfilling but it also allows me to design better products. As a human with human interests you should at least give it a try.

I appreciate this perspective quite a lot.

I think that for me, being a good engineer is first and foremost about solving problems for people, and if I lose sight of that simple goal, I lose a lot of my energy for my work.

Exactly, and the harder the problem, the greater the reward when it's finally solved.

The problem solving process never ceases to amaze me, how a problem can go unsolved for months on end, and then suddenly all the dots can be connected and the solution appears.

Starting out with the notion that "It must be possible to solve this", is always the first step i find.

Thank you, this is a nice counter to the usual nihilistic stuff you find on HN. I find that just doing something useful is fulfilling for me, especially if it makes peoples' lives easier, no matter how little I care about or understand the actual product itself.

I like the contrast of your reply to the original post because it really highlights the two general types of developers - product focused developers who use technology as a tool to focus on the customer and technology focused developers who treat programming as an art ahead of focusing on customers.

I would say it can be tempting if you fall into one of the two broad buckets to think the other side is doing something wrong and that there is a tendency to want to compel them to “see the light” so to speak but in my experience those efforts tend to go to waste (if not appearing outright condescending).

Ultimately people have different interests and priorities both in life and their careers and people derive fulfillment from different sources. There are no right answers here.

You need both kinds for a good product. Both of these types add something the other is not interested in adding. The most value I ever added was joining a company filled with type X (purposefully avoiding which one) as a type Y and going on a binge of doing incredibly valuable work that had been left as "low hanging fruit" because nobody thought it interesting and/or important enough to give it a good look.

This reminds me of the product-infrastructure spectrum of dev specialization. [1]

[1] https://www.michellelim.org/writing/stop-using-frontend-back...

It's an amazing feeling when you read someone's written words about something you've been thinking of yourself.

I don't see why you cannot be both.

How is it hard to have empathy and interest in solving problems and yet still a deep love and interest in the underlying tech you use?

I feel I am in this category. I would venture to guess that a broad array of useful developers do as well.

Siloing people like this creates an artificial construct wherein people feel they need to fit.

For what it's worth, I would definitely not hire the OP after his speech about being more interested in using a new tech to solve my problems than solving my problems.

They rarely overlap. If you’re trying to solve arbitrary problems efficiently whatever tools you know are unlikely to be the best fit. But that doesn’t mean you’re going to be more productive learning something new.

customer-focus has the nice property of limiting my perfectionism to the threshold of meeting their need.

My technology-focus projects are unlimited and therefore never satisfied.

I have had these types of "boring but fulfilling projects" as well. I have also been on the other side where I cannot feel any pride in what I am building and the only solice is at least I got to learn something new.

I think what makes the difference is the proximity to the user. In your printing company you got to know the process then build a solution that directly helped your co-worker and boss. Even if it only helps in a small way that feels very satisfying. Where I get frustrated is and lose all that empathy is when the company keeps multiple layers of indirection between the devs and the users (customer report -> Customer Service -> Product Management -> devs).

Another frustrating point for me is when the decision makers / stakeholders and the users don't overlap.

No matter your technical proficiency, you are a lousy hire. I do not want a developer that is solely interested in work that improves their skills. These projects contribute to the success of the business in one way or another. If you are not invested in understanding why that project is funded and what it will accomplish you will not do the job as well as someone who is engaged and only has half your skills.

You mean you want someone who is willing to blow smoke up your ass.

No, I think they're looking for people who are intrinsically motivated by the drive to do a professional job applying their craft, rather than to use a project as an opportunity to experiment with technology that they want to learn for their own curiosity or career trajectory.

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.

So do you ask your contractor what keeps him passionate about garages?

Not the OP, but I'd like it if my contractor shows at least a bit of professional engagement.

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'd like for my contractor to suggest garage designs that aren't decades old, insecure, unmaintainable, to know what're the modern garage tools...

There are buildings that have stood for hundreds of years, meanwhile you have to re-paint your own house every 10 year... new/modern is not always better.

How do you reconcile how bespoke and ever changing the requirements are for software products vs how stable the requirements are for garages?

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?

Construction isn't a bad analogy. Imagine you're a contractor getting called in to finish a house that some incompetent jabroni started, then got out of their depth and got fired midway. Meanwhile the homeowner has changed their mind and wants an open-concept kitchen, and the building inspector has come back with objections to the wiring plan that need to be rectified.

The physical dependencies of a house vs the abstract nature of software interdependencies really makes the analogy fail for me. Houses just don't don't regularly fall down 8 times a day because one framer is putting a nail in a new wall and that caused the fireplace to explode.

> No, I think they're looking for people who are intrinsically motivated by the drive to do a professional job applying their craft, rather than to use a project as an opportunity to experiment with technology that they want to learn for their own curiosity or career trajectory.

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 should care about how much you pay the contractor and the quality of work you get in response. That's your only contract with them. Same for a developer.

> 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".

One gets more than just money from work. Or one can get more. Friendship, community (however fleeting), challange, growth. If you over index on comp you may miss out on more fuzzy aspects. You are there 6+ hours a day might as well optimize more broadly.

How many devs out there are just faking it? People have learned to answer the "Why do you want to work here with?" questions "I have a passion about X, because Y."

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.

I think there's a bit of a spectrum between "I don't give a rat's ass about you or your project" and "This is my new life's passion".

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 really think it comes down to having empathy for the end user, which requires some level of caring about the product.

This is HN though. This is the same level of conversation at a trade show or over drinks. If you can’t lay out your dispassion bluntly (even if just for effect) here then where can you?

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.

I like to think most software engineers have at least some interest in what they're investing most of their waking hours in. Sounds miserable otherwise!

I like to think most software engineers don't work 56 hour weeks. Someone can take interest in their craft without taking interest in a product. And many people are happy enough working to live instead of living to work.

I’m kinda the opposite. I tried to be like this and it broke my brain.

hah you'll never figure this out before you hire me and pay me

Pay me commission.

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).

>No matter your technical proficiency, you are a lousy hire.

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.

It’s not strange if you’ve worked out that people who are invested are easier to exploit.

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.

This is just a really silly way to think of craftsmanship. Whoever you pay to redo your bathroom doesn't care at all, literally at all, about your motivations behind wanting to redo your bathroom and how you think it'll change your whole morning and evening routines. They don't care. It's their craft. They will redo your bathroom to the best of their abilities and will take pleasure in new or interesting units of work you've included in your bathroom design that they haven't been able to try.

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 would disagree. If they knew I was redoing my bathroom to sell the house and know my sink design choice is less saleable than another sink design choice, I would absolutely want this person to tell me as such and would pay extra money to hire a contractor who would say things like that. And then tell everyone I know to hire this contractor, they are worth the money.

That's not a contractor though....

This isn't really true IME. The best contractors will understand the goals and motivations for your project, and make suggestions based on their vastly greater experience of ways to improve upon the project.

This is correct. Also tends to be more expensive as well.

This comment makes it seem like you've never worked with a contractor.

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.

> 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.

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.

The grandparent said

> 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

I guess I don't see how "caring about writing code" disqualifies one from caring about the future?

> This is just a really silly way to think of craftsmanship. Whoever you pay to redo your bathroom doesn't care at all, literally at all, about your motivations behind wanting to redo your bathroom and how you think it'll change your whole morning and evening routines.

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.

> 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.

It's like you skipped over my entire post and only read the last sentence.

> 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.

> 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.

"I think that a who does not care about his or her end user is a worse in concrete ways"

> "I think that a who does not care about his or her end user is a worse in concrete ways"

You're just....saying things...? What does "Caring about the end user" have to do with "Believing in your product"?

You told them to remove "developer" from their sentence and they did, that's how the sentence now reads. I didn't get your point either above.

Dare to care. It may surprise you. If you take mercantile view of the world then that’s how the world will treat you.

More nonsense. I care hard about things that care about me, aka not businesses that I do not have a stake in.

Then ask for a stake? This is why so many people are paid part of their salary in stock options.

Yep, I do. But lots of employers don't offer any form of equity as compensation. The same employers that demand their employees to be "invested" in the company.

I remember hearing a story from a structural engineer who was disappointed with a builder on a commercial site. He took him around the site and showed him some of the sub-standard work and said to him, "This is not your best work, is it?" The builder responded with, "You should have told me you wanted my best."

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.

They sound like a great hire to me. If you needed an electrician to wire your house, would you rather hire someone who likes to get inspired and find creative ways to do electrical wiring, or someone who just wants to do the best and most documented practices while saving their creativity for personal projects

How about someone who cares about why you're trying to get a 200A circuit run to your garage and can provide feedback and point out things that they've seen before that could make your life easier. Or, like in my current situation, I really hope an electrician can come up with a creative solution to my current house wiring situation because it seems like it's going to be a huge hassle and the previous owner has painted us into a corner.

My own current situation is that I work with an electrician who found a hard-but-solved problem and wanted his own solution to it. He is now the only person who understands the wiring he did, and if he ever leaves the company we'll also need to find a creative person to work on it, or else throw it all out and start over.

EDIT: just be clear I'm still actually talking about software

There's a place for both- you need the devs who care more about adding business value quickly, and you need the devs that lean more towards perfectionism in how it's built.

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

In practice, the latter scenario seems rampant, at least IME.

Then the problem is that people who care about business don't want to learn to code. Blame them and tell them to learn to code rather than argue that people who like technical stuff must care about what you care about. In the end there are way more people out there who care about the business side so shouldn't be hard at all to make them the majority.

> These projects contribute to the success of the business in one way or another.

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.

Having been on the receiving end of shares, devs are in an extremely bad position to estimate their valuation. It’s like being a passenger on a train and being asked to judge which direction it goes. And I’m a product-oriented dev who loved the business side and loved doing plenty of UX interviews.

Being now on the donating end of shares, employees know much better how to value the gross pay.

But they did hire him. So now they have to figure out how to work with him.

Alternatively, and depending on the severity, they can recognize they've hired a bad (apple|fit) and separate, possibly update the hiring process, and move on.

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.

I disagree. I would love this hire. This person has clearly expressed what motivates them. I now know what type of work they prefer (and don’t), as well as the level of involvement they expect with outside stakeholders. It’s much easier to have a productive relationship with someone who can articulate this clearly.

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.

Very cool and healthy that people on this website instinctively imagine themselves as the boss of random commenters on a website whose motivations are incredibly relatable.

A while back we replaced the windows in our house with new, more efficient windows. The workers who showed up were the usual contract construction labor folks; generic company truck, not a whole lot of enthusiasm. Every replacement window came in a box. Every window wasn't the same, but neither were they very much different. A fair amount of pessimistic banter when they thought the customer wasn't in earshot.

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).

The project is your vision, all the decisions about the future of the project are being made by you (or your business people), how can you expect a developer to feel invested or engaged in the project? Are you willing to give the developer the same decision power as the business people?

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 this is a valid sanity saving technique, you have to be very judicious with it. Too often people get more excited by the tech they’re using than the problem domain, and their solutions start to fit that domain badly. Then we have impedance mismatches, and someone who is effectively holding the code hostage because that is where all of their emotional investment is.

I’ve seen this many times, participated a couple. In the end there’s a moment you should move on to something more interesting. And like selling your house, you should never look back at what they did to your code.

This is such an interesting concept coming from a different industry (architecture) into software development. I find it hard to be so disconnected to the outcome of what I am making. I definitely care about the projects that I am a part of, otherwise it just feels mechanical. I want to work to solve a problem that I care about, feel like I am doing something more meaningful than just implementing another warehouse logistics crud app.

Don't get me wrong, I have gotten pretty decent at making crud apps, but I find it so much more compelling if the crud app is making education more efficient, vs another problem that I don't care about.

I just find it so foreign that software engineering culture holds your mentality more often than not, where the tools that you are working with are advertised more than the problem you are solving. Not good nor bad, just an observation.

> writing code, and dreaming of a decent Transformers movie before I die

Have you seen Bumblebee? I don't know what your idea of a "decent" Transformers movie is, but if you still like the original series there's a lot to like about Bumblebee, including character designs, voices, and dialogue that are close to the 1980s originals.

This is ridiculous. Do you expect your contractor to explicitly tell you every detail of the project? It isn't even possible. Because the code itself is the only way to describe the project comprehensively. Because natural language is weak, and sometimes useless, especially in describing specifics. Natural language is good for negotiating incentives, which is why you have to think like your contractor in order to do the job.

This type of mechanical reasoning is a common pitfall. People did too much symbolic reasoning they end up embracing too much symbolism instead of real life and real people.

You might be perfectly suited for a devops-style of job.

As a developer working on business-related tasks your net contribution might even be negative with this attitude (because if you don't understand the business and you are not even interested in understanding it then the only tasks you can do yourself must be so small and so well specified that it (the specification) might take more time than doing the task itself).

I get where you're coming from, and I've been there, but this is a truly sad way to live.

If you can't find something that you care about to work on, why do it? Isn't it worth everything to do something that you're proud of with your life?

You can be proud of the accoutrements it takes to do your job without caring about the end product, especially if it's an environment you have little influence in the direction of the product.

It's not mutually exclusive.

Do you think tax attorneys are proud of tax laws, or do you think they care about being the best tax attorney in their field? This mind set isn't exclusive to certain industries.

I would perhaps re-think how you achieve your personal development, to be frank your username sums it up. Try to align what you want to achieve with the best interests of the project, it can be achieved I do it weekly.

A large enough project needs juniors and seniors. It's OK to be one but not the other. The juniors don't necessarily need to understand the project in a big-picture sense. But somebody does.

I don't see how not being emotionally invested in a project would mean you can't understand or even design the big picture of it. Feels a bit straw man-ish.

I really hated the Michael Bay Transformer films. Have you seen Transformers War for Cybertron on Netflix? It’s nothing amazing, but more entertaining than the Bay films.

> However for every project I take on, there will always be something I have never done before, or a maybe some new technique I want to try, could be a new language.

So you do care. But you care about the technology, not the InCrEdIbLe ImPaCt this latest "X-but-as-an-app" is going to have on the course of human history.

There's nothing wrong with you, and I'd love to work with you.

I think it was DHH who had a great line about this: Don't care about product, care about process.

For developers, the process of delivering value IS the excitement, it doesn't matter how awesome or boring the product itself is, it's the process of writing good code to solve customer problems that excites us.

Reply on news.ycombinator.com