5 ms·
> 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 a
by shapiro92 8y ago
> 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?
- LandR 8y agoYes. 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.
- metric10 8y agoWasn'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...
- emilecantin 8y agoThere _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.
- externalreality 8y agoI 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".
- jimbokun 8y ago"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?
- externalreality 8y agoI 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!
- caseymarquis 8y agoWhile 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.