Live data from Hacker News

A Cautionary Tale of Learning to Code

blog.freecodecamp.com

91–100 of 135 posts

Re: A Cautionary Tale of Learning to Code

#91
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 comment might not float to the top of the thread, but I'll post it anyways.

When dentistry started out, there likely were more than a few dentists who learned this way. There are still, on occasion, unlicensed dentists found practicing dentistry with decently successful businesses.

Software development doesn't have the Software Development Association protecting the practice like dentistry and medicine do, for their respective associations.

Re: A Cautionary Tale of Learning to Code

#92
post #89

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

I have been programming for 10+ years (and really more like 15 if you count being a teenager coding), and I change languages/editors/distros all the time. I have never switched keyboard layout (this honestly to me sounds like the biggest waste of time I have ever heard of). I am just saying that its not about finding some random piece of technology that you stick with forever, 90% of the time its using the right tool for the job, or contributing to something that already has momentum.

Re: A Cautionary Tale of Learning to Code

#93
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?

They are more of an understanding of what theoretically can be computed, rather than anything to do with how to do it or how to efficiently do it. I study lots of theoretical computer science, but it doesn't intersect with software engineering much. Software engineering tends to more relate to project management, operations research etc.

Re: A Cautionary Tale of Learning to Code

#94
post #73
post #43

Earlier quoted context omitted.

+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 ba…

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

I don't believe that, to be honest. There's a profound difference between a highly qualified professional and a hobbyist, and I am perfectly happy demanding that the first have a credential.

Re: A Cautionary Tale of Learning to Code

#95
post #60
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…

> If we wanted to engage in the same level of software engineering for all software, we could. But we don't want to.

Of course. Like building structures, there are different kinds of software. I can build a garden shed by myself as long as I have the skills to get the thing to stand up. If it blows down in a storm I'm the only person with a loss. But just because I can get a garden shed (or even a larger structure like a barn or a house) to survive windstorms without incident doesn't make me a structural engineer.

Re: A Cautionary Tale of Learning to Code

#96
post #89

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

I have been programming for 10+ years (and really more like 15 if you count being a teenager coding), and I change languages/editors/distros all the time. I have never switched keyboard layout (this honestly to me sounds like the biggest waste of time I have ever heard of). I am just saying that its not about finding some random piece of technology that you stick with forever, 90% of the time its using the right tool…

If you're already a decent QWERTY typist I agree it is a waste of time to learn a new keyboard layout.

But if you're hunt a peck QWERTY typist who decides to pick up touch typing, choosing an ergonomic layout like Dvorak or Colemak makes sense. You're essentially staring from zero anyways so you're not wasting much time on the layout anymore so than you would on the QWERTY layout.

This way, you retain your two-finger QWERTY skills while learning a layout that minimizes the odds of developing RSI.

Re: A Cautionary Tale of Learning to Code

#97
post #96

Earlier quoted context omitted.

I have been programming for 10+ years (and really more like 15 if you count being a teenager coding), and I change languages/editors/distros all the time. I have never switched keyboard layout (this honestly to me sounds like the biggest waste of time I have ever heard of). I am just saying that its not about finding some random piece of technology that you stick with forever, 90% of the time its using the right tool…

If you're already a decent QWERTY typist I agree it is a waste of time to learn a new keyboard layout. But if you're hunt a peck QWERTY typist who decides to pick up touch typing, choosing an ergonomic layout like Dvorak or Colemak makes sense. You're essentially staring from zero anyways so you're not wasting much time on the layout anymore so than you would on the QWERTY layout. This way, you retain your two-finger…

I suppose so, it just seems that the odds that you may need to work on a machine that isn't setup for you is probably going to be pretty high at some point. I agree that RSI is probably something we should avoid, but other than that things like typing speed have zero effect (in my experience).

Re: A Cautionary Tale of Learning to Code

#98
post #94
post #73

Earlier quoted context omitted.

> +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 ba…

> If we destroy the ability of newbie programmers to come up outside the university-professional path, we've just irreparably damaged the whole field. I don't believe that, to be honest. There's a profound difference between a highly qualified professional and a hobbyist, and I am perfectly happy demanding that the first have a credential.

Fortunately this is self-selecting. The highly qualified people (quite often these are the very best people) who don't have credentials would never, ever want to work for you.

Re: A Cautionary Tale of Learning to Code

#99
post #74
post #66

Earlier quoted context omitted.

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

"Sheer brute force" is probably a bit of an exaggeration. But just a bit. As you describe yourself, the kind of advance from C to more modern languages is a step away from "sheer brute force" and towards reasonable approaches. And only a small step compared to where we have to get before this is engineering.

I'd say a much larger part of all software projects is dysfunctional compared to the same in architectural or civil engineering projects, and I think this situation will greatly improve in the future, thanks to a handful of qualitatively innovative insights providing enormous improvements that we are yet to see.

Re: A Cautionary Tale of Learning to Code

#100
post #96

Earlier quoted context omitted.

If you're already a decent QWERTY typist I agree it is a waste of time to learn a new keyboard layout. But if you're hunt a peck QWERTY typist who decides to pick up touch typing, choosing an ergonomic layout like Dvorak or Colemak makes sense. You're essentially staring from zero anyways so you're not wasting much time on the layout anymore so than you would on the QWERTY layout. This way, you retain your two-finger…

I suppose so, it just seems that the odds that you may need to work on a machine that isn't setup for you is probably going to be pretty high at some point. I agree that RSI is probably something we should avoid, but other than that things like typing speed have zero effect (in my experience).

It's takes a trivial amount of time to set up these layouts on most machines.

I agree that good typing skills do not necessarily make you a more productive programmer. But I do find that it is a skill that compliments other programming skills nicely. It's also nice for countless other parts of my workflow that do not include programming.

Post reply on HN