43 ms·

You need Software Developers to believe in your project (2020)

249 points by replyifuagree 5y ago

roenxi 5y ago
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.
coding123 5y ago
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.
- Kranar 5y ago
  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.
  - hpoe 5y ago
    I envy you if that is your experience. Almost all UX persons I have worked with have a degree in "Design" and are artsy type that tell me. "You can't make this blue it just doesn't vibe with the green we have." Many of who use the argument "Apple/Google does it this way" I'm not saying your now right it's just been my experience that they aren't engineers or Computer Scientists.
    - exdsq 5y ago
      I've seen what happens when computer scientists go off on their own and design a user-centric product. Trust me, its good to have an 'artsy type'. I worked on a project with some pretty 'famous' CS guys (obviously relative to the field) and their form of documentation were essentially quizzes for the users to work through. Practically an end of term exam. It was crazy.
  - carlmr 5y ago
    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.
    - spicybright 5y ago
      That sounds discouraging. But you can apply the same story about any manager-like figure, no? If one's priority is design freedom or whatever, a good working relationship with your higher ups is the best chance to enable that. Working well with managers is also a good strat for becoming one yourself, and having more influence over things you care about.
      - carlmr 5y ago
        >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.
  - MattGaiser 5y ago
    Most of the ones I have ever encountered are former graphic design people.
    - ratww 5y ago
      For me it is 100% former graphic design people. In fact I've seen several engineers trying to migrate to UX but the gatekeeping and prejudice made them give up.
  - eplanit 5y ago
    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.
  - chii 5y ago
    the problem happens when they aren't your equal, but the workplace is too politically correct for you to bluntly point it out. All you can do is suggest improvements, if at all.
    - Pokepokalypse 5y ago
      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.
      - chii 5y ago
        > summarily judge them as "my inferior" 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.
  - rubyist5eva 5y ago
    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.
  - bjornsing 5y ago
    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?
  - ratww 5y ago
    The thing is that the "seeing as equals" has to cut both ways. UX people, UI designers and PO/PMs who see developers purely as interface xerox machines don't really deserve much respect.
  - hsn915 5y ago
    This comment is condescending and disrespectful. 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.
- MattGaiser 5y ago
  One of the things that really surprised me working as a software engineer was how much my work would be judged how how well it matched the drawing. It often seems like there is more verification of that than whether it does what was intended.
  - mgkimsal 5y ago
    But... for most of the reviewers/team, what was intended is that the result look like the drawing. That's it. "Here's a mockup - we spent a lot of time on this". "OK... what does it look like on tablet, mobile, what are the failure states, what should error handling look like?" "We spent a lot of time on this - make it look like the mockup". Had a project years ago that was... almost as bad as that sounds.
    - MattGaiser 5y ago
      I worked on a project where the buy button was off the screen on anything but a wide monitor. So I could not see it on my laptop.
  - jollybean 5y ago
    It's an easy thing to inspect for, and, most UX designers have pixel perfect expectations, which is actually not unreasonable in most cases as every pixel generally does have it's place. The problem of course is that it's too easy to focus on pixel perfection at the cost of other things. Recently, I've worked on a project and we had to force ourselves to 'not care' about those things until the very end when we did clean up.
    - legulere 5y ago
      But aren’t projects where you don’t have time to work in the details not also projects where the next project is waiting around the corner?
- AnIdiotOnTheNet 5y ago
  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.
  - atatatat 5y ago
    Well-put. Thanks for noticing — I hope to be on a project of yours soon.
  - pm90 5y ago
    I believe that most trained UI/UX designers (ie those who have internalized that UX is supposed to help people and not just how fancy or standard conformant you can get) do build pretty great designs, but I’ve noticed a lot of ego in this area from design leaders in my personal experience. Nearly every time design becomes political and every change needs to be conformant to even the most minute standards even if they may not have any material effects on the product. I think the field just has a lot of shitty “leaders”, most of the “grunts” I’ve worked with have been incredibly helpful and willing to think out of the box to make UX easier.
    - atatatat 5y ago
      Death by 1000 cuts. "Is this component really that shitty for the user?" is how you end up with...hell, insert any Enterprise software here.
  - swiley 5y ago
    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.
    - p0nce 5y ago
