This was a really good read. I thoroughly enjoyed it. Thanks!
A Cautionary Tale of Learning to Code
61–70 of 135 posts
Re: A Cautionary Tale of Learning to Code
#62Earlier quoted context omitted.
Because one finds many self-taught developers out there who can outperform college-educated compsci majors day in and day out. Because one can read universally-acknowledged figures explaining how a large number of people with a software engineering degree can't code their way out of a paper bag or pass the most basic "fizz buzz test". (1) Because we can see non-genius 17-year-olds writing apps that are bought by top…
Software engineering is a relatively young field. However, to say we don't properly understand the fundamentals is absurd.
Of course that's your take, definitely not mine. Not easy to discuss though: the obtuseness in today's software building won't be obvious until we discover the principles that turn it into engineering.
In ancient Egypt, pyramid-building must have seemed the unbelievable pinnacle of human achievement, only surpassable by ever higher and larger pyramids. Only now we see the primitiveness of those works (notwithstanding their merit and value).
It is my take that our current level of understanding of software building is similar to the that of architecture when pyramids were built.
Fortunately, advance is now much faster thanks to the many tools that help experimentation and communication, and we should be approaching somewhere reasonable in just a few decades.
Re: A Cautionary Tale of Learning to Code
#63I'd spent months sitting alone in libraries and cafes, blindly installing tools from the command line, debugging Linux driver problems, and banging my head over things as trivial as missing parenthesis.
Yet this illustrates a very important thing that most proponents of "learning to code" neglect entirely.
Writing code isn't an isolated black box. To write code is to interact with the extremely entangled software environments that we have cumulatively been building up for over 60 years now.
Anything beyond Fibonacci sequences will require you to spill out into lots and lots of domain-specific areas and subdisciplines. A proficient programmer in general will also need at least basic skills in system administration.
To build a real useful application intersects with areas such as network protocols (which is immeasurably vast, depending on what layer you pick and how much you abstract), widget toolkits (and the wider quandaries of computer graphics, windowing, displays, etc.), cryptography (which pretty much intersects with most bodies of computer science), the workings of the kernel, dynamic linker (thus object files and libraries), the C library...
Profiling an application will likely require you to learn some complexity theory. I/O-bound applications will require you to learn how file systems, I/O schedulers and disks work. System programming is a rabbit hole of its own, with POSIX alone just about being an independent branch.
The bottom line is that programming can mean just about anything. And since programming itself is not innate, but a member of its own in the tangled web of computing, programming is thus a vast body of theory itself, a lot of which one will need to learn, unless they intend on staying frozen.
Paradoxically, the more we try to make things so that people won't have to be specialized in order to use them, the more we necessitate huge drifts of specialization in the people that want to do more than cursory tasks.
While picking a few components and sticking with them is probably necessary at least in professional environments to maintain sanity and interoperability, it is not very realistic for hobbyists and learners.
Of course, if you just want to write macros to automate tedious tasks, you can get by with the basics. But that is pretty much something that will end up being born from necessity, and likely self-discovered rather than taught through compulsory means.
Re: A Cautionary Tale of Learning to Code
#64A Cautionary Tale of Learning to Fix Teeth. My own. How a reasonably balanced individual nearly went insane I was just a guy in a suit in an office with a vague healthcare idea. Then I decided to learn to fix teeth. I overheard some guy at a happy hour bragging about how easily he was able to automate his overbite by using a technique called "4 Handed Dentristry". I thought, "huh, 4 Handed Dentistry." I went home, go…
It's tough when you're reading HackerNews or spend a lot of time around technical people. Technical people are, necessarily, very adamant about the technologies they use. When you're first starting out, you just want the "best." Among the most common misunderstandings for non-technical people is what a programming "language" is. You don't realize that almost all programming languages are made up of very similar const…
Great advice, thank you for this.
Re: A Cautionary Tale of Learning to Code
#65Earlier quoted context omitted.
Because one finds many self-taught developers out there who can outperform college-educated compsci majors day in and day out. Because one can read universally-acknowledged figures explaining how a large number of people with a software engineering degree can't code their way out of a paper bag or pass the most basic "fizz buzz test". (1) Because we can see non-genius 17-year-olds writing apps that are bought by top…
Architecture, engineering, and the law are all well over 6,000 years old. People have changed less (ed: more slowly) than you might think. Consider, people where applying makeup 6,000 years ago and there is some evidence the practice is ~100,000 years old.
I just threw an approximate guess of 2-3k years. If it's 6k, more to my reasoning: there's been so much time and effort to learn those that proper principles are now well known and can be taught and applied repeatedly, reliably, affordably.
I don't think people have changed at all, and I didn't say it anywhere above, so I don't understand why you assume I think people have changed significantly.
Our knowledge in a few areas has grown significantly though (read: crafts, science and technology). I don't think anyone reasonable would disagree, but who knows.
Re: A Cautionary Tale of Learning to Code
#66Earlier quoted context omitted.
Because one finds many self-taught developers out there who can outperform college-educated compsci majors day in and day out. Because one can read universally-acknowledged figures explaining how a large number of people with a software engineering degree can't code their way out of a paper bag or pass the most basic "fizz buzz test". (1) Because we can see non-genius 17-year-olds writing apps that are bought by top…
That is engineering, software projects with today's tools and techniques are not. This will happen some day in software. We are not there yet, by far. Sure we are, at least pretty close. Commercial avionics software developed to DO-178B standards calls for reams of requirements, verification tests, compliance to process, internal quality reviews, external audits, and sign-off by FAA representatives. A one-line code c…
In my understanding, those projects are the modern pyramids of software. Built by sheer brute force at an unsustainable cost, only affordable by a select few.
Large amounts of reliable, performant and scalable software will be built on time and on budget at some point in the future, with a cost and effort similar to today's run-of-the-mill software development. This will happen when, thanks to better understanding of the principles, we can create better tools and techniques to do so.
Re: A Cautionary Tale of Learning to Code
#67I like this article because as someone who struggles with learning to code, I have found myself making it worse by jumping from language to language, learning the very basics of their syntax. Great, I can FizzBuzz in 4 different languages, but I still can't put together something comprehensive and useful.
Reading this was kind of the reminder I needed. Focus. Pick one, become proficient (with the language and just the concepts of programming), and I guess somewhere down the road if I feel compelled try another.
So for now, I'll focus.
Re: A Cautionary Tale of Learning to Code
#68Earlier quoted context omitted.
Architecture, engineering, and the law are all well over 6,000 years old. People have changed less (ed: more slowly) than you might think. Consider, people where applying makeup 6,000 years ago and there is some evidence the practice is ~100,000 years old.
I just threw an approximate guess of 2-3k years. If it's 6k, more to my reasoning: there's been so much time and effort to learn those that proper principles are now well known and can be taught and applied repeatedly, reliably, affordably. I don't think people have changed at all, and I didn't say it anywhere above, so I don't understand why you assume I think people have changed significantly. Our knowledge in a fe…
No offence intended, I just noticed a lot of those numbers where fairly low. Like where you say dentistry is century's old which is clearly true, but "Remains from the early Harappan periods of the Indus Valley Civilization (c. 3300 BCE) show evidence of teeth having been drilled dating back 9,000 years." http://en.wikipedia.org/wiki/Dentistry
So it's 90+ century's old. Which is one of those, wait what? moments for me that I like to share.
Re: A Cautionary Tale of Learning to Code
#69I think the key takeaway from this is that you need to focus on learning one thing at a time. If you want to learn how to program, don't distract yourself by trying to learn some complex text editor at the same time. Use whatever plain-text editor feels easiest to you. And use the environment that's easiest to get going in.
As you learn more, you'll find things that annoy you about your editor/environment. Fix those as you see fit. Eventually you'll have an environment that fits you "like a glove".
It's absolutely detrimental to try to get a fully customized environment set up before you know what your workflow is going to be like. It took me years to get to my environment (tmux, vim+plugins, ack, a VirtualBox environment with a proxy). I experimented a lot. But getting "the perfect environment" was never a goal; it was just a lot of "this is annoying, there has to be a better way -> google -> environment change".
Re: A Cautionary Tale of Learning to Code
#70Earlier quoted context omitted.
Because one finds many self-taught developers out there who can outperform college-educated compsci majors day in and day out. Because one can read universally-acknowledged figures explaining how a large number of people with a software engineering degree can't code their way out of a paper bag or pass the most basic "fizz buzz test". (1) Because we can see non-genius 17-year-olds writing apps that are bought by top…
That is engineering, software projects with today's tools and techniques are not. This will happen some day in software. We are not there yet, by far. Sure we are, at least pretty close. Commercial avionics software developed to DO-178B standards calls for reams of requirements, verification tests, compliance to process, internal quality reviews, external audits, and sign-off by FAA representatives. A one-line code c…
> But the software is extremely robust.
Does the specification specify the input as well, or is it actually robust against real input?
By real input I mean stuff like HTML tag soup: There's no single standards document which describes it fully, or even mostly, and it isn't going to be fixed. Ever. It simply has to be processed, to the limits of your ability to process it.
Avionics software is robust, sure, but it's almost a toy problem, its domain is so well-specified. You can ignore so much about reality because you've got a contract which says "We only care about what's listed, everything else can go hang" and in the real world (or, well, in the rest of the real world) you can't usually do that.