4 ms·

It seems that there are mostly 2 types of devs: - those that use tools, learn them and master in them, - those that always want to create their own tools, and w

It seems that there are mostly 2 types of devs: - those that use tools, learn them and master in them, - those that always want to create their own tools, and will usually oppose adopting and learning existing ones. I belong to the first type. I love frameworks because they give publicly available documentation that plenty of people contribute to - so my project will have access to all of it even if I'm gone. Another reason is that frameworks have opportunity to be battle tested in terms of robustness and in terms of use cases. My stance here is that I love to use wheels instead of creating my own ones. I'm a project developer and not an academia developer. The second type of devs are what I would avoid hiring to my projects if they wouldn't be an academia projects. I need to deliver business goals in a most efficient way. That efficiency has to be on multiple levels. One these levels is to that the code won't be depending on one or two my best developers, because there is a high chance they will go at some point. My project would then rely only on what they created and documented, hoping that documentation cover everything. But my project would also slowly deteriorate technically, because most devoted contributors would be gone. Frameworks usually take much longer to become abandoned. I believe first type should work for businesses. The second type - should aim academia.

iveqy 4y ago
I belong to the second type. I believe it's a great asset to have in business. Most often less code means shorter development time and cheaper maintenance. People knowing a framework will often use it for everything. Instead looking at the problem and find the easiest solution to it offers great time to marked. I've proudly deleted more code than I've written at work.
- willsmith72 4y ago
  Agree on the importance of deleting code, but with "less code means shorter development time and cheaper maintenance", I don't think I've ever seen a program without a framework use "less code" than it would using one.
- mightyRodri 4y ago
  > Instead looking at the problem and find the easiest solution to it offers great time to marked. The easiest solution you can imagine. These are 90% of the time cute tricks that narrow down the scope of the solution so far it makes the surrounding code unmaintainable after a year. I learned to call those people "Ricks" they are best used in walled of projects that are not expected to change. Not useable in cooperation.
billythemaniam 4y ago
There is a third type: those of us that work with frameworks and build our own with libraries when needed. The right tool for the job essentially. The "right" framework is absolutely a net benefit, even in academia, but it can be very hard to pick the right one. Sometimes none of the available framework options are "right" either. The downsides of picking the wrong framework for a project are massive and worse than custom code in my experience. I rarely hear pro-framework-only people talk about the downsides, and I always wonder how experienced they are. Have they never seen a project go sideways by picking the wrong framework?
philote 4y ago
I'd propose a different dichotomy: those that have good experience using and developing complex systems, and those that don't. The former are more likely to fit with your dichotomy, while the latter are more likely to do what's best for their project. Though nobody can predict the future and what seems like the right choice initially might not be later on.

iveqy 4y ago

I belong to the second type. I believe it's a great asset to have in business. Most often less code means shorter development time and cheaper maintenance. People knowing a framework will often use it for everything. Instead looking at the problem and find the easiest solution to it offers great time to marked. I've proudly deleted more code than I've written at work.

willsmith72 4y ago
Agree on the importance of deleting code, but with "less code means shorter development time and cheaper maintenance", I don't think I've ever seen a program without a framework use "less code" than it would using one.
mightyRodri 4y ago
> Instead looking at the problem and find the easiest solution to it offers great time to marked. The easiest solution you can imagine. These are 90% of the time cute tricks that narrow down the scope of the solution so far it makes the surrounding code unmaintainable after a year. I learned to call those people "Ricks" they are best used in walled of projects that are not expected to change. Not useable in cooperation.

billythemaniam 4y ago

There is a third type: those of us that work with frameworks and build our own with libraries when needed. The right tool for the job essentially. The "right" framework is absolutely a net benefit, even in academia, but it can be very hard to pick the right one. Sometimes none of the available framework options are "right" either. The downsides of picking the wrong framework for a project are massive and worse than custom code in my experience. I rarely hear pro-framework-only people talk about the downsides, and I always wonder how experienced they are. Have they never seen a project go sideways by picking the wrong framework?

philote 4y ago

I'd propose a different dichotomy: those that have good experience using and developing complex systems, and those that don't. The former are more likely to fit with your dichotomy, while the latter are more likely to do what's best for their project. Though nobody can predict the future and what seems like the right choice initially might not be later on.