- madeofpalk 5y ago
  Oof this kind of adversarial us vs them doesn't sound great! In well functioning product teams everyone should be working together to make a better product, recognising the roles and strengths of each other. If this isn't the case, then your org has bigger problems.
  - mgkimsal 5y ago
    >everyone should be working together to make a better product That's rarely the top priority for everyone on the team at the same time. Design folks want to 'design', and agreeing that 'feature X' doesn't need to be in the screens - even if it's "the better product", doesn't align with their career need to have showcase material for the next job interview. Similar with tech/dev folks - an update feature might just need simple poll mechanism, but that doesn't give them experience with building a full pub/sub scalable architecture platform, or testing out the newest messaging libraries. The more people on that team, the more conflicting priorities there will be.
    - madeofpalk 5y ago
      > In well functioning product teams This doesn't sound like a great team, and doesn't really align with my (sure, admittedly limited) experience. I've only really worked once with someone who had strongly personally motivations that worked against the teams goal, and it was recognised that they were a wanker.
      - mgkimsal 5y ago
        the notion of "a better product" is... way too amorphous. without a lot of definition and constraints, people can make solid arguments for 'the good of the project' which also align with their personal goals (new tech, more design, etc) and it's often very hard to argue against those, because they sound good aren't necessarily 'wrong'.
  - ElViajero 5y ago
    > If this isn't the case, then your org has bigger problems. That is completely true. To work together to build a product, to have everybody understanding what is what needs to be achieved, and collaboration in general is the way to go. In organizations where business does not trust engineering, engineering does not trust design ... things are never going to work. It is a collaborative effort, one point of view is insufficient to create an attractive product in a cost-effective way that is not full of tech-debt.
- sam0x17 5y ago
  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.
- brightball 5y ago
  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.
- carlgreene 5y ago
  This is because the UI/UX of a 2021 website/app is far more involved and complicated than that of a 2001 website/app. Product cohesion and well thought out human psychology levers are very important in products of today. I long for the days of building a simple site for my company. No fancy wizards, bifurcating flow, or complex animations. I unfortunately don’t think we’re going back to that time though.
  - coding123 5y ago
    Not necessarily. Look at the site we're on. They don't monetize, but I bet if they did it would make millions per year.
    - AnIdiotOnTheNet 5y ago
      If they monetized they'd cease being simple because it'd be less profitable than implementing user-hostile "engagement" practices.
    - carlgreene 5y ago
      HN is an outlier and you know it ;). I do wish more sites were like HN both in terms simplicity and community
    - rightbyte 5y ago
      There are YC adds on HN though in the feed, so I guess you can say HN moneyizes? E.g. this job add was on my feed right now: https://jobs.ashbyhq.com/moderntreasury/dc9bcfe8-64ef-4377-ad74-0cdbca3be694 https://jobs.ashbyhq.com/moderntreasury/dc9bcfe8-64ef-4377-a...
- notjustanymike 5y ago
  UX design is heavily influenced by rules and research, just like engineering. There are systems at play which I'm sure the company would like to keep consistent. While you may be able to build a working page, can you ensure that every engineer builds it with the same interactions, flows, language, and even colors? Will you build and test it for the users the UX team has researched, or will you build it for yourself?
  - hpoe 5y ago
    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....?
- apercu 5y ago
  Developers creating user experiences that don't actually take in to account what the user needs to achieve as tasks many many times a day are entirely the reason we now have UX people.
- onion2k 5y ago
  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. :)
- spamizbad 5y ago
  Yeah, I have noticed a certain measure of developer autonomy has been lost, going to product management (who in-turn defer to design/UX). I don't think it's all bad: I always appreciated expertise when it comes to esthetic and experiential parts of software. What I do find frustrating is when they only concern themselves "happy path", and developers don't have the authority to fill in the gaps. It creates a waterfall-like experience where you are often stuck waiting to hear back from product/design to make a decision because they didn't consider a scenario where the user might submit a form with an incorrect field or some other seemingly obvious path. Another bad practice is product people who assume screenshots or Figma files are technical requirements; not realizing these only give you clues as to how something will look, not how something will work, so flows and business logic go under-examined by product, which can lead to more "let's hold off on that, let me think about it" after telling you to start something ASAP.
  - BreakfastB0b 5y ago
    I like to call this the human centipede of product development. This is why I only work at smaller companies where this is less of a problem.
  - emptysea 5y ago
    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).
