4 ms·
> Because your framework eventually becomes a badly written, not as widely tested version of a known framework. When you leave, it will be a lot easier to hire
by jseban 4y ago
> Because your framework eventually becomes a badly written, not as widely tested version of a known framework. When you leave, it will be a lot easier to hire someone who knows React than someone who knows jseban.js.
Why are you assuming that everything a software engineer creates will always be bad? That's an unbelievably deprecating attitude. Do you ever see any other professions do this? UX? Product? Writers? "everything we always try to do will always be bad" and we have to try to safe us from ourselves? What?
And this "framework" would be custom made to solve exactly the use cases at hand, and nothing else by definition would be better at those specific use cases.
And why would you optimise so much for onboarding and hiring anyway, at the expense of so much continuous wasted time and less output?
When my product owner quit, the new guy was working in parallel for three months, because "of course, they have to learn the ropes". That's normal for every single job basically, except software engineering.
Why not just spend a couple of days, or a week, to give an introduction to your new hires, so that they understand and learn how you have structured your program?
The only "problem" with that, is that you have to stop acting out this farce of the computer genius with the superior intelligence, in your hiring and onboarding process.
- Tabular-Iceberg 4y ago>Why are you assuming that everything a software engineer creates will always be bad? Not necessarily, but it usually ends up badly. I have no doubts most of my peers could write a fine custom framework, but it's going to take a whole team of them at least a year to come up with something decently ergonomic, tested and documented. How often is the business side of the company going to be on board with spending that amount of resources on a solved problem? Instead developers decide to fly under the radar and do it anyway, but then run out of steam while the framework is still an untested, undocumented prototype and the pressure to shift focus to features becomes too great to resist. And by that they have doomed the whole company to a bottomless swamp of technical debt, with seniors getting fed up and leaving, and being replaced with juniors with no clue of what's going on, making the onboarding problem magnitudes greater than it was in the first place. And if someone has the genius idea of a big rewrite, we all know where that's going, especially since the only people they have been able to retain the whole time are either inexperienced juniors and mediocre seniors, so the cycle repeats again.
- jseban 4y ago> I have no doubts most of my peers could write a fine custom framework, but it's going to take a whole team of them at least a year to come up with something decently ergonomic, tested and documented. No, because they would not make a framework, it would not require all of this work, because it's not designed to be generic and reused by others. Simply write a program. Not a framework. Has this idea been completely lost? Solve your own use cases only. Don't try to generalise it and optimise it for reuse by someone else.
- Tabular-Iceberg 4y agoAn abstraction doesn't care what you call it, or how many times it gets used. It still needs to be carefully designed, tested and documented, and this almost never happens in industry.
- scarface74 4y agoIt’s not about the person being a “genius”. A popular framework has been well tested, written by a group of people, it’s well documented, a community has grown up around it, their are books, training videos, etc. Would you write your own operating system or programming language because it might be better suited to solve your particular use case or use a general purpose language?