12 ms·

I'm good at working on a team and looping in others. I also find it to be one of the most exhausting parts of software development. It's so difficult to constan

I'm good at working on a team and looping in others. I also find it to be one of the most exhausting parts of software development. It's so difficult to constantly need to get feedback and buy-in from other people, and takes away a lot of the creativity and joy in programming (for me). Which isn't to say you shouldn't do it, just that it's one of the things that makes me dislike working on a team. I actually think this may be one of the factors in burnout for a lot of developers. Writing code as a team is almost like writing a novel with a few dozen other people, all of which have differing ideas on how the book should be written, or even what it should be about. It's hard to feel the joy in creating something when you're only a small cog in the development machine, and every decision needs a dozen voices of input. It's disempowering to feel like you're never able to make a decision yourself, despite supposedly being hired for your expertise in the field. > Always encourage engineers to show their work as quickly as possible – an engineer on a project should never go more than a week without showing something, and usually it should be more like a day. "usually it should be more like a day" is bad advice in my opinion, and a likely source of micro management. Let professionals do their work.

mattferderer 5y ago
As much as I love the feeling of writing something clever or that feels really well done, I hate the feeling of realizing it's the wrong thing even more.
- Trasmatta 5y ago
  Agreed, and that's why I mentioned I think you shouldn't just silo yourself. That doesn't seem to work either. I don't really have a good answer or alternative, more just pointing out how the dynamics of team based software development seem to be optimized towards burning out programmers. I don't know how to fix it, but it seems to be a problem. A first step is probably treating your developers skilled specialists (hopefully you've hired a good team, of course), and not just code monkeys who have to show their manager a progress report every single day.
  - peakaboo 5y ago
    You do know how to fix it - you don't loop in others until you want to. The problem is our industry, forcing developers to exhaust their energy on pair programming in open offices. May as well be in a daycare center with children all around.
    - Trasmatta 5y ago
      Ugh, my worst development job ever was one that had mandatory full time pair programming. Full time pairing is one of the worst ideas ever conceived in the software world.
      - onemoresoop 5y ago
        Pair programming should be optional and for whoever wants to get team members (especially juniors) up to speed and on the same page. It could be very productive but like all methods/tools that are shoved down everyone's throat and forced to apply them, I could see them being a disaster.
        Trasmatta 5y ago
        I generally enjoy pair programming when utilized occasionally and as needed, but mandatory pairing is just horrible.
        onemoresoop 5y ago
        Each tool has its use case. Forced use results in misuse.
      - dhosek 5y ago
        I actually found it quite helpful, not just for getting up to speed. After moving to another division of that company that didn't employ full-time pair programming, I saw code of noticeably lower quality being produced. That said, it was emotionally exhausting for me to do full-time pairing and I'm not sure I'd go back to it.
- deleted 5y ago
  [deleted]
daenz 5y ago
The trick is to make the "right" decision yourself while helping people feel like they were heard and had a chance to give their input. From my experience, people don't actually want to control the output of everything, they just want the opportunity to be heard. What you do with it from there doesn't matter as much, so long as the desired outcome is "correct". If the desired outcome is not correct however... then you have to justify all of the input that you didn't act on.
- Trasmatta 5y ago
  The tricky part for me is that sometimes I did actually need that input from others on the team. Sometimes it's all just bikeshedding and a waste of time, but sometimes it does help me from going down a rabbit hole that might have wasted weeks of development. But regardless, I find that whole process exhausting and disempowering, even if there is sometimes a benefit from it.
