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

81–90 of 135 posts

Re: A Cautionary Tale of Learning to Code

#81

Post by tjr »

cbd1984 wrote: post #70
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…

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

A fair observation. In the example of handling HTML input, I would suppose that's not a problem with individual developers, but a problem with the industry. Such a relaxed format should not have been allowed to exist, if the industry cared about its software products being as robust as possible.

I'm failing to think of any avionics application that might handle HTML, but avionics systems do have their own formats to deal with. ARINC 661, for example, is an XML file format for transmitting graphical display elements:

http://en.wikipedia.org/wiki/ARINC_661

Of course, all uses of ARINC 661 data are thoroughly tested. I'm not sure I would go so far as to describe it as a "toy problem", but it certainly does intentionally limit the problem domain to exactly what needs to be dealt with. Malformed ARINC 661 data received would just be discarded, not tried to be displayed in the best possible way even if it wasn't quite right, because that would be unacceptable; the problem would be with whoever was sending the malformed data.

Anyway, you're quite right though; without a precise and unambiguous format definition, you can only go so far down the path of robustness.

Re: A Cautionary Tale of Learning to Code

#82

Post by graycat »

thomyorkie wrote: post #48
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…

Software engineering is a relatively young field. However, to say we don't properly understand the fundamentals is absurd.

A mechanical engineer knows about the properties of the metals, plastics, etc. he uses. A civil engineer knows about strengths of steel I-beams, etc. An electrical engineer knows about capacities of cables, switches, etc. So, these engineers can do real engineering and have transmissions run, electric power networks provide the power, and tall buildings and long bridges stand.

A software engineer knows about the capacity of a server? With what I/O rate, TCP/IP data rate, memory locality of reference, independent threads, memory that can be effectively cached, the memory usage, errors and their consequences?

E.g., one of the problems of doing optimization of assigning programs to servers in a server farm is knowing what (1) the servers can do, also considering other programs the server is running, and (2) what resources the software needs, and it's too tough to know either and, then, in a significantly large and complex server farm, fully to exploit this data for full optimization.

Software engineers are working with at best rubber specs on both the resources they have and the resources they will be using. So, can't really do engineering on the work, e.g., really can guarantee next to nothing. Or, would you want to bet the life of your wife or daughter on some software doing its work without errors and on time? Neither would I!

Re: A Cautionary Tale of Learning to Code

#83

Post by kiraken »

This blog post is an insult to every developer out there. The blogger actually want us to believe that he just overheard a conversation, went home, googled what ever he said he heard and in 7 months became an expert and landed a job. So in my professional opinion, and i do get to say that as opposed to the blogger since i actually studied Computer science and been a developer for 20 YEARS, that his story is a work of fiction, or the company that hired him is one of those startups that just hires anyone that walks in the door like most of them these days. A developer needs time not just to learn a language, trust me once you learn one you learned em all, you just need to get used to the new environment and light changes in syntax. What you need time for is to learn the LOGIC of our trade and learn how to fix errors and how to improve/optimize your code. And all of these things come with time and effort and no amount of facebook posts or reading books could teach you that.

Re: A Cautionary Tale of Learning to Code

#84

Post by gaius »

AlexanderDhoore wrote: post #8

Very very good article, although the latter part is a bit too focussed on web dev and dynamic scripting languages. I personally think every programmer should know some C. Basic things like what the stack and the heap are. Edit: Ok, probably not in the case of absolute beginners, but after a year or two...

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.

Re: A Cautionary Tale of Learning to Code

#85

Post by berdario »

cbd1984 wrote: post #71
austenallred wrote: post #29

Earlier quoted context omitted.

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?)

This!

...and moving from javascript strings to Ruby strings is far from a "30 seconds syntactical exercise", unless you don't take into account the fact that:

* Ruby strings don't necessarily have all the same encoding

* Javascript strings don't implement all of Ruby Strings' methods

* Ruby Strings are mutable, while JS's are immutable

* R̶u̶b̶y̶ ̶d̶o̶e̶s̶n̶'̶t̶ ̶h̶a̶v̶e̶ ̶C̶h̶a̶r̶s̶,̶ ̶J̶a̶v̶a̶s̶c̶r̶i̶p̶t̶ ̶d̶o̶e̶s̶ (edit: brain fart... I probably wrote too much Clojure[script], even if char literals in cljs just yield strings again)

