As an introvert who had to push himself to become one of those "people-oriented idiots", the reality you have to recognize is that software is ultimately about people. It is not written in a vacuum to make computers happy, there's generally a human (or a bunch of them) at the other end who will be deriving value from it. Working competently to solve the wrong problem is not how successful software is written. And the chances of solving the right problem without talking to people are, frankly, slim.
There will not be a revolution that eschews the people aspects, the industry has evolved (yes, the opposite of devolved) beyond that. Walking around calling people idiots and being generally angry is not going to win you any trophies either.
Externally, with customers, sure. I agree that we are ultimately doing this for people.
But internally, I do not think that having requirements filter through ever-growing and increasingly specialized teams is a net positive. Early in my career I worked directly with stakeholders and shareholders, and I was empowered to build and deploy things that solved their issues, often from scratch. And I did exactly that, and it felt great!
When I quit, I worked mainly with my product manager, who in turn interfaced with god knows how many people, and only receive tasks after they were parceled out and dispatched to me via JIRA, where I could only see a small part of the picture and I was held to arbitrary metrics on performance.
Things were much better when we programmers were a weird and mysterious rainmakers that the higher-ups didn't understand. This newer, more gentrified profession is ... a lot less enjoyable to work in.
> There needs to be a revolution that returns programming back into the hands of solitary nerds working on sheer competence.
sounds and awful lot like the problematic example you described:
> and only receive tasks after they were parceled out and dispatched to me via JIRA, where I could only see a small part of the picture and I was held to arbitrary metrics on performance.
IME, only the simplest technical projects, with completely pre-defined inputs and outputs can be successfully executed by "solitary nerds working on sheer competence", and that's because all the messy work of defining the requirements and managing the uncertainty has been done by someone else.
For even moderately complex projects, you need to work with a team, and being "nice" - which just means not being a jerk - is pretty essential for working even with an all technical team.
The Pirate Bay under Peter Sunde's management comes to mind as an example of a small team working mostly autonomously to create a large project. Though I think they worked as such to minimize exposure to legal liability and to keep their legal opponents guessing and fumbling about as they tried their case in court. But they (and a lot of other underground sites) are exemplars in 'solitary nerds working on sheer competence'
> The Pirate Bay
> But they (and a lot of other underground sites) are exemplars in 'solitary nerds working on sheer competence'
Those are highly exceptional cases with specific motivations for their organizational structure (evading the law). They are also a sort of projects that have very few competitors due to their questionable legality, and therefore the organizational structure's effectiveness can't really be compared against regular "licit" software projects.
> For even moderately complex projects, you need to work with a team, and being "nice" - which just means not being a jerk - is pretty essential for working even with an all technical team.
Would you call Google a moderately complex project? Because Google is very much focused on individuals rather than teams. Sometimes individuals works together, but it isn't required and you can spend your entire career just working on your own separate problems.
Of course Google also has lots of people who are competent at organizing and talking to people, but having a ton of engineers you can give a well defined problem and they will build a great solution without any extra input is still great to have and you can use that to compose reliable solutions to huge problems. There is no reason work groups needs to be teams rather than individuals.
> Would you call Google a moderately complex project?
Yes... but Google is my employer of well over a decade, so I might be biased on the complexity of the problems worked on here.
> Because Google is very much focused on individuals rather than teams. Because Google is very much focused on individuals rather than teams. Sometimes individuals works together, but it isn't required and you can spend your entire career just working on your own separate problems.
This is untrue in nearly all of my experience at Google. I'm not sure where you are getting your information from, but it's a big company, so maybe there are some corners where that might be true, but it's far from the norm.
ICs at all levels are expected to do a lot of intra and inter-team communication and collaboration. You could limit your opportunities if you choose to silo yourself.
> having a ton of engineers you can give a well defined problem and they will build a great solution without any extra input
This is what interns and entry-level engineering hires do at Google, with the strong expectation that they move beyond working on unambiguous problems into tackling harder problems with more ambiguous and often conflicting requirements.
Have you worked at a team outside of Google? I don't think you understand what people mean when they talk about teamwork. Lets take a project you would give to one junior engineer at Google, at a typical large company they would give that to a team of 5 and then they would need to communicate and talk a lot with each other how to get that project done, all that communication disappears when you work like Google does.
> This is what interns and entry-level engineering hires do at Google, with the strong expectation that they move beyond working on unambiguous problems into tackling harder problems with more ambiguous and often conflicting requirements.
Right, they tackle problems on their own, that was my point. They are expected to figure out requirements etc, and ask the questions needed to be asked. That greatly reduces the amount of communication needed compared to the teamwork approach where you split this project up into 10 parts and those are done by different people who go and ask a lot of different questions that then needs to be communicated and then some things were missing so people have to go and ask more things etc.
Communicating with stakeholders and users is very different from communicating with teammates. First and foremost the quantity is much lower, so people who burn out quickly from social interactions can still manage. Lets say a person gets burned out on social interactions after 5 hours a week. That is enough for an hour of meetings a day and then individual work, more than enough to work as a senior engineer at Google (non manager), but that wouldn't be nearly enough to work at most places where you need to communicate a lot just to code.
> Lets take a project you would give to one junior engineer at Google, at a typical large company they would give that to a team of 5
This statement lacks any sort of basis for the 1:5 Google:Non-Google staffing ratio you are quoting. I'm not sure where you are getting it. Even though I work there, I don't think Google engineers are 5x as "effective" as a typical engineer at another large company, they just often deal with problems specific to Google's technology and scale.
If anything, large companies like Google can afford to staff their projects with a deeper bench than smaller companies - in part to mitigate burnout caused by being overworked, but also to maximize knowledge sharing and minimize knowledge silos. It's not a good thing if only the person who wrote a system understands how the system works.
> and then they would need to communicate and talk a lot with each other how to get that project done, all that communication disappears when you work like Google does.
That's not my experience at all at Google. It's the opposite: engineers at all levels communicate and talk a lot with each other to get a project done. In fact, we rely on these conversations heavily to validate our ideas and get constructively critical feedback on our approach. It's wired into the process, from design documents through to code reviews. Very often these can require F2F communications and even negotiations when engineer-time is a constrained resource. So I'm not sure what you mean by "work like Google does".
It sounds like you're burnt out on bad company/team culture then? I can assure you that there are still plenty of teams that operate similar to your early career experience. These tend to be in smaller companies. But even larger ones exist that offer team autonomy, participation in customer discovery, and sane management practices. You just have to be very careful about sussing out this info during the interview process.
I guess what I'm getting at is while there are plenty of shitty teams, I wouldn't say it's an indictment on the industry as a whole. After 20-ish years in it, I'm actually optimistic that things are improving as new companies shed more of the traditional command-and-control techniques.
Yes part of it is difference in organization side. And if I have to go back into the industry I am definitely seeking out a smaller org, as I have learned that larger companies aren't for me.
And to their credit, my last team was actually very good. Nice people, all very smart programmers. But the product was still a mess, and corporate's gotta corporate.
>more people need to care about the quality of the final output than whether or not the guy who wrote it is "a nice fellow".
GP is very clearly saying that software has to be written to satisfy customers. It is the process and the quality of outcome they have a problem with, not the focus.
The word solitary was used more than once, so I don't think it's a strawman. My point is the quality of the final output is going to be suspect if you take the "leave me alone and let me code" approach.
From the original comment alone one can't deduce it was about zero communication without some serious assumptions. Only a difference in communication structure.
That this invokes the kneejerk response of "well you need to communicate to make products" is arguably a bigger testament of what is wrong with tech. Including the incessant need to label everything with only the smallest details.
There will not be a revolution that eschews the people aspects, the industry has evolved (yes, the opposite of devolved) beyond that. Walking around calling people idiots and being generally angry is not going to win you any trophies either.