4 ms·
As an upper 40ish something who has been coding since I was 10, this one made my day. So very very true.... but it's amazing how many 20 somethings are to nar
by TimMeade 11y ago
As an upper 40ish something who has been coding since I was 10, this one made my day. So very very true.... but it's amazing how many 20 somethings are to narrow in their thinking or too lacking in medium to long term vision on projects and just hack together a bunch of web found code to make a non extendable solution.
Then there are those who I call the 'google' generation, they just google the problem and proclaim the number one result as the solution without really understanding what and especially why the problem really is occurring.
Every generation has it's exceptions, but also each has their share of averages. Great article, nice way to start Monday morning.
- throwaway13337 11y agoI also developed before web framework proliferation and stackoverflow. I see most of these things as speed boosts. If you take the rose colored glasses off, in the old days - we simply worked slower on easier (though more interesting) problems. We didn't have to deal with so much damn integration and the mountain of spaghetti we've built! The non extendable solution gets the job done as well. No need to worry about 'technical debt' when the vast majority of your projects never see scale. Moving faster is better. When I see a developer wasting too much time on the above - not googling the solution, spending too much time overengineering, and not using the libraries available (not hacking together components)... well, I guess I'm disappointed. In the old days, I did think more in your terms. I changed to fit the needs of the time.
- Jtsummers 11y agoTechnical debt is not an issue, just, of scaling code (presumably you mean to large numbers of connections or database sizes or something). It's really an issue of maintenance. The more technical debt you have on a project, the longer any round of maintenance will take. Even simple tools that are just slapped together quickly might be easier to rewrite than modify, but rewriting them each time results in a different sort of technical debt. Implementation X has features used by user A, implantation Y has features used by user B, so now both tools have to be maintained or you try for Implementation Z that tries to pull it all back together (but probably fails, because you're still not properly budgeting time and engineers). Overengineering is still a problem, but underengineering is the one I run into more often.
- TimMeade 11y agoOh i agree with both of these responses. It's not that google is a bad thing, personally i laugh at how we used to have a wall of books to run to. It's more of the 'take the first google hit' that i was referring to. Not understanding how routing in the firewall works, just throwing code that seems like it might be what is occurring.
- Jtsummers 11y agoYeah, that's definitely a problem. I kind of miss the wall of books, though. Though I came in at the tail end of that era (more while I was still in school than after). I get a better understanding for things when I have a physical resource to go to. It helps that I (apparently) have an above average memory, but it works mostly by associating the physical act with the information I learned (I remember notes by recalling literally writing them on the page, for instance). So books seem to be more effective for conveying information to me in a retainable way, and I imagine that I'm not unique. That many of my colleagues with "terrible" memories are really just suffering from using the wrong resources to learn subjects, something about the computer screen as information source seems to stick less for people. My pet theory: The lack of other senses involved. A book has smell, texture, and then the physical act of turning pages. A lecturer versus a video, the lecture hall at least has a smell and feel to it, and there's more variation, less polish, on a live lecture compared to a video that's been thoroughly edited.