MattGaiser 5y ago
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.
surfingdino 5y ago
Vision is good, a decent spec that doesn't get re-written every week is even better.
deleted 5y ago
[deleted]
tut-urut-utut 5y ago
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.
- hpoe 5y ago
  Counterpoint I work on a big boring business. I have two projects I am working on right now. One is a project that is interesting and I think will benefit the project. The other is one that I find poorly considered and a waste of money and effort. I try to do both to the best of my ability, but for the second project it has been made clear to me that my opinion is not really appreciated and that my technical opinion is not valued this has hence killed my initiative and desire to go above and beyond or my desire to advocate for changes for the betterment of the project. Not because I am lazy or resentful I've just learned that attempting to do so on this project is a waste of time and effort and my energy would be better spent elsewhere.
  - tut-urut-utut 5y ago
    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.
sam0x17 5y ago
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.
ItsMonkk 5y ago
I've been looking into this subject lately as I am now moving into management positions and attempting to figure out the best way to do so. Software Developers, let's say I gave you a problem, and that problem was currently being solved with an O(n^2) algorithm, and it turns out that problem was taking up 50+% of your cycles, and because of how it was solved there is hard-coupling that disallowed better approaches, and that you can resolve this problem into an O(1) algorithm? Would you want to hear about that algorithm? Because it's called communication. The model I now think of Development teams is that you have Developers at the center, and then everyone else are teachers assisting them. A UX Designer is there not to create the UI but to teach the Developer how to go about creating the UI. He will start by creating designs, but he will allow the developer to make their own mistakes and eventually the Developer will become a Master UX Designer in his own right. This is true of every element of the Software Development LifeCycle. From technical to designing the product itself. Once you have a Developer that understands Databases, understands Backend, Frontend, CSS, UX, understands the Product, works with the Users and dog-foods his own product, you will find the amount of time that it takes to get a superior product will drop massively. The example I like to give here is that Linus Torvalds created git in 10 days because he was a master user of Source Control and knew exactly what he needed, while Microsoft's Source Control team had worked with hundreds of developers over years and couldn't compete. When you have hundreds working on a project the ability to communicate in a depth-first-search style drops to 0, and you are left to only breadth-first-search solutions. Metcalfe's Law destroys productivity. Meta about the article: I think it's moving forwards but it's got so much going on it's hard to pay attention to any single point.
- Iv 5y ago
  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?
  - ItsMonkk 5y ago
    Sorry, the problem is communication. The solution is no communication. You do so by teaching your developers everything they need to know.
phkahler 5y ago
>> 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.
pawelduda 5y ago
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...
alexaholic 5y ago
My experience has been different than what is described here. I haven’t met that many developers who didn’t know why they were doing what they were doing. Instead I’ve met lots of managers who used the _why_ as if it was some magic wand that made the impossible possible, that turned garbage into clean, working code, that magically reduced the number of bugs to none, that squeezed six hours of hacking into one etc. I’ve met people who repeat the same _why_ over and over again as if that turned developers into machines that spit out good software, fast and cheap. More often than not I found myself telling my manager “I don’t know”, “I’m not sure”, “I’ll think about it” or “that will take a while”, and got a response like “yeah, but we need this because of/in order to/etc.”
- specialist 5y ago
  > 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 https://en.wikipedia.org/wiki/The_Macintosh_Way - Compliment sandwiches, surrounding criticisms with praise. Gene Wilder's letter to the costume designers for Willy Wonka is an oft cited example. - All that active listening and empathy stuff. eg Really, really listening to people, instead of just waiting for my turn to talk. eg #2, in meetings, hold back with my own feedback to see if any one else will make the same points first, thereby not sucking up all the oxygen. Etc. It's fucking exhausting. But like all skills, it does get easier over time. And my (probably wrong) perception is that I'm slightly less boorish and offensive. PS- I save up all my unsolicited feedback energy for HN. Haha.
  - alexaholic 5y ago
    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!
