6 ms·

You’re Not Managing a Team of Software Engineers, You’re Managing Writers

97 points by ohjeez 8y ago

protomyth 8y ago
I do wonder how a TV show runner of some experience would handle a software production. There are a lot of moving parts that are not unlike what they deal with.
- 21 8y ago
  There is no technical debt in TV production. That alone changes many things. You don't need to care how you arrived at the result or how "maintainable" it is.
  - smackay 8y ago
    I thought that "the ship that made the Kessel Run in less than 12 parsecs." was the very definition of tehnical debt - which took 40 years to finally resolve. https://www.forbes.com/sites/jvchamary/2018/05/30/solo-star-wars-story-kessel-run-12-parsecs/ https://www.forbes.com/sites/jvchamary/2018/05/30/solo-star-...
  - AnimalMuppet 8y ago
    Plot debt? I could actually see that describing some shows...
    - XorNot 8y ago
      The Stargate SG-1 writers regretted the "3 shots from a zat-gun disintegrates" thing, and had zat guns only ever hit stuff twice for the rest of the show after they realized the mistake they'd made. The problem was introduced to solve a plot issue in one episode - they needed a way for the team to get rid of the bodies they were leaving behind on a spaceship in one episode.
    - delecti 8y ago
      But plenty of other franchises just ignore things in the past as though they never happened, even up to and including characters.
  - protomyth 8y ago
    I'm not sure that quite right. You do need to make sure it is maintainable because (at least in the US), they needed multiple seasons to reach a mark that would allow syndication.
    - lbriner 8y ago
      I think 21 is talking about the technical side of production e.g. hacking some weird sound effect - doesn't necessarily matter if it was hard, once it's recorded and produced, it's done. If you had to have someone holding up a part of the set, as long as it worked, it doesn't need to be maintained. What you are talking about is maintenance of the storyline, which in some ways is probably more consistent with what us Devs talk about with technical debt. That said, there are plenty of plot holes in many TV shows and I still watch them!
  - callmeal 8y ago
    There is. It's just called continuity errors, or retroactive continuity. Not something that you can easily fix given the type of industry.
  - mrob 8y ago
    Interlacing is technical debt. It looks bad and there's no longer any need for it, but it's still included in currently supported standards.
  - walshemj 8y ago
    There is in production you start out with x pages of script and have 7 days to shoot it. Listen to and commentary with directors and actors they will often refer to getting the day done i.e. they shot the required number of pages and having to cut stuff or not be able to do some cool shot they wanted.
thinkingkong 8y ago
No youre managing a team of software engineers, one skill they have is writing. The product isnt the text. The product is the entire system designed to keep the text alive, functional, reasonably error free all in a relatively unpredictable environment. We definitely need to keep considering how other professions manage the unpredictable nature of their work so we can learn. Im just not sure this narrative suits that goal.
- slededit 8y ago
  The uncomfortable fact is other professions treat their employees like cogs (hiring booms then mass layoffs), or their customers like crap (ever wait an hour for your set time appointment at the doctor?). The determining factor is really the price of the professional. Software development is in a real interesting situation as its transitioning from a low status job to a high status one. As this progresses you'll see more and more "the customer is always wrong" style blog posts. They are already pretty common already.
  - harlanji 8y ago
    What’s your basis for determing status? In my experience it massively elevated my status 15 years ago thru now, where it seems to have no effect and perhaps anchor me away from higher level jobs given the value of the output and scarcity of 10x engineers. I’m happy enough as a simple IC if they pay and treat me well, but that’s not been the case in 5+ years which has me in retirement from the field.
    - marktangotango 8y ago
      You’re saying there’s less status now than 15 years ago and you’re retired now? Can you talk about your experience, very interesting!
    - slededit 8y ago
      Status normally follows money (with enough gestation time). For the simple reason to get money you need to convince someone who already has it to give it to you. The inverse is also true, while a Noble title will get you a good spot at a traditional restaurant in London - for the most part nobody cares now that they don't employ half the village.
