3 ms·
Even at an established company, a really smart language newbie could write a bunch of ad-hoc code that does almost the same thing as well-understood libraries t
by jbooth 14y ago
Even at an established company, a really smart language newbie could write a bunch of ad-hoc code that does almost the same thing as well-understood libraries that everyone more experienced in the language uses. Even if his code was relatively high-quality, now you have a bunch of extra stuff to maintain, and everyone who interacts with it will have to learn this thing instead of just using the library everyone knows. I've done this in languages I'm unfamiliar with and will probably continue to do so.
- timr 14y agoNot Invented Here syndrome goes away with general experience. It doesn't come back every time you switch to a new language. Just because I've never written Erlang doesn't mean that I will automatically try to write a random-number generator (say) the first time I need one in Erlang. I have enough experience to look for a library function first. Empirically, NIH tends to be more common in single-language developers, not less. People who place a lot of value on their "expertise" in Blub tend to do so because they're over-weighting the importance of their memory of the API details. When they don't automatically remember something, they leap to the conclusion that it doesn't exist. They're also typically a less-experienced cohort than people who have written in lots of different languages.
- jbooth 14y agoI wasn't talking about NIH syndrome, I was talking about "I don't know that a common library exists for this standard use-case so I'm going to write my own one-off because I have a job to do". I mean, you can google for libraries but sometimes you just don't find them and then find out a few weeks later what you should have used.
- timr 14y agoI don't know that a common library exists for this standard use-case so I'm going to write my own one-off because I have a job to do. That's called "laziness", and is even more likely than NIH syndrome to be mitigated by experience. Certainly, having lots of coding time with a single language doesn't make you less lazy, and having lots of experience with different languages doesn't make you lazier.
- jbooth 14y agoWell, I'm less lazy than most devs and have worked in lots of languages and did it just the other week -- maybe I'm just not that bright :)
- lifeisstillgood 14y agoCould you give a specific example as I am still thinking "random number generator" and want to balance it with your "standard idiom or library that everyone steeped in $lang knows " Cheers
- philh 14y agoI dunno how well-known the things I didn't know about are, but an example of me doing it: https://news.ycombinator.com/item?id=5113202 https://news.ycombinator.com/item?id=5113202
- lifeisstillgood 14y agoI think there is a fine line between using a library and writin your own to understand better the domain It's something to do with how critical the library functions are to you / your system. I would never write my own compression software, but I can see why people would just to learn about the trade offs.
- WildUtah 14y agoThat's just an imbalance in programming virtues: too much hubris, not nearly enough laziness (unknown impatience).
- grey-area 14y agoThis is unlikely with go as it has a good standard library and a central place for documentation of all the packages. http://golang.org/pkg/ http://golang.org/pkg/ Third party libraries are also listed here: http://go-lang.cat-v.org/pure-go-libs http://go-lang.cat-v.org/pure-go-libs And the ecosystem is not so broad or mature that you would miss significant libraries because there are too many options and you just didn't find them.
- belorn 14y agoBeing a programmer is not about knowing everything. With experience one should be able to separate library functions that should always exist from those that are unique for each language. Everything else should just be a matter of information searching.
- mercurial 14y agoIt depends. If you're the only one knowing the language at this company... it's a bad idea, because the bus factor becomes unacceptable. Otherwise you have a methodology problem. You don't do daily standups, where you'd have the opportunity to say "Yesterday, I started implementing X because I couldn't find a library" and more experienced coworkers would tell you "Use library Y instead".
- themckman 14y agoThat's where code review can be such a valuable tool. I was learning Python coming from Ruby about a year ago and, sure, the languages are similar and it wasn't too hard to get started, but having code review sped up how quickly I became proficient by a lot. It's great having a bunch of people around you that can say things like "There's this thing that exists, don't do that." or "It's more idiomatic to do this that way instead of how you're doing it." or "People hate that because, do it like this.". It makes a huge difference.
- flyinRyan 14y agoYou talk as if we develop code by chiseling it out in stone. We write it in text files, usually with IDEs. No one needs to learn the new libraries the newbie made, they can talk to the newbie, point out what the library already gives (and where to look in future) and write to well known interfaces. Any project should have time allocated for "tech debt" and that's where this sort of thing gets addressed.