5 ms·
As an engineer with more than 15 years professional experience, my definition of "junior shit" would be thinking you can hand-roll a foundation or framework bet
by seattle_spring 5y ago
As an engineer with more than 15 years professional experience, my definition of "junior shit" would be thinking you can hand-roll a foundation or framework better than something that already exists.
- Tade0 5y agoIt's number 39. in Akin's Laws of Spacecraft Design. https://spacecraft.ssl.umd.edu/akins_laws.html https://spacecraft.ssl.umd.edu/akins_laws.html I have this on my list of questions I ask interviewers. I should follow-up with "how much of your budget is dedicated to this?" Major red flag if they don't even know how much catering to their NIH syndrome currently costs them.
- cableshaft 5y agoReally great list, thanks for sharing that!
- cbm-vic-20 5y agoNumber 4 hits too close to home. Great list.
- LAC-Tech 5y agoDo you also ask the opposite? How much of your budget is dedicated to working round, debugging, and wrestling with tools developed for the framework?
- austincheney 5y agoThat reminds me of people comparing writing in JavaScript (without their pet abstraction library) to writing in assembly. What a bunch of horse shit. It’s a red flag to self-identify configuration monkeys (people limited to following instructions) apart from those that can actually write and test applications. This rule about absolute failure in rolling your own realistically only applies to cryptography, because the bar there is set extremely high and there is a rigorous vetting process.
- LAC-Tech 5y agoI mean you put it a bit harshly but I'm with you. Last year I delivered an app in vanilla JS (super tight deadline and couldn't figure out how the google maps / react integration worked). It was fine. I rolled my own reactive data structure in a few lines of code (seriously, it can be less than 10) and got to work. Really enjoyable experience. Felt so much closer to the browser and didn't feel like I was suffering a big loss in expressiveness. I've been doing some more vanilla JS recently in my off time. The only thing that really makes me wish for a library is IndexedDB - by the time I took JS seriously it already had promises, and this oldschool callback heavy 'onerror' style is a challenge.
- blagie 5y agoI often come to this conclusion. One of my frameworks has hundreds of open source contributors now, and tens of millions of downstream users use things built on top of it. I'm now working on another one, and we just had our first few PRs from people who aren't me. And I ain't too young anymore. (And yes, this comment, while true, is tongue-in-cheek; there were darned good reasons for making new frameworks in both cases)
- LAC-Tech 5y agoBackend framework? Fair enough. Frontend framework? I'm really not so sure anymore. user does something -> change state -> modify DOM This isn't exactly rocket science.
- rhapsodic 5y ago>This isn't exactly rocket science. Hear, hear.
- Tade0 5y agoDOM modifications can get very slow very soon. After all, each reflow is actually a whole cascade of operations. Ostensibly simple things like swapping rows in a table can be computationally intensive if not done right.
- seattle_spring 5y agoIt's a fruitless endeavor arguing with people who think frontend is trivial. They've only worked on small, isolated projects by themselves and have used that experience to convince them it's the whole story and captures every project.
- LAC-Tech 5y ago> It's a fruitless endeavor arguing with people Agreed :D
- LAC-Tech 5y agoOh absolutely. You need to know what you're doing. But they same applies to react.
- OldHand2018 5y agoIf the existing framework is so great, why does it keep getting replaced with a new framework? Why aren’t we all still on Angular? And if we all keep hiring only the best candidates, why would we think that they can’t write a better framework? somebody is writing a better framework.
- blooalien 5y ago> As an engineer with more than 15 years professional experience, my definition of "junior shit" would be thinking you can hand-roll a foundation or framework better than something that already exists. You're not wrong, although to be fair, it isn't always about hand-rolling a framework. Sometimes it's just about experience and knowledge about which existing framework might best fit a given use case (without unnecessary bloat) as opposed to just choosing the latest "ooh shiny!" bloated buzzword framework to build upon purely because it's new and trendy this week. Although some use cases do call for the "bloated" framework, because feature requirements demand using a framework that provides those features. Again, experience and knowledge can inform whether this is necessarily the case, and one should obviously avoid hiring any applicant who does not see a valid need for the choice of framework/toolchain when it was chosen for good reason.