Consultant32452 5y ago
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.
cutler 5y ago
No you don't. A competent software engineer can produce good work whether or not he/she believes in the project. Projects vary in their scope for making the world a better place. In a capitalist econonmy many businesses are not required to produce a net benefit for anyone other than the shareholders. This kind of thinking comes from the same kindergarten view of life which espouses only working on what you feel passionate about. If we all did that there would be an immediate shortage of shelf-fillers and cleaners. The same applies to the tech industry where a siginifcant number of fintech projects, such as HFT, contribute nothing of any real value to society. Each time I hear some startup wonk claiming he gets excited about making a better todo app I just want to throw up. The startup world is full of trivia chasing investment dollars. I've made a point of telling interviewers that I don't believe in their product and that it shouldn't matter. I'm hired for my technical ability alone for which I have a track record of producing good work on projects in which I had no personal investment. Clarity of goals does matter. That can make or break a project but it has nothing to do with believing in the product.
- musingsole 5y ago
  You know it is entirely possible to be passionate about mortgage insurance market platforms. Or any [insert nominally boring task here]. If there is enough money to afford a developer for a problem, I'd argue it's a guarantee that it's possible for someone to be passionate about the problem space. So, if passionate problem solvers are available, what comes of not using them? Insufficient solutions. Keep telling yourself you make fine systems when you don't love the project. I bet you do. But the developer who actually cares will always produce something better. Add in that technology becomes entrenched, I'd argue we're always better working with no solution than to become attached to an inadequate one. Before you get hung up on "inadequate", I'll also throw out there that no spec is perfect and it is only the passionate who can properly fill it in. tl;dr projects completed by the jaded will only meet stated requirements. Projects completed by the passionate will define the actual problem in the course of solving it. Projects produced by the jaded should be discarded.
  - cutler 5y ago
    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.
LordN00b 5y ago
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.
- jnorthrop 5y ago
  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.
  - schwartzworld 5y ago
    You mean you want someone who is willing to blow smoke up your ass.
    - uDontKnowMe 5y ago
      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.
deleted 5y ago
[deleted]
robinj6 5y ago
This was really capturing my interest until I saw their title-cased Invented Solution that they were promoting to fix this.
mehphp 5y ago
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.
_rutinerad 5y ago
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”?
- edderly 5y ago
  I suspect the author is misapplying the more direct expression: "I'm being kept in the dark and fed shit" Which applies to a lot of dis-functional workplaces.
- okwubodu 5y ago
  Apple trees in an orchard can see where the fruits of their labor are headed.
specialist 5y ago
This article triggers my nostalgia. I like it. Very similar to how we methodology-philes talked back in the 90s. Peopleware, Mythical Man Month, Luke Hohmann's Journey of the Software Professional, etc. Thanks for posting. IISM.org is a great find. More like this, please.
one_off_comment 5y ago
Talking about the importance of your employees' passion is code for how to get more work for less compensation. View statements about the importance of passion from potential employers with the same suspicion you would statements like "we're a family here" and "it's not about the money".
- ianmcgowan 5y ago
  "word hard, play hard" is also a red flag
waylandsmithers 5y ago
Personally, I've had my heart broken by projects and companies enough that I now take a more impartial approach.
deleted 5y ago
[deleted]
edderly 5y ago
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.
deregulateMed 5y ago
Believing in a project just means they are going to underpay and overwork you. Give me equity and I'll care.
- throwaway98797 5y ago
  no you wont. you give people some equity they want more. or worse yet now as an owner you will comment on direction of the company since you have a vested interest. distracting the folks who are leading the company. not saying that the leaders know what they are doing, but at least let them fail without distraction from small stake owners.
papito 5y ago
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.
ravenstine 5y ago
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.
bob1029 5y ago
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...
anm89 5y ago
or if they don't, you need to be paying software developers enough that they are willing to believe in your project
rossdavidh 5y ago
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.
somishere 5y ago
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 ...
cultofmetatron 5y ago
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.
mikewarot 5y ago
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.
mcavoybn 5y ago
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.
ThinkBeat 5y ago
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.
cooervo 5y ago
nah, you need to apply good software dev practices, give excellent pay, benefits and vacations. Everything else is BS. You give me the above points I'll give my 100% from 9-5 of course.
underwater 5y ago
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. [1]: The useful shorthand I've used to describe engineers in this model is Product-minded Engineers: https://blog.pragmaticengineer.com/the-product-minded-engineer/ https://blog.pragmaticengineer.com/the-product-minded-engine...
travisgriggs 5y ago
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.
brailsafe 5y ago
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.
kgin 5y ago
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?