GoToRO 8y ago
You should not manage anything unless you yourself did that job successfully for 10 years.
- samatman 8y ago
  Best not build anything that didn't exist ten years ago then.
  - corpMaverick 8y ago
    Think of it as: "Don't manage software engineers unless you were a software engineer for X years"
- vbuwivbiu 8y ago
  put another way, the best managers came from the shop floor
ilovecaching 8y ago
Managers shouldn't be writing code or architecting at all. A manager's job is to manage people or a product. If it's people, she should be completely focused on unblocking the engineers and keeping them out of meetings. If it's the product, she should be completely focused on gathering the requirements and constraints and communicating with the customer and getting estimates from the engineers. The architecture and implementation is a hidden detail for a manager. Either the team lead, architect, or team as a whole should design and move on the code.
- poof131 8y ago
  The problem is the architecture is intertwined with the product is intertwined with the people. Believing that these things can easily be broken apart is an illusion. It’s how product believes one thing and engineers believe another, resulting in quick hacks, missed deadlines, and a mediocre product, if it’s released at all. Meanwhile the manager is a “people person”. Teams need leadership, not three leaders. Dev managers should be able to understand the architecture, and the product, and the team. Product advises on the direction. Tech leads argue for the implementation. But the dev manager needs to bring these things together and provide direction. Otherwise all three people will just point fingers when the results suck—diffusion of responsibility. Teams need leaders and leaders need to be accountable for results.
  - ilovecaching 8y ago
    > Believing that these things can easily be broken apart is an illusion. It works really well were I work. It's led to an extremely bottom up culture were engineers want to stay forever, because they feel like management isn't getting in their way or compromising technical decisions. > Teams need leadership, not three leaders. I'm not advocating for shared responsibility. What I'm advocating for is separating responsibility such that each person knows exactly what they are expected to deliver. The manager is expected to help his team perform and be happy. The TPM is responsible for delivering the product the users want. The tech team is responsibility for delivering a product as quickly as possible that is maintainable and bug free and meets the requirements set by the TPM. In your model, managers argue with the tech team, which causes people on the tech team to quit or become frustrated because the managers can't understand all of the details and still fulfill all their managerial duties. > It’s how product believes one thing and engineers believe another The role of the TPM is to make sure the tech team is building what the user wants. the TPM should be synchronizing with the user and the tech team, making sure this doesn't happen. It's their responsibility. > Teams need leaders and leaders need to be accountable for results. Agreed, teams need leaders who are focused on doing one thing, and one thing well. They should not be backseat architecting or leading the technical direction, unless they are the tech lead.
contingencies 8y ago
Niven's First Law of Writing: Writers who write for other writers should write letters. - Larry Niven, science fiction author (1989) The writer is that person who, embarking upon her task, does not know what to do. - Donald Barthelme Summary of advice from writers: Advice from writers is useful, and not only about naming. Writers have been at it for centuries; programming is merely decades old. Also, their advice is better written. And funnier. - Peter Hilton ... via http://github.com/globalcitizen/taoup http://github.com/globalcitizen/taoup
ilaksh 8y ago
This article is a great example of the biggest problem with software development management: they often fundamentally do not understand what software engineering entails. You can tell that he has caught on to a few aspects in terms of requiring editing and creativity and not being able to plan everything ahead. But really he doesn't understand the full extent of what programming involves. If he did he would definitely not carry the writer metaphor so far. A writer's output is natural language. Natural languages and programming languages are extremely different things. Prose does not have strong and brittle constraints on syntax and semantics that computer code does. Prose does not create real systems with many moving parts that must align and synchronize precisely. If you could get a creative writer to sit down and just design a new type of spacecraft engine by using his creative powers like a science fiction exercise, then the metaphor would work. But engineers have to make systems that are completely detailed, exacting, follow the laws of physics and harness them in intricate ways. Software engineers are often essentially doing research on new systems or new ways to combine systems. If at all possible, get an experienced programmer to act as a manager for programmers. A programmer would not describe it as simply writing.
- shanghaiaway 8y ago
  Software developers cannot sit down and design a new type of spacecraft engine.
  - lovich 8y ago
    That metaphor seemed like it was trying to show equivalent complexity, not that the jobs were interchangeable. Engineers on a spacecraft needing to know that at a certain temperature a material contracts which changes the friction coefficient it has and increases the heat generated until two moving parts melt, seems to have the same equivalence as knowing that at a certain rate of incoming messages your cache technology starts hitting a race condition where messages are double sent and now the downstream work is duplicated but not able to be correlated. All of this is different from ambiguous wording in natural language, where the ambiguity might even be the intent.
    - 8y ago
