Hacker News Reader

Comment by throwitaway222 | Hacker News Reader

Most of those processes, tps reports, jira and other annoyances is because in a programming environment you literally have too many cooks in the kitchen. Every programmer can create the system from scratch, so to prevent them from doing so, we have to make it super annoying. Basically it's a people problem.

The most incredible work happens in the first 3 months by a lone developer green-fielding with no boundaries. The only way for that codebase to move forward after getting a second/third/fourth person is to increase process, introduce pain and bloodshed.

View on HN

“ The interaction of two programmers looking over a program that either one of them could have worked out is entirely different from the interaction of two programmers working on separate parts of a whole which is too great for either one to produce.

The difference lies in the way conflicting demands are resolved. In the first case, resolution of conflict is the thinking process of one person—aided perhaps by other people, but always under that one person's control. In the second case, conflicting technical demands are translated into potential interpersonal conflicts, and a social mechanism must be formed to resolve them."

- 'The Psychology of Computer Programming', Gerald Weinberg

Yes, pair programming is fine, but even just two folks working on something literally too complex to individually grasp necessitates committee work, paperwork, and all the rest.

Jerry Weinberg wasn't writing about pair programming. He was writing about group work and where the problems lie in the interactions.

I never said he was? I'm writing it out, not him.

Peopleware is also a good book on the same general topic.

https://en.m.wikipedia.org/wiki/Peopleware:_Productive_Proje...

I agree with some of this, and that green field productivity can be impressive... but I work a lot on very large systems that would simply be impossible for a single person to create in a reasonable amount of time. Even though I am sure I could create every system I need to solve the problem, it would take decades. I like working on small subsets of the overall problem, that is not the issue. I even like working on teams!

The issue is the things outside of solving the actual problem.

Yeah. Except I need you to work on a legacy system from which we have only the source. Or on a project that you won't be able to handle alone for a time short enough for the product to keep relevance. Or any other big projects... How do you deal with this ?

Let's not speak about the need to sync with other team, external partner, showing progress to the management, getting the information from all those peoples, getting ready with side department like compliance, marketing or whatever is needed to make the work relevant.

So no, it's not to prevent anyone from starting a project from scratch. It's to make sure that the project will come to fruition, useful and if possible reach its goal.

And honestly, a good manager/tool will help deal with that. Now... there are a lot of them that create a kafkaesque hell.

>Every programmer can create the system from scratch

Are you sure about that? Can one coder recreate Facebook's(for example) complete architecture from scratch? Unless I misunderstood you, I'd imagine there is just too much domain specific knowledge in all the components to do so even in a single lifetime.

>The most incredible work happens in the first 3 months by a lone developer green-fielding with no boundaries.

The graveyard of github projects with the mentality of "I could recreate that in a weekend" seems to somewhat contradict this line of thinking.

I think the point was that code is not inherently limited in the same way as other kinds of engineering.

If you tell someone to engineer you the arm for positioning a desk lamp, they aren't going to give you the hydraulic arm for a 12-ton backhoe without anyone noticing. There are physical and cost constraints that will prevent that from happening pretty quickly.

In software, there are no comparable constraints. A few MiB of software contains extraordinary amounts of complexity but could easily fly under the radar and ship, and then become a maintenance nightmare.

As we are not cooks and git is not a kitchen, one must take issue with your “literally.” Be wary of ever qualifying an idiom that way, as they are so often prepackaged metaphors, as here!

But your point is otherwise an insight. Coordination is a (the?) salient challenge and opportunity in all sorts of scaled industrial production. Git itself is fundamentally a coordination tool. Small optimizations can enable OOM jumps in scale.

That is to say: managers do have a purpose, though perhaps only the platonic, spherical manager fulfills it adequately.

Hum... When the computer we command run into that kind of problem, it's almost universally better to fix incompatibilities post-fact with an exceptional process than it's to avoid creating them.

But somehow, people are never allowed to do that.

But rest assured that if you need a heavy process just to coordinate a handful of developers, you have a bad architecture. Even if you do pessimistic preemptive coordination.

Yeah, his "very large system" is just that way because it is modelled after the organization/team structure. Unavoidable.

95% of the programmers do not know hackernews. They finished their degree in Java and thats what they do their entire career. Noway they can rebuild an entire facebook. Not everyone is an all stack hacker developer, infra structure specialist like many folks here

> Every programmer can create the system from scratch

Every programmer believes he can create the system from scratch

FTFY

I'm one of the "every", too. If I knew how hard writing a C++ compiler from scratch would be, I'd have never tried it.

Which parts did you find blockingly complex, or was it more the interaction of so many language features?

The operator overloading aspect of C++ , IMO, allows for obtusely opaque domain specific languages where the actions and side effects of an operation aren't immediately clear to someone getting to know a new codebase. It's almost as bad as the enterprisy nightmare of polymorphic objects and interfaces that can be found in JAVA where tracing code execution can pierce through hundreds of source files just to figure out the effects of one line of code.

I found C++ code to be simply difficult to read. When code "in the wild" didn't compile with my compiler, it would often take a long time to find the problem and understand what went wrong.

Probably the most time consuming and frustrating aspect was trying to be compatible with Microsoft's compiler. Much of the way it worked was quirky and ad-hoc, and took a lot of time to figure out.

Be sure to use a cover sheet for the tps reports.

Didn't you get the memo? Lumbergh requires cover sheets for all tps reports now. We …lost some people this week, and everyone is playing catch-up…

Reply on news.ycombinator.com