249 points by replyifuagree 5y ago

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.

coding123 5y ago

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.

Kranar 5y ago
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.
- hpoe 5y ago
  I envy you if that is your experience. Almost all UX persons I have worked with have a degree in "Design" and are artsy type that tell me. "You can't make this blue it just doesn't vibe with the green we have." Many of who use the argument "Apple/Google does it this way" I'm not saying your now right it's just been my experience that they aren't engineers or Computer Scientists.
  - exdsq 5y ago
    I've seen what happens when computer scientists go off on their own and design a user-centric product. Trust me, its good to have an 'artsy type'. I worked on a project with some pretty 'famous' CS guys (obviously relative to the field) and their form of documentation were essentially quizzes for the users to work through. Practically an end of term exam. It was crazy.
- carlmr 5y ago
  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.
  - spicybright 5y ago
    That sounds discouraging. But you can apply the same story about any manager-like figure, no? If one's priority is design freedom or whatever, a good working relationship with your higher ups is the best chance to enable that. Working well with managers is also a good strat for becoming one yourself, and having more influence over things you care about.
    - carlmr 5y ago
      >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.
- MattGaiser 5y ago
  Most of the ones I have ever encountered are former graphic design people.
  - ratww 5y ago
    For me it is 100% former graphic design people. In fact I've seen several engineers trying to migrate to UX but the gatekeeping and prejudice made them give up.
- eplanit 5y ago
  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.
- chii 5y ago
  the problem happens when they aren't your equal, but the workplace is too politically correct for you to bluntly point it out. All you can do is suggest improvements, if at all.
  - Pokepokalypse 5y ago
    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.
    - chii 5y ago
      > summarily judge them as "my inferior" 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.
- rubyist5eva 5y ago
  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.
- bjornsing 5y ago
  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?
- ratww 5y ago
  The thing is that the "seeing as equals" has to cut both ways. UX people, UI designers and PO/PMs who see developers purely as interface xerox machines don't really deserve much respect.
- hsn915 5y ago
  This comment is condescending and disrespectful. 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.
MattGaiser 5y ago
One of the things that really surprised me working as a software engineer was how much my work would be judged how how well it matched the drawing. It often seems like there is more verification of that than whether it does what was intended.
- mgkimsal 5y ago
  But... for most of the reviewers/team, what was intended is that the result look like the drawing. That's it. "Here's a mockup - we spent a lot of time on this". "OK... what does it look like on tablet, mobile, what are the failure states, what should error handling look like?" "We spent a lot of time on this - make it look like the mockup". Had a project years ago that was... almost as bad as that sounds.
  - MattGaiser 5y ago
    I worked on a project where the buy button was off the screen on anything but a wide monitor. So I could not see it on my laptop.
- jollybean 5y ago
  It's an easy thing to inspect for, and, most UX designers have pixel perfect expectations, which is actually not unreasonable in most cases as every pixel generally does have it's place. The problem of course is that it's too easy to focus on pixel perfection at the cost of other things. Recently, I've worked on a project and we had to force ourselves to 'not care' about those things until the very end when we did clean up.
  - legulere 5y ago
    But aren’t projects where you don’t have time to work in the details not also projects where the next project is waiting around the corner?
AnIdiotOnTheNet 5y ago
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.
- atatatat 5y ago
  Well-put. Thanks for noticing — I hope to be on a project of yours soon.
- pm90 5y ago
  I believe that most trained UI/UX designers (ie those who have internalized that UX is supposed to help people and not just how fancy or standard conformant you can get) do build pretty great designs, but I’ve noticed a lot of ego in this area from design leaders in my personal experience. Nearly every time design becomes political and every change needs to be conformant to even the most minute standards even if they may not have any material effects on the product. I think the field just has a lot of shitty “leaders”, most of the “grunts” I’ve worked with have been incredibly helpful and willing to think out of the box to make UX easier.
  - atatatat 5y ago
    Death by 1000 cuts. "Is this component really that shitty for the user?" is how you end up with...hell, insert any Enterprise software here.
- swiley 5y ago
  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.
  - p0nce 5y ago