peakaboo 5y ago
Completely agree with this, and this is why I simply don't loop in others. I wrote a program the way I think it should be. Clean code, super easy to understand, super low complexity. Anyone can understand what it does. Thats fun for me, when the code is very simple, reads like English and there are no complex functions. I don't do real software engineering however (just business intelligence and python programs to extract and load data). But when it comes to looping in colleagues, I avoid it for the same reasons as above. Its exhausting.
Panoramix 5y ago
I wholeheartedly agree, if you need daily feedback you're a bad manager (unless you're in some exotic situation like a rocket launch or something). This issue largely disappears if your engineers are given the proper context, background and system overview. I'm not advocating everybody should take their project and run with it for weeks on end, but daily updates are ridiculous.
- TameAntelope 5y ago
  I'd actually flip that, and say if you can't give daily feedback you're a "bad" developer (I'd probably use "inexperienced" or "new" rather than "bad", because it's a hard mindset shift and it takes time). In fact, not only should you be able to give daily updates, you should be able to ship functionality on the daily. From first line of code into production and in front of customers should only ever take about 2 to 16 hours of work. If you can't work at that cadence, you're probably not being as effective as you could be, as a developer. A "good" manager enables you to work like this.
  - dogleash 5y ago
    I used to work at an R&D company. While that cadence is possible in a website mill, it’s a laughable blanket statement.
    - diggs 5y ago
      Agreed - I’ve spent months working on a deep tech problem before I could even show a functional core, let alone putting it into production. Some problems take time, experience and foresight to solve and the solution only dovetails at the end.
    - gffrd 5y ago
      Just wanted to say thank you for "website mill" … I'm reminded of this stark difference when talking with a friend who builds ultrasonic hardware.
    - ngc248 5y ago
n0w 5y ago
> Writing code as a team is almost like writing a novel with a few dozen other people, all of which have differing ideas on how the book should be written, or even what it should be about. It's hard to feel the joy in creating something when you're only a small cog in the development machine, and every decision needs a dozen voices of input. This resonates with me. I think we do our best work when we have the autonomy to apply our expertise. But at the end of the day, you're not the only one writing that novel. If you have an idea of where the plot is going but your teammates think it's heading somewhere else, it's going to be very problematic. The other problem is that you _will_ make mistakes. Some could be avoided by leveraging the experience of your teammates. You also won't always strictly have the best ideas. Brainstorming as a group can be a lot more effective than sitting alone for a long time thinking hard about a problem (but also sometimes hard problems need a lot of individual thought). I suppose my point is that I'm not sure where the happy medium is? I've been on both sides of the "engineer working too long alone before sharing" problem and I think it sucks. How do we enable engineers to do their best work but also allow our teams to be successful?
- strictfp 5y ago
  You can just let some people make mistakes, and give them feedback on it for next time. That way, you get autonomy and eventually mastery. We don't all have to agree on everything. I think that's a fallacy.
  - comp_throw7 5y ago
    The idea that people will better learn from spending several weeks doing something useless (i.e. unnecessary design) instead of having that headed off at the pass is silly, when the specific thing they should be learning is to _not spend several weeks working on something without feedback_.
    - js8 5y ago
      I don't think that's what GP was suggesting at all.. everyone in the thread agrees that feedback is good. However, the opposite extreme, spending time in meetings where lot of good ideas get proposed but most of them get killed, because somebody doesn't like a detail, or nobody champions them strongly enough, is not a good learning experience either.
