4 ms·

One reason of "invented here syndrome" is proliferation of crappy developers. I've seen that many times in the companies are worked for (as senior dev / archite

by mamon 10y ago

One reason of "invented here syndrome" is proliferation of crappy developers. I've seen that many times in the companies are worked for (as senior dev / architect): the code that is required by some web framework or library is quite clean and well structured, code that is at core, business logic is a mess. Tell some junior to mid-level developer to write any significant piece of application and the host of bugs and NullPointerExceptions will follow. Finding a library for everything and only leaving simple gluing them together as a task for developers seems like the only way of ensuring minimum required code quality.

k__ 10y ago
The other extreme is people who end up with hundrets of deps in their project.
- ben-schaaf 10y ago
  'node_modules' can get quite scary
sgift 10y ago
If all they are allowed to do is gluing code together they will never learn and will never get better at anything than .. gluing code together. Sounds like a bad idea.
- mamon 10y ago
  Maybe part of the issue is that I personally never work as full-time employee. I'm more like consultant, hired on per-project basis, so training less experienced developers is neither in my job description nor in my schedule.
  - Nursie 10y ago
    I work as a consultant on a project-basis too. I would tend to consider training up of any permanent staff on the team to be part of my job. Perhaps not on basic technology, but certainly on what we're doing. That way, when I leave, there's still knowledge in house. This may seem to limit business opportunities, but I consider it part of a job well done.
- lmm 10y ago
  If gluing code together is sufficient to solve the business problem (and 99.9% of the time it is) then it's probably the most efficient thing to be doing, and absolutely what they should be focusing on.
awinder 10y ago
Invented here and not invented here are equal signatures of crappy developers, in my opinion. I'll admit there's some skill involved, sometimes, in the engineering efforts of the NIH minded developer. But I've also seen NIH developers insist on building things like CI servers, company wikis, and message queues. And none of them have even been tangentially better than the alternatives. They're both mindsets that speak to immaturity and lack of judgement, but man, I've seen way more of NIH than IH, and in a lot more business-destructive senses
ohnomrbill 10y ago
On the other hand, I've just been at a place where "invented here syndrome" masked crappy developers to the detriment of the business. One tester spent 3 days tracking down a simple python dependency bug - but in the meantime he was productive because Travis is so easy to set up, and his Ruby tests worked. Travis is definitely more appealing to me than maintaining my own Jenkins instance. But I can't help but feel that we would have caught this guy's crappiness much earlier if he had to set up his own Jenkins job instead of a travis.yml file.

by mamon 10y ago

k__ 10y ago

The other extreme is people who end up with hundrets of deps in their project.

ben-schaaf 10y ago
'node_modules' can get quite scary

sgift 10y ago

If all they are allowed to do is gluing code together they will never learn and will never get better at anything than .. gluing code together. Sounds like a bad idea.

mamon 10y ago
Maybe part of the issue is that I personally never work as full-time employee. I'm more like consultant, hired on per-project basis, so training less experienced developers is neither in my job description nor in my schedule.
- Nursie 10y ago
  I work as a consultant on a project-basis too. I would tend to consider training up of any permanent staff on the team to be part of my job. Perhaps not on basic technology, but certainly on what we're doing. That way, when I leave, there's still knowledge in house. This may seem to limit business opportunities, but I consider it part of a job well done.
lmm 10y ago
If gluing code together is sufficient to solve the business problem (and 99.9% of the time it is) then it's probably the most efficient thing to be doing, and absolutely what they should be focusing on.

awinder 10y ago

Invented here and not invented here are equal signatures of crappy developers, in my opinion. I'll admit there's some skill involved, sometimes, in the engineering efforts of the NIH minded developer. But I've also seen NIH developers insist on building things like CI servers, company wikis, and message queues. And none of them have even been tangentially better than the alternatives. They're both mindsets that speak to immaturity and lack of judgement, but man, I've seen way more of NIH than IH, and in a lot more business-destructive senses

ohnomrbill 10y ago

On the other hand, I've just been at a place where "invented here syndrome" masked crappy developers to the detriment of the business. One tester spent 3 days tracking down a simple python dependency bug - but in the meantime he was productive because Travis is so easy to set up, and his Ruby tests worked. Travis is definitely more appealing to me than maintaining my own Jenkins instance. But I can't help but feel that we would have caught this guy's crappiness much earlier if he had to set up his own Jenkins job instead of a travis.yml file.