5 ms·

"Coding" as a primitive activity has become subservient to the goals of coding. What are the goals of coding? - Make money - Solve a problem In any non trivial

"Coding" as a primitive activity has become subservient to the goals of coding. What are the goals of coding? - Make money - Solve a problem In any non trivial pursuit along those two vectors, complexity typically creeps in because more people are involved. Since more people are involved, this becomes a human organization. A human organization is not concerned with only the primitive activity to be done, but also what are the right approaches, methods, measurement, priorities, politics, scaling, learning, etc. Therefore, one cannot just be doing the primitive activity and ignore all of these higher level goals. I am going to use an analogy: let's say coding is brick layering + painting + wall building + carpet + etc. and we are going to build a building. The worker says he just "wants to do work" but if we let her do that the building would be a disaster, unless you are just building a dog house. In which case the risks are low and a single person can do the work. At the beginning (startup), one can just "do coding" because the problem is ill defined and an organization has not been established to manage the higher level work. I wonder to what extent this mentality of "just want to code" is related to the (stereotypical) aversion of the developer as anti-social and introvert.

treerock 12y ago
To use your example the workers can generally just turn up and work. The bricklayer doesn't have to be concerned with the carpets. The joiner doesn't have to worry about zoning restriction. I'm curious if software development (in large organisations) will ever reach that level of specialization, where a coder will be able to 'just code', because others workers will be employed to handle everything else.
- sanderjd 12y ago
  I think this actually does happen to some extent. The larger an organization and longer it's been around, the more likely it is that some people on the team spend some or all of their time working on tooling for the rest of the team. When done right, this means that most of the team members just need to follow some well documented or automated process to get fully up and running, and never need to really think about all the moving parts.
- hyperliner 12y ago
  Let's push this: Before any carpet or brick is placed, a foundation needs to be poured, but before that, a hole must be made, but before that, a machine must be purchased. Then, someone is going to ask: "how big should the hole be?" And the answer would be, "Whatever, I am just going to put these bricks on it." and the whole thing just falls apart because nobody can just lay bricks.
- codingdave 12y ago
  It does get there already, in some places. I've been in large organizations that have a build person, a source control person, etc. They take care of it all, so the coders can "just code". Those environments have totally sucked, because to pigeonhole people into those roles in the first place requires a non-flexible, non-creative culture. There is a proper balance to everything, but few organizations succeed in finding it.
  - jimmaswell 12y ago
    >a source control person, etc. They take care of it all, so the coders can "just code". What do you mean a source control person, just someone who manages the source control when it goes wrong? The programmers are still doing the committing, pushing, pulling, branching themselves
    - codingdave 12y ago
      Committing yes, everything else no. The source person managed the servers, branched and merged as necessary, and oversaw the build processes to be sure we had good dev, test, UA, and prod deployments at any given time. She hated that job, BTW. :)
  - sashahart 12y ago
    I was fascinated with Brooks' proposed "head surgeon" solution to the coordination problem for large projects - basically (and forgive me if my summary butchers this a bit), instead of having 1000 programmers on one repo arguing, you have a smaller number of vertically-integrated teams with a "head surgeon" at the top of each, and it is the head surgeons who have to coordinate. (Needless to say, the "head surgeon" has to know how to code pretty well and be significantly involved in the project rather than hovering at 20,000 feet...) I guess most people would only like to be the "head surgeon" because of the implied status (and not really knowing what it is like to be e.g. Linus Torvalds). But personally, I wouldn't mind doing a specialized job like the tools programmer or language lawyer because these are still interesting jobs allowing good forward progress to be made. If the load of tedious work like build systems is too much, and the best we can do is either load-balance it across the team or dump it on some schmuck, maybe that just means we should try harder to break up projects into smaller units so that process doesn't completely dominate them.
- mobiuscog 12y ago
  This is a great point. How many 'full stack' builders do you find ? They obviously exist, but would generally fall under the 'handyman' moniker, which is maybe equivalent to a 'hacker' ? Unfortunately, the world of software development seems to have been pushed away from specialisation and each person knowing certian topics well, into 'everyone is just a resource - anyone can code' mindset.
Dewie 12y ago
> I wonder to what extent this mentality of "just want to code" is related to the (stereotypical) aversion of the developer as anti-social and introvert. Being anti-social is not really a developer stereotype. Being a pedant is, though. ;)
sashahart 12y ago
Fred Brooks wrote about the organizational complexity around larger projects in one of those books many cite but nobody reads, "The Mythical Man-Month." For example, he highlighted time spent on coordination among the n parties required to meet production targets. As you add more people, you might need anything up to n*n lines of communication; in other words, you have possibly an exponential growth in meetings. So he discussed some things IBM had tried, and some possible ways to mitigate that growth in coordination events. Bear in mind that Brooks was mostly talking about his work on OS/360 at IBM. OS/360 wasn't a doghouse. IBM wasn't a small organization. His interest in reducing meetings wasn't caused by being anti-social, or having some antipathy toward management or PMs. It was caused by an interest in shipping products on time, which programmers are held accountable to do. (Consider that the next time you feel like accusing developers of being anti-social for wanting to get work done.) Of course Brooks was discussing an idealized version of the problem, aimed at the essentials. But reality includes a lot of kinds of organizational bloat which really aren't necessary to software production goals, they're just hard to avoid in large organizations. Say you are building a big house, and you can't wait for one person to finish it by herself, so you have to hire and manage and pay n workers and keep the pipelines full; so you need funding up front; long story short, you make a construction company. Everything you're doing to scale up the organization encourages "leaks." With more funding, more self-interested contention over where it goes, more fighting over who got it for the company, etc. With more hiring, more competition among hiring managers to build empires underneath themselves. With more management structure, more regulation and enforcement to justify and expand the management structure. With more decisions, more attempts to influence or take credit for those decisions, and endless arguments down to useless bikeshedding. ('what are the right approaches, methods ...') With more people, more internal social dynamics that become ends in themselves and change how the organization is steered and how resources are allocated in ways that often are actively harmful to the organization's stated goals. Now relative to these real-world phenomena, does it make sense for software-producing organizations to see their chief risk as letting the programmers who know about code write the requested code as they know best how to do? Or to solve that "problem" with micromanagement, creating more and more barriers and distractions (and morale drains, and reasons to leave) for programmers?

