Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Cautionary Tale of Learning to Code

blog.freecodecamp.com

Post reply on HN
Print view View original

71–80 of 135 posts

Re: A Cautionary Tale of Learning to Code

#71

Post by cbd1984 »

austenallred wrote: post #29
edw519 wrote: 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…

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…

> It doesn't actually mater what language you learn first

OK, start with Prolog. Now move to Ruby. Then Haskell, and include some SQL in that as well, somehow.

Now write me a program in APL.

Languages within the same paradigm are mostly similar. But there are a lot of paradigms, and some concepts don't transfer well at all. (Quick, what's the equivalent of an anonymous inner class in Prolog?)

Re: A Cautionary Tale of Learning to Code

#72

Post by drcomputer »

I am going to be slightly rude, but only because I have done exactly the same thing.

Stop trying to cram n years of experience into a blog post seeking some form of social validation. You are guaranteed to contradict yourself more than half the time. That's because you can't include all the important bits that helped you learn. Every stupid mistake is really your future best friend.

Re: A Cautionary Tale of Learning to Code

#73

Post by cbd1984 »

pnathan wrote: post #43
edw519 wrote: 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…

+1 I strongly believe that we're a profession and should have professional standards. On the other hand, I do suggest you look at hobbyist/quasi-professional magazines. It's.... not terribly dissimilar. Example cover: http://popularwoodworking.woodworkingplansplans.com/images/w... Conceptually, that's the same exact approach taken..

> +1 I strongly believe that we're a profession and should have professional standards.

As long as we don't kill the goose which laid a lot of us golden eggs.

If we destroy the ability of newbie programmers to come up outside the university-professional path, we've just irreparably damaged the whole field.

This is also why I don't like the idea of unionizing programmers: Even if we come up with a union which isn't based on the wage-and-hour, put-in-your-time model, unions are still based on seniority and coming up the "right" way as opposed to being able to strike out on your own in your own little company, without needing to pay dues, literal or metaphorical.

Re: A Cautionary Tale of Learning to Code

#74

Post by tjr »

jng wrote: post #66
tjr wrote: post #60

Earlier quoted context omitted.

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…

I think sheer brute force would be far less organized. How do you suppose designing and constructing a building according to designs and building codes is a more advanced, less brute-forced activity than building software according to requirements and industry standards?

But avionics-style software engineering need not be an all-or-nothing approach. Elements of it could be introduced into other programming applications for increased robustness. Greenspun wrote up an excellent article on adding external design review to web application development:

http://philip.greenspun.com/software/design-review

Such would not be a heavy burden on a project, and would likely help catch at least the most glaring errors that went unnoticed by the developers.

In any event, I agree that better tools and techniques offer the tantalizing possibility to help all software be more robust, even if it is never more "engineered". Modern languages have, for example, done away with whole categories of bugs that used to plague C programmers (and still do, unfortunately).

Re: A Cautionary Tale of Learning to Code

#75

Post by jimmaswell »

jng wrote: post #62
thomyorkie wrote: post #48

Earlier quoted context omitted.

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…

In what way does the work of Alan Turing etc. long ago not constitute a firm fundamental understanding of the field?

Re: A Cautionary Tale of Learning to Code

#76

Post by graycat »

tjr wrote: post #60
jng wrote: post #32

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

Yes, long ago it was observed that the first step in proving software correct was a clear specification of what the software was supposed to do and that for a lot of realistic software writing that spec was unreasonably difficult.

Re: A Cautionary Tale of Learning to Code

#77

Post by jng »

Retric wrote: post #68
jng wrote: post #65

Earlier quoted context omitted.

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

That's fine. I don't know the exact details of all those disciplines, I like history, but my knowledge of it is limited. I was within reasonable orders of magnitude of the real dates, or lower, which helps my argument that software engineering is incredibly young, which is the whole point :)

Re: A Cautionary Tale of Learning to Code

#78

Post by cbd1984 »

pnathan wrote: post #54
ChuckMcM wrote: post #34

Earlier quoted context omitted.

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…

> And that last bit is something that computers have largely avoided by consistently disclaiming all warranties. When that changes, and programmers (or their employers) are held liable for the incidental or consequential damage caused by their bugs, you will see a much stricter code for hiring and employing people who write code that runs on other people computers. My understanding is that life-critical systems have…

> (Also, since we're on the topic - what do you think of having some level of Professional Association ala the Bar or the Professional Engineering association)

I'll be interested in comparing defect rates between Professional Association members and non-members, and in how long such comparisons remain legal and not covered by NDAs and professional codes of silence.

If every programmer has to join, we've just killed the field.

Re: A Cautionary Tale of Learning to Code

#79

Post by debacle »

edw519 wrote: 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…

There is a line between "professional programmers" and "dangerous script kiddies."

You need a lot of clout to draw that line, you are going to upset a lot of people on the bottom half of the stratification, and you really need to work hard to convince a lot of programmers that creating a professional organization is a good idea, for some unknown reason.

Re: A Cautionary Tale of Learning to Code

#80

Post by jng »

jimmaswell wrote: post #75
jng wrote: post #62

Earlier quoted context omitted.

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…

In what way does the work of Alan Turing etc. long ago not constitute a firm fundamental understanding of the field?

In my view, Turing's results are equivalent in computer science (an important part of software creation) to Pythagoras' theorem in geometry (an important part of architecture): incredibly insightful, fundamental, everlasting and useful. Used directly or indirectly in all early works, respectively, in software and architecture. And only a tiny part of the foundational understanding necessary for really mastering the discipline, a level I think we still haven't reached in software.
Post reply on HN