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.
One of the first bits of paid work I did was for a printing company that made business cards among lots of other things. They would manually create a CorelDraw document with a page full of cards for each employee, taking the contact information from an excel spreadsheet. The data entry for making cards for 100 people would take several days.
I was able to automate this for them with a pretty simple VB.net script. Several days of boring mind-numbing work per month were reduced to a couple button clicks and a few seconds of CPU time. It also eliminated all typographical errors on the part of the printing company.
I never touched vb.net again after that. I had no interest in the technology at all and there was nothing particularly interesting about the work itself. However saving people from having to do a bunch of boring work is extremely satisfying. And it saved the owner money which feels great too.
I find that being empathic towards my users not only makes the work more fulfilling but it also allows me to design better products. As a human with human interests you should at least give it a try.
I like the contrast of your reply to the original post because it really highlights the two general types of developers - product focused developers who use technology as a tool to focus on the customer and technology focused developers who treat programming as an art ahead of focusing on customers.
I would say it can be tempting if you fall into one of the two broad buckets to think the other side is doing something wrong and that there is a tendency to want to compel them to “see the light” so to speak but in my experience those efforts tend to go to waste (if not appearing outright condescending).
Ultimately people have different interests and priorities both in life and their careers and people derive fulfillment from different sources. There are no right answers here.
You need both kinds for a good product. Both of these types add something the other is not interested in adding. The most value I ever added was joining a company filled with type X (purposefully avoiding which one) as a type Y and going on a binge of doing incredibly valuable work that had been left as "low hanging fruit" because nobody thought it interesting and/or important enough to give it a good look.
How is it hard to have empathy and interest in solving problems and yet still a deep love and interest in the underlying tech you use?
I feel I am in this category. I would venture to guess that a broad array of useful developers do as well.
Siloing people like this creates an artificial construct wherein people feel they need to fit.
For what it's worth, I would definitely not hire the OP after his speech about being more interested in using a new tech to solve my problems than solving my problems.
They rarely overlap. If you’re trying to solve arbitrary problems efficiently whatever tools you know are unlikely to be the best fit. But that doesn’t mean you’re going to be more productive learning something new.
Thank you, this is a nice counter to the usual nihilistic stuff you find on HN. I find that just doing something useful is fulfilling for me, especially if it makes peoples' lives easier, no matter how little I care about or understand the actual product itself.
I think that for me, being a good engineer is first and foremost about solving problems for people, and if I lose sight of that simple goal, I lose a lot of my energy for my work.
Exactly, and the harder the problem, the greater the reward when it's finally solved.
The problem solving process never ceases to amaze me, how a problem can go unsolved for months on end, and then suddenly all the dots can be connected and the solution appears.
Starting out with the notion that "It must be possible to solve this", is always the first step i find.
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).
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.
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".
This comment makes it seem like you've never worked with a contractor.
I come from a family of contractors (electricians and metalworkers mostly), and every experience I've ever had working with them tell me that they care about understanding. If you ask them to make you a bathroom without any waterproofing they'll ask you if you've gone mad and tell you that you NEED waterproofing, because they understand that you don't want your house to rot. If you say you want a metal frame and you have a drawing. The very first step they will take is to analyze your drawing to see if it makes any sense.
I have never worked with a contractor that just did whatever you told them to, without understanding what you're doing. If they chose to disengage with a problem, it's a conscious choice.
The big differentiator is the ease of understanding. Building a bathroom is relatable. You kinds of intuitively understand why you want a new bathroom, and people understand the sorts of issues a new bathroom can solve. People do NOT understand what new software can solve, and how it solves it. They think software is magic pixie dust that you sprinkle on problems to make them go away. That means we have to do more of the work of helping them map out the solution than a contractor would.
> If you ask them to make you a bathroom without any waterproofing they'll ask you if you've gone mad and tell you that you NEED waterproofing, because they understand that you don't want your house to rot.
Nowhere did I suggest otherwise.
> I've ever had working with them tell me that they care about understanding.
They care about understanding to complete the task at hand. I have never met a contractor that got emotionally invested in whether the cabinets you picked out were the cabinets of your dreams. I've met many contractors that were, in some ways, invested in the buyer being satisfied with their job, but that's not really the same thing.
> I don't care about the project, I care about writing code
this is like the contractor saying they only care about installing cabinets, not helping you model your bathroom.
The point is that you want someone that's going to look at the plan and say "that's going to rot in 2 years", not just do the exact thing requested by the customer and leave
I 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.
This isn't really true IME. The best contractors will understand the goals and motivations for your project, and make suggestions based on their vastly greater experience of ways to improve upon the project.
> This is 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.
I remember hearing a story from a structural engineer who was disappointed with a builder on a commercial site. He took him around the site and showed him some of the sub-standard work and said to him, "This is not your best work, is it?" The builder responded with, "You should have told me you wanted my best."
I've seen this in software too. People push for cheaper and faster, but often that will only come at the cost of quality. There are good reasons to take on technical debt. For example, to get to market without the funds to avoid technical debt, in the hope you can pay down that debt with revenue flowing in. But there are seldom conversations with business people to negotiate on the quality, time, and cost trade-offs.
> 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.
Yep, I do. But lots of employers don't offer any form of equity as compensation. The same employers that demand their employees to be "invested" in the company.
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.
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).
How many devs out there are just faking it? People have learned to answer the "Why do you want to work here with?" questions "I have a passion about X, because Y."
It is like med school interviews. Everyone knows the answer to "why do you want to be a doctor?" is "I like science and want to help people." along with an anecdote proving that when tons go to medicine as it is a well paid and stable career.
I think there's a bit of a spectrum between "I don't give a rat's ass about you or your project" and "This is my new life's passion".
From my own experience I find that yeah, job interview answers are mostly self-marketing BS. But I do also care about the quality of the end product beyond just having fun with the tech.
This is HN though. This is the same level of conversation at a trade show or over drinks. If you can’t lay out your dispassion bluntly (even if just for effect) here then where can you?
I would not encourage anyone to talk to their boss the way GP is talking. But these are peers talking, and if you don’t think convos like this happen, then you haven’t seen them or you’ve dismissed them. If you haven’t seen them, I can only assume nobody trusts you enough to vent.
I like to think most software engineers have at least some interest in what they're investing most of their waking hours in. Sounds miserable otherwise!
I like to think most software engineers don't work 56 hour weeks. Someone can take interest in their craft without taking interest in a product. And many people are happy enough working to live instead of living to work.
> These projects contribute to the success of the business in one way or another.
If you want your workers to care about the success of your business, then pay them with the success of business (e.g. shares). If you are only paying an hourly salary, you're not entitled to anything but their hour's output.
Having been on the receiving end of shares, devs are in an extremely bad position to estimate their valuation. It’s like being a passenger on a train and being asked to judge which direction it goes. And I’m a product-oriented dev who loved the business side and loved doing plenty of UX interviews.
Being now on the donating end of shares, employees know much better how to value the gross pay.
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.
> 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.
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.
There are buildings that have stood for hundreds of years, meanwhile you have to re-paint your own house every 10 year... new/modern is not always better.
How do you reconcile how bespoke and ever changing the requirements are for software products vs how stable the requirements are for garages?
I'm asking because I see the construction analogy pop up a lot and I just can't reconcile the two things.
To me the development of a new blueprint for a new kind of garage for a new kind of vehicle operated by a never before seen alien species is a bit closer to creating a software product.
I mean, who would ask a contractor to do what people regularly ask software engineering teams to do?
Construction isn't a bad analogy. Imagine you're a contractor getting called in to finish a house that some incompetent jabroni started, then got out of their depth and got fired midway. Meanwhile the homeowner has changed their mind and wants an open-concept kitchen, and the building inspector has come back with objections to the wiring plan that need to be rectified.
The physical dependencies of a house vs the abstract nature of software interdependencies really makes the analogy fail for me. Houses just don't don't regularly fall down 8 times a day because one framer is putting a nail in a new wall and that caused the fireplace to explode.
You should care about how much you pay the contractor and the quality of work you get in response. That's your only contract with them. Same for a developer.
> You don't want someone showing up who just views your garage primarily as an opportunity to learn about this new construction material they've heard about that doesn't help you.
That's a terrible analogy. Most of the time developers aren't writing greenfield projects, meaning they don't choose the stack. Devs have the leverage to choose by accepting jobs that use the stack we know (or want to know).
As to contractors, if you had already started building a garage with a new construction material, you probably would really want to hire people who were experienced in it. If you couldn't find them, you might want people who were interested in learning to use it.
If you want passion and motivation, consider hiring an actor or prostitute. I'm going to stick with my usual plan of "write good code in exchange for good money".
One gets more than just money from work. Or one can get more. Friendship, community (however fleeting), challange, growth. If you over index on comp you may miss out on more fuzzy aspects. You are there 6+ hours a day might as well optimize more broadly.
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.
They sound like a great hire to me. If you needed an electrician to wire your house, would you rather hire someone who likes to get inspired and find creative ways to do electrical wiring, or someone who just wants to do the best and most documented practices while saving their creativity for personal projects
How about someone who cares about why you're trying to get a 200A circuit run to your garage and can provide feedback and point out things that they've seen before that could make your life easier. Or, like in my current situation, I really hope an electrician can come up with a creative solution to my current house wiring situation because it seems like it's going to be a huge hassle and the previous owner has painted us into a corner.
My own current situation is that I work with an electrician who found a hard-but-solved problem and wanted his own solution to it. He is now the only person who understands the wiring he did, and if he ever leaves the company we'll also need to find a creative person to work on it, or else throw it all out and start over.
EDIT: just be clear I'm still actually talking about software
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).
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
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.
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.
The project is your vision, all the decisions about the future of the project are being made by you (or your business people), how can you expect a developer to feel invested or engaged in the project? Are you willing to give the developer the same decision power as the business people?
The reason developers love to work on personal projects is not primarily because it is using some shiny new tech but because they own the vision, they own the decisions, they started the question and they want to build the answer.
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.
While this is a valid sanity saving technique, you have to be very judicious with it. Too often people get more excited by the tech they’re using than the problem domain, and their solutions start to fit that domain badly. Then we have impedance mismatches, and someone who is effectively holding the code hostage because that is where all of their emotional investment is.
I’ve seen this many times, participated a couple. In the end there’s a moment you should move on to something more interesting. And like selling your house, you should never look back at what they did to your code.
This is such an interesting concept coming from a different industry (architecture) into software development. I find it hard to be so disconnected to the outcome of what I am making. I definitely care about the projects that I am a part of, otherwise it just feels mechanical. I want to work to solve a problem that I care about, feel like I am doing something more meaningful than just implementing another warehouse logistics crud app.
Don't get me wrong, I have gotten pretty decent at making crud apps, but I find it so much more compelling if the crud app is making education more efficient, vs another problem that I don't care about.
I just find it so foreign that software engineering culture holds your mentality more often than not, where the tools that you are working with are advertised more than the problem you are solving. Not good nor bad, just an observation.
> writing code, and dreaming of a decent Transformers movie before I die
Have you seen Bumblebee? I don't know what your idea of a "decent" Transformers movie is, but if you still like the original series there's a lot to like about Bumblebee, including character designs, voices, and dialogue that are close to the 1980s originals.
This is ridiculous. Do you expect your contractor to explicitly tell you every detail of the project? It isn't even possible. Because the code itself is the only way to describe the project comprehensively. Because natural language is weak, and sometimes useless, especially in describing specifics. Natural language is good for negotiating incentives, which is why you have to think like your contractor in order to do the job.
This type of mechanical reasoning is a common pitfall. People did too much symbolic reasoning they end up embracing too much symbolism instead of real life and real people.
You might be perfectly suited for a devops-style of job.
As a developer working on business-related tasks your net contribution might even be negative with this attitude (because if you don't understand the business and you are not even interested in understanding it then the only tasks you can do yourself must be so small and so well specified that it (the specification) might take more time than doing the task itself).
You can be proud of the accoutrements it takes to do your job without caring about the end product, especially if it's an environment you have little influence in the direction of the product.
It's not mutually exclusive.
Do you think tax attorneys are proud of tax laws, or do you think they care about being the best tax attorney in their field? This mind set isn't exclusive to certain industries.
I would perhaps re-think how you achieve your personal development, to be frank your username sums it up. Try to align what you want to achieve with the best interests of the project, it can be achieved I do it weekly.
A large enough project needs juniors and seniors. It's OK to be one but not the other. The juniors don't necessarily need to understand the project in a big-picture sense. But somebody does.
I don't see how not being emotionally invested in a project would mean you can't understand or even design the big picture of it. Feels a bit straw man-ish.
I really hated the Michael Bay Transformer films. Have you seen Transformers War for Cybertron on Netflix? It’s nothing amazing, but more entertaining than the Bay films.
> However for every project I take on, there will always be something I have never done before, or a maybe some new technique I want to try, could be a new language.
So you do care. But you care about the technology, not the InCrEdIbLe ImPaCt this latest "X-but-as-an-app" is going to have on the course of human history.
There's nothing wrong with you, and I'd love to work with you.
I think it was DHH who had a great line about this: Don't care about product, care about process.
For developers, the process of delivering value IS the excitement, it doesn't matter how awesome or boring the product itself is, it's the process of writing good code to solve customer problems that excites us.
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.
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.
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.
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.
> 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).
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).
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.
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.
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.
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.
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.
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.
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.
I've used photoshop, its UX wasn't nearly as bad. Me as a user had a pretty good experience with photoshop, but a really bad experience with gimp. Hence gimp has bad UX and photoshop has ok UX, according to me and most people I've seen. People trying to convince me and the other people that our experience wasn't all that bad with Gimp is the problem here, that attitude ensures Gimp will always have bad user experience.
Just to clarify, GIMP definitely has issues, and I'm not trying to convince you otherwise. But they are not issues that can be solved with more UX research or what you would typically call "UX work." That's what I think the misunderstanding here is, please don't misinterpret what I'm saying. The UX issues that are there are already known, what's left is to do the (hard) work of fixing it.
I'd argue that UX requires a lot of engagement and work by software engineers. Sure it isn't work people with the title of "UX designer" or whatever would do, which is why the UX role is usually bullshit, but it is still work needed to fix the UX. And small developer led teams often refuse to bother to even consider that they have to change anything to fix these things.
You are correct that it does, but not every change made by engineers is a UX change. But even if you want to think of it like that, the backend changes still need to happen first in order to get any significant UX change going.
>small developer led teams often refuse to bother to even consider that they have to change anything to fix these things.
Out of curiosity, what task were you using gimp/photoshop for: (a) edit a photo, (b) draw an illustration, (c) draw a diagram, (d) annotate an image or map?
The DPI scaling issues should be mostly fixed in GIMP 3.
CMYK support is not a UX issue, that is another thing that's missing on the backend. I don't think it has anything to do with patents, the problem is more because of lack of manpower.
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.
I'm saying this as some who's done UX and is familiar with the problems in GIMP, there really is no quick fix that can be done here. If you view everything as a UX issue that can simply be solved by moving things around, then we can't really have a discussion because there is no meaningful distinction we can make. The major issues with GIMP are mostly on the backend. The work is being put in to fix it, but it's slow going because there are not enough people working on it. I agree with you that people would really see it as a UX improvement if there were good shape tools like photoshop has, but my point is you can't just get that by changing around the ellipse select tool. If it were that easy, somebody would have done it by now. The GIMP people I've known have said they would love to fix a lot of things but it's harder than it seems and they don't have infinite time.
Just to make it a little clearer what I mean here: if there were actual shape drawing capabilities on the backend then it would be pretty easy to make any kind of circle/ellipse tool that you wanted, or set up the circle tool to do what you want by default, but those don't exist right now.
> If you view everything as a UX issue that can simply be solved by moving things around
That isn't what UX is about. I am making games, and stuff that isn't simply moving things about is a core part of user experience. For example consider a game where you want to move around armies on a map. You can implement that by moving around the armies using numpad only, or you can calculate a shortest path on a mouse click to a location and show it to the user. Both allows the same kind of movement, but the second offers way better user experience which is why all modern big strategy games uses it over one step at a time movement.
> but my point is you can't just get that by changing around the ellipse select tool
I never said that a good UX was easy, I just said that the developers of GIMP didn't want to put into the work to make GIMP have good UX, and a lot of that work is redesigning the technical architecture or implementing those features the tedious ugly way. It is possible to make it decently easy to make easy to use tools for gimp, I just don't know all the details of what those tools should do exactly but I know how to build that sort of things. When making games you don't have as patient users as you have in GIMP, so you'd never get away with that kind of UX, so from my perspective when your product has GIMP's level of UX then it isn't complete as a product since it would basically ensure business failure.
I'm not much of a gamer but what you are describing doesn't seem to be relevant, for example there are simpler games where moving using numpad is perfectly usable and desired. There is not really anything specific you're designing for there, you just chose to make that type of game.
>the developers of GIMP didn't want to put into the work to make GIMP have good UX
From what I have heard from GIMP developers, this is not correct. There is plenty of desire to fix issues, the main issue is lack of contributors. Please help if that's what you're interested in.
You're talking about "getting away with the UX" but I'm also not sure what you're talking about there, GIMP is not a commercial product that is trying to get customers. It's an open source project driven by volunteers who improve it in their free time because they feel like it.
From experience I am almost certain the issue has to do with architecture, the original developers didn't properly consider UX when making the first steps and that has shaped how everything else was implemented in it, and this is the end result. Fixing it at that stage is way too much work as you said, rewriting all tools and the UI from scratch would probably be the easiest way to fix the UX at this point. If it was easy then it would have been fixed as it is an open project as you said.
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.
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.
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.
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.
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.
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.
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.
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”
> 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.
> 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.
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.
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.
>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.
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.
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.
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.
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.
1) I've never met a UX person who is a programmer. Most of them are from graphic design background, sometimes for vouchers or magazines and they don't necessarily understand that the computer screen is not the same kind of medium as a piece of paper.
2) Having a professional relationship entails pushing back and questioning. Being a "yes man" to the UX people is not a good working relationship. The implication of your comment is in order to push back and provide feedback I must first acknowledge my subservience to their whims and only once they approve of my work I may humbly submit some suggestions for their kind consideration.
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?
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.
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.
most organizations that tend to have office politics and are very politically-correct in their behaviour tends to end up with people in roles calling shots, despite those shots not being great.
graphics designers is just one example of this that i've seen, where a poor UI or bad UX is mocked up, but because you're an engineer, you do not get to have much input or your input is regarded as irrelevant (because your role is to code, not do UX design).
That's what i mean by the "inferior" comment - that the UX/UI designer isn't as good at their craft as you are in implementing code.
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.
Design at my current place doesn't include loading and error states in their designs so we have to free hand those ourselves.
IMHO, loading states and error states are one of the more important parts of the design since they'll be seen often (for loading) and when the product isn't working for a user (error states).
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.
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.
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.
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.
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.
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. :)
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.
>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.
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.
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'.
> 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.
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?
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....?
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.
> 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.
> 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.
These are all great things to ask for. I'd also be tempted to add "Ethical decision making and respect for the end user's time, attention, and privacy" but now we're moving into crazy-land.
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.
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.
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.
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
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.
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.
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.
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.
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.”
> 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 Gassée 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.
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!
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!
Everyone is attacking the overall theme of this article, and I agree with many of the points made, but nobody seems to be focused on the actual solutions provided in the article which I think are good. The article isn't about software developers believing in you PRODUCT its about software developers believing in your PROJECT. If I was the author, I would probably try to rephrase this as "Software developers are most effective when they feel a sense of ownership and responsibility for the projects they contribute to." The article suggests 4 items:
Don't withhold newly discovered information about the customer's needs
Avoid the temptation of isolating the team in the name of "just getting* it done"
Avoid discouraging technical team members who express interest in the market or business model
Avoid over-statusing your software development initiatives
All four of these items are ways you can signal to your developers that you trust them to do their job and respect their ability to make use of the information given to them (You can't handle the truth!!). I think its worth at least being aware of this methodology in the case that you have a dev team which is showing interest in "the why" of a particular project, or appear to be struggling to build what the business is asking for. Otherwise, you are better off incentivizing devs with bonuses, pay raises, and equity because they might just not care about "the why" or "the why" might just not be useful for them to do their job.
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.
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.
>> 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.
I personally wholeheartedly agree with this article. It is True Doctrine. For me at least.
BUT... these last few years, I have come to some uncomfortable realizations. Not all software developers/engineers are indeed like what this article describes. It took me a while to understand it, but I came to realize that really investing yourself into what you're developing means taking on additional risk. To have successful insights that transcend those basic market driven requirements, you're also going to hit some foul balls. To push yourself to learn new things, to ask questions, creates risk for ego. The personalities that do not conform to what the article describes, are the first to advocate "leadership, direction, single point of contact", etc. I've realized they are sometimes codeword for "offload risk." An interesting symbiosis occurs between developers and non-developers: the doers and the deciders. Because the risk is now floating somewhere between a sort of dissociated yen and yang, both groups can comfortably offload blame/risk on the other group. Everyone wins. Except for the customers and the product. Even if it threatens the long term longevity/viability of the product, the short term optimization of comfort wins out.
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.
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.
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".
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.
I personally hate it when someoen is trying to hype up something idiotic as changing the world.
"We will rent office space in a new way and save the world doing it. "
"We will xxx and humanity will thank us forever!!!!"
Working on a computer system should not entail adopting a religion for
the company, or the CEO or whatever.
Often it is combined with en embrace of the prosperty gospel.
Not only will we save the world but YOU (look into my eyes) YOU..
will become a BILLIONAIRE. $$$$$$$.
I have all my spiritual needs figured out and met.
It is a job, it should not be a cult.
A much minor but slighlty related annoyance is
"Failture is not an option"
Well yes it very much is.
Someone quoting that line is a huge indicator that failure may be imminent.
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.
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...
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.
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?
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
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".
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.
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.
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.
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.
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.
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.
> 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).
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.
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?
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.
> 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.
> 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.
Someone, somewhere has a job that they need to get done, I'll do whatever I can to make it easier for them, if I understand what they are doing now, why it does and doesn't work, and the proposed solution, I'll be quite willing to do whatever is required to make that happen.
If you can't connect those dots for me, you're wasting a lot of time and effort, yours, mine, and the customers who aren't going to get the right solution.
I don't care what language, database, etc. is going to be used, except how it relates to reliability and maintainability. The computer, punch card, double entry ledger, tally stick, etc. are all just ways to manage data.
A good part of this resonates with me. In 2015 I moved to a new city to work for a large auction company doing frontend. It was a large corp that I didn't feel I was well-suited for, but I thought it was worth a shot. For 6 months things were fine and I figured out how to work on the codebase with collaboration from a later hire. At around that 6 month mark, they started planning a new initiative to rebuild another part of the site, and my colleague chose to take that on, while I continued on the bit I was familiar with. Fast forward 2 months, and just as the new project starts, the upper middle manager decides to shuffle all the teams because they heard on the internet or something it was a good idea. I end up on the project my colleague has been planning this whole time, he ends up on mine, and we're in different parts of the office with no reason to communicate and 1 month to get it done. Wasn't involved in conception, wasn't familiar with the code or constraints, didn't agree with any of the decisions, and couldn't concentrate well in the noisy office. Went from productive and enthusiastic, to miserable and burnt out after blowing past the deadline because shocker, all this was stupid and didn't help me get things done faster. Years later, and I have a very hard time being enthusiastic for professional programming, because I internalized a sense that I didn't matter, the products don't matter, and it's not worth trying very hard unless you have agency over the decisions being made. Fuck you Brad.
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.
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.
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.
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.
I've come to the conclusion that there are many perfectly valid, but incompatible, ways to run a team. A strict process with strong requirements can work. A self-managing team with autonomy and design input can work[1].
The model should be chosen based on the needs of your business and your product. But, most importantly, you can't mix any match approaches. If you want teams to use creativity to build novel solutions, but your business is driven by a sales team who only want cookie cutter features on a strict deadline, you're going to have a bad time.
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 ...
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.
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”?
I’m always struck by theme of replies in threads like these.
For those saying “I’m just here to write code for money, full stop” was that always how you approached software engineering? If not, would you choose a different career if you could do it all over again?
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.
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.
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.
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...
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.
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.