drawkbox 5y ago
> Writing code as a team is almost like writing a novel with a few dozen other people, all of which have differing ideas on how the book should be written, or even what it should be about. I use this exact description when discussing balancing creative side of the value creation project processes, design and development over the value extraction side of products. Small empowered teams with an almost startup mindset is key, but even more is time to play to find solutions that can make products that are more like friends than enemies to people. Engineering/development, creative and product design/development are creative fields, a value creation action and activity. Business, finance, marketing do not see many parts of this as a creative action but a production line, a value extraction action and activity. A large problem is the misunderstanding that new projects are value creation not just value extraction, and rely on creativity at inception. Once they are established they can be more patterned and predictable and ramped up, but initially the creative phase is the key to making good products. Smaller teams, more empowering of the people that can create products that get the early points right. Taking long enough in the "open" mode before the "closed" mode is key, essentially prototyping and play is needed, but rarely available in the modern processes and project management systems where engineering is simply "production". There is a pre-production and post-production that is usually left out. For instance in game development, pushing through a project process before the main game mechanic is "fun" is a problem. You can't get creative on a forced schedule just as you couldn't write a book that way or come up with a novel new concept in some software app that should be a friend to users. The prototype of the project or product must have some time to simmer and iterate on. The first thing managers do is cut that time and sometimes throw too many people at it resulting in Mythical Man Month level mistakes leading to too many cooks. When a prototype or early product has value mostly figured out, then it can go into a more robust process to create variations or iterations. The initial value creation will always be wildly hard to estimate. Good examples of this in software are programming languages, usually it is one person for a long time then others join in to ramp up when the vibe of the language is set. Same with books, movies, games, anything really. You can't have 10 people drawing the same illustration or writing the same book, the parallel part can be multiple people doing their own to see which is best, but you can't have them all in on one creative project without it being confused. I have seen companies turn into faction based wars when varying groups don't clearly respect the value creation and value extraction balance, the value creation MUST come before the value extraction. The open mode before the closed mode. A great talk by John Cleese on the "open" and "closed" mode [1] helps describe this, which I recommend and hope everyone I work with watches. Value creators need time and creativity to create value both in the "open" mode to explore/prototype/build and the "closed" mode when things are decided to ship. The value extractors always want people in the controlled "closed" mode only, the "open" mode is non quantifiable and seen as almost an enemy to the value extractors but is key to creating products that are so good they are like friends to value creators and the people using the products. The value extractors are who Fred Brooks talked about in the Mythical Man month [2], they think things are a factory with already figured out steps, when you are in a field that uses originality, creativity, the mind over the physical, it isn't like a factory or supply line. Every single project manager needs to know about the Mythical Man month. Here's a great point by Steve Jobs about product stagnation and the managers/business side [3] and how they can run amok if not controlled to allow value creation to continue, and how monopolies or problems that arise when only the business/managers are in charge. This point is more about larger companies than new projects but the same forces that stop innovation at large companies also kill it in any sized companies when there is no value creation / value extraction balance. > It turns out the same thing can happen in technology companies that get monopolies, like IBM or Xerox. If you were a product person at IBM or Xerox, so you make a better copier or computer. So what? When you have monopoly market share, the company's not any more successful. > So the people that can make the company more successful are sales and marketing people, and they end up running the companies. And the product people get driven out of the decision making forums, and the companies forget what it means to make great products. The product sensibility and the product genius that brought them to that monopolistic position gets rotted out by people running these companies that have no conception of a good product versus a bad product. > They have no conception of the craftsmanship that's required to take a good idea and turn it into a good product. And they really have no feeling in their hearts, usually, about wanting to really help the customers. Modern project management processes promote shallow change over deeper dives. They create a risk profile for anyone looking to bring new innovations that might be hard to estimate because it will be a perceptual hit. These rigid tightly wound processes are horrible for creativity. Agile itself has been captured with tightly wound controlling mechanisms like the daily standup, and so much weight around trying new things as well as perceptual hits for that. Anyone truly trying to make new value will be seen as an enemy to these systems. Agile was created to give product people more margin to build, but it has been coopted into being used to control creativity which cannot be controlled, it simply disappears when there is no open mode and only a closed mode or nothing but value extraction. All of this is spelled out in "How Software Companies Die" as well [4]. I wonder when if these realities will make it into the business education curriculum. [1] https://www.youtube.com/watch?v=Pb5oIIPO62g https://www.youtube.com/watch?v=Pb5oIIPO62g [2] https://en.wikipedia.org/wiki/The_Mythical_Man-Month https://en.wikipedia.org/wiki/The_Mythical_Man-Month [3] https://www.businessinsider.com/steve-jobs-on-why-innovation-dies-at-tech-monopolies-2014-11 https://www.businessinsider.com/steve-jobs-on-why-innovation... [4] https://news.ycombinator.com/item?id=1866486 https://news.ycombinator.com/item?id=1866486
rurp 5y ago
Due to some turnover I ended up working mostly independently for about a year at a previous job. Nobody cared one bit about the code I wrote, just the end result. Overall it was great! I was surprised at how productive I was in that time. I'm not a partiularly amazing developer, but I managed to ship a ton of work that held up quite well. Obviously there are limits to this approach and it wouldn't work well for solving really difficult problems, but really, 99% of day-to-day development work isn't that special. A motivated and conscientious developer with average skills can get an awful lot done with minimal distractions.
- e12e 5y ago
  Sounds like high bus-factor. Were you also expected to pick up "alien" code dumps as other programmers left? Were you happy/efficient working with these unseen code bases?
  - rurp 5y ago
    I had a few coworkers working on very related areas that I coordinated with, plus we did have some contingency plans so one of us could step into the others place in a pinch. But that was a weakness and things could have been rough if I had been hit by a bus. An alien code dump is basically how I ended up in the situation. My boss left abruptly and a bunch of work he had been handling himself suddenly fell to me. At first it was really stressful trying to get a handle on everything, but once I got over the hump it was quite nice.
