3 ms·
> Put it another way: the me of 2018 knows this. The me of 1998 probably did not. For this, I partly blame the dearth of mentoring[1] in the industry. It's bee
by mmt 8y ago
> Put it another way: the me of 2018 knows this. The me of 1998 probably did not.
For this, I partly blame the dearth of mentoring[1] in the industry. It's been discussed here on HN countless times before, and I'm pretty sure that has been the case since well before even 1998.
The author does, of course, point out the "rush-rush-rush" culture of shipping fast and fixing later (if the company still exists). That does certainly make sense for very early startups, but it seems to have permeated everywhere, if it didn't originate in larger companies in the first place.
I also partly blame the pushing out of programmers (and perhaps other technical professionals) with this magnitude of experience: to continue in their careers they face a choice of switching to a much less programming-focussed job such as management [2] or consulting or professional services or sales engineering, contracting, or essentially accepting permanent wage stagnation by pretending to be less experienced and going for those kinds of jobs.
Some of this is ageism, I expect, but a better explanation seems to be economic incentives. Technical debt is invisible in quarterly results, but big salaries of senior engineers are. I'll keep my fingers crossed that now that money is going toward flying^H^H^H^H^H^Hself-driving cars instead of 140^H^H^H280 characters, this could change. Likely not in time to beat my parents to retirement but for me.
[1] By which I mean hiring relatively inexperienced, but presumably talented, staff and having more experienced staff members train them in best practices and process and skills that may not otherwise be learnable from reading, formal education, or even pair programming (though that can be a vehicle for mentorship). Management buy-in on this is key, especially in startups, where the managers themselves may be the ones who can benefit the most from such mentoring.
[2] Which could, in theory, be a beneficial use of all that gained wisdom, but, then, the experience stagnates, and they might just have had a single-step Peter Principle promotion.
- JdeBP 8y agoThe Rachel Kroll of 1998 would have been hard pressed to be familiar with %G, something that only got standardized in ISO 9899:1999 and IEEE 1003.1:2001 and was somewhat experimental in the years before. (I don't remember precisely when I added these to my C library back in the 1990s, but they were definitely interesting but highly non-standard extensions in the 1990s.) Of course this supports xyr point that this was not "documented all over the place".
- mmt 8y agoSorry, I didn't mean to imply that anyone in 1998 should have known specifically about %G. I was, rather, referring, more generally, to something like the wisdom of finishing the man page, even if one thinks one has what one needs partway through, even if one is in a hurry. That's something I've personally tried to teach whenever I can, along with as many rationales for why this is the case that I can come up with at the time. This inherent flaw/tradeoff, of ordering, is one of them. No matter what order the author chooses, some reader (sometimes the same person at different times) will find that order suboptimal.