treerock 12y ago

To use your example the workers can generally just turn up and work. The bricklayer doesn't have to be concerned with the carpets. The joiner doesn't have to worry about zoning restriction. I'm curious if software development (in large organisations) will ever reach that level of specialization, where a coder will be able to 'just code', because others workers will be employed to handle everything else.

sanderjd 12y ago
I think this actually does happen to some extent. The larger an organization and longer it's been around, the more likely it is that some people on the team spend some or all of their time working on tooling for the rest of the team. When done right, this means that most of the team members just need to follow some well documented or automated process to get fully up and running, and never need to really think about all the moving parts.
hyperliner 12y ago
Let's push this: Before any carpet or brick is placed, a foundation needs to be poured, but before that, a hole must be made, but before that, a machine must be purchased. Then, someone is going to ask: "how big should the hole be?" And the answer would be, "Whatever, I am just going to put these bricks on it." and the whole thing just falls apart because nobody can just lay bricks.
codingdave 12y ago
It does get there already, in some places. I've been in large organizations that have a build person, a source control person, etc. They take care of it all, so the coders can "just code". Those environments have totally sucked, because to pigeonhole people into those roles in the first place requires a non-flexible, non-creative culture. There is a proper balance to everything, but few organizations succeed in finding it.
- jimmaswell 12y ago
  >a source control person, etc. They take care of it all, so the coders can "just code". What do you mean a source control person, just someone who manages the source control when it goes wrong? The programmers are still doing the committing, pushing, pulling, branching themselves
  - codingdave 12y ago
    Committing yes, everything else no. The source person managed the servers, branched and merged as necessary, and oversaw the build processes to be sure we had good dev, test, UA, and prod deployments at any given time. She hated that job, BTW. :)
- sashahart 12y ago
  I was fascinated with Brooks' proposed "head surgeon" solution to the coordination problem for large projects - basically (and forgive me if my summary butchers this a bit), instead of having 1000 programmers on one repo arguing, you have a smaller number of vertically-integrated teams with a "head surgeon" at the top of each, and it is the head surgeons who have to coordinate. (Needless to say, the "head surgeon" has to know how to code pretty well and be significantly involved in the project rather than hovering at 20,000 feet...) I guess most people would only like to be the "head surgeon" because of the implied status (and not really knowing what it is like to be e.g. Linus Torvalds). But personally, I wouldn't mind doing a specialized job like the tools programmer or language lawyer because these are still interesting jobs allowing good forward progress to be made. If the load of tedious work like build systems is too much, and the best we can do is either load-balance it across the team or dump it on some schmuck, maybe that just means we should try harder to break up projects into smaller units so that process doesn't completely dominate them.
mobiuscog 12y ago
This is a great point. How many 'full stack' builders do you find ? They obviously exist, but would generally fall under the 'handyman' moniker, which is maybe equivalent to a 'hacker' ? Unfortunately, the world of software development seems to have been pushed away from specialisation and each person knowing certian topics well, into 'everyone is just a resource - anyone can code' mindset.

Dewie 12y ago

> I wonder to what extent this mentality of "just want to code" is related to the (stereotypical) aversion of the developer as anti-social and introvert. Being anti-social is not really a developer stereotype. Being a pedant is, though. ;)

sashahart 12y ago

Fred Brooks wrote about the organizational complexity around larger projects in one of those books many cite but nobody reads, "The Mythical Man-Month." For example, he highlighted time spent on coordination among the n parties required to meet production targets. As you add more people, you might need anything up to n*n lines of communication; in other words, you have possibly an exponential growth in meetings. So he discussed some things IBM had tried, and some possible ways to mitigate that growth in coordination events. Bear in mind that Brooks was mostly talking about his work on OS/360 at IBM. OS/360 wasn't a doghouse. IBM wasn't a small organization. His interest in reducing meetings wasn't caused by being anti-social, or having some antipathy toward management or PMs. It was caused by an interest in shipping products on time, which programmers are held accountable to do. (Consider that the next time you feel like accusing developers of being anti-social for wanting to get work done.) Of course Brooks was discussing an idealized version of the problem, aimed at the essentials. But reality includes a lot of kinds of organizational bloat which really aren't necessary to software production goals, they're just hard to avoid in large organizations. Say you are building a big house, and you can't wait for one person to finish it by herself, so you have to hire and manage and pay n workers and keep the pipelines full; so you need funding up front; long story short, you make a construction company. Everything you're doing to scale up the organization encourages "leaks." With more funding, more self-interested contention over where it goes, more fighting over who got it for the company, etc. With more hiring, more competition among hiring managers to build empires underneath themselves. With more management structure, more regulation and enforcement to justify and expand the management structure. With more decisions, more attempts to influence or take credit for those decisions, and endless arguments down to useless bikeshedding. ('what are the right approaches, methods ...') With more people, more internal social dynamics that become ends in themselves and change how the organization is steered and how resources are allocated in ways that often are actively harmful to the organization's stated goals. Now relative to these real-world phenomena, does it make sense for software-producing organizations to see their chief risk as letting the programmers who know about code write the requested code as they know best how to do? Or to solve that "problem" with micromanagement, creating more and more barriers and distractions (and morale drains, and reasons to leave) for programmers?