3 ms·
Senior here. I think this is an overly cynical take. You want to pick a set of tools which will help you get the job at hand done most effectively. It’s often
by josephg 3y ago
Senior here. I think this is an overly cynical take.
You want to pick a set of tools which will help you get the job at hand done most effectively. It’s often easier and cheaper to hire or train a team to use a framework or library than it is to reimplement the functionality that library provides from scratch. Eg, if I was building a big single page app, I’d rather use react than reimplement react’s functionality, badly, on top of jquery or something.
Projects last years. An engineer with solid fundamental knowledge can get up to speed with most of these tools and libraries in a few days. The math usually checks out to make them worth using.
But I still acknowledge your point. There are plenty of terrible senior engineers out there making bad choices on tools. And there is a lot of damage a bad tool choice can make to a project. Libraries and frameworks rarely tell you when they’re buggy messes. And coworkers rarely tell you when learning some new tool feels beyond them. So I’m sure there’s plenty of projects out there trying to use fancy tools which have a net negative effect on team productivity.
- adrianmsmith 3y agoYou're absolutely right, there is definitely an optimal level of framework usage, for the reasons you state. I suppose what I meant was really excessive framework usage, the type of which is alluded to in the original article with the factory factory factories etc. I shall edit my comment to clarify that.
- josephg 3y agoYeah fair enough. The whole factory factory factory thing feels separate to me. I think of it as a disastrous, productivity destroying meme that spreads through words like “hidden implementation” and “one interface, multiple implementations”. You don’t to be a senior to be vulnerable to the mind virus, though once it gets into the heads of your senior engineers your whole team or company can be in peril. The disease has claimed entire programming communities with its cloying rot. (Dare I say the J-word and invoke its wrath?). As an individual, it can take years to recover from these ideas. Some poor hacker souls never recover.
- sfn42 3y agoSounds like you haven't really understood the benefits of polymorphism, encapsulation etc. The general idea is to compartmentalize your logic and only expose the important parts like if you need to generate pdfs from html you may need to use a lot of moving parts to make that happen but you hide all of it and only expose an interface with a single action that takes html and returns a pdf. If you later need to change how you do the pdf generation you can freely mess with the internals of the system any way you want because consumers have no dependencies on any of it. If you need to rewrite it from scratch you can implement the same interface and none of the code using it needs to change at all.
- BlargMcLarg 3y agoNot everything needs a hyper-abstracted solution. Most people suck at writing neat abstractions, so they spend an excessive amount of time writing shoddy solutions which no one really wants to deal with but there's a soft, begrudging agreement to use them anyway while the business sees no value in having their devs rewrite it. This goes double when you step into the world of microservices, where you now have another layer where you can easily swap the implementation behind the interface. Surely years of old Java shops with absolutely dreadful software architecture, sloppily copied from literature, showcase the path to hell being paved by good intentions.
- sfn42 3y agoSure, you can write bad code using abstractions. Doesn't mean abstractions are bad or useless. There's just a lot of devs out there who don't write very good code. There are also devs writing decent code but too tightly coupled, making it much more difficult to develop the code further without first refactoring the existing solution. It is also often very difficult to refactor the solution because its parts are also very tightly coupled so you end up with a whole tree of changes you have to make before you can do the actual refactor you want in order to make the actual change you wanted to do in the first place.
- 3y ago
- hutzlibu 3y ago"Libraries and frameworks rarely tell you when they’re buggy messes." GitHub Issues usually gives you a good insight, into what problems exists and whether they get fixed, or not. (as a senior, you likely know, but others reading this, maybe not)
- josephg 3y agoTrue, though figuring out community sentiment from GitHub issues is a bit tricky. The numbers alone certainly aren’t a good indication because projects attract a lot more issues when they’re popular.
- xmcqdpt2 3y agoGithub Issues is full of confounding factors though. Lots of Issues mean that there are bugs but all software has bugs. It also means that there lots of users and that users feel that raising an issue is a good way to get something fixed, which is good! IMO the better metric is how many outstanding unmerged pull requests exist. If there are too many this means that bugs exists and they aren't getting fixed.
- hutzlibu 3y agoI did not say the quantity of issues matters. And people can do lots of weird PRs that do not get accepted as well. Code quality, obscure features implemented, etc. but it can be hard to figure out what is what, so they might just sit there open for some time, that is not ideal, but can still mean the code base is solid. For me this is easier to figure out in the issues/discussion page. (And reading the actual source and documentation)