Live data from Hacker News

A Cautionary Tale of Learning to Code

blog.freecodecamp.com

131–135 of 135 posts

Re: A Cautionary Tale of Learning to Code

#131

Earlier quoted context omitted.

Perhaps because you can learn to code without several years of intense schooling. The bar to entry is significantly lower.

You can learn to clean teeth without several years of intense schooling, you cannot learn peridontal surgery in that time, nor by "practice", in a reasonable amount of time or without losing a few patients. What is interesting to me is that we have gone from having computers go from giant obscure machines in room, leased by large corporations, to having them all over the place in your house. There is a gradation of e…

> When that changes, and programmers (or their employers) are held liable for the incidental or consequential damage caused by their bugs

In a way, employers already are - when selling a product, the contract will define SLA and if that product doesn't "live up to expectations", then fines or other penalties will be used against the seller.

Also I don't think creating a good bug-free product is a matter of good programmers, as it is a matter of good testers. While both are obviously important, bugs will always happen and it is up to the test process (i.e. it's up to the management to design proper process) to catch as many of them as possible.

Re: A Cautionary Tale of Learning to Code

#132
post #122

Earlier quoted context omitted.

No, this statement is based on years of learning, practice and reflection, all around the creation and release of many successful software products of many kinds on the cutting edge of software development. I don't know why you assume I ignore all those things when I make my statement. The list of techniques you provide is a hodgepodge of valuable but limited techniques, inapplicable theoretical results, and voodoo-l…

> another shaman practice, valuable but without providing guarantees This is the same fallacious argument you keep making over and over. You dismiss tools that provide guarantees as "not practical," while calling techniques derived from experience "voodoo." You obviously have no experience in construction or civil engineering, have never looked at a building code book, and generally have no idea what engineering is:…

> You obviously have no experience in construction or civil engineering, have never looked at a building code book, and generally have no idea what engineering is:

I have very little experience in a architecture project decades ago, I just described my experience a couple comments above - I haven't claimed any more than that. I don't know what reasonable claim you could have to affirming I have never looked at a building code book - I more than looked at one, implemented in software the rules in there following the direction of an architect, and was generally amazed when I saw how real engineering works. I also spent five years attending an engineering school before working in large "software engineering" projects for 20 years, which I don't think are an instance of engineering at all, but hey.

Enjoy your faith in software engineering, your ad-hominems, your cynicism, and your real engineering career. Good bye.

Re: A Cautionary Tale of Learning to Code

#133
post #21

A 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…

This analogy is as absurd and oversimplified as comparing grand theft auto to a download of Taylor Swift albums. There is no such thing as "freelance amateur dentistry". You can't start tinkering with teeth and get a job the way you can tinker with programs as a hobby before getting a junior position at a programming gig. To compare the two professions and suggest the path to engagement and skill are the same is obtu…

I don't think he's mocking a lack of guidance, as much as the implicit indignation at not understanding a sprawling and complex field in an afternoon.

Re: A Cautionary Tale of Learning to Code

#134
post #111
post #84

Earlier quoted context omitted.

When I were a lad, everyone you'd meet in the industry had started out doing C on Unix, and had then specialised, maybe they liked Unix more and became sysadmins, maybe they liked C more and wrote Motif apps, or branched further out into C++ on Windows. But everyone had that core, fundamental knowledge. Nowadays people go straight into the very abstract stuff, and have nothing to tie it all together with.

C on UNIX? You were lucky! My dad had to toggle the bootloader into the front panel every morning before he could even run the assembler!

Maybe, but I'm only talking 15-20 years ago. So much has been lost in a relatively short time.

Re: A Cautionary Tale of Learning to Code

#135
The last sentence was the most important; the rest should be ignored. Have patience, perseverance, and you'll do anything.

Or, converge onto interesting problems and fail gloriously; the only way to do anything of worth.

The post comparing this to dentistry is precisely what I was thinking, except nowhere near as hilarious. I wish I was intelligent enough to write a Markov algorithm for logic that paralleled reasoning in such a way automatically. Thank you for that.

Post reply on HN