baby 5y ago
> Writing code as a team is almost like writing a novel with a few dozen other people, all of which have differing ideas on how the book should be written, or even what it should be about. It's hard to feel the joy in creating something when you're only a small cog in the development machine, and every decision needs a dozen voices of input. I believe this is why books most often have a single author. A solution to this, is to agree on the global design, and then have different developers own different "modules" of the design. These modules should be treated like third-party libraries (and should act like third-party libraries vis-a-vis of their documentation and API). Basically, microservices can exist within your code if you know how to modularize well.
- e12e 5y ago
  > I believe this is why books most often have a single author. ... And at least one editor, no?
  - baby 5y ago
    I see the editor as the code reviewer :p
- lolc 5y ago
  I don't like the analogy to writing a novel because in a novel you do want suspense, drama, surprises and generally a non-ordinary flow of the story. With source-code, you want none of that. The whole process is geared to remove it. And we should not deplore that but embrace it. Maybe there will be non-conventional things, because you have non-conventional requirements, or you're trying something new, but that should be the exception.
Kaze404 5y ago
> It's disempowering to feel like you're never able to make a decision yourself, despite supposedly being hired for your expertise in the field. I'm going through exactly this at the moment. For reasons HN will probably consider fiction, my superiors have started treating me as a toddler that needs oversight on every single decision that needs to be made. It's something I've been dealing with in therapy, and the way I was able to explain it to her was by saying that I feel like the monkey in the infinite monkey theorem. Never thinking about what you're producing (if you can call it producing at all), just pressing buttons. It makes me wonder what the point of having me even is, considering they spend so much time solving all my problems for me. I've come really close to saying "ok, go ahead and let me know when it's done" during 40 minute meetings where every minute detail of what I'm supposed to do is discussed by 3 people.
- Trasmatta 5y ago
  I feel this deeply. I had an extremely similar situation at my last job. My current job is quite a bit better at least, but I still deal with it here. I guess there's a reason the phrase "code monkey" exists. Jonathan Coulton said it pretty well: Code Monkey have boring meeting With boring manager Rob Rob say Code Monkey very diligent But his output stink His code not “functional” or “elegant” What do Code Monkey think? Code Monkey think maybe manager want to write god damned login page himself https://www.youtube.com/watch?v=AEBld6I_AKs https://www.youtube.com/watch?v=AEBld6I_AKs
  - burntoutfire 5y ago
    I personally much prefer this version: https://www.youtube.com/watch?v=RUbp_d2DkYU https://www.youtube.com/watch?v=RUbp_d2DkYU
- heurist 5y ago
  Leave that company immediately and find something that gives you room to breathe.
  - Kaze404 5y ago
yuliyp 5y ago
In good teams I've been able to bounce ideas off my teammates without pressure. They'd come back with things I hadn't thought of, I'd iterate and they'd respond, etc. After this I left the discussion with a better understanding of the problem, still ultimately in the driver's seat for solving the problem. Getting feedback in these situations is empowering. In bad teams I end up defending myself from people who want to leave their mark on what I'm doing, or just have different taste than me. Getting feedback in these situations is frustrating and demoralizing.
ximm 5y ago
> "usually it should be more like a day" is bad advice in my opinion, and a likely source of micro management. Let professionals do their work. In my team we always publish some form of status report at the end of the day. This could be a pull request or a list of open questions on the task. For us that is less about micro management and more about bus factor: If a person calls in sick the next day the rest of the team wouldn't be able to continue that persons tasks without this process. I understand that this can be detrimental when it feels like micro management. But I believe it is more a question of framing.
e12e 5y ago
> "usually it should be more like a day" is bad advice in my opinion, and a likely source of micro management. Depends what "showing" means - on the other end is doing all prototyping/exploration as pair programming - thus immediately "showing" work to at least one other engineer.