(Or you use Opal, which doesn't abstract Javascript Strings much)

Re: A Cautionary Tale of Learning to Code

#86

Post by AnimalMuppet »

thomyorkie wrote: post #48
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…

Software engineering is a relatively young field. However, to say we don't properly understand the fundamentals is absurd.

Define "understand the fundamentals".

If you mean "the theoretical underpinnings", then, yes, we think we do. Turing machines and Church calculus provide solid theoretical underpinnings, that (as far as we know now) are complete. (Of course, the future could show us that they are incomplete. That's the problem with knowing whether your current understanding is proper - you don't know what gaps the future will reveal.)

However, if you mean "we know how to build programs so they work", there's massive empirical evidence that says that we don't. (That is, we can do it... sometimes. And sometimes we can do it after it takes five times as much money as we expected. And sometimes we can't make it work, ever. And we can't tell up front which will happen.) So in terms of this being engineering - as opposed to computer science - saying that we don't properly understand the fundamentals seems like an entirely reasonable statement.

Re: A Cautionary Tale of Learning to Code

#87

Post by JamesSwift »

cylinder wrote: post #44

How did you land job interviews after being self-taught? I'm doing the same right now, but I assume I need to complete some sort of bootcamp or what not in order to actually land an entry level job as a web developer. How do you get noticed when you don't have formal experience?

Have something to show. I don't know what technologies/languages you have experience in and/or are looking to interview in, but having a single example of a fully completed app/webapp will get you to the interview portion in a fair number of places.

Re: A Cautionary Tale of Learning to Code

#88

Post by jimbokun »

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. Because many people can easily afford the tools you need to learn programming (like the author said, a used MacBook, or any computer that can run Ubuntu). I'm pretty sure getting a hold of all the gear you need to be a practicing dentist will be much more expensive.

2. Because you can probably learn enough software development to do something useful in several months, maybe even enough to succeed in an entry level job. I think learning enough dentistry to actually practice it will take longer.

3. Because programming is much more lax about credentials. Sure, many employers require a CS degree for anyone they hire, but many do not.

Re: A Cautionary Tale of Learning to Code

#89

Post by spain »

This actually mirrors my own experience a lot, except for a few differences. Biggest one being I haven't actually looked into employment yet.

I too bounced between Vim and Emacs until recently I decided to stick with Emacs. I too switched to Dvorak, later switching to Colemak. I used a typing tutor software with which I was actually able to get up to a respectably 50-60 WPM if I remember correctly. However I eventually switched back to Qwerty after growing tired of keyboard shortcuts never working the way they were supposed to. Sure I could rebind them in my favorite editor (and even that was a pain in the ass) but each time I installed something new I'd have to do it again. One thing I am grateful for from Colemak is rebinding Caps lock to Control, what a great idea.

I've also been dabbling between C, Lisp, C++, Python, Bash, and a few others, but I never really became really good at any of them. It was more than just the OPs 50-page dabble (something like 400 pages into C++ Primer) but I feel like I can relate. Sure I can write basic programs in all of them but I didn't have a "default" so to speak that I've mastered. Only recently I made the decision that Python would be that default. The reasoning behind it is simple, I already kinda knew it and it fit my use case well. I just wanted to do stuff with the language and Python makes it easy with its wealth of libraries and (in my opinion) intuitive structure. Stuff like Lisp and Haskell still have a place in my heart because of how elegant they are, but I just feel more productive in Python.

That's my sort of ongoing story of getting at what I feel is the same kind of focus the OP was talking about. Now if only I could just settle on a Linux distro instead of hopping around every few months (currently messing around in Slackware, though I suspect I'd be better off switching back to Ubuntu which I was using before I switched to Slackware).

Re: A Cautionary Tale of Learning to Code

#90

Post by bitwize »

I like the idea to choose one language, but... Start with Python. You're going to hear Ruby this and JavaScript that and Swift the other -- but seriously, I'm from the future. You should start with Python. It's essentially BASIC for this century: a great place to start learning the basics without being too weird. There's plenty of time and once you have those cold, you can investigate other languages, including the fun ones that have separate compilation steps and may produce segmentation faults if you're not careful.
Post reply on HN