91–100 of 407 posts
Now days, Framework's mutant offspring ad-order-of-magnitue-larger, Platforms, is what I cope with. Why I Hate Platforms would be the same general rant writ large.
Earlier quoted context omitted.
> a good engineer has know where to go for the right information That colleges aren't teaching this as a first-rate topic is a real failure. This is, in my opinion, the most important skill any engineer should have.
I would add that intuition and knowing how to question it is also vastly important. My main driver is Ruby - I have a good feeling about code that can be refactored to use Enumerable more effectively; but I also know that Enumerable offers so much that I might be expecting too much of it. So 80% of the time I point to a method that solves the exact problem and the rest of the time I know how to write it differently.…
I agree. Especially knowing how to question and how to break problems down. I'm not sure intuition is a thing that can be taught, but it's a thing that emerges as a consequence of being curious and learning how to question and find answers to those questions.
That aspect is also why I think that being generally curious and having a broad base of knowledge makes you a better engineer. It's amazing how often apparently unrelated knowledge can give you an insight into solving programming problems. People who are laser-focused on "computer stuff" specifically often miss important insights.
This is taking a shot at Java, and a pretty old "joke" but I've heard of this actually being a thing out in the wild: https://stevenheidel.medium.com/a-factoryfactoryfactory-in-p...
The worst part of this kind of thing is that young carpenters honestly, really, truly, just need to learn to use a hammer. They can't even conceive of the problems that are being solved by the hammer factory, let alone the factory factory. But in the world of the factory factory factory, the apprentice carpenter (who really just wanted to drive a few nails) is now faced with trying to understand the gargantuan comple…
Everyone needs to learn to do calculus by hand before advancing to the calculator. People picking up frameworks without fundamental understanding is a shockingly common fallacy.
No company will pay you for several years just to learn complexity theory, write sorting algorithms, study schedulers, rewrite UNIX tools, understand hardware architectures, etc... They want you to be productive right away, and the shortest path is just to follow recipes with the latest framework.
That's the point of education, universities teach you what you won't learn on the job. So that when you finally get to work, you will have a better understanding of what you are doing.
Earlier quoted context omitted.
Like factories, frameworks are methods of reducing production costs, but come at the expense of certain aspects of product quality. Sometimes, that quality/cost tradeoff is desirable, sometimes it's not. The trouble comes if using a factory or framework is the only, or even main, tool in your toolbox, and it ends up getting used for everything.
> the main tool in your toolbox, and it ends up getting used for everything. I you get the work done efficiently this may be a good strategy. It may be a worse strategy, to spend a lot of time to find the "perfect" framework and a lot of time to master it, just because it's a better fit for the problem. "Good enough" very often does the trick.
Absolutely. From an engineering standpoint, "good enough" is often the right thing. An essential thing engineers do, after all, is to select appropriate compromises.
I don't get it. I assume the author is trying to make it sound absurd that you would need all these layers of factories to build a simple spice rack and, by analogy, that frameworks are also absurd. But if you were building spice racks at scale, of course you would build them in a factory! And you'd use machinery made in other factories. And those factories would have tools and machines made in yet other factories. T…
In fact, if somebody didn’t use a common library or framework and instead “rolled their own” it’s downright irresponsible, obnoxiously egotistical and just creates a huge maintenance burden for whoever has to maintain it when you move on.
Take for example a crud app in ruby. If instead of using rails or another framework you instead “rolled your own” for one it would take you way longer for two it would never be as battle tested as the framework and lastly you are guaranteeing that whoever has to maintain it will need to learn the idiosyncrasies of your amazing implementation with zero outside help. It’s a recipe for disaster.
Earlier quoted context omitted.
Extremely common, and was one I fell into as a junior dev myself (early 2010's). Some reasons (based on my experience): - University classes were either very low level, or using some new framework to increase your employment prospects - All the experienced devs would hop jobs every few years, leaving less opportunity for mentorship. - Lack of convenient resources for gaining base knowledge. Googling "how to make a to…
> a good engineer has know where to go for the right information That colleges aren't teaching this as a first-rate topic is a real failure. This is, in my opinion, the most important skill any engineer should have.
I think students at all levels tend to avoid this, and there isn’t stomach to fail them for it on the academic or family sides.