mattferderer 5y ago

As much as I love the feeling of writing something clever or that feels really well done, I hate the feeling of realizing it's the wrong thing even more.

Trasmatta 5y ago
Agreed, and that's why I mentioned I think you shouldn't just silo yourself. That doesn't seem to work either. I don't really have a good answer or alternative, more just pointing out how the dynamics of team based software development seem to be optimized towards burning out programmers. I don't know how to fix it, but it seems to be a problem. A first step is probably treating your developers skilled specialists (hopefully you've hired a good team, of course), and not just code monkeys who have to show their manager a progress report every single day.
- peakaboo 5y ago
  You do know how to fix it - you don't loop in others until you want to. The problem is our industry, forcing developers to exhaust their energy on pair programming in open offices. May as well be in a daycare center with children all around.
  - Trasmatta 5y ago
    Ugh, my worst development job ever was one that had mandatory full time pair programming. Full time pairing is one of the worst ideas ever conceived in the software world.
    - onemoresoop 5y ago
      Pair programming should be optional and for whoever wants to get team members (especially juniors) up to speed and on the same page. It could be very productive but like all methods/tools that are shoved down everyone's throat and forced to apply them, I could see them being a disaster.
      - Trasmatta 5y ago
        I generally enjoy pair programming when utilized occasionally and as needed, but mandatory pairing is just horrible.
        onemoresoop 5y ago
        Each tool has its use case. Forced use results in misuse.
    - dhosek 5y ago
      I actually found it quite helpful, not just for getting up to speed. After moving to another division of that company that didn't employ full-time pair programming, I saw code of noticeably lower quality being produced. That said, it was emotionally exhausting for me to do full-time pairing and I'm not sure I'd go back to it.
deleted 5y ago
[deleted]

daenz 5y ago

The trick is to make the "right" decision yourself while helping people feel like they were heard and had a chance to give their input. From my experience, people don't actually want to control the output of everything, they just want the opportunity to be heard. What you do with it from there doesn't matter as much, so long as the desired outcome is "correct". If the desired outcome is not correct however... then you have to justify all of the input that you didn't act on.

Trasmatta 5y ago
The tricky part for me is that sometimes I did actually need that input from others on the team. Sometimes it's all just bikeshedding and a waste of time, but sometimes it does help me from going down a rabbit hole that might have wasted weeks of development. But regardless, I find that whole process exhausting and disempowering, even if there is sometimes a benefit from it.

peakaboo 5y ago

Completely agree with this, and this is why I simply don't loop in others. I wrote a program the way I think it should be. Clean code, super easy to understand, super low complexity. Anyone can understand what it does. Thats fun for me, when the code is very simple, reads like English and there are no complex functions. I don't do real software engineering however (just business intelligence and python programs to extract and load data). But when it comes to looping in colleagues, I avoid it for the same reasons as above. Its exhausting.

Panoramix 5y ago

I wholeheartedly agree, if you need daily feedback you're a bad manager (unless you're in some exotic situation like a rocket launch or something). This issue largely disappears if your engineers are given the proper context, background and system overview. I'm not advocating everybody should take their project and run with it for weeks on end, but daily updates are ridiculous.

