5 ms·

> Crush chaos and entropy through decoupled design, through APIs that are simple and affordant, crush chaos by making it everyone's job to make the whole simple

> Crush chaos and entropy through decoupled design, through APIs that are simple and affordant, crush chaos by making it everyone's job to make the whole simpler. The author and yourself are talking about entirely different things. Decoupled design and APIs won't help you manage tens or hundreds of developers, it won't help you guide a team towards the same goal. It also won't help as a communication buffer between all the different areas/developers. This is where the PM comes in. The author's thinking _above_ the code level. With his 105 developers, even if they're all producing amazing software, you still need to setup a comm. and product guidance machinery [0]. > Don't add people who cannot code and hope they will improve things. I'm sorry to nitpick this specific phrase from your comment but a lot of people has expressed this "people who can't add code won't add value" thinking. The reality is that the author never mentioned bringing non developers to do the job (but from the comments on this thread it seems this has been a recurring theme for many people). Speaking from my own experience, the best PMs almost always started as developers. You don't have to bring an outsider with no technical knowledge, you can just find the right team member who's already starting to take over this and then make it "official". This prevailing "but he can't code" ideation shows that most people's experiences with PMs has been bad and us developers bring it up because code is where we excel, it's what we can understand and fix. The reality is that if the PM failed to do his job correctly it was most likely not related to his coding skills (but again, we frame it in terms of what we understand, code). [0] Keep in mind that this does not mean you need to add more layers to your company structure. Empowering current employees seems to be working just fine for companies like Valve and GitHub.

lifeisstillgood 13y ago
An email list, and a hierarchy of committers through whom changes bubble up will help a lot more than any number of project managers - list(s) can set priorities, explain rationales and keep everyone informed. And committer hierarchies work really well for splitting teams up along code lines Yes ex-developers promoted into positions in that committeer Hierarchy will do less development and more "steering". But they know that - as do editors at newspapers. Junio Hamano even writes interesting notes on it. But again only a fool hires an illiterate for that position. And only a fool creates a seperate parallel organisation to keep an eye on / communicate with, the software teams. Once upon a time there were few developers and software was a strategic project to reduce costs. Now it is everywhere - like literacy, it infects everything with outsized leverage. And you cannot maintain two parallel organisations - one that does the business and one that then goes off and imements it. It's insanity. Again I like to use the newspaper analogy - it makes it clear where we need to go. It is probably true that project managers are needed for an organisation that is illiterate at the board level, in the sales force and in the marketing dept. But companies like GitHub are not showing us how to overlay old illiterate management styles on company with mostly developers - They are showing how to run a company when everyone in it can read and write. Honestly I do not know how companies prior to printing press organised themselves - but I bet it was different after literacy was widespread - and I bet the old companies did not survive the new
- fbuilesv 13y ago
  It's interesting that you mention Mr. Hamano since I was thinking about how Git or Linux works while writing my comment. I think we both agree that having someone who steers the ship is then fine, call it PM, higher-ups in the commit hierarchy, etc. The Linux kernel has people like like GregKH or even Linus who I'd call PMs, their main jobs are communication and reviews, not writing code. You don't need a parallel organization for this but you need to create some structure to support a big number of people working in different projects under the same umbrella. I think your comments are targeted more towards having someone "illiterate" steering the ship and that is a whole different thing that's not mentioned anywhere in the article. I won't argue anything in this regard since I think it's really dependent on the person and not the abstract role, but it seems (judging from the other comments in the thread) that most people have been burned by people with no knowledge giving direct orders on how to proceed.
  - lifeisstillgood 13y ago
    so we have highly skilled technical practitioners, intimately familiar with the codebase, such as that found in the "commit hierarchy" of Linux/git. i cannot equate them with PRoject/product/programme managers, especially not with the overriding focus on planned dates. We have a industrial management system based on the physical needs of large scale factory style production. And it is ignoring the management styles of the creAtive industries - where there is always a commit hierarchy and this not in it are ignored or supply finan e
    - fbuilesv 13y ago
      I like your last paragraph. I don't know what the future will bring but I totally agree that today's world works mostly under an old school, factory-style management regime, which is not efficient in industries like ours. Having said that, I personally still see value in some of those old practices. As [lukatmyshu] mentioned in this thread: Think of [PMs] as oil in an engine. The best ones know how to communicate extremely well, are paragons of organization, and know how to facilitate decision making. Instead of getting in the way they make life easier for everybody. I do understand that's not the typical experience for most people in our line of work.

lifeisstillgood 13y ago

An email list, and a hierarchy of committers through whom changes bubble up will help a lot more than any number of project managers - list(s) can set priorities, explain rationales and keep everyone informed. And committer hierarchies work really well for splitting teams up along code lines Yes ex-developers promoted into positions in that committeer Hierarchy will do less development and more "steering". But they know that - as do editors at newspapers. Junio Hamano even writes interesting notes on it. But again only a fool hires an illiterate for that position. And only a fool creates a seperate parallel organisation to keep an eye on / communicate with, the software teams. Once upon a time there were few developers and software was a strategic project to reduce costs. Now it is everywhere - like literacy, it infects everything with outsized leverage. And you cannot maintain two parallel organisations - one that does the business and one that then goes off and imements it. It's insanity. Again I like to use the newspaper analogy - it makes it clear where we need to go. It is probably true that project managers are needed for an organisation that is illiterate at the board level, in the sales force and in the marketing dept. But companies like GitHub are not showing us how to overlay old illiterate management styles on company with mostly developers - They are showing how to run a company when everyone in it can read and write. Honestly I do not know how companies prior to printing press organised themselves - but I bet it was different after literacy was widespread - and I bet the old companies did not survive the new

fbuilesv 13y ago
It's interesting that you mention Mr. Hamano since I was thinking about how Git or Linux works while writing my comment. I think we both agree that having someone who steers the ship is then fine, call it PM, higher-ups in the commit hierarchy, etc. The Linux kernel has people like like GregKH or even Linus who I'd call PMs, their main jobs are communication and reviews, not writing code. You don't need a parallel organization for this but you need to create some structure to support a big number of people working in different projects under the same umbrella. I think your comments are targeted more towards having someone "illiterate" steering the ship and that is a whole different thing that's not mentioned anywhere in the article. I won't argue anything in this regard since I think it's really dependent on the person and not the abstract role, but it seems (judging from the other comments in the thread) that most people have been burned by people with no knowledge giving direct orders on how to proceed.
- lifeisstillgood 13y ago
  so we have highly skilled technical practitioners, intimately familiar with the codebase, such as that found in the "commit hierarchy" of Linux/git. i cannot equate them with PRoject/product/programme managers, especially not with the overriding focus on planned dates. We have a industrial management system based on the physical needs of large scale factory style production. And it is ignoring the management styles of the creAtive industries - where there is always a commit hierarchy and this not in it are ignored or supply finan e
  - fbuilesv 13y ago
    I like your last paragraph. I don't know what the future will bring but I totally agree that today's world works mostly under an old school, factory-style management regime, which is not efficient in industries like ours. Having said that, I personally still see value in some of those old practices. As [lukatmyshu] mentioned in this thread: Think of [PMs] as oil in an engine. The best ones know how to communicate extremely well, are paragons of organization, and know how to facilitate decision making. Instead of getting in the way they make life easier for everybody. I do understand that's not the typical experience for most people in our line of work.