2 ms·
Not 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 Er
by timr 14y ago
Not 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.
- jorgeleo 14y agoI have nothing interesting to say, I just wanted to see how far the left indentation can go
- philh 14y agoOkay, but if I had known about the alternatives I would have used them, so I'm not sure how that's relevant.
- lifeisstillgood 14y agophilosophising really. I guess on the "actually helpful advice" level, I'm all out if the googles cant help.
- aidos 14y agoThings like the Counter in python collections. Actually, the python collections library in general. You don't need that stuff to do the job, but it makes the code a lot clearer. It probably took a couple of months full time in python before I had enough understanding of the std lib to know where to find everything (I sat down and read through a description of most of the functions in there). There are still plenty of libraries that would have made my life easier if I knew about them. I'm sure there are plenty more. Having said all that, that's just for example. When it comes to hiring I'd still pick a good experienced developer over a specific language expert for a full time position. For me it's not so much about the understanding of a specific language as it is the appetite for understanding computers / systems in general that makes truely good developers. Ultimately the task is going to dictate the best type of hire. Short term contract, get a specific expert. Long term hire, find someone who actually enjoys developing software :)
- 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.