These are the exact strategies senior engineers use to prioritise impact, eliminate distractions, and ship high-value code quickly. Support me on Patreon: / jackhodkinson
Half of the advice is utter bullcrap. Third party dependencies are more often liability rather than help. Yes, you can quickly crap things together from a pile of open source third party components, but when this contraption fails to do exactly what you need, you'll curse the day you decided to use some third party trash instead of writing from scratch.
The nice part of open source is that you can just edit it if it's close enough to what you need. Having a starting point saves you from having to waste time solving all the problems that the library's author already took the time to solve. It's basically the same advice as "steal code", but instead it's "steal large amounts of code at once". I mostly program for fun, so I love reinventing the wheel and avoid libraries just for the sake of avoiding libraries. But I'll still occasionally copy/paste a function from a library if it's doing hard math or something. And obviously I use 3rd party libraries and software for things like SSL encryption and image decompression and whatnot.
@willard2397 it works for only small, self-contained, very well designed software packages that do not drag tons of other dependencies with them. This is very rare. Look at the dumpster fire that, say, the Python ecosystem is. Pip install the tiny little package you need, get half a gb of extra dependencies (none of which you're going to audit, realistically). Pull an open souce C++ library, and it drags in the awful Boost that you should avoild at all costs. This is just wrong. Software is not that hard. Everything, outside of some really core functionality (OS, unless you do bare metal real-time, DBMS, compilers) are better built ffom the ground up.
yep, sounds about right for so much stuff sucks. - Quality is a curse word to businesses and people who make most stuff. (the build documentation dev tools is decent, but most people both under- and over-do it instead) - remove problems before solving them is genuine advice, tho
We've been stealing code since 1985
Thank you for the non-BS advice, I will try to implement this
Brilliant
Fire
Half of the advice is utter bullcrap. Third party dependencies are more often liability rather than help. Yes, you can quickly crap things together from a pile of open source third party components, but when this contraption fails to do exactly what you need, you'll curse the day you decided to use some third party trash instead of writing from scratch.
Thank you for stopping by
The nice part of open source is that you can just edit it if it's close enough to what you need. Having a starting point saves you from having to waste time solving all the problems that the library's author already took the time to solve. It's basically the same advice as "steal code", but instead it's "steal large amounts of code at once".
I mostly program for fun, so I love reinventing the wheel and avoid libraries just for the sake of avoiding libraries. But I'll still occasionally copy/paste a function from a library if it's doing hard math or something. And obviously I use 3rd party libraries and software for things like SSL encryption and image decompression and whatnot.
@willard2397 it works for only small, self-contained, very well designed software packages that do not drag tons of other dependencies with them. This is very rare. Look at the dumpster fire that, say, the Python ecosystem is. Pip install the tiny little package you need, get half a gb of extra dependencies (none of which you're going to audit, realistically). Pull an open souce C++ library, and it drags in the awful Boost that you should avoild at all costs.
This is just wrong. Software is not that hard. Everything, outside of some really core functionality (OS, unless you do bare metal real-time, DBMS, compilers) are better built ffom the ground up.
I bet you use Arch too
@GreenGrapesMilk no. But I write a lot of bare-metal code.
yep, sounds about right for so much stuff sucks. - Quality is a curse word to businesses and people who make most stuff.
(the build documentation dev tools is decent, but most people both under- and over-do it instead)
- remove problems before solving them is genuine advice, tho