[magicalhippo]

> if you can’t read the code you Shldnt be working on it

I don't know this AW guy, but to me that's a huge red flag and a sign that a programmer hasn't worked on anything substantial. Ie non-trivial stuff that's maintained by a team over time.

Being able to read the code is irrelevant, as the comments should tell you why the code is doing what it's doing.

For example, yeah I trivially can see the code is doing a retry loop trying to create a file with the same name.

That looks like a bug, if you can't create the file with that name, you change the name in the retry loop.

But the comment will tell me this is due to certain virus scanners doing dumb stuff, so we might have to try the same name a few times.

Sure, good code will have few comments as most of it should be self-documenting through good structure and names of classes and variables. But in non-trivial code there will always be places where it is not obvious why the code does what it does.

[JonChesterfield]

Defining substantial as written by a team over a long period of time seems to be putting the value in the wrong place. Is the important thing what the software does, or that it took a lot of people a long time to write it?

[magicalhippo]

I didn't say long time to write it. I said maintained by a team over time.

Sure there might be some substantial software that was written as a one-off (ie not modified after release), but that's the minority by far.

[anonzzzies]

> a sign that a programmer hasn't worked on anything substantial

Maybe you want to check who he is?

[magicalhippo]

I meant I don't know as in I haven't actually worked with him.

Based on what I've seen before as well as the supplied code, I would be very skeptical to have him on my team.

[wood_spirit]

This is a bit of a tangent but it’s a thought experiment that I recently heard:

Data pipeline A is written and maintained by a team in a type safe language with extensive unit tests.

Data pipeline B be was written long ago by a scientist who has since left, in sql in a day.

Both compute the same dataset, but B gets the answer correct.

Which is the better pipeline, and why?

[magicalhippo]

Without more context or additional assumptions there's no good answer to that.

If you just care about today, then clearly B is better because it provides the correct result today.

Also, just because A is written in a type-safe language and has extensive unit tests doesn't in itself mean it's any less complex and undecipherable than B.

I can think of several takes, with different assumptions, leading to very different perspectives.

One take could be this:

Lets assume A has been written by a competent team, using good practices. Lets also assume the problem of incorrect answers in A has been known for some time and has been investigated a fair bit. That is, it's not just a trivial bug that's not been caught yet.

Since A doesn't work one could reasonably assume B is complex and difficult to understand, otherwise A's team should be able to find their error based on studying the SQL in B. Otherwise it indicates A's team is not competent, which goes against our previous assumption.

Given that, one could reasonably assume changing B will be very difficult.

Thus if one cares about maintaining and evolving the pipeline due to changing demands over many years, then it's likely A is better, as the bug in A producing the wrong answer should be fixable by a competent team.

Again, just one take of many possible...

An alternate, more trivial take could be that team A were given an incorrect specification. So while they implemented the specification correctly, B actually implements something slightly differently.

We see this one with customers all the time. Where they think the old system does X but it does in fact do something slightly different, so when we implement the new system as requested, the customer files a bug report because it doesn't do what the old system actually did.

[tresclow]

And how do you know B's answer is correct?

[JonChesterfield]

In the world of science you get to compare software's predictions against reality. It's a weird concept but it grows on you.

I've seen systems with this structure. Part of the fun is B's code is likely to have a lot of errors in it that cancel each other out in exciting ways when running on the domain of interest, which makes using it to work out why A's code is failing to correspond to reality much harder than it could be.

[nlitened]

It makes all the money

[Pet_Ant]

He would be your entire team

[magicalhippo]

Even worse, as then the bus factor is as bad as it can get.

[IshKebab]

I think what he meant is he hasn't had to work with other people's code. Other people have to work with his code.

[Qem]

This reminds me of Rorschach prison remarks.

[hi-v-rocknroll]

> hasn't worked on anything substantial

This isn't the case. It's more likely a lack of business socialization combined with individual hyper-achievement. Reminds me of Ian Pratt in some ways.

An annoyance in tech, both startups and corporate, is technically-capable people but with outsized egos.

[defrost]

for reference: https://en.wikipedia.org/wiki/Arthur_Whitney_(computer_scien...