[HN Gopher] You need Software Developers to believe in your proj...
___________________________________________________________________
You need Software Developers to believe in your project (2020)
Author : replyifuagree
Score : 196 points
Date : 2021-07-08 12:45 UTC (10 hours ago)
(HTM) web link (iism.org)
(TXT) w3m dump (iism.org)
| cultofmetatron wrote:
| I regularly pull in extra hours and all nighters for my startup.
| If there's a fire, I drop everything and focus until its fixed.
| If the product guys can reasonably argue that "doing x feature
| will close more sale", I will spend an entire weekend doing it.
| My incentives are completely aligned with the company.
|
| Whats the secret? I have the benefit of working with nontechnical
| cofounders who's earned my respect. Instead of wasting my time on
| "going webscale" and lofty ambitions, they spend their time
| interacting with customers to sell the product and gather
| feedback. Every features request that comes back to me to create
| is something thats going to be used.
|
| Of course, thats not enough. Thats just a baseline every startup
| should adhere to. I also have enough equity that if everything
| takes off like a rocket, I'll be set for life. I took the equity
| offer because of previous point.
|
| I don't expect anyone reporting to me to have that level of
| commitment if they don't have that level of stake in the outcome.
| By all means, they should do the work they are being paid for but
| I don't expect them to do more.
| MattGaiser wrote:
| The caveat to this is that if I am not going to have any real
| influence anyway, I would rather be a mushroom, as the
| alternative is being a meeting mushroom.
| anm89 wrote:
| or if they don't, you need to be paying software developers
| enough that they are willing to believe in your project
| surfingdino wrote:
| Vision is good, a decent spec that doesn't get re-written every
| week is even better.
| robinj6 wrote:
| This was really capturing my interest until I saw their title-
| cased Invented Solution that they were promoting to fix this.
| cutler wrote:
| No you don't. A competent software engineer can produce good work
| whether or not he/she believes in the project. Projects vary in
| their scope for making the world a better place. In a capitalist
| econonmy many businesses are not required to produce a net
| benefit for anyone other than the shareholders.
|
| This kind of thinking comes from the same kindergarten view of
| life which espouses only working on what you feel passionate
| about. If we all did that there would be an immediate shortage of
| shelf-fillers and cleaners. The same applies to the tech industry
| where a siginifcant number of fintech projects, such as HFT,
| contribute nothing of any real value to society. Each time I hear
| some startup wonk claiming he gets excited about making a better
| todo app I just want to throw up. The startup world is full of
| trivia chasing investment dollars.
|
| I've made a point of telling interviewers that I don't believe in
| their product and that it shouldn't matter. I'm hired for my
| technical ability alone for which I have a track record of
| producing good work on projects in which I had no personal
| investment.
|
| Clarity of goals does matter. That can make or break a project
| but it has nothing to do with believing in the product.
| musingsole wrote:
| You know it is entirely possible to be passionate about
| mortgage insurance market platforms. Or any [insert nominally
| boring task here]. If there is enough money to afford a
| developer for a problem, I'd argue it's a guarantee that it's
| possible for someone to be passionate about the problem space.
|
| So, if passionate problem solvers are available, what comes of
| not using them? Insufficient solutions. Keep telling yourself
| you make fine systems when you don't love the project. I bet
| you do. But the developer who actually cares will always
| produce something better.
|
| Add in that technology becomes entrenched, I'd argue we're
| always better working with no solution than to become attached
| to an inadequate one.
|
| Before you get hung up on "inadequate", I'll also throw out
| there that no spec is perfect and it is only the passionate who
| can properly fill it in.
|
| tl;dr projects completed by the jaded will only meet stated
| requirements. Projects completed by the passionate will define
| the _actual_ problem in the course of solving it. Projects
| produced by the jaded should be discarded.
| cutler wrote:
| It may be possible but is it likely? If you only have to hire
| one dev for the job you might get lucky but I'm talking about
| macro trends here. A lot of jobs to a lot of people are just
| plain boring. Life sucks.
|
| You say the developer who cares will always produce something
| better. Isn't that assuming parity of technical ability? Big
| assumption.
|
| You don't have to be jaded to not invest in the product
| personally. What's wrong with just doing a good job with
| professional detachment? Maybe it's more the case that
| projects/domains vary in their scope for passion and belief.
| A small team working in a startup is a different world than a
| Java team working in a large bank where corporate structure
| dominates.
| tester756 wrote:
| >A competent software engineer can produce good work whether or
| not he/she believes in the project.
|
| good? yea, maybe.
|
| can motivated employee do something better? more likely.
|
| If I'm working in exhausting/problematic business domain and
| salary is bad, then I'm not trying to outperform/save the
| day/yadayada
|
| unless I really see stuff that must be improved, but generally
| I'm just doing my stuff and go ahead.
|
| I don't like it, but sometimes there's boundary of how much you
| can mess with stuff that writing burns your hands.
| ravenstine wrote:
| Belief can be powerful, but there's a few problems with it.
|
| Firstly, people aren't going to just believe in anything. Let's
| face it, very few "believe" in something like Coca-Cola. Does
| that mean no one should work for Coca-Cola? _Of course people
| should._ (ethic of business practices aside!) Some of the work I
| 'm sure is interesting, and despite that millions of people enjoy
| Coke and many would be happy being associated with it. They might
| even be content working for them. I don't think it's necessary to
| have a belief or passion in a company to do good work for them
| and not hate your job.
|
| Belief is also fleeting because, if your company is successful,
| inevitably you will sabotage the things that made people
| passionate about it in the first place. Once you get corporate,
| stuck in your ways, and implement layers of aloof middle
| management, no one is going to care about your business from a
| personal level _no matter how much company surveys will suggest
| the opposite_. Belief is great, but you can 't count on it
| forever. You might be able to extend that belief by being smart
| and not doing things that would show up in a Dilbert comic, but
| it's far more common that companies abandon the things that truly
| inspired their employees. Most businesses dilute
| responsibilities, get rid of most of the nonstandard perks, and
| fundamentally get lazy as they milk the cash cow.
|
| What's more valuable long term is _respect_ and _trust_ in
| subordinates. If you don 't foster those things in your culture,
| you'll inevitably get 90% complacence and yes-men and 10% semi-
| disgruntled performers who do most of the work. So many employers
| don't want to hear what the experts they've hired have to say;
| they disrespect them by treating them the same as sales (and
| sometimes the sales dept becomes the _most_ respected) and
| milking as much effort as they can, disregarding any sort of
| estimates someone like an engineer would make.
|
| If you don't have respect, not only will nobody care about your
| project, but no one will give a _fuck_ about your project.
| rossdavidh wrote:
| So, I misread the date at first as being in 2013. That totally
| explained using Mark Zuckerberg as an example of an inspiring
| leader. For 2020, that seems like an odd choice.
| _rutinerad wrote:
| That first line "All too often organizations treat software
| engineers like mushrooms, which is to say they are fed
| "requirements" and kept in the dark about the why" really threw
| me off. Are there any "plants" that get told why they are "fed"?
| okwubodu wrote:
| Apple trees in an orchard can see where the fruits of their
| labor are headed.
| edderly wrote:
| I suspect the author is misapplying the more direct expression:
|
| "I'm being kept in the dark and fed shit"
|
| Which applies to a lot of dis-functional workplaces.
| bob1029 wrote:
| Did this article change for anyone just now? I was reading on my
| phone and I went to share with a coworker and its like half the
| content was deleted...
| LordN00b wrote:
| 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.
| maxbaines wrote:
| 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.
| hinkley wrote:
| 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.
| blacktriangle wrote:
| 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.
| bitwize wrote:
| > 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.
| slumdev wrote:
| > 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.
| jnorthrop wrote:
| 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.
| void_mint wrote:
| 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".
| SamoyedFurFluff wrote:
| 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.
| void_mint wrote:
| That's not a contractor though....
| mdoms wrote:
| > 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.
| void_mint wrote:
| > 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.
| mdoms wrote:
| 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.
| void_mint wrote:
| > 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.
| mdoms wrote:
| "I think that a who does not care about his or her end
| user is a worse in concrete ways"
|
| ??
| void_mint wrote:
| > "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"?
| throwaway98797 wrote:
| Dare to care. It may surprise you. If you take mercantile
| view of the world then that's how the world will treat
| you.
| void_mint wrote:
| More nonsense. I care hard about things that care about
| me, aka not businesses that I do not have a stake in.
| delusional wrote:
| 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.
| void_mint wrote:
| > 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.
| lexicality wrote:
| 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
| void_mint wrote:
| I guess I don't see how "caring about writing code"
| disqualifies one from caring about the future?
| notJim wrote:
| 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.
| twic wrote:
| But they did hire him. So now they have to figure out how to
| work with him.
| weimerica wrote:
| 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.
| kabdib wrote:
| 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).
| acituan wrote:
| > 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.
| laurent92 wrote:
| 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.
| tehjoker wrote:
| 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.
| idrios wrote:
| 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
| tonyarkles wrote:
| 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.
| idrios wrote:
| 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
| occams_chainsaw wrote:
| 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
| morgancmartin wrote:
| In practice, the latter scenario seems rampant, at least
| IME.
| username90 wrote:
| 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.
| whateveracct wrote:
| hah you'll never figure this out before you hire me and pay
| me
| schwartzworld wrote:
| You mean you want someone who is willing to blow smoke up
| your ass.
| uDontKnowMe wrote:
| 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.
| void_mint wrote:
| > 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.
| schwartzworld wrote:
| 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".
| throwaway98797 wrote:
| 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.
| andi999 wrote:
| So do you ask your contractor what keeps him passionate
| about garages?
| babyblueblanket wrote:
| 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...
| z3t4 wrote:
| 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.
| rpeden wrote:
| 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.
| LegitGandalf wrote:
| 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?
| thrower123 wrote:
| 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.
| LegitGandalf wrote:
| 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.
| ramphastidae wrote:
| 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.
| MattGaiser wrote:
| 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.
| afarrell wrote:
| I'm kinda the opposite. I tried to be like this and it
| broke my brain.
| allo37 wrote:
| 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.
| xur17 wrote:
| I really think it comes down to having empathy for the
| end user, which requires some level of caring about the
| product.
| hinkley wrote:
| 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.
| allo37 wrote:
| 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!
| pseudalopex wrote:
| 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.
| whycombinater wrote:
| 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).
| ABCLAW wrote:
| >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.
| hinkley wrote:
| 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.
| dnh44 wrote:
| 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.
| r-bar wrote:
| 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).
| qqtt wrote:
| 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.
| WJW wrote:
| 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.
| ketzo wrote:
| 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.
| sharken wrote:
| 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.
| darkhorse13 wrote:
| 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.
| somishere wrote:
| I feel like most of these comments don't apply particulary well
| to not-for-profit or cause based efforts. A situation where I
| find it almost impossible to reconcile a dev's involvement if
| they are not invested in the cause. Yes they can contribute
| piecemeal and under direct instruction, but if the vision isn't
| there ...
| specialist wrote:
| This article triggers my nostalgia. I like it.
|
| Very similar to how we methodology-philes talked back in the 90s.
| Peopleware, Mythical Man Month, Luke Hohmann's Journey of the
| Software Professional, etc.
|
| Thanks for posting. IISM.org is a great find. More like this,
| please.
| papito wrote:
| The last thing I am going to do is be attached to a piece of
| code. Most of the code that you wrote in your life? That's gone.
| A complete rewrite by some punk who did not want to understand
| it, the company no longer there, or just a failed product.
|
| If I am going to get invested, I want to be, you know,
| _invested_.
| pawelduda wrote:
| This resonates with me a lot. The projects that I found were
| burning me out the most were ones when I felt my work is
| meaningless because the projects weren't accomplishing anything
| and I didn't really believe my work alone could change that.
|
| As soon as I started working at something more meaningful, the
| feeling of burnout was orders of magnitude lighter, if not gone
| at all...
| mehphp wrote:
| While I do care about working hard and delivering quality work in
| general, I will never care about someone else's projects as much
| as I will my own or my own career advancement.
|
| It's very difficult to get excited when the CEO tries to drum up
| motivation for something that will make him fabulously more
| wealthy (if it goes well) and might mean a marginal increase in
| pay for me. Yeah, thanks, but no thanks.
|
| If you want me to put in more effort than I'm already doing,
| you're going to need to use cold hard cash.
| Consultant32452 wrote:
| My personal recommendation to new developers is to never be
| tricked into caring about the product you deliver or the company
| you work for. Care about your professional reputation, sure.
| Delivery high quality work, of course. But if the company/product
| fails that's not a reflection on you personally. Nor is it a
| reflection on you personally if it succeeds. If you want to also
| put your "heart" into something, make sure it's something that's
| yours. That could be your own business/product, could be your
| family or hobbies. But don't let it becomes your wage provider.
| This is the path to misery for most people. The trick is you
| won't feel it until your 40s or 50s.
|
| One personal anecdote in this area. I once had a manager
| compliment me in my 1on1 about how I always maintain my cool
| during stressful events and just get things working. He asked
| what my strategy was. I explained it's easy to not get flustered
| about project issues because I don't care about the project or
| the company. So a project or company failing isn't any reflection
| on me personally, it's just a minor inconvenience. He laughed in
| an awkward way that you could tell he wasn't prepared for that
| kind of answer. He promoted me the next year.
| roenxi wrote:
| There needs to be a clear vision of what the software is meant to
| be doing. Software engineers can believe in anything if they put
| their mind to it (eg, a disturbing number effectively work in
| projects that are tributary eyeball streams to adtech).
|
| The problem is when the vision is so confused and committee
| powered that nobody can resolve conflicts between teams by making
| strategic compromises. Software engineers are willing put up with
| a lot in the workplace, like everyone does.
| [deleted]
| [deleted]
| tut-urut-utut wrote:
| I don't need software developers to believe in my project. I am
| not working on some groundbreaking "save the world" project, just
| on some boring business applications.
|
| I don't need believers. I need professionals instead, that will
| do their best during the working hours, and implement things as
| requested, even if they personally think the project itself is
| totally nonsensical.
|
| However, what I would expect from developers is to be
| professionals and strive to the high technical quality of
| implementation, even if they don't believe in the usefulness of
| the project.
|
| EDIT: Looks like I was not clear about my role. I am not some
| business owner messing up with the technical decisions and asking
| developers to "be professionals" and "do what they are asked".
|
| Instead, by "being a professional" I am arguing that we as a
| technical team need to focus on the technical implementation of
| the business request, even if we don't believe in the business
| value. We can tell business if something doesn't make sense to
| us, but in the end it's their responsibility. We should not push
| our view of business requirements upon them, as much as we don't
| want that business push their view of technical implementation to
| us.
| cjfd wrote:
| Nonsense. This will make your project take at least 50% more
| time, if not more. The dialogue that one could have with
| developers will bring out ideas on how to do things simpler.
| Also, sometimes a requirement that you have now conflicts with
| one that you had earlier. If you don't have a good dialogue
| with your developers it may be that the first requirement just
| gets disabled or otherwise starts to behave unexpectedly. Then
| the users start to complain why it no longer works and things
| need to be redone. Good communication with the developers can
| prevent such things and save rework.
| spratzt wrote:
| Good communication has got nothing to do with whether
| developers believe in a project or not. The two are
| orthogonal.
| musingsole wrote:
| They are not orthogonal. At all. While it is possible that
| a project is compelling despite terrible communication,
| they are highly correlated.
|
| Orthogonal is a great word. Don't weaken it.
| spratzt wrote:
| It's the converse that's the issue.
|
| Projects with excellent communication that are not in the
| least compelling.
| OzyM wrote:
| I think it all depends on what the goal is.
|
| For tractable, straightforward, or routine software
| development, this seems _very_ true. For middling-difficulty,
| this seems often true.
|
| It's more just the edge cases - problems requiring a lot of
| creative thought or unique problem-solving tactics - where it
| seems like getting software developers to "believe" would be a
| huge boon.
|
| Just as curiosity is a large multiplier to learning, genuine
| interest is a large multiplier on difficult mental work.
|
| As a side note, offering "interesting" and "meaningful" work
| can be seen as another perk of a job listing (just like other
| optional benefits), especially to young or idealistic devs.
| p0nce wrote:
| > I would expect from developers is to be professionals and
| strive to the high technical quality of implementation, even if
| they don't believe in the usefulness of the project.
|
| And these are very reasonable requirements.
|
| As programmer, what I want from leadership is product vision,
| basic knowledge of software quality economics, lack of scope
| creep, technical debt control, good people management, and
| respecting the law. More often than not, you get zero out of
| these six.
| hpoe wrote:
| Counterpoint I work on a big boring business. I have two
| projects I am working on right now. One is a project that is
| interesting and I think will benefit the project.
|
| The other is one that I find poorly considered and a waste of
| money and effort. I try to do both to the best of my ability,
| but for the second project it has been made clear to me that my
| opinion is not really appreciated and that my technical opinion
| is not valued this has hence killed my initiative and desire to
| go above and beyond or my desire to advocate for changes for
| the betterment of the project. Not because I am lazy or
| resentful I've just learned that attempting to do so on this
| project is a waste of time and effort and my energy would be
| better spent elsewhere.
| tut-urut-utut wrote:
| I feel you there. I am also working on a project now that, I
| feel, is a net negative for my company. And you are right, no
| one is listening to me about it. And they shouldn't, as a
| software architect who am I to tell business owners that
| basing a company around SAP ERP is a good idea from the
| business standpoint.
|
| However, as an internal technical team full of professionals,
| we are making sure that right technical decisions are taken
| during the implementation, and we don't allow inferior SAP
| tools that "work out of the box with the SAP ERP" to pollute
| our technical landscape, and we are not letting SAP
| consultants to further lock us in into their world.
|
| That's the part where we still can be professionals and do a
| great implementation of a "shitty" project we don't believe
| in. But you are right, if we were not allowed to be
| professionals and if business would not respect our technical
| decisions, it would not be our fault to be demotivated and
| just do the bare minimum required not to be fired on the
| spot.
| bizzleDawg wrote:
| I largely agree and I have structured my career around this
| belief in recent years, however, I do feel the cognitive
| dissonance of "being a professional" despite feeling that a
| project is not a net benefit to society does take its toll
| [deleted]
| spratzt wrote:
| I absolutely agree.
|
| Even worse, of course, are 'passionate' developers. They're a
| real nuisance.
| OzyM wrote:
| How so? Wouldn't working with someone passionate about
| improving the project be useful, even if you're not equally
| interested?
| rleigh wrote:
| Because it can often mean that they lack dispassionate
| objectivity.
|
| How often have you seen starry-eyed people like this push
| their pet technology into a project just because it was
| their passion, but without any view as to the wider
| technical context or business context. They can be a real
| menace. Not because they aren't technically competent. But
| because their judgement is poor. Looked at from a distance,
| they aren't looking at what's best for the company or the
| project, but what's best for themselves.
| OzyM wrote:
| Ah, that's fair. I definitely agree it's a problem when
| trying to cooperate on a program. I think it's probably
| more a function of inexperience or poor judgement than
| passion per se, but overzealousness definitely
| exacerbates it.
| etripe wrote:
| Are you finding, getting and keeping the professionals you
| want? In other words, do your employees seem to agree with you?
| MattGaiser wrote:
| A lot of this comes down to how "do their best" is defined, as
| implementing things as requested would send many of the
| projects I have worked on careening off a cliff very quickly.
| one_off_comment wrote:
| Talking about the importance of your employees' passion is code
| for how to get more work for less compensation. View statements
| about the importance of passion from potential employers with the
| same suspicion you would statements like "we're a family here"
| and "it's not about the money".
| ianmcgowan wrote:
| "word hard, play hard" is also a red flag
| ItsMonkk wrote:
| I've been looking into this subject lately as I am now moving
| into management positions and attempting to figure out the best
| way to do so.
|
| Software Developers, let's say I gave you a problem, and that
| problem was currently being solved with an O(n^2) algorithm, and
| it turns out that problem was taking up 50+% of your cycles, and
| because of how it was solved there is hard-coupling that
| disallowed better approaches, and that you can resolve this
| problem into an O(1) algorithm?
|
| Would you want to hear about that algorithm? Because it's called
| communication.
|
| The model I now think of Development teams is that you have
| Developers at the center, and then everyone else are teachers
| assisting them. A UX Designer is there not to create the UI but
| to teach the Developer how to go about creating the UI. He will
| start by creating designs, but he will allow the developer to
| make their own mistakes and eventually the Developer will become
| a Master UX Designer in his own right. This is true of every
| element of the Software Development LifeCycle. From technical to
| designing the product itself.
|
| Once you have a Developer that understands Databases, understands
| Backend, Frontend, CSS, UX, understands the Product, works with
| the Users and dog-foods his own product, you will find the amount
| of time that it takes to get a superior product will drop
| massively. The example I like to give here is that Linus Torvalds
| created git in 10 days because he was a master user of Source
| Control and knew exactly what he needed, while Microsoft's Source
| Control team had worked with hundreds of developers over years
| and couldn't compete. When you have hundreds working on a project
| the ability to communicate in a depth-first-search style drops to
| 0, and you are left to only breadth-first-search solutions.
| Metcalfe's Law destroys productivity.
|
| Meta about the article: I think it's moving forwards but it's got
| so much going on it's hard to pay attention to any single point.
| Iv wrote:
| I fail to see your point. You are saying that communication can
| help developers be more efficient then you give an example of a
| good developer who did not need a team to develop a ground
| breaking product?
| kirkules wrote:
| I think somewhere in there was a point about how when these
| different roles (backend, frontend, ux, dogfood, etc) are
| distributed across multiple developers instead of one,
| connections between the roles are outside of a brain and so
| need to be optimized explicitly.
|
| It was framed for a reader already convinced that management
| of developers is not useful, but didn't make that clear.
|
| Lesson for GP: implicitly assuming a position that your
| audience may not have can be confusing -- a barrier to
| communication
|
| Edit: from other comments, looks like i was wrong and it was
| utter nonsense
| ItsMonkk wrote:
| Sorry, the problem is communication. The solution is no
| communication. You do so by teaching your developers
| everything they need to know.
| mehphp wrote:
| oof..
| selfhoster11 wrote:
| I don't want to be an expert in everything. I want to have
| a passing knowledge of UX, JS and so on, but my area of
| expertise is Java backend. Let's keep it that way.
| thrower123 wrote:
| Ah yes, the human-hatrack developer.
|
| Hats! More hats! You're not a real full-stack developer
| unless you can do the work of eight or ten people on one
| salary.
|
| I've done this, it's not sustainable.
| throwawayswede wrote:
| > You do so by teaching your developers everything they
| need to know.
|
| I feel bad for people who are going to work on your team.
| romanhn wrote:
| I don't mean to pile on, please take this as advice from
| someone who has been in engineering management for quite
| some years...
|
| You seem to have some preconceived notions about managing
| people (and engineers specifically) that will, frankly,
| cause you a lot of trouble were you to implement them with
| your teams. Minimizing all communication will lead to a
| total breakdown of context - you want to strive for more of
| good communication (immediate team collaboration, access to
| stakeholders, healthy relationships with other teams) and
| less of bad communication (pointless meetings, status
| updates, cross-team blockages). Having engineers be
| responsible for _everything_ is also a solid recipe for
| burn out and dissatisfaction, as others have pointed out.
| Most engineers do actually enjoy learning, but the manager
| 's role is to encourage and provide opportunities, not to
| be the teacher, or appoint teachers.
|
| I highly recommend reading existing literature on
| management, and not paving your own path here. Start with
| Camille Fournier's "The Manager's Path".
| throwawayswede wrote:
| Don't take this the wrong way but your comment represents many
| things that are wrong with the industry.
|
| Meta about your comment: Major condescending-vibe overall.
|
| > Would you want to hear about that algorithm? Because it's
| called communication.
|
| First of all, drop the patronizing tone. Second: what are you
| saying? Developers don't communicate? Don't communicate
| efficiently or correctly? Specify the thing that is wrong and
| your proposed solution and then it can be assessed. As it
| stands your first paragraph is meaningless. For what it's worth
| I've worked with marketing teams that have communication skills
| that match a random rock on the street, so this is not a
| developer issue. That "developers are all geeks and nerds and
| can't talk to people, and i'm here to fix it" is an old tired
| routine that needs to be dropped.
|
| > A UX Designer is there not to create the UI but to teach the
| Developer how to go about creating the UI
|
| You're assuming a random developer is: A) interested in
| learning UI design, B) needs to learn to design UI, and C) that
| whoever this random UI person wants or even can teach them.
| You're building too many assumptions on top of each other.
|
| This kind of comments resembles the thinking process of a
| person with "product manager" position in a small/medium size
| company. Deep down (consciously or subconsciously) they don't
| really respect or see the value of the individual developer,
| but they see the team more like a bunch of horses going around
| the mill. They optimize for "the product" and throw around
| sophists-like pseudo-philosophical thoughts that appeal to
| like-minded individuals or to their bosses.
| babycake wrote:
| Wow, this speaks so many truths. And to add to this, if you
| want us to care more about the product, the simple truth is
| just to pay us more. Hit that sweet financial spot for us and
| we're yours. This is universally true for any job, in fact.
|
| Instead we get what is essentially a Mcdonald motivation
| video in white collar form... telling us that we should care
| cause of impact, customer care, improve motor skills, blah
| blah.
| [deleted]
| OzyM wrote:
| I really don't think this is universal. Sure, some people
| are definitely like this, but I want to be able to believe
| I'm building something interesting that will be used after
| I leave. I would take (and have taken) slightly lower-paid
| jobs that I thought would matter more in the long run.
|
| Also, I feel like this view of software developers'
| motivation would have a really hard time explaining major
| FOSS projects.
| babycake wrote:
| There's two ways to look at this. One is you've found
| your dream job, and that job defines you as a person.
| That's fine, because it's working for you and it's how
| you want to spend your life. But I feel this is a rare
| event, to find and maintain their dream job for years
| over reorgs and new CEOs, or having the company bought
| out and new company making bad internal changes.
|
| Then there's the other bucket of people, who are just
| trying to make a living, but the environment makes it
| hard for them to do so due to it being so toxic. And this
| is where no amount of starry-eyed speeches will sway this
| group to working harder without pure cash. They're there
| to make money, they understand that the employer they
| work for are gonna get richer while they only get
| inflation-rate increases. These people would rather spend
| their time with family and friends.
|
| For what it's worth though, based on friends who are
| chaplains and priests, those dying on hospital beds
| always tell a tale of being with friends or family, or
| personal events that gave them positive memories. Not a
| single one of those people they talked to ever spoke of
| how they did well at any of their jobs. And from this I
| think most of us fall under the second bucket. To
| encounter someone like Linus or Stallman who would
| probably talk about their work as a life achievement is
| probably a one-off unicorn.
| OzyM wrote:
| I feel like there's some room for middle ground here.
| While I disagree with some of 80,000 hours' conclusions,
| I do think that a person's job is a major way they have
| an effect on the world.
|
| I have hobbies, friends, family, etc. that I consider
| more important to who I am as a person than my job is.
| However, I still have a marginal preference for decently-
| paid meaningful work over well-paid meaningless work.
| bjornsing wrote:
| > This kind of comments resembles the thinking process of a
| person with "product manager" position in a small/medium size
| company. Deep down (consciously or subconsciously) they don't
| really respect or see the value of the individual developer,
| but they see the team more like a bunch of horses going
| around the mill. They optimize for "the product" and throw
| around sophists-like pseudo-philosophical thoughts that
| appeal to like-minded individuals or to their bosses.
|
| There's some truth to that somewhat cynical description. :)
| But how do you organize software development without falling
| into that hole? A product has to make sense as a whole, and
| the only/easiest way to accomplish that is to make a single
| person responsible for its high-level specification. From
| there the negative cultural fallout you describe is to some
| extent inevitable (although you can and should counteract it
| of course).
| throwawayswede wrote:
| I think product manager is a very important role. But I'm
| yet to see a product manager that respects the craft/skill
| or even spends any effort to understand what's entailed.
| Most are shoot-an-email-assign-on-jira-and-call-it-a-day
| type. Nothing more depressing than getting a condescending
| "good job!" from an oily haired zoro for making a menu
| bigger and not getting any recognition for lowering server
| costs 50%. This is not an exaggeration, there are many many
| stories like that or even worse. I've heard developers
| described as plumbers even from people who work in highly
| respected and big companies. There's nothing wrong with
| plumbers, but it's just to show how they think about what
| we do.
| bjornsing wrote:
| Sure, I've seen a lot of it first hand, both as a
| developer and in other roles. It's sad really as it feels
| very destructive / counterproductive. But it seems hard
| to get around.
|
| Couldn't help noticing your username implies you're
| Swedish. I am too. Sometimes I get a feeling there is
| something about Swedish work culture that makes this
| worse. We have a long tradition of workers unions and
| collective bargaining, and everyone being replaceable is
| sort of taken for granted (or even encouraged). Any
| thoughts on this or how to get around it?
| ItsMonkk wrote:
| It's not ironic that I am failing to communicate when my
| argument is that it is hard to communicate.
|
| Perfection is in knowing everything and not having to
| communicate. Nobody is perfect and communication is
| inevitable. New domains pop-up every year. It is up to the
| developer to work out which domain they want to seek out next
| and a team of developers that have all sorts of skills will
| always be required. The core of my argument is that we need
| to empower developers to discover what will lead to
| efficiency. Hopefully those developers can cross-train, as
| the only way to lessen the load on the team is remove
| complexity of the application, and the only way to do that is
| to communicate between all of the domains. The best way to
| communicate is to have someone who knows all of the domains.
| throwawayswede wrote:
| > The core of my argument is that we need to empower
| developers to discover what will lead to efficiency
|
| As others have answered, the answer is very obvious and
| doesn't need a lot of theorizing. Give good money and
| respect. Treat people as individuals (especially your
| mid/senior people). Accept that people will work on your
| team NOT because they believe in your product (they may in
| fact hate it) but because they need the money or the
| experience. This is not bad or wrong as long as they're
| being professional about it. Most important one is to not
| generalize, and to recognize nonsense that might creep into
| your thinking process. Most engineers have a great eye for
| spotting nonsense and they smell bullshit a mile away.
|
| > as the only way to lessen the load on the team is remove
| complexity of the application, and the only way to do that
| is to communicate between all of the domains
|
| Shaky assumptions upon shaky assumptions. These kinds of
| statements usually come from either a very experienced
| person or an extremely inexperienced one. From the
| substance of these statements it's obvious it's the latter
| and not the former.
|
| > The best way to communicate is to have someone who knows
| all of the domains.
|
| Honestly if you had started with this statement I wouldn't
| have replied at all because I would be 100% sure you're
| trolling. I can't even tell anymore. But this is way beyond
| unfounded.
| ItsMonkk wrote:
| > These kinds of statements usually come from either a
| very experienced person or an extremely inexperienced
| one.
|
| Why not both? I'm an experienced developer with no
| management experience. This is exactly why I opened with
| "moving into". I do not believe that these are shaky
| assumptions, but have been proven by my development work.
| I am a man of many hats. Some of those hats are chiseled
| perfectly, some of them are rough.
|
| The way that I work out how to go about learning things
| is go down a utopian path and create myself a minimal
| example. Many times the approach falls apart right away.
| When they don't, like this one has, and the world isn't
| already working that way, I expect that I am wrong but
| don't know why. So I reach out on places like Message
| Boards and peers in an attempt to work out why.
|
| Unfortunately this thread has been filled with a lot of
| harsh responses that mostly show that I have blown
| peoples weirdness budgets and am outside of the Overton
| Window with no real substance. That may be partly my
| fault and I hope that I at least learned something from
| it.
| arawde wrote:
| > Once you have a developer [who does everything], development
| time to get a superior product will drop massively
|
| I feel like you're just going to get stressed engineers who are
| stretched thin across multiple domains. This sounds horrible
| deregulateMed wrote:
| Believing in a project just means they are going to underpay and
| overwork you.
|
| Give me equity and I'll care.
| throwaway98797 wrote:
| no you wont.
|
| you give people some equity they want more.
|
| or worse yet now as an owner you will comment on direction of
| the company since you have a vested interest. distracting the
| folks who are leading the company.
|
| not saying that the leaders know what they are doing, but at
| least let them fail without distraction from small stake
| owners.
| alexaholic wrote:
| My experience has been different than what is described here. I
| haven't met that many developers who didn't know why they were
| doing what they were doing. Instead I've met lots of managers who
| used the _why_ as if it was some magic wand that made the
| impossible possible, that turned garbage into clean, working
| code, that magically reduced the number of bugs to none, that
| squeezed six hours of hacking into one etc. I've met people who
| repeat the same _why_ over and over again as if that turned
| developers into machines that spit out good software, fast and
| cheap. More often than not I found myself telling my manager "I
| don't know", "I'm not sure", "I'll think about it" or "that will
| take a while", and got a response like "yeah, but we need this
| because of/in order to/etc."
| specialist wrote:
| > _More often than not I found myself telling my manager "I
| don't know"..._
|
| In my experience, intellectual honesty has greatly limited my
| career.
|
| I physically can't outright lie. But over time I've gotten
| (minutely) better at diplomacy.
|
| - Rephrase negatives as positives. eg Instead of "Don't run!"
| ask "Please walk.'
|
| - To always sound encouraging, supportive. h/t Guy Kawaski's
| depiction of Gassee in The Macintosh Way. "Wow, what a great
| idea! You've clearly put a lot of effort into this."
| https://en.wikipedia.org/wiki/The_Macintosh_Way
|
| - Compliment sandwiches, surrounding criticisms with praise.
| Gene Wilder's letter to the costume designers for Willy Wonka
| is an oft cited example.
|
| - All that active listening and empathy stuff. eg Really,
| really listening to people, instead of just waiting for my turn
| to talk. eg #2, in meetings, hold back with my own feedback to
| see if any one else will make the same points first, thereby
| not sucking up all the oxygen.
|
| Etc.
|
| It's fucking exhausting. But like all skills, it does get
| easier over time. And my (probably wrong) perception is that
| I'm slightly less boorish and offensive.
|
| PS- I save up all my unsolicited feedback energy for HN. Haha.
| alexaholic wrote:
| I appreciate your gracious response. It's important that we
| discuss such matters openly and positively. You're practical,
| as always, and I feel inspired to apply some of your
| suggestions in my own practice. There couldn't be a better
| time to bring this up, in fact. Just this Tuesday marketing
| reported one of our customers thinks our monolithic
| architecture is too conservative and hurts their feelings.
| They suggested we switch to micro services as it aligns
| better with their beliefs. We did the math and found indeed
| micro services would not only make our customers happier but
| would also bring in more business. The CEO thinks it's
| crucial we transition before our competition does to not hurt
| our business projections. I was thinking we could squeeze
| this into your next sprint and don't waste any more time. I'm
| thankful to have you on the team as you've proved yourself
| tenacious and a key player. Your positivity is such an
| inspiration for the team! A can-do attitude is one of the
| best things one can do to themselves, their boss and their
| customers. In fact I feel it aligns very well with our "Yes,
| we can!" strategy to effective customer communications. Keep
| up the good work, our customers depend on you!
| specialist wrote:
| Nice.
|
| You'll be senior executive VP of advanced design
| actualization in no time!
|
| Fast track!
|
| More seriously, I discovered two weird unexpected side
| effects. First, even when you know it's all pro forma,
| praise still feels kinda awesome. Also, how you talk
| changes how you think. So eventually you'll come to
| actually believe it. Insidious!
| sam0x17 wrote:
| This is so very true. I've definitely worked in those
| environments where threats are used to try to eek out more
| performance, and the net result is lower performance. As the
| article says, you need buy-in from your developers, and if you
| are a problem, they will solve you instead of solving the problem
| they are supposed to be solving.
| coding123 wrote:
| I feel like 20 years ago I was empowered at places I worked to
| add features or menu options or even entire screens that made
| sense. Lately everything is designed by some UX person and it has
| to look exactly like that. I am guessing even early twitter had
| engineers that dictated how things worked or looked and I'm
| guessing now they pay millions of dollars for each 20x20 pixel
| area of the screen.
| spamizbad wrote:
| Yeah, I have noticed a certain measure of developer autonomy
| has been lost, going to product management (who in-turn defer
| to design/UX). I don't think it's all bad: I always appreciated
| expertise when it comes to esthetic and experiential parts of
| software.
|
| What I do find frustrating is when they only concern themselves
| "happy path", and developers don't have the authority to fill
| in the gaps. It creates a waterfall-like experience where you
| are often stuck waiting to hear back from product/design to
| make a decision because they didn't consider a scenario where
| the user might submit a form with an incorrect field or some
| other seemingly obvious path.
|
| Another bad practice is product people who assume screenshots
| or Figma files are technical requirements; not realizing these
| only give you clues as to how something will _look_ , not how
| something will _work_ , so flows and business logic go under-
| examined by product, which can lead to more "let's hold off on
| that, let me think about it" after telling you to start
| something ASAP.
| BreakfastB0b wrote:
| I like to call this the human centipede of product
| development. This is why I only work at smaller companies
| where this is less of a problem.
| brightball wrote:
| I'm a big fan of prototyping functionality with no UX input at
| all, so that the engineers have full authority to look at all
| the moving parts and figure out the best way to make them
| work...without any design constraints.
|
| At the point we have a functional prototype, go through it with
| UX so they can understand all of the pieces before they do the
| design. Sometimes it leads to minor improvements on what the
| engineers already came up with. Other times it leads to an
| overhaul.
|
| But as long as all of the core functionality is built first,
| iterating on the design will just be moving a few things
| around.
| apercu wrote:
| Developers creating user experiences that don't actually take
| in to account what the user needs to achieve as tasks many many
| times a day are entirely the reason we now have UX people.
| onion2k wrote:
| _I feel like 20 years ago I was empowered at places I worked to
| add features or menu options or even entire screens that made
| sense._
|
| My first startup made an application that tried to control
| changes to projects and stop scope creep, and this reminds me
| why I thought there was a market for it. :)
| notjustanymike wrote:
| UX design is heavily influenced by rules and research, just
| like engineering. There are systems at play which I'm sure the
| company would like to keep consistent.
|
| While you may be able to build a working page, can you ensure
| that every engineer builds it with the same interactions,
| flows, language, and even colors? Will you build and test it
| for the users the UX team has researched, or will you build it
| for yourself?
| hpoe wrote:
| I can actually by just sourcing a CSS file that has the color
| scheme defined and that can be changed as needed.
|
| I can keep consistentancy by just having a JS library that
| has our components.
|
| As for flow no I can't because different situations and
| objectives require different workflows to force them all to
| be the same is the kind of thing that sounds like a good idea
| until it is clearly not.
|
| But the funny thing about all of that is that everything
| listed above has to be done either way, and usually the UX
| guys will shove it off on engineering to implement so where
| is their value add....?
| Kranar wrote:
| Many "UX persons" are engineers or computer scientists, and
| having a good working relationship with them and seeing them as
| equals goes a long way to allowing you to provide your own
| insight and give suggestions and feedback.
| chii wrote:
| the problem happens when they aren't your equal, but the
| workplace is too politically correct for you to bluntly point
| it out. All you can do is suggest improvements, if at all.
| Pokepokalypse wrote:
| When I'm working with a colleague who has a specialty, I
| don't generally concern myself with whether they're "my
| equal" but rather, whether they bring something
| constructive to the table, in their specialty.
|
| I find "graphic designers" to be enormously helpful in
| solving problems related to user interaction and judgment
| with regard to use of color, typeface, and effective use of
| limited screen real-estate.
|
| There are good ones and bad ones. The key is to assess
| where they are, and learn how to communicate with them with
| regards to any technical impacts.
|
| The last thing I'd want to do in collaborating with a team-
| mate is summarily judge them as "my inferior". But that's
| (unfortunately) just me.
| hpoe wrote:
| I envy you if that is your experience. Almost all UX persons
| I have worked with have a degree in "Design" and are artsy
| type that tell me. "You can't make this blue it just doesn't
| vibe with the green we have."
|
| Many of who use the argument "Apple/Google does it this way"
| I'm not saying your now right it's just been my experience
| that they aren't engineers or Computer Scientists.
| exdsq wrote:
| I've seen what happens when computer scientists go off on
| their own and design a user-centric product. Trust me, its
| good to have an 'artsy type'. I worked on a project with
| some pretty 'famous' CS guys (obviously relative to the
| field) and their form of documentation were essentially
| quizzes for the users to work through. Practically an end
| of term exam. It was crazy.
| carlmr wrote:
| The problem is not necessarily their incompetence, but that
| they're given the exclusive right to dictate every detail of
| the UX.
|
| The problem is that they often don't know the constraints of
| the system you're working with, something that only comes
| with actually working on the implementation.
|
| E.g. I was working on a display. The graphics were designed
| by a UX Team. However the display only had 256 colors, had to
| be readable outside, had a 320x240 resolution. They had
| designed everything as vector graphics with highest color
| settings on really good Eizo monitors. The customer thought
| the designs look cool, and I wasn't given any freedom in
| improving them.
|
| I tried discussing the constraints with them, but because
| they were "on top" they wouldn't listen.
|
| In the end the customer saw the prototype and said it looked
| terrible. But I had all the communication with the UX Team
| and them that I wasn't allowed to make it work for this
| display.
|
| In the end it cost everyone an extra month and a lot of
| frustration to arrive at basically what I suggested when I
| first checked the hardware.
|
| The problem isn't to learn about UX, it's that you have a "UX
| person" that may not know about UX and dictates the terms.
| nicoburns wrote:
| IMO if they're not respecting technical constraints then
| they are incompetent. Good UX people I've worked with not
| only worked closely with developers to understand technical
| constraints, but developed a good understanding of the
| platforms we working with in their own right such that they
| would often pick up these issues themselves if they'd come
| across them before.
| gherkinnn wrote:
| That very painful example sounds like a bad setup where
| clear technical constraints weren't taken in to account.
|
| People not listening come in all forms. UX, dev, MBA.
| volta83 wrote:
| To me it sounds like either you failed to communicate, or
| your UX persons were bad hires.
| carlmr wrote:
| I didn't hire them, and I did exactly communicate the
| issues early on to my manager and the UX people.
|
| Everything else was out of my hands.
| rapfaria wrote:
| I've been through something very, very similar.
|
| UX person suggests a design that is sprinkled with choices
| that clearly are from someone that has not been on the web
| that long, like wrong icons.
|
| We do a meeting and explain what is going on, what the user
| wants to see on the page, and the UX comes back (usually
| that same day - how quick of them) with another version,
| but this version shows that the UX person did not
| understand the problem again. And again. And again.
|
| I've seen the UX person showing a wireframe to the user and
| asking 'Will this cover all scenarios?'. Client said yes,
| we delivered the feature monday, and tuesday client was
| 'hummm, without the hability to do scenario X, this won't
| be used'.
|
| The reason the UX person is so beloved between a bunch of
| devs is only because of the UI aspect of it - it looks
| good, something we devs could not come up with. But damn, I
| would love to work with an UX that I feel that knows what
| she's doing.
| eecc wrote:
| By this description they weren't actually good UX
| Designers. A true professional will take all constraints
| into account, particularly in what seems to be a custom
| display for an appliance/kiosk/dashboard.
|
| It's like that guy that said: "it's easy to be a good
| investor in god times, it's when recession hits that the
| pros really shine"
| bluefirebrand wrote:
| > By this description they weren't actually good UX
| Designers. A true professional will take all constraints
| into account, particularly in what seems to be a custom
| display for an appliance/kiosk/dashboard
|
| No true Scotsman would ignore the technical specs!
|
| The fact is that many UX designers are designers first
| and foremost and maybe even entirely non-technical when
| it comes to specs. The existence of "true professional"
| UX designers does not mitigate the vast quantities of
| average skill UX people most teams will encounter.
| nicoburns wrote:
| > The fact is that many UX designers are designers first
| and foremost and maybe even entirely non-technical when
| it comes to specs
|
| I don't think that's much of an excuse. A graphic
| designer needs to know about page bleed and colour
| spaces. A product designer needs to understand the
| strengths (literally sometimes) and weaknesses of the
| materials they are working with. And a UX designer for a
| tech product needs to understand the technical
| constraints of the medium they designing for, or be able
| to talk proficiently to someone who does.
|
| How can you design a user's experience (lest we forget
| what UX stands for) if you don't understand to at least
| some level the medium through which it will be conveyed.
| Designing something that a user will never see because
| the colour depth of the display they be using can't
| convey it is not designing the user's experience at all.
| dgb23 wrote:
| Whether we build an OS kernel, a HTTP server or a video
| game, we essentially translate between two abstraction
| layers to facilitate communication. It's on us to
| understand both sides well enough to achieve this.
|
| A UI is essentially the highest layer of abstraction we
| build and thus should follow the same principles as any
| other. Namely respecting _both_ the lower and the upper
| abstraction barriers.
|
| UX designers are responsible for the language on top of all
| these layers. They need to understand the human side of
| things (often through data or through direct interaction
| such as workshops), but also the technical and artistic
| side of UI implementation. Direct interaction, written
| documentation and learning are paramount.
|
| The good thing is that we programmers also want to
| understand the layer above us, so there is a natural pull
| for programmers and designers to communicate and to refine
| that communication.
| spicybright wrote:
| That sounds discouraging. But you can apply the same story
| about any manager-like figure, no?
|
| If one's priority is design freedom or whatever, a good
| working relationship with your higher ups is the best
| chance to enable that.
|
| Working well with managers is also a good strat for
| becoming one yourself, and having more influence over
| things you care about.
| carlmr wrote:
| >you can apply the same story about any manager-like
| figure, no?
|
| True, the problem is more when companies become more and
| more top-heavy over time. These intermediate layers are
| created. With every layer it becomes less likely that the
| people that can actually decide won't ever hear valuable
| feedback until it's too late.
|
| >Working well with managers is also a good strat for
| becoming one yourself, and having more influence over
| things you care about.
|
| In the end I showed them what had to be done to make it
| look decent on this kind of display. Because all layers
| of management were in the room, they managed to decide to
| do these changes. It's just a very inefficient way to get
| to this point.
| atatatat wrote:
| > necessarily their incompetence, but that they're given
| the exclusive right to dictate every detail of the UX.
|
| Unless you have valid reason to think the user would prefer
| your way, this sounds like the correct chain of command for
| a strong product.
| varjag wrote:
| ...aand we're back to waterfall
| exdsq wrote:
| Yaaaay, less meetings
| marcosdumay wrote:
| You certainly mean less meetings once we are past the
| design phase. Because that phase is a single non-stop
| months-long meeting. Also, as soon as the design phase
| ends, the design is discovered to be broken. So the phase
| must be restarted.
|
| Repeat the above for as long as you want.
|
| Of course, the kind of place the GGP is complaining bout
| won't let peasants like developers to take part on that
| phase, so win-win, I guess.
| carlmr wrote:
| I think usability is a valid reason. Their design had
| none.
| MattGaiser wrote:
| Most of the ones I have ever encountered are former graphic
| design people.
| ratww wrote:
| For me it is 100% former graphic design people.
|
| In fact I've seen several engineers trying to migrate to UX
| but the gatekeeping and prejudice made them give up.
| rubyist5eva wrote:
| I have worked at over a dozen companies of various scales and
| never once met a "UX Person" that was an engineer or a
| computer scientist, let alone have any formal education or
| experience with human-computer interaction. They were
| glorified web designers at best, and them dreaming up
| ridiculous features with no technical know-how, ultimately
| leading to "compromises" (aka. massive amounts of technical
| debt) was the #1 contributor to lack of morale and engineer
| churn at every single one.
| ratww wrote:
| The thing is that the "seeing as equals" has to cut both
| ways.
|
| UX people, UI designers and PO/PMs who see developers purely
| as interface xerox machines don't really deserve much
| respect.
| bjornsing wrote:
| Eh? When one person dictates every aspect of the end result
| to another person there's definitely some inequality there,
| but doesn't it run in the opposite direction to the one you
| imply?
| eplanit wrote:
| I've worked with many, and none have ever had a bona fide
| engineering or comp. sci. background, except for a few who
| didn't cut it in the ranks of developers, and so redirected
| themselves or were shunted off to UI (now "UX" to make it
| sound cool) -- they've all been visual artist types. I find
| it best to get high-level (graphics, the css, color schemes)
| design ideas from them, and then leave it to the engineers
| for implementation, who might tweak/adjust/remove some items
| in order to balance with performance, usability, and sanity.
| If, instead, UX is given "authori-tie" then it becomes
| ridiculous, fast.
| MattGaiser wrote:
| One of the things that really surprised me working as a
| software engineer was how much my work would be judged how how
| well it matched the drawing.
|
| It often seems like there is more verification of that than
| whether it does what was intended.
| mgkimsal wrote:
| But... for most of the reviewers/team, what was intended is
| that the result look like the drawing. That's it.
|
| "Here's a mockup - we spent a lot of time on this".
|
| "OK... what does it look like on tablet, mobile, what are the
| failure states, what should error handling look like?"
|
| "We spent a lot of time on this - make it look like the
| mockup".
|
| Had a project years ago that was... almost as bad as that
| sounds.
| MattGaiser wrote:
| I worked on a project where the buy button was off the
| screen on anything but a wide monitor. So I could not see
| it on my laptop.
| jollybean wrote:
| It's an easy thing to inspect for, and, most UX designers
| have pixel perfect expectations, which is actually not
| unreasonable in most cases as every pixel generally does have
| it's place.
|
| The problem of course is that it's too easy to focus on pixel
| perfection at the cost of other things.
|
| Recently, I've worked on a project and we had to force
| ourselves to 'not care' about those things until the very end
| when we did clean up.
| legulere wrote:
| But aren't projects where you don't have time to work in
| the details not also projects where the next project is
| waiting around the corner?
| AnIdiotOnTheNet wrote:
| I'd be totally fine with UX designers having final authority on
| these matters if more of them were actually good at UX design.
| It seems that UX these days just means making interfaces that
| match some arbitrary opinion of "beautiful" without any actual
| regard to what works and doesn't for a user interface. I miss
| when actual UX designers did actual studies to find actually
| good ways to put interfaces together.
| swiley wrote:
| I'd completely disagree. Software engineers tend to be very
| pragmatic. Perhaps it's really due to the involvement of the
| community but you look at open source software that has no
| "UX person" and it tends to be miles ahead of closed software
| that has them.
| AnIdiotOnTheNet wrote:
| > Perhaps it's really due to the involvement of the
| community but you look at open source software that has no
| "UX person" and it tends to be miles ahead of closed
| software that has them.
|
| You're setting a really low bar there. If you compare open
| source UX to the UX of closed source applications pre-
| iphone, you'll find that their incomprehensibility was
| frequently criticized. Case in point: GIMP.
|
| What's changed is that closed source UX has gotten worse
| faster than open source UX (unless you count GNOME, which
| has set world records for how fast it degraded).
| swiley wrote:
| Why does everyone point out GIMP as having bad UX?
|
| You apt-get install it, you double click on your photo,
| you use a pretty standard WIMP interface to edit it.
|
| Compared to modern Adobe software that's fucking amazing.
| beckingz wrote:
| Agreed. Gimp is feature rich and has a high learning
| curve.
|
| This is not the same thing as bad UX.
| AnIdiotOnTheNet wrote:
| I'm fairly certain literally everyone who works with
| image editing for a living will disagree with you on
| that.
|
| Hell, even Paint.NET has a better interface than GIMP.
| swiley wrote:
| If we're going to get into specialized software why not
| compare OpenSSH to RDP?
| [deleted]
| zxzax wrote:
| It would be nice if you were more specific. Most of the
| serious complaints I see artists making about GIMP are
| about lack of non-destructive editing features, or about
| lack of support for specific workflows, which are
| technical issues, not UX ones (and ones that are being
| addressed, slowly).
| username90 wrote:
| I want to do a basic thing in gimp, draw a circle. How do
| you do that? First you click the rectangle button, then
| you select "elipse select", then you select an area, then
| you click edit and fill with color. This flow is much
| more unintuitive compared to anything else I've seen, why
| would you click on the rectangle to draw an ellipse? And
| then suddenly that button is no an ellipse, so next time
| you want to draw a rectangle you now have to click on the
| ellipse button and switch it back to a rectangle.
|
| And that is just one thing, the whole program is littered
| with small obnoxious design decisions like that. Maybe
| you can learn to get used to it after a while, but if you
| have to go through a tutorial and get lost the first 20
| times you try to draw a basic shape then your drawing
| program has bad UX. In the end you will learn that the
| ellipse button and rectangle button are the same things
| etc, but until you learn all those things the program is
| just frustrating to use.
| zxzax wrote:
| That again is not a UX issue, that is a lack of shape
| tools for that particular workflow. Like, this is not
| something you can fix just by moving some buttons around
| or by changing the name of the ellipse tool to circle
| draw tool and having it fill automatically (i.e. bugfix-
| type things that a UX person would do), somebody has to
| implement an entirely new feature for that to work the
| way you are expecting, and then it would need to be
| redesigned as well. And GIMP historically has not been
| focused on shape drawing. If you want an open source
| program that focuses on shapes and vector drawing, you
| may want to use Krita or Inkscape. Or you can try
| developing what you're looking for as a GIMP plugin, and
| the going from there and trying to get it merged upstream
| if it's popular enough.
| username90 wrote:
| UX is User Experience, not User Interface. Lack of tools
| to do things quickly and easily with discoverability is a
| huge UX issue.
|
| And then the rectangle button changing to an ellipse
| button just because that was the most recent sub tool you
| used is a UX issue that is purely in the UI. I probably
| lost several hours to that until I understood what
| happened, because I couldn't find the buttons I wanted to
| click on and then assumed I had to look for them
| elsewhere etc. And it still is bad even after I learned
| that since everywhere I look at tutorials how to do stuff
| the menu looks different since they had different
| previously active tools so it is a pain trying to figure
| out what to click.
| zxzax wrote:
| What you're saying doesn't really make any sense to me,
| that's like saying you bought a sedan and found that it
| didn't have a pickup bed, so now it's a UX issue because
| you couldn't quickly and easily figure out how to move a
| refrigerator with it. Not everything is going to have the
| same tools, or support the same workflows. Maybe that's a
| problem that needs solving but it can't be solved by UX
| designers trying to redesign the sedan -- you would just
| get a trailer and put the refrigerator in that.
|
| You're right about the tool menus, those are an actual UI
| issue, but they can be disabled. Maybe they should be
| disabled by default? I can't say.
| username90 wrote:
| Drawing a circle isn't a new feature, the feature already
| exists in the program. It is just that the workflow to
| use the feature is very burdensome, all they need is a
| button that does several of the steps at once. It
| wouldn't implement any new behaviour, it is just a quick
| button.
|
| Now, it would take some work to implement those quick
| buttons, sure, but that is purely an UX change it doesn't
| add any new capabilities to the program, it just makes
| some actions easier to do.
|
| Basically, the feature lacking in the program are those
| "quick buttons" which would make adding these simple UX
| fixes easy rather than burdensome engineering work.
| zxzax wrote:
| And I'm saying you're mistaken, that feature never really
| existed. Trying to hack the ellipse tool into "quick
| buttons" to draw circles would not be what is expected,
| would not match the capability of other vector drawing
| tools, and would probably create other UX issues in the
| process. But of course, if you thought that was a good
| idea, you could easily make a plugin that does that, and
| test it out for yourself.
| username90 wrote:
| I think this discussion highlights perfectly why Gimps UX
| sucks. It is because the people who made it has a view on
| UX like you do and refuse to put in the work to fix it,
| with arguments such as "That isn't an UX issue" and so
| on. Fact is that Gimps UX sucks and people will have to
| live with it since it is a free product so the developers
| don't have any reason to do what you want.
|
| Anyway, you might be right about this issue, I am not an
| expert on image editing. However I do understand UX and
| your view on development will lead to horrible UX like
| what you have in Gimp. It might work great in enterprise
| products where you sell features and not UX, but a
| product intended to be used by normal users needs more
| work on UX for people to like them.
| mch82 wrote:
| You're both right.
|
| Zxzax is correct that GIMP is an alternative to
| Photoshop, so the tool pallet is appropriate for editing
| photos. The typical workflow is: (1) stack layers, (2)
| mask layers, (4) composite. It's rare to draw a circle on
| top of a photo. Usually it's most efficient to select an
| area of a photo with a rectangle to isolate it on a
| layer, then use masking to refine the non-rectangular
| edge. If your goal is to draw a 2D illustration & work
| with gradient meshes, then Inkscape is an alternative to
| Illustrator. Both those programs are for illustrating in
| 2D and there are purpose-built features for drawing &
| editing shapes.
|
| That said, GIMP does have real UX issues. For example,
| the controls and GUI elements don't scale well to high
| resolution screens and could be much better on tablets
| like the Surface. They're also missing CMYK color space
| support. But, I always assume they're waiting for Adobe
| patents to expire to add those features.
| sebular wrote:
| How do you explain the loathsome UX of software like GIMP?
| p0nce wrote:
| miles _ahead_? I'm not seeing that, at all. Software
| without UX persons... often has bad UX.
| handrous wrote:
| I'd agree, for desktop programs specifically. "Web App"
| UX & design is a source of much UX & design employment,
| yet is largely god-awful, and it's infected desktop
| program design (via Electron, in part). The result is
| that 90s-style programmer-designed desktop UI sometimes
| is better, not because they're especially good, but
| because current trends are terrible and 90s-style desktop
| program design is better than what's trendy now.
|
| I don't think this means open source desktop programs are
| a great place to look for top-notch UI/UX inspiration.
| BoxOfRain wrote:
| >(via Electron, in part)
|
| Electron is basically the digital equivalent of coal-
| rolling in my opinion, technologies like React Native are
| a much more elegant way of achieving what Electron tries
| to.
| atatatat wrote:
| Well-put.
|
| Thanks for noticing -- I hope to be on a project of yours
| soon.
| pm90 wrote:
| I believe that most trained UI/UX designers (ie those who
| have internalized that UX is supposed to help people and not
| just how fancy or standard conformant you can get) do build
| pretty great designs, but I've noticed a lot of ego in this
| area from design leaders in my personal experience.
|
| Nearly every time design becomes political and every change
| needs to be conformant to even the most minute standards even
| if they may not have any material effects on the product. I
| think the field just has a lot of shitty "leaders", most of
| the "grunts" I've worked with have been incredibly helpful
| and willing to think out of the box to make UX easier.
| atatatat wrote:
| Death by 1000 cuts.
|
| "Is this component _really that_ shitty for the user? " is
| how you end up with...hell, insert any Enterprise software
| here.
| ectopod wrote:
| UI designers of old were working to improve the user's
| experience of the UI. UX designers are optimising the user's
| experience for the benefit of the business. For apps and
| websites this often involves actively user-hostile patterns.
| carlgreene wrote:
| This is because the UI/UX of a 2021 website/app is far more
| involved and complicated than that of a 2001 website/app.
| Product cohesion and well thought out human psychology levers
| are very important in products of today.
|
| I long for the days of building a simple site for my company.
| No fancy wizards, bifurcating flow, or complex animations. I
| unfortunately don't think we're going back to that time though.
| coding123 wrote:
| Not necessarily. Look at the site we're on. They don't
| monetize, but I bet if they did it would make millions per
| year.
| AnIdiotOnTheNet wrote:
| If they monetized they'd cease being simple because it'd be
| less profitable than implementing user-hostile "engagement"
| practices.
| carlgreene wrote:
| HN is an outlier and you know it ;). I do wish more sites
| were like HN both in terms simplicity and community
| rightbyte wrote:
| There are YC adds on HN though in the feed, so I guess you
| can say HN moneyizes?
|
| E.g. this job add was on my feed right now: https://jobs.as
| hbyhq.com/moderntreasury/dc9bcfe8-64ef-4377-a...
| madeofpalk wrote:
| Oof this kind of adversarial us vs them doesn't sound great!
|
| In well functioning product teams everyone should be working
| together to make a better product, recognising the roles and
| strengths of each other. If this isn't the case, then your org
| has bigger problems.
| mgkimsal wrote:
| >everyone should be working together to make a better product
|
| That's rarely the top priority for everyone on the team at
| the same time. Design folks want to 'design', and agreeing
| that 'feature X' doesn't need to be in the screens - even if
| it's "the better product", doesn't align with their career
| need to have showcase material for the next job interview.
|
| Similar with tech/dev folks - an update feature might just
| need simple poll mechanism, but that doesn't give them
| experience with building a full pub/sub scalable architecture
| platform, or testing out the newest messaging libraries.
|
| The more people on that team, the more conflicting priorities
| there will be.
| madeofpalk wrote:
| > In well functioning product teams
|
| This doesn't sound like a great team, and doesn't really
| align with my (sure, admittedly limited) experience. I've
| only really worked once with someone who had strongly
| personally motivations that worked against the teams goal,
| and it was recognised that they were a wanker.
| mgkimsal wrote:
| the notion of "a better product" is... way too amorphous.
| without a lot of definition and constraints, people can
| make solid arguments for 'the good of the project' which
| also align with their personal goals (new tech, more
| design, etc) and it's often very hard to argue against
| those, because they sound good aren't necessarily
| 'wrong'.
| ElViajero wrote:
| > If this isn't the case, then your org has bigger problems.
|
| That is completely true. To work together to build a product,
| to have everybody understanding what is what needs to be
| achieved, and collaboration in general is the way to go.
|
| In organizations where business does not trust engineering,
| engineering does not trust design ... things are never going
| to work. It is a collaborative effort, one point of view is
| insufficient to create an attractive product in a cost-
| effective way that is not full of tech-debt.
| sam0x17 wrote:
| This is true. One way to combat it I've found (as a CTO) is to
| ensure backend engineers are involved in the initial pre-mockup
| conversations and mockup iteration conversations and to give
| them just as much vetoing power as someone from bizdev. In some
| orgs this is impossible but it works great for us.
|
| I also find that backend people tend to have extremely good
| ideas when it comes to UX (better, even, than a lot of UX
| people), they just don't enjoy or aren't good at executing
| these ideas (or aren't allowed to). The takeaway is to take
| your backend engineers' opinions seriously and let them touch
| the frontend when they want to.
| edderly wrote:
| First you need Software Developers to believe and trust in your
| management. I find it surprising how many companies do not
| include developers in manager hire interviews.
| waylandsmithers wrote:
| Personally, I've had my heart broken by projects and companies
| enough that I now take a more impartial approach.
| phkahler wrote:
| >> Evidence of traction is very motivating, just ask any engineer
| whose github project starts gathering stars!
|
| I notice this on an open source project. There was a feature add
| by someone on their private branch. I asked why we didn't merge
| it and was told the implementation was not good enough. It was a
| cool hack, but inferior to doing it "right". So I started
| investigating the right way to implement it and a discussion
| followed and someone else started almost competing with me on
| implementation. In the end I backed off and encouraged him to
| complete it and that worked.
|
| I have noticed on other occasions that when the project seems to
| be stagnating, doing _something_ and opening a dialog will often
| bring people together to get something done.
|
| People seem motivated by the notion that someone actually cares
| about their work. Go figure.
| [deleted]
___________________________________________________________________
(page generated 2021-07-08 23:01 UTC)