3 ms·
I'm just not sure how it's possible to have any API committed to memory these days, though I agree that if one picks a small number of dependencies as core tech
by abalashov 11y ago
I'm just not sure how it's possible to have any API committed to memory these days, though I agree that if one picks a small number of dependencies as core tech, one stands a far better chance of doing it and will realise better productivity outcomes than someone who compulsively includes every 30-line $PITHYNAME.js novelty to hit HN and GitHub.
Still, I grew up writing backend C in Linux environments, focusing heavily on socket programming, protocols and systems generally. I cannot help but feel that rapid development was a lot easier back then, and coding felt more rewarding. Part of that is definitely age; I'm 29 now, been writing C since I was 10, and started to feel consciously "burnt out" on coding around 20. (Basically running on motivational fumes ever since.)
However, there's more to it than that. C had a small and generally static standard library that one committed to memory easily with a little experience. Sure, one had to consult man pages from time to time for system calls, but in the grand scheme of things, writing code was a very original exercise, since so little could be taken for granted. That's why, even though I had to write 10x the lines of code, with my own lists and hash tables (notwithstanding GLIB etc.), I felt massively more productive after a coding marathon in those days.
I really feel that the practice of programming has shifted radically in its intellectual content since then. Primarily, we're wiring together prefabricated Lego blocks nowadays; when I write code in modern languages, I've got 27 browser tabs open and seem to spend 95% of my time looking up the fine points of how this Lego block connects to that one. Java is the archetype for this, but it happens even in more terse, expressive languages. Clearly, there are some productivity benefits from all this, being able to develop at a higher level while taking for granted many data structure primitives and wrappers, and I'm not blind to that. Still, it seems like the real art these days has shifted to adroitly and dexterously figuring out new APIs and libraries.
And there's so many of them! Verily a diarrhoeal explosion of APIs, libraries and dependencies. Even if you're impervious to the latest fads and fashions, the technology is shifting rapidly from year to year, and with it, entirely new documentation, methodologies, reference manuals -- an entirely new skill set, practically.
So, I'm hard-pressed to imagine how I'm supposed to ingrain APIs into motor memory when they are so numerous, expansive, and ever-shifting. Overall, I feel that my productivity as a programmer has declined considerably, even if the overall efficiency of lines of code has gone up. Pragmatically speaking, I'm not sure I'd trade in the overall productivity gains of all the abstraction for the halcyon era of C programming, but I definitely find it challenging to motivate myself to code when the primary skill set seems to be in looking things up.
- nostrademons 11y agoI think you've captured well the spirit of my comment. The point that I didn't mention - and that may partially answer your question - is that the other thing all of these "highly productive programmers" did is narrowly specialize in a particular niche where there weren't good existing solutions but are a number of potential users. There are still C libraries that remain unbuilt! Actually, with the decline of good C programmers and the rise of scripting languages, the relative demand for quality C libraries has probably gone upwards if anything. Usually these programmers (along with more recent ones like Zed Shaw and Mongrel, Brad Fitzpatrick and memcached, or Salvatore Sanfilippo and Redis) identified a specific need, solved it quickly and efficiently, and then leveraged the fame & reputation from that successful open-source project into a good job at a company that lets them do what they want or a series of consulting engagements supporting that software.
- abalashov 11y agoidentified a specific need, solved it quickly and efficiently, and then leveraged the fame & reputation from that successful open-source project into a good job at a company that lets them do what they want or a series of consulting engagements supporting that software. That's what I need to do. I almost did a few years ago, but unfortunately made the mistake of exclusively licencing the project to the customer, for a very cut-rate price. It was a gamble, as it was skunkworks, so it could have paid really well. Instead, it paid crappily, while demand for it elsewhere was abundant. Alas, IP...
- swah 11y agoIIRC Brad's approach was more of a social hack/MVP: wrote memcached in perl, convinced people of its obvious importance, let other folks write the C version (which I'm pretty sure he could have written, judging by his Go code).