madeofpalk 5y ago
Oof this kind of adversarial us vs them doesn't sound great! In well functioning product teams everyone should be working together to make a better product, recognising the roles and strengths of each other. If this isn't the case, then your org has bigger problems.
- mgkimsal 5y ago
  >everyone should be working together to make a better product That's rarely the top priority for everyone on the team at the same time. Design folks want to 'design', and agreeing that 'feature X' doesn't need to be in the screens - even if it's "the better product", doesn't align with their career need to have showcase material for the next job interview. Similar with tech/dev folks - an update feature might just need simple poll mechanism, but that doesn't give them experience with building a full pub/sub scalable architecture platform, or testing out the newest messaging libraries. The more people on that team, the more conflicting priorities there will be.
  - madeofpalk 5y ago
    > In well functioning product teams This doesn't sound like a great team, and doesn't really align with my (sure, admittedly limited) experience. I've only really worked once with someone who had strongly personally motivations that worked against the teams goal, and it was recognised that they were a wanker.
    - mgkimsal 5y ago
      the notion of "a better product" is... way too amorphous. without a lot of definition and constraints, people can make solid arguments for 'the good of the project' which also align with their personal goals (new tech, more design, etc) and it's often very hard to argue against those, because they sound good aren't necessarily 'wrong'.
- ElViajero 5y ago
  > If this isn't the case, then your org has bigger problems. That is completely true. To work together to build a product, to have everybody understanding what is what needs to be achieved, and collaboration in general is the way to go. In organizations where business does not trust engineering, engineering does not trust design ... things are never going to work. It is a collaborative effort, one point of view is insufficient to create an attractive product in a cost-effective way that is not full of tech-debt.
sam0x17 5y ago
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.
brightball 5y ago
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.
carlgreene 5y ago
This is because the UI/UX of a 2021 website/app is far more involved and complicated than that of a 2001 website/app. Product cohesion and well thought out human psychology levers are very important in products of today. I long for the days of building a simple site for my company. No fancy wizards, bifurcating flow, or complex animations. I unfortunately don’t think we’re going back to that time though.
- coding123 5y ago
  Not necessarily. Look at the site we're on. They don't monetize, but I bet if they did it would make millions per year.
  - AnIdiotOnTheNet 5y ago
    If they monetized they'd cease being simple because it'd be less profitable than implementing user-hostile "engagement" practices.
  - carlgreene 5y ago
    HN is an outlier and you know it ;). I do wish more sites were like HN both in terms simplicity and community
  - rightbyte 5y ago
    There are YC adds on HN though in the feed, so I guess you can say HN moneyizes? E.g. this job add was on my feed right now: https://jobs.ashbyhq.com/moderntreasury/dc9bcfe8-64ef-4377-ad74-0cdbca3be694 https://jobs.ashbyhq.com/moderntreasury/dc9bcfe8-64ef-4377-a...
notjustanymike 5y ago
UX design is heavily influenced by rules and research, just like engineering. There are systems at play which I'm sure the company would like to keep consistent. While you may be able to build a working page, can you ensure that every engineer builds it with the same interactions, flows, language, and even colors? Will you build and test it for the users the UX team has researched, or will you build it for yourself?
- hpoe 5y ago
  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....?
apercu 5y ago
Developers creating user experiences that don't actually take in to account what the user needs to achieve as tasks many many times a day are entirely the reason we now have UX people.
onion2k 5y ago
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. :)
spamizbad 5y ago
Yeah, I have noticed a certain measure of developer autonomy has been lost, going to product management (who in-turn defer to design/UX). I don't think it's all bad: I always appreciated expertise when it comes to esthetic and experiential parts of software. What I do find frustrating is when they only concern themselves "happy path", and developers don't have the authority to fill in the gaps. It creates a waterfall-like experience where you are often stuck waiting to hear back from product/design to make a decision because they didn't consider a scenario where the user might submit a form with an incorrect field or some other seemingly obvious path. Another bad practice is product people who assume screenshots or Figma files are technical requirements; not realizing these only give you clues as to how something will look, not how something will work, so flows and business logic go under-examined by product, which can lead to more "let's hold off on that, let me think about it" after telling you to start something ASAP.
- BreakfastB0b 5y ago
  I like to call this the human centipede of product development. This is why I only work at smaller companies where this is less of a problem.