alexandercrohde 8y ago
I think it's a fine analogy. But the author doesn't go far enough. My thoughts here: https://blog.alexrohde.com/archives/432 https://blog.alexrohde.com/archives/432
sonnyblarney 8y ago
I prefer to think of them as carpenters. Every carpentry job requires solving a lot of problems every day, and using a variety of skills. But carpenters don't think of themselves as divas or creatives. In most cases, it's not nearly so romantic. There are objectives, roadmaps, client needs: it's just a job. Put on your hard hat, get your morning coffee and do it.
- millisecond 8y ago
  In former times, what we consider the trades were also romanticized. The masons and all that. I expect software to follow the same path and at an accelerated rate but that still gives us a while before we‘re fully normalized.
- 0x445442 8y ago
  I agree with everything you say but what bugs the living hell out of me is this profession's infatuation the new shiny. That along with the almost universal absence of any objective evidence that the new shiny will positively effect the project's bottom line.
teunispeters 8y ago
I have found that a lot of the skills to do with writing effectively, professionally and reliably also apply to writing (and maintaining) software. It's not to say they're the same discipline, but they're closer than - say - electronics engineering. But then a lot of disciplines are also assisted by having more writing skills as well.
0x445442 8y ago
Publisher(9am): Time for the morning scrum... Author: Yesterday I worked on a few paragraphs where the antagonist was just about ready to reveal to the protagonist his knowledge of the protagonist's long lost brother. But I'm blocked on the historical research about Vietnam POW camps. Hopefully, if my research assistant can run that down soon I can move that paragraph from the unblocked column back to in progress. In the mean time I'm pulling in the foot chase scene "story" but at this time I think both these "stories" will carry over to next sprint. Publisher: Hmmm, that's going to negatively affect your velocity.

97 points by ohjeez 8y ago

I do wonder how a TV show runner of some experience would handle a software production. There are a lot of moving parts that are not unlike what they deal with.

21 8y ago
There is no technical debt in TV production. That alone changes many things. You don't need to care how you arrived at the result or how "maintainable" it is.
- smackay 8y ago
  I thought that "the ship that made the Kessel Run in less than 12 parsecs." was the very definition of tehnical debt - which took 40 years to finally resolve. https://www.forbes.com/sites/jvchamary/2018/05/30/solo-star-wars-story-kessel-run-12-parsecs/ https://www.forbes.com/sites/jvchamary/2018/05/30/solo-star-...
- AnimalMuppet 8y ago
  Plot debt? I could actually see that describing some shows...
  - XorNot 8y ago
    The Stargate SG-1 writers regretted the "3 shots from a zat-gun disintegrates" thing, and had zat guns only ever hit stuff twice for the rest of the show after they realized the mistake they'd made. The problem was introduced to solve a plot issue in one episode - they needed a way for the team to get rid of the bodies they were leaving behind on a spaceship in one episode.
  - delecti 8y ago
    But plenty of other franchises just ignore things in the past as though they never happened, even up to and including characters.
- protomyth 8y ago
  I'm not sure that quite right. You do need to make sure it is maintainable because (at least in the US), they needed multiple seasons to reach a mark that would allow syndication.
  - lbriner 8y ago
    I think 21 is talking about the technical side of production e.g. hacking some weird sound effect - doesn't necessarily matter if it was hard, once it's recorded and produced, it's done. If you had to have someone holding up a part of the set, as long as it worked, it doesn't need to be maintained. What you are talking about is maintenance of the storyline, which in some ways is probably more consistent with what us Devs talk about with technical debt. That said, there are plenty of plot holes in many TV shows and I still watch them!
- callmeal 8y ago
  There is. It's just called continuity errors, or retroactive continuity. Not something that you can easily fix given the type of industry.
