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

So You Want to be a Programmer

codinghorror.com

Post reply on HN
Print view View original

91–99 of 99 posts

Re: So You Want to be a Programmer

#91

Post by randomdata »

pohl wrote: post #82
randomdata wrote: post #60

Earlier quoted context omitted.

Why programming? The study of mechanics seems like it would have a much more profound impact on average people's lives. Often, it seems, I find myself hitting walls in the physical realm where someone with the right background would just build a simple machine to overcome the problem. I would never discourage the pursuit of knowledge, I'm just not seeing why programming gets its very own pedestal. It seems no more im…

Where I'm from, most schools already have shop classes where practical arts like mechanics are taught. So the status quo here is that mechanics is on a pedestal relative to programming.

That's interesting. The closest thing we had was auto shop, but that's like the learning MS Word equivalent of a programming class. What we did have, interestingly, was some programming lessons, though probably lighter than it should have been.

Re: So You Want to be a Programmer

#92

Post by h84ru3a »

mikecarlucci wrote: post #77
h84ru3a wrote: post #42

Earlier quoted context omitted.

What sort of project? Are you the type of person who like to take things apart and put them back together? Do you like to figure out how things work?

I am. I like restoring old computers, replacing capacitors etc. to get them running again, keeping my bike in order (though not my car), and messing around with HTML for simple things on a blog. I'm working on learning Ruby and slogging along iOS tutorials while designing my own board game. I did take a few CS classes in college but was a liberal arts major. If I had known more, might have flipped it, but at the time…

"programming would mean cooped up in a cube all day"

Unfortunately, I think for most programmers, it still does.

My guess is Atwood was once of them.