- emptysea 5y ago
  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).

MattGaiser 5y ago

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.

surfingdino 5y ago

Vision is good, a decent spec that doesn't get re-written every week is even better.

deleted 5y ago

[deleted]

tut-urut-utut 5y ago

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.

hpoe 5y ago
Counterpoint I work on a big boring business. I have two projects I am working on right now. One is a project that is interesting and I think will benefit the project. The other is one that I find poorly considered and a waste of money and effort. I try to do both to the best of my ability, but for the second project it has been made clear to me that my opinion is not really appreciated and that my technical opinion is not valued this has hence killed my initiative and desire to go above and beyond or my desire to advocate for changes for the betterment of the project. Not because I am lazy or resentful I've just learned that attempting to do so on this project is a waste of time and effort and my energy would be better spent elsewhere.
- tut-urut-utut 5y ago
  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.

sam0x17 5y ago

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.

ItsMonkk 5y ago

I've been looking into this subject lately as I am now moving into management positions and attempting to figure out the best way to do so. Software Developers, let's say I gave you a problem, and that problem was currently being solved with an O(n^2) algorithm, and it turns out that problem was taking up 50+% of your cycles, and because of how it was solved there is hard-coupling that disallowed better approaches, and that you can resolve this problem into an O(1) algorithm? Would you want to hear about that algorithm? Because it's called communication. The model I now think of Development teams is that you have Developers at the center, and then everyone else are teachers assisting them. A UX Designer is there not to create the UI but to teach the Developer how to go about creating the UI. He will start by creating designs, but he will allow the developer to make their own mistakes and eventually the Developer will become a Master UX Designer in his own right. This is true of every element of the Software Development LifeCycle. From technical to designing the product itself. Once you have a Developer that understands Databases, understands Backend, Frontend, CSS, UX, understands the Product, works with the Users and dog-foods his own product, you will find the amount of time that it takes to get a superior product will drop massively. The example I like to give here is that Linus Torvalds created git in 10 days because he was a master user of Source Control and knew exactly what he needed, while Microsoft's Source Control team had worked with hundreds of developers over years and couldn't compete. When you have hundreds working on a project the ability to communicate in a depth-first-search style drops to 0, and you are left to only breadth-first-search solutions. Metcalfe's Law destroys productivity. Meta about the article: I think it's moving forwards but it's got so much going on it's hard to pay attention to any single point.

Iv 5y ago
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?
- ItsMonkk 5y ago
  Sorry, the problem is communication. The solution is no communication. You do so by teaching your developers everything they need to know.

phkahler 5y ago

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

pawelduda 5y ago

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

alexaholic 5y ago

My experience has been different than what is described here. I haven’t met that many developers who didn’t know why they were doing what they were doing. Instead I’ve met lots of managers who used the _why_ as if it was some magic wand that made the impossible possible, that turned garbage into clean, working code, that magically reduced the number of bugs to none, that squeezed six hours of hacking into one etc. I’ve met people who repeat the same _why_ over and over again as if that turned developers into machines that spit out good software, fast and cheap. More often than not I found myself telling my manager “I don’t know”, “I’m not sure”, “I’ll think about it” or “that will take a while”, and got a response like “yeah, but we need this because of/in order to/etc.”

specialist 5y ago
> 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 https://en.wikipedia.org/wiki/The_Macintosh_Way - Compliment sandwiches, surrounding criticisms with praise. Gene Wilder's letter to the costume designers for Willy Wonka is an oft cited example. - All that active listening and empathy stuff. eg Really, really listening to people, instead of just waiting for my turn to talk. eg #2, in meetings, hold back with my own feedback to see if any one else will make the same points first, thereby not sucking up all the oxygen. Etc. It's fucking exhausting. But like all skills, it does get easier over time. And my (probably wrong) perception is that I'm slightly less boorish and offensive. PS- I save up all my unsolicited feedback energy for HN. Haha.
- alexaholic 5y ago
  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!

Consultant32452 5y ago

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.

cutler 5y ago