- mrob 8y ago
  Interlacing is technical debt. It looks bad and there's no longer any need for it, but it's still included in currently supported standards.
- walshemj 8y ago
  There is in production you start out with x pages of script and have 7 days to shoot it. Listen to and commentary with directors and actors they will often refer to getting the day done i.e. they shot the required number of pages and having to cut stuff or not be able to do some cool shot they wanted.

thinkingkong 8y ago

No youre managing a team of software engineers, one skill they have is writing. The product isnt the text. The product is the entire system designed to keep the text alive, functional, reasonably error free all in a relatively unpredictable environment. We definitely need to keep considering how other professions manage the unpredictable nature of their work so we can learn. Im just not sure this narrative suits that goal.

slededit 8y ago
The uncomfortable fact is other professions treat their employees like cogs (hiring booms then mass layoffs), or their customers like crap (ever wait an hour for your set time appointment at the doctor?). The determining factor is really the price of the professional. Software development is in a real interesting situation as its transitioning from a low status job to a high status one. As this progresses you'll see more and more "the customer is always wrong" style blog posts. They are already pretty common already.
- harlanji 8y ago
  What’s your basis for determing status? In my experience it massively elevated my status 15 years ago thru now, where it seems to have no effect and perhaps anchor me away from higher level jobs given the value of the output and scarcity of 10x engineers. I’m happy enough as a simple IC if they pay and treat me well, but that’s not been the case in 5+ years which has me in retirement from the field.
  - marktangotango 8y ago
    You’re saying there’s less status now than 15 years ago and you’re retired now? Can you talk about your experience, very interesting!
  - slededit 8y ago
    Status normally follows money (with enough gestation time). For the simple reason to get money you need to convince someone who already has it to give it to you. The inverse is also true, while a Noble title will get you a good spot at a traditional restaurant in London - for the most part nobody cares now that they don't employ half the village.

GoToRO 8y ago

You should not manage anything unless you yourself did that job successfully for 10 years.

samatman 8y ago
Best not build anything that didn't exist ten years ago then.
- corpMaverick 8y ago
  Think of it as: "Don't manage software engineers unless you were a software engineer for X years"
vbuwivbiu 8y ago
put another way, the best managers came from the shop floor

ilovecaching 8y ago

Managers shouldn't be writing code or architecting at all. A manager's job is to manage people or a product. If it's people, she should be completely focused on unblocking the engineers and keeping them out of meetings. If it's the product, she should be completely focused on gathering the requirements and constraints and communicating with the customer and getting estimates from the engineers. The architecture and implementation is a hidden detail for a manager. Either the team lead, architect, or team as a whole should design and move on the code.

poof131 8y ago
The problem is the architecture is intertwined with the product is intertwined with the people. Believing that these things can easily be broken apart is an illusion. It’s how product believes one thing and engineers believe another, resulting in quick hacks, missed deadlines, and a mediocre product, if it’s released at all. Meanwhile the manager is a “people person”. Teams need leadership, not three leaders. Dev managers should be able to understand the architecture, and the product, and the team. Product advises on the direction. Tech leads argue for the implementation. But the dev manager needs to bring these things together and provide direction. Otherwise all three people will just point fingers when the results suck—diffusion of responsibility. Teams need leaders and leaders need to be accountable for results.
- ilovecaching 8y ago
  > Believing that these things can easily be broken apart is an illusion. It works really well were I work. It's led to an extremely bottom up culture were engineers want to stay forever, because they feel like management isn't getting in their way or compromising technical decisions. > Teams need leadership, not three leaders. I'm not advocating for shared responsibility. What I'm advocating for is separating responsibility such that each person knows exactly what they are expected to deliver. The manager is expected to help his team perform and be happy. The TPM is responsible for delivering the product the users want. The tech team is responsibility for delivering a product as quickly as possible that is maintainable and bug free and meets the requirements set by the TPM. In your model, managers argue with the tech team, which causes people on the tech team to quit or become frustrated because the managers can't understand all of the details and still fulfill all their managerial duties. > It’s how product believes one thing and engineers believe another The role of the TPM is to make sure the tech team is building what the user wants. the TPM should be synchronizing with the user and the tech team, making sure this doesn't happen. It's their responsibility. > Teams need leaders and leaders need to be accountable for results. Agreed, teams need leaders who are focused on doing one thing, and one thing well. They should not be backseat architecting or leading the technical direction, unless they are the tech lead.

