Hacker News Reader

> All the things most programmers do these days are pretty mundane and the only thing you need to ascertain is if they are familiar with the technologies that are being used.

this is exactly the company/boss i would not want to work for. It is exactly the opposite. You should not care if the person if familiar with the tech you use. Who cares if you do php or c#? Does it REALLY make any difference when it comes to taking the business logic and adapting it into MVC/API?

Yes.

Because if they don't have a deepish understand of the language and framework IME they tend to write crap code.

If someone is being hired to write C# /.NET all day every day I don't want to have to spend time teaching them C# or .NET

Especially not how to write good C# / .NET.

Wasn't part of the point of C#'s syntax was that it was easy for C++ and Java programmers to learn? Would any real C# advocate really tell me it would take months of manager supervised learning to pickup?

I've been writing code for a long time in many languages and I do my best to write "good" code. The principles that make code "good" in one language appear to apply equally to other languages...

I would argue that what makes code "good" is completely subjective which is why I don't spend too much time thinking about it.

The only criteria I have for good code these days is "Does it work", "Can I understand it". Everything else is a good IDE's command away for being willed into reality. So I really don't spend too much time on the "good" code debate like I did as a teen reading "Clean Code" and GOF books. I actually wish I could have that time back, I would have read, in their place, books on type theory and OS design, Posix, in other words things that actually help me build stuff and get things done and that I subsequently had to read later. Undo the damage done by the "good code" people that have me thinking about stuff that nobody cares about. Take a month off, read a book on game design in opengl, and write a cool robot simulation or something and remember how much more gratifying that is than writing a small do-nothing program just to try out some useless design pattern that doesn't scale beyond micro-examples.

There is so much varying lit out there on how to write good code that I am surprised that I am surprised if even 2 programmers can truly agree on what good code is. So Again, I'll say that "good" when it comes to code should be equivalent to "easy to understand" and "does the flow of text match the flow of program execution" in other words "is it easy to understand given I am familiar with the problem domain".

"The only criteria I have for good code these days is "Does it work", "Can I understand it"."

Which of course, are not trivial to achieve by any means.

Maybe also add "Can my coworkers understand it?" Which might be a very different metric.

"I would have read, in their place, books on type theory and OS design, Posix, in other words things that actually help me build stuff and get things done and that I subsequently had to read later."

If you want to get very far with any of those, you will need to write "good code", as you have defined it. So maybe a better way to understand good code would be to read the code of large projects implementing the things you want to learn about?

I don't know. Procedural code in Golang is pretty trivial - you basic constructs are regular in the selection, iteration, and sequence sense with a sprinkle of interfaces and some CSP constructs for concurrent design. That covers like 99% of what you need to write good code. I'd say pattern matching is pretty helpful Ala ML, Haskell, Rust. Beyond that all the GOF and Solid and all that jazz seems to do way more harm than good IMHO.

> If you want to get very far with any of those, you will need to write "good code"

If you have ever looked at the code of the most successful programs the code is anything but "good". Have you glanced at the Linux Kernel code lately? But again, "good" is very subjective. The Linux Kernel works well enough to server the purpose of millions of users and enough people understand it. Its good code!

There _are_ differences in good code between language. For exmaple, I've recently worked with a very good Java dev who wrote some code for a React frontend. While his code was very good, it definitely had that "java" feel to it, and I actually fixed a few bugs by removing some of it, mostly around state vs props synchronization.

While it might not always be a huge leap between languages, I think it would be a bit more work to explain something like this to a PHP user: "We used reflection to modify the expression tree Entity Framework generated from this SQLFunctions.DateDiff call to allow dynamic ranges to be used. This has saved us thousands of lines of boilerplate code, but it should only be used in non-critical locations, like reports, as it depends on the internal implementation of the expression tree using a list, which is not guaranteed under any circumstances, but very unlikely to change."

I'm sure there are similar situations going from .NET to PHP. I think they would understand the implications, but I'm not sure they would be able to quickly fix it if the expression tree implementation changed and they had to determine which implementation was being used with reflection.

That said, I would hire the PHP/Ruby programmer who didn't run screaming at the use of reflection and monkey patching over a .NET/Java developer with no interest in all the neat things their language of choice can do to eliminate massive amounts of boilerplate code.

Man, you are singing on my frequency. I’ve worked with too many John Musks. And I’ve seen too many full table scans and null reference exceptions :-(

> We just really be testing their ability to sort through a bunch of legacy OOP designed by people who are so board with the project domain that made of bunch of bad abstractions

My preferred coding interview approach is indeed to let the candidate interact with a correct but poorly-written piece of code and refactor it into something more maintainable. I find that reading and working with other people's code is a hugely important part of the job on a modern dev team, but rarely is that part of the evaluation.

No, they are not. The things programmers do are not mundane.

The word you are missing from your description is "effects". The parts of program or system interacts with each other not only by passing and returning values, but also by effects. It is good if your effects are isolated in SQL with ACID, but oftentimes they are not. The interaction is often subtle when resource in conflicting usage is shared indirectly (systems programming, come here!). And in the end of the day you are more Sherlok than you could imagine you ever would.

I am here not to say that interview questions are perfect. I am here to say that things that programmers do are not mundane (or they would be automated out quite quickly).

"I am here to say that things that programmers do are not mundane (or they would be automated out quite quickly)."

And they have been automated out, and so we are all working to solve other things now, which will then be automated, leaving us to solve other things...until the Singularity.