No you don't. A competent software engineer can produce good work whether or not he/she believes in the project. Projects vary in their scope for making the world a better place. In a capitalist econonmy many businesses are not required to produce a net benefit for anyone other than the shareholders. This kind of thinking comes from the same kindergarten view of life which espouses only working on what you feel passionate about. If we all did that there would be an immediate shortage of shelf-fillers and cleaners. The same applies to the tech industry where a siginifcant number of fintech projects, such as HFT, contribute nothing of any real value to society. Each time I hear some startup wonk claiming he gets excited about making a better todo app I just want to throw up. The startup world is full of trivia chasing investment dollars. I've made a point of telling interviewers that I don't believe in their product and that it shouldn't matter. I'm hired for my technical ability alone for which I have a track record of producing good work on projects in which I had no personal investment. Clarity of goals does matter. That can make or break a project but it has nothing to do with believing in the product.

musingsole 5y ago
You know it is entirely possible to be passionate about mortgage insurance market platforms. Or any [insert nominally boring task here]. If there is enough money to afford a developer for a problem, I'd argue it's a guarantee that it's possible for someone to be passionate about the problem space. So, if passionate problem solvers are available, what comes of not using them? Insufficient solutions. Keep telling yourself you make fine systems when you don't love the project. I bet you do. But the developer who actually cares will always produce something better. Add in that technology becomes entrenched, I'd argue we're always better working with no solution than to become attached to an inadequate one. Before you get hung up on "inadequate", I'll also throw out there that no spec is perfect and it is only the passionate who can properly fill it in. tl;dr projects completed by the jaded will only meet stated requirements. Projects completed by the passionate will define the actual problem in the course of solving it. Projects produced by the jaded should be discarded.
- cutler 5y ago
  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.

LordN00b 5y ago

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.

jnorthrop 5y ago
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.
- schwartzworld 5y ago
  You mean you want someone who is willing to blow smoke up your ass.
  - uDontKnowMe 5y ago
    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.

deleted 5y ago

[deleted]

robinj6 5y ago

This was really capturing my interest until I saw their title-cased Invented Solution that they were promoting to fix this.

mehphp 5y ago

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.

_rutinerad 5y ago

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”?

edderly 5y ago
I suspect the author is misapplying the more direct expression: "I'm being kept in the dark and fed shit" Which applies to a lot of dis-functional workplaces.
okwubodu 5y ago
Apple trees in an orchard can see where the fruits of their labor are headed.

specialist 5y ago

This article triggers my nostalgia. I like it. Very similar to how we methodology-philes talked back in the 90s. Peopleware, Mythical Man Month, Luke Hohmann's Journey of the Software Professional, etc. Thanks for posting. IISM.org is a great find. More like this, please.

one_off_comment 5y ago

Talking about the importance of your employees' passion is code for how to get more work for less compensation. View statements about the importance of passion from potential employers with the same suspicion you would statements like "we're a family here" and "it's not about the money".

ianmcgowan 5y ago
"word hard, play hard" is also a red flag

waylandsmithers 5y ago

Personally, I've had my heart broken by projects and companies enough that I now take a more impartial approach.

deleted 5y ago

[deleted]

edderly 5y ago

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.

deregulateMed 5y ago

Believing in a project just means they are going to underpay and overwork you. Give me equity and I'll care.

throwaway98797 5y ago
no you wont. you give people some equity they want more. or worse yet now as an owner you will comment on direction of the company since you have a vested interest. distracting the folks who are leading the company. not saying that the leaders know what they are doing, but at least let them fail without distraction from small stake owners.

papito 5y ago

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.

ravenstine 5y ago

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.

bob1029 5y ago

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

anm89 5y ago

or if they don't, you need to be paying software developers enough that they are willing to believe in your project

rossdavidh 5y ago

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.

somishere 5y ago

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

cultofmetatron 5y ago

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.

mikewarot 5y ago

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.

mcavoybn 5y ago

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.

ThinkBeat 5y ago

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.

cooervo 5y ago

nah, you need to apply good software dev practices, give excellent pay, benefits and vacations. Everything else is BS. You give me the above points I'll give my 100% from 9-5 of course.

underwater 5y ago

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. [1]: The useful shorthand I've used to describe engineers in this model is Product-minded Engineers: https://blog.pragmaticengineer.com/the-product-minded-engineer/ https://blog.pragmaticengineer.com/the-product-minded-engine...

travisgriggs 5y ago

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.

brailsafe 5y ago

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.

kgin 5y ago

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?