When I started to reach some sort "enlightenment" (series of epiphanies, ah-ha moments or whatever you want to call it) with respect to "programming" I found that I wanted to share my knowledge with others. I think I still have that urge now and again. (And even now I'd still be happy to show you or anyone what I've learned if they were really interested. However I must admit I've never had much interest in computer games or understanding how they work, and I prefer using Lua over Ruby.)

When I keep seeing these ridiculous blog posts like Atwood's I have a hard time seeing his sort of thinking as helpful to anyone (even himself). That's just how I see it. But then, what do I know? (A chorus of underappreciated programmers in cubicles responds: "Not much!" ;)

They're right. But so am I. In the grand scheme of things, none of us really knows much. That much, I do know. (Credit: Socrates)

Re: So You Want to be a Programmer

#93

Post by rmATinnovafy »

shadesandcolour wrote: post #76
ecounysis wrote: post #27

Earlier quoted context omitted.

You don't need to be a mechanic to change oil, but a small amount of mechanical knowledge helps quite a bit. I am talking about knowledge such as what is a drain plug, what is oil, what is an oil filter. Most people have at least a rudimentary knowledge of how a car works. Computing is still magic to many people, and it should not be.

Trust me I wish that it wasn't magic to people either. I need lots of hands to count the number of times I've explained some pretty basic (in my eyes) things about computers. Computer literacy is very important, but people don't seem to see it that way.

They are taught to trust the computer. To let it do its magic. Why then, should they go and learn how it works? For what purpose?

Imagine a world where people actually knew how to code. That means they would have enough skills to do basic math, and science. They would ask questions, rather than accept the answers given. They would challenge authority, rather than sit down and take orders.

Re: So You Want to be a Programmer

#94

Post by Peaker »

parasubvert wrote: post #80
Peaker wrote: post #65

Why does he mention the "No Silver Bullet" paper? Oh, how I hate that paper: it is pure speculation (Nobody has any idea what complexity is actually essential and what accidental), and it seems to ignore the fact that the past of programming sports a couple of silver bullets already. Saying the past had silver bullets but there are no silver bullets left to be found is like saying we've already invented all things, a…

Really? That's a seminal paper for a reason. Firstly, it's pretty obvious to a skilled developer what aspects of that program's complexity are accidental vs. essential. Layers upon layers of indirection for no particular end is one example of accidental complexity. As is tuning assembler for a particular processor. Understanding and constructing the appropriate usability and function of your software for your target…

I completely disagree that it's obvious to a skilled developer which parts are accidental/essential. Programmers (and everyone else) often don't realize they have a problem or are missing something until someone solves it for them. Similarly, programmers implement the exact same concepts over and over, and many of them don't even realize all of the things they're implementing are specializations of general patterns.

As for past silver bullets, the move from assembly language to C along with some extra tooling was easily an order of magnitude difference in development speed.

Re: So You Want to be a Programmer

#95

Post by smsm42 »

agentultra wrote: post #9

He's still missing the point. If anything "learning to code," is just bad language to describe something more worthwhile: teaching people the fundamentals of algorithmic and logical thinking. We don't teach mathematics to kids so that they will all become mathematicians and we certainly don't teach them literacy so that they will all become the next J.D. Salinger. They are just tools for solving other problems. "Lear…

Why should people care about computer systems in a plane? Do you know all hydraulic, mechanical, electrical, audio, video, etc. systems in the plane? Would average person know how plumbing in a plane works? Does he know what is the name of the plastic the storage bins or his seat handles are made of? Does he know how the metal that makes the wings is made? Most of the people don't know anything about 99% of things they use beyond what they need to know to use it. It is called division of labor, and without it civilization could not exist. Computers are no different. They do a lot of stuff, and most people don't care about the details, and they shouldn't. There are people that take care for it instead and get paid for it.

Algorithmic literacy very little to do with computers. People identified the need to systematic approach to solving problems long before computers, and some modern techniques existed very well without them. For example, TRIZ (https://en.wikipedia.org/wiki/TRIZ) was invented in 1946, without any computers existing. Systematic thinking and systematic approach to problem solving should be taught and learned, but programming is one narrow application of it, and should not be confused with it.

Re: So You Want to be a Programmer

#96

Post by smsm42 »

Zakharov wrote: post #48

The way I see it, subjects taught in school are ranked according to their perceived importance: 1 - Math, english 2 - Science, PE 3 - LOTE, history, geography, music, etc 4 - IT, drama, shop, economics, etc 5 - Plumbing, mechanics, technical drawing, etc Joel is, I think, arguing against people that say coding should be a tier 1 or 2 subject.

It is sad that economics is listed tier 4 and apparently as important (if not less important) as drama... Such common perceptions are probably why there are so many financially illiterate people and so much bad economic policy out there.

Re: So You Want to be a Programmer

#98

Post by parasubvert »

Peaker wrote: post #94
parasubvert wrote: post #80

Earlier quoted context omitted.

Really? That's a seminal paper for a reason. Firstly, it's pretty obvious to a skilled developer what aspects of that program's complexity are accidental vs. essential. Layers upon layers of indirection for no particular end is one example of accidental complexity. As is tuning assembler for a particular processor. Understanding and constructing the appropriate usability and function of your software for your target…

I completely disagree that it's obvious to a skilled developer which parts are accidental/essential. Programmers (and everyone else) often don't realize they have a problem or are missing something until someone solves it for them. Similarly, programmers implement the exact same concepts over and over, and many of them don't even realize all of the things they're implementing are specializations of general patterns.…

So, what I think you're suggesting is that a developer wouldn't understand accidental/essential complexity differences until a more skilled developer figured out the essence of certain classes of problems and others learned to apply their experience.

But, isn't that the case with any domain built on knowledge? My point was that a skilled developer had learned much the state of the art knowledge up to this point, and understands the pitfalls over over-complicating a solution that one can get into with certain solutions of the problem.

Brooks' paper wasn't even getting deeply into what we are talking about, he was just suggesting that software development is inherently complicated, that it's always going to be hard, because unlike Newtonian physics, you can't wave away the complexities and distill the essence of a problem into simple equations. The complexities ARE the software. Abstractions, though helpful, are flawed and leaky, unless they're designed by a master.

If software development is a fundamentally hard activity, like playing a musical instrument well, you're not likely going to make it a "breakthrough" with a piece of technology, you're going to improve it with better programmers. A highly talented programmer will be less productive using COBOL and older tools and technologies, but will not be an order of magnitude less productive. Back in the 80's, this was bitter medicine that management types had to hear, thinking that programming was rote activity with barely any need for higher pay or recognition of the 10:1 or more disparity in productivity among individuals.

Re: So You Want to be a Programmer

#99

Post by Peaker »

parasubvert wrote: post #98
Peaker wrote: post #94

Earlier quoted context omitted.

I completely disagree that it's obvious to a skilled developer which parts are accidental/essential. Programmers (and everyone else) often don't realize they have a problem or are missing something until someone solves it for them. Similarly, programmers implement the exact same concepts over and over, and many of them don't even realize all of the things they're implementing are specializations of general patterns.…

So, what I think you're suggesting is that a developer wouldn't understand accidental/essential complexity differences until a more skilled developer figured out the essence of certain classes of problems and others learned to apply their experience. But, isn't that the case with any domain built on knowledge? My point was that a skilled developer had learned much the state of the art knowledge up to this point, and…

> A highly talented programmer will be less productive using COBOL and older tools and technologies, but will not be an order of magnitude less productive.

I'm not sure about that, especially if you replace COBOL with assembly language. Definitely if you replace COBOL with machine code encodings, or punch cards.

Part of the disparity amongst individual programmers can be attributed to tooling, and we have no way of knowing how much that is.

I think we can agree the paper is saying: "Programming is inherently complicated, and we predict that our current tools already reduce complexity almost as much as possible". I just disagree with that prediction, and think our tools currently encompass massive amounts of accidental complexity which easily dwarf the essential complexity.

Post reply on HN