3 ms·
I agree that lines of code is a terrible measurement of productivity. I don’t agree that short is always better. Sometimes it’s better to write the code so tha
by eksemplar 8y ago
I agree that lines of code is a terrible measurement of productivity.
I don’t agree that short is always better. Sometimes it’s better to write the code so that it’s easier to understand than to use smart tricks to make it short, because the next person looking at the code might not be on to your tricks. You can argue both ways on this of course, but I prefer clean and easily understandable because I’ve seen what happens when you don’t do that and a junior programmer has to fix something 15 years later.
I also disagree that libraries are better. You seem wary of JS, and that’s good, but no libraries are magical and none of them can be trusted to do something for you, unless you look under the hood.
Especially not open source libraries. If you don’t know what is going on inside the libraries you use, then you’re heading for a world of pain. Of course some libraries are better than others, but using them blindly is wrong. And if you have to read up on them, then they aren’t really quick fixes.
We had a developer who used a library to handle decimals. We have our own library for this, that we’ve build because almost none of the open source libraries for decimals are very good at handling memory allocation and floats and computers aren’t 0.00000000000 they are 0.00000001436 etc. But our developer didn’t know we had our own library for this, so he used a public one. One that uses around 10 other libraries, one of which didn’t handle memory allocation the way you’d want.
So suddenly our decimals were wrong, but the computer didn’t know they were wrong, because technically the library worked it just wasn’t specific enough. And it cost us a lot of money to clean things up afterwards.
This is the extreme example, but it’s never been more relevant than it is today. Especially not in a world where less and less programmers seem to actually know how computers or even compilers work.
- jgtrosh 8y agoI assume that's “especially not-open-source libraries” and not “especially not open-source libraries”
- eksemplar 8y agoNo, I meant to say that open source libraries are especially dangerous. I get why you may object, but open source libraries have failed us a lot and by contract the .net framework library hasn't. There are a lot of great open source libraries, that are both well documented and maintained, but there are a lot more that aren't.
- jgtrosh 8y agoThen i don't understand why you associate not knowing what's in a library with specifically open source ones. They tend by nature to be more open to introspection by any member of the community.
- eksemplar 8y agohttps://arstechnica.com/information-technology/2018/11/hacker-backdoors-widely-used-open-source-software-to-steal-bitcoin/ https://arstechnica.com/information-technology/2018/11/hacke...
- MrGilbert 8y ago> But our developer didn’t know we had our own library for this [...] I guess you also addressed this problem, right? Distributing knowledge inside the company is an issue, that's even more crucial in software engineering.
- quanticle 8y ago>I also disagree that libraries are better. You seem wary of JS, and that’s good, but no libraries are magical and none of them can be trusted to do something for you, unless you look under the hood. I wouldn't go that far. You use glibc, right? Have you looked under its hood? If you're writing Java, have you really looked inside Spring or Hibernate? In the .Net world, how many people have really looked at the ASP.Net source code? How many Python developers look at the code for Requests? Even in Javascript, I can't remember the last time I had to crack open jQuery and take a look at its internals.