contingencies 8y ago

Niven's First Law of Writing: Writers who write for other writers should write letters. - Larry Niven, science fiction author (1989) The writer is that person who, embarking upon her task, does not know what to do. - Donald Barthelme Summary of advice from writers: Advice from writers is useful, and not only about naming. Writers have been at it for centuries; programming is merely decades old. Also, their advice is better written. And funnier. - Peter Hilton ... via http://github.com/globalcitizen/taoup http://github.com/globalcitizen/taoup

ilaksh 8y ago

This article is a great example of the biggest problem with software development management: they often fundamentally do not understand what software engineering entails. You can tell that he has caught on to a few aspects in terms of requiring editing and creativity and not being able to plan everything ahead. But really he doesn't understand the full extent of what programming involves. If he did he would definitely not carry the writer metaphor so far. A writer's output is natural language. Natural languages and programming languages are extremely different things. Prose does not have strong and brittle constraints on syntax and semantics that computer code does. Prose does not create real systems with many moving parts that must align and synchronize precisely. If you could get a creative writer to sit down and just design a new type of spacecraft engine by using his creative powers like a science fiction exercise, then the metaphor would work. But engineers have to make systems that are completely detailed, exacting, follow the laws of physics and harness them in intricate ways. Software engineers are often essentially doing research on new systems or new ways to combine systems. If at all possible, get an experienced programmer to act as a manager for programmers. A programmer would not describe it as simply writing.

shanghaiaway 8y ago
Software developers cannot sit down and design a new type of spacecraft engine.
- lovich 8y ago
  That metaphor seemed like it was trying to show equivalent complexity, not that the jobs were interchangeable. Engineers on a spacecraft needing to know that at a certain temperature a material contracts which changes the friction coefficient it has and increases the heat generated until two moving parts melt, seems to have the same equivalence as knowing that at a certain rate of incoming messages your cache technology starts hitting a race condition where messages are double sent and now the downstream work is duplicated but not able to be correlated. All of this is different from ambiguous wording in natural language, where the ambiguity might even be the intent.
  - 8y ago

alexandercrohde 8y ago

I think it's a fine analogy. But the author doesn't go far enough. My thoughts here: https://blog.alexrohde.com/archives/432 https://blog.alexrohde.com/archives/432

sonnyblarney 8y ago

I prefer to think of them as carpenters. Every carpentry job requires solving a lot of problems every day, and using a variety of skills. But carpenters don't think of themselves as divas or creatives. In most cases, it's not nearly so romantic. There are objectives, roadmaps, client needs: it's just a job. Put on your hard hat, get your morning coffee and do it.

millisecond 8y ago
In former times, what we consider the trades were also romanticized. The masons and all that. I expect software to follow the same path and at an accelerated rate but that still gives us a while before we‘re fully normalized.
0x445442 8y ago
I agree with everything you say but what bugs the living hell out of me is this profession's infatuation the new shiny. That along with the almost universal absence of any objective evidence that the new shiny will positively effect the project's bottom line.

teunispeters 8y ago

I have found that a lot of the skills to do with writing effectively, professionally and reliably also apply to writing (and maintaining) software. It's not to say they're the same discipline, but they're closer than - say - electronics engineering. But then a lot of disciplines are also assisted by having more writing skills as well.

0x445442 8y ago

Publisher(9am): Time for the morning scrum... Author: Yesterday I worked on a few paragraphs where the antagonist was just about ready to reveal to the protagonist his knowledge of the protagonist's long lost brother. But I'm blocked on the historical research about Vietnam POW camps. Hopefully, if my research assistant can run that down soon I can move that paragraph from the unblocked column back to in progress. In the mean time I'm pulling in the foot chase scene "story" but at this time I think both these "stories" will carry over to next sprint. Publisher: Hmmm, that's going to negatively affect your velocity.