TameAntelope 5y ago
I'd actually flip that, and say if you can't give daily feedback you're a "bad" developer (I'd probably use "inexperienced" or "new" rather than "bad", because it's a hard mindset shift and it takes time). In fact, not only should you be able to give daily updates, you should be able to ship functionality on the daily. From first line of code into production and in front of customers should only ever take about 2 to 16 hours of work. If you can't work at that cadence, you're probably not being as effective as you could be, as a developer. A "good" manager enables you to work like this.
- dogleash 5y ago
  I used to work at an R&D company. While that cadence is possible in a website mill, it’s a laughable blanket statement.
  - diggs 5y ago
    Agreed - I’ve spent months working on a deep tech problem before I could even show a functional core, let alone putting it into production. Some problems take time, experience and foresight to solve and the solution only dovetails at the end.
  - gffrd 5y ago
    Just wanted to say thank you for "website mill" … I'm reminded of this stark difference when talking with a friend who builds ultrasonic hardware.
  - ngc248 5y ago

n0w 5y ago

> Writing code as a team is almost like writing a novel with a few dozen other people, all of which have differing ideas on how the book should be written, or even what it should be about. It's hard to feel the joy in creating something when you're only a small cog in the development machine, and every decision needs a dozen voices of input. This resonates with me. I think we do our best work when we have the autonomy to apply our expertise. But at the end of the day, you're not the only one writing that novel. If you have an idea of where the plot is going but your teammates think it's heading somewhere else, it's going to be very problematic. The other problem is that you _will_ make mistakes. Some could be avoided by leveraging the experience of your teammates. You also won't always strictly have the best ideas. Brainstorming as a group can be a lot more effective than sitting alone for a long time thinking hard about a problem (but also sometimes hard problems need a lot of individual thought). I suppose my point is that I'm not sure where the happy medium is? I've been on both sides of the "engineer working too long alone before sharing" problem and I think it sucks. How do we enable engineers to do their best work but also allow our teams to be successful?

strictfp 5y ago
You can just let some people make mistakes, and give them feedback on it for next time. That way, you get autonomy and eventually mastery. We don't all have to agree on everything. I think that's a fallacy.
- comp_throw7 5y ago
  The idea that people will better learn from spending several weeks doing something useless (i.e. unnecessary design) instead of having that headed off at the pass is silly, when the specific thing they should be learning is to _not spend several weeks working on something without feedback_.
  - js8 5y ago
    I don't think that's what GP was suggesting at all.. everyone in the thread agrees that feedback is good. However, the opposite extreme, spending time in meetings where lot of good ideas get proposed but most of them get killed, because somebody doesn't like a detail, or nobody champions them strongly enough, is not a good learning experience either.

drawkbox 5y ago

> Writing code as a team is almost like writing a novel with a few dozen other people, all of which have differing ideas on how the book should be written, or even what it should be about. I use this exact description when discussing balancing creative side of the value creation project processes, design and development over the value extraction side of products. Small empowered teams with an almost startup mindset is key, but even more is time to play to find solutions that can make products that are more like friends than enemies to people. Engineering/development, creative and product design/development are creative fields, a value creation action and activity. Business, finance, marketing do not see many parts of this as a creative action but a production line, a value extraction action and activity. A large problem is the misunderstanding that new projects are value creation not just value extraction, and rely on creativity at inception. Once they are established they can be more patterned and predictable and ramped up, but initially the creative phase is the key to making good products. Smaller teams, more empowering of the people that can create products that get the early points right. Taking long enough in the "open" mode before the "closed" mode is key, essentially prototyping and play is needed, but rarely available in the modern processes and project management systems where engineering is simply "production". There is a pre-production and post-production that is usually left out. For instance in game development, pushing through a project process before the main game mechanic is "fun" is a problem. You can't get creative on a forced schedule just as you couldn't write a book that way or come up with a novel new concept in some software app that should be a friend to users. The prototype of the project or product must have some time to simmer and iterate on. The first thing managers do is cut that time and sometimes throw too many people at it resulting in Mythical Man Month level mistakes leading to too many cooks. When a prototype or early product has value mostly figured out, then it can go into a more robust process to create variations or iterations. The initial value creation will always be wildly hard to estimate. Good examples of this in software are programming languages, usually it is one person for a long time then others join in to ramp up when the vibe of the language is set. Same with books, movies, games, anything really. You can't have 10 people drawing the same illustration or writing the same book, the parallel part can be multiple people doing their own to see which is best, but you can't have them all in on one creative project without it being confused. I have seen companies turn into faction based wars when varying groups don't clearly respect the value creation and value extraction balance, the value creation MUST come before the value extraction. The open mode before the closed mode. A great talk by John Cleese on the "open" and "closed" mode [1] helps describe this, which I recommend and hope everyone I work with watches. Value creators need time and creativity to create value both in the "open" mode to explore/prototype/build and the "closed" mode when things are decided to ship. The value extractors always want people in the controlled "closed" mode only, the "open" mode is non quantifiable and seen as almost an enemy to the value extractors but is key to creating products that are so good they are like friends to value creators and the people using the products. The value extractors are who Fred Brooks talked about in the Mythical Man month [2], they think things are a factory with already figured out steps, when you are in a field that uses originality, creativity, the mind over the physical, it isn't like a factory or supply line. Every single project manager needs to know about the Mythical Man month. Here's a great point by Steve Jobs about product stagnation and the managers/business side [3] and how they can run amok if not controlled to allow value creation to continue, and how monopolies or problems that arise when only the business/managers are in charge. This point is more about larger companies than new projects but the same forces that stop innovation at large companies also kill it in any sized companies when there is no value creation / value extraction balance. > It turns out the same thing can happen in technology companies that get monopolies, like IBM or Xerox. If you were a product person at IBM or Xerox, so you make a better copier or computer. So what? When you have monopoly market share, the company's not any more successful. > So the people that can make the company more successful are sales and marketing people, and they end up running the companies. And the product people get driven out of the decision making forums, and the companies forget what it means to make great products. The product sensibility and the product genius that brought them to that monopolistic position gets rotted out by people running these companies that have no conception of a good product versus a bad product. > They have no conception of the craftsmanship that's required to take a good idea and turn it into a good product. And they really have no feeling in their hearts, usually, about wanting to really help the customers. Modern project management processes promote shallow change over deeper dives. They create a risk profile for anyone looking to bring new innovations that might be hard to estimate because it will be a perceptual hit. These rigid tightly wound processes are horrible for creativity. Agile itself has been captured with tightly wound controlling mechanisms like the daily standup, and so much weight around trying new things as well as perceptual hits for that. Anyone truly trying to make new value will be seen as an enemy to these systems. Agile was created to give product people more margin to build, but it has been coopted into being used to control creativity which cannot be controlled, it simply disappears when there is no open mode and only a closed mode or nothing but value extraction. All of this is spelled out in "How Software Companies Die" as well [4]. I wonder when if these realities will make it into the business education curriculum. [1] https://www.youtube.com/watch?v=Pb5oIIPO62g https://www.youtube.com/watch?v=Pb5oIIPO62g [2] https://en.wikipedia.org/wiki/The_Mythical_Man-Month https://en.wikipedia.org/wiki/The_Mythical_Man-Month [3] https://www.businessinsider.com/steve-jobs-on-why-innovation-dies-at-tech-monopolies-2014-11 https://www.businessinsider.com/steve-jobs-on-why-innovation... [4] https://news.ycombinator.com/item?id=1866486 https://news.ycombinator.com/item?id=1866486

rurp 5y ago

Due to some turnover I ended up working mostly independently for about a year at a previous job. Nobody cared one bit about the code I wrote, just the end result. Overall it was great! I was surprised at how productive I was in that time. I'm not a partiularly amazing developer, but I managed to ship a ton of work that held up quite well. Obviously there are limits to this approach and it wouldn't work well for solving really difficult problems, but really, 99% of day-to-day development work isn't that special. A motivated and conscientious developer with average skills can get an awful lot done with minimal distractions.

e12e 5y ago
Sounds like high bus-factor. Were you also expected to pick up "alien" code dumps as other programmers left? Were you happy/efficient working with these unseen code bases?
- rurp 5y ago
  I had a few coworkers working on very related areas that I coordinated with, plus we did have some contingency plans so one of us could step into the others place in a pinch. But that was a weakness and things could have been rough if I had been hit by a bus. An alien code dump is basically how I ended up in the situation. My boss left abruptly and a bunch of work he had been handling himself suddenly fell to me. At first it was really stressful trying to get a handle on everything, but once I got over the hump it was quite nice.

baby 5y ago

> Writing code as a team is almost like writing a novel with a few dozen other people, all of which have differing ideas on how the book should be written, or even what it should be about. It's hard to feel the joy in creating something when you're only a small cog in the development machine, and every decision needs a dozen voices of input. I believe this is why books most often have a single author. A solution to this, is to agree on the global design, and then have different developers own different "modules" of the design. These modules should be treated like third-party libraries (and should act like third-party libraries vis-a-vis of their documentation and API). Basically, microservices can exist within your code if you know how to modularize well.

e12e 5y ago
> I believe this is why books most often have a single author. ... And at least one editor, no?
- baby 5y ago
  I see the editor as the code reviewer :p
lolc 5y ago
I don't like the analogy to writing a novel because in a novel you do want suspense, drama, surprises and generally a non-ordinary flow of the story. With source-code, you want none of that. The whole process is geared to remove it. And we should not deplore that but embrace it. Maybe there will be non-conventional things, because you have non-conventional requirements, or you're trying something new, but that should be the exception.

Kaze404 5y ago

> It's disempowering to feel like you're never able to make a decision yourself, despite supposedly being hired for your expertise in the field. I'm going through exactly this at the moment. For reasons HN will probably consider fiction, my superiors have started treating me as a toddler that needs oversight on every single decision that needs to be made. It's something I've been dealing with in therapy, and the way I was able to explain it to her was by saying that I feel like the monkey in the infinite monkey theorem. Never thinking about what you're producing (if you can call it producing at all), just pressing buttons. It makes me wonder what the point of having me even is, considering they spend so much time solving all my problems for me. I've come really close to saying "ok, go ahead and let me know when it's done" during 40 minute meetings where every minute detail of what I'm supposed to do is discussed by 3 people.

Trasmatta 5y ago
I feel this deeply. I had an extremely similar situation at my last job. My current job is quite a bit better at least, but I still deal with it here. I guess there's a reason the phrase "code monkey" exists. Jonathan Coulton said it pretty well: Code Monkey have boring meeting With boring manager Rob Rob say Code Monkey very diligent But his output stink His code not “functional” or “elegant” What do Code Monkey think? Code Monkey think maybe manager want to write god damned login page himself https://www.youtube.com/watch?v=AEBld6I_AKs https://www.youtube.com/watch?v=AEBld6I_AKs
- burntoutfire 5y ago
  I personally much prefer this version: https://www.youtube.com/watch?v=RUbp_d2DkYU https://www.youtube.com/watch?v=RUbp_d2DkYU
heurist 5y ago
Leave that company immediately and find something that gives you room to breathe.
- Kaze404 5y ago

yuliyp 5y ago

In good teams I've been able to bounce ideas off my teammates without pressure. They'd come back with things I hadn't thought of, I'd iterate and they'd respond, etc. After this I left the discussion with a better understanding of the problem, still ultimately in the driver's seat for solving the problem. Getting feedback in these situations is empowering. In bad teams I end up defending myself from people who want to leave their mark on what I'm doing, or just have different taste than me. Getting feedback in these situations is frustrating and demoralizing.

ximm 5y ago

> "usually it should be more like a day" is bad advice in my opinion, and a likely source of micro management. Let professionals do their work. In my team we always publish some form of status report at the end of the day. This could be a pull request or a list of open questions on the task. For us that is less about micro management and more about bus factor: If a person calls in sick the next day the rest of the team wouldn't be able to continue that persons tasks without this process. I understand that this can be detrimental when it feels like micro management. But I believe it is more a question of framing.

e12e 5y ago

> "usually it should be more like a day" is bad advice in my opinion, and a likely source of micro management. Depends what "showing" means - on the other end is doing all prototyping/exploration as pair programming - thus immediately "showing" work to at least one other engineer.