To those who argue programming is an essential skill we should be teaching our children, right up there with reading, writing, and arithmetic: can you explain to me how Michael Bloomberg would be better at his day to day job of leading the largest city in the USA if he woke up one morning as a crack Java coder?
"If you go through this book, and do each exercise for one or two hours a night, you will have a good foundation for moving on to another book. You might not really learn 'programming' from this book, but you will learn the foundation skills you need to start learning the language."
---From Learn Python the Hard Way, unfortunately no page reference because the preview is for the Kindle edition, but it's the second full paragraph after the ToC.
At some point there absolutely must be some form of knitted-stitched computer language, like a cross between spies communicating through coded color threads and those old computers directed through paper holepunched cards, only fuzzier and more attractive to hang on the wall.
I think Atwood is overestimating how rarefied and precious coding ability is--while not skilled, the average web-surfing tween will learn some BBEdit & HTML just to yell at people in forums in bold about video games--and he's underestimating how many people are desperate to find and trying to cram on skills like Mardi Gras beads to catch someone's eye.
People like Atwood who think they're hot shit and who make computer science into an ivory tower are a major part of the problem, because those like my friend think people in IT are magicians or geniuses, when they are, in fact, just glorified problem solvers who, more often than not, are mostly just using prewritten APIs (including Atwood, I'll bet) that someone else wrote, which hide most of the code under a hood of abstraction, anyway.
can you explain to me how Michael Bloomberg would be better at his day to day job of leading the largest city in the USA if he woke up one morning as a crack Java coder (emphasis mine)
On preview -- in response, most recently, to b1tr0t, but also to the others with similar opinions -- why not just learn to code for the sake of coding? Why is that so obviously a "bad idea"? Why not tinker with things for the sake of tinkering with them? What's the downside here? It's fun, like doing a crossword puzzle or making a crossword puzzle. Why not know how to do more things?
The comment just earlier by novalis_dt, which was a repeat of the same argument made at least once before in the thread, is about as wrongheaded as it could possibly be (and, not incidentally, it's exactly what people were saying 30 years ago, and it's not become true)
I spent the last two years working with software engineers with real degrees and I saw some awful code. I was the author of the coding guidelines for my workplace.
As far as I know, Microsoft and most other companies that produce the software running on most computers, does not hire self-taught software engineers.
They recruit heavily from the CS departments at top universities.
Proper software engineering isn't in the code, it's in the design, in industry standard best-practices, the use of tried-and-true toolsets that are extremely well-understood. This is how actual engineering works.
That assertion is about as idiotic as they come. Programming is not basic in the way that math is. If you can't see that, then you don't know much about math, or programming, or both.
Similarly, the coding that melissam discusses is just coding, not software engineering.
And this is no small part of why our computers crash but our bridges don't.
1) One example would be a "data analyst", someone who takes data and analyzes it, often writing basic tools (perhaps in something like matlab) to apply different algorithms to it. - there are lots of jobs that basically boil down to this now. A lot of biology involves analyzing lots of data about gene interactions (or whatever). Knowing how to code well enough to extract the information you need can be helpful, but you don't need to ever release a product that doesn't crash. There was a talk by a lexicographer in an FPP a long time ago, who basically said a lot of her work was data analysis with computers. Her only product was a dictionary, but you have to write software tools to do the analysis itself.
2) Someone writing low level drivers or embedded software. Yes, you don't want the software to crash, at all, but at the same time you're writing fairly simple 'programs' that don't need a lot of complex algorithms - you just need to shuffle data from one device to another, but you need to keep track of a lot of low-level hardware details.
3) Game programming. John Carmak gave a talk recently discussing how Id was just starting to get into software engineering now that their codebases were getting larger and larger. For something like Angry Birds or a million other 99 ¢ cellphone games the code itself isn't that large, and it just needs to work and be stable, beyond that it's largely disposable.
4) User interface design, web coding - The job may be "design" but knowing JS and basic programming will obviously be really helpful. The code doesn't always need to be super complex, and if it seems to work, it can be good enough. If it fails every once in a while, oh well. It's not the end of the world.
I put the blame for our crashy computers mostly on C and C++. Any program you pick at random has a good chance of either being written in C or C++, or being executed by a VM/runtime written in C or C++. Your operating system is in all likelihood written in C or C++. These languages have a number of features that interact in spectacularly bad ways. They:
I'm contesting the notion that what end-users accomplish by crafting a SQL query today they'll be accomplishing by crafting SQL queries twenty years from now.
Yeah, but those are all pretty carefully delineated, in many cases requiring certfication, and an electrical contractor doesn't get hired to design part of your car.
There will always be people writing code. But we'll no more need everyone writing code in twenty years than we need everyone writing code today.
I agree with you about this. But, basically — and I've avoided this terminology because I've feared it would be provocative — I believe that the hacker culture is why this is the case. It's not that people want to be audidacts at programming, or do so. I largely did. Like so many others. But because there's so many of us, there's huge resistance to the cultural changes that would be necessary to transition to a true engineering paradigm.
It's insane. We're backsliding to 12+ years ago when companies were all sorts of clueless and cheap and wanted one person to do everything. It's a brutal fight, and not made any easier by the mindless parroting about "Everyone should know how to code". There's an increasingly real expectation that well, really, it's all the same thing, you know, and how hard can it be? Of course, heaven forfend that the salaries reflect the sheer amount of expertise demanded.
(coding literacy is a nice thing, but there are a lot of things that are more important, like learning to actually communicate with other people)
In fact, given the trajectory over the past few years the idea that we'll all have graphical logic tools is actually less likely then the idea that everyone will know how to program. It's actually something that was tried and given up on so far.
But that said, how is using a graphical query tool not "programming" or "coding"? It's the same thing, just because you're using a flowchart style layout rather then typing commands doesn't mean it's not "programming". The problem with graphical techniques is that they get bogged down when you start making things larger. That's why people use hardware description languages to design complex circuits, rather then laying everything out using CAD tools.
These concurrent models are not executable themselves; there is no "compiler" for them. As such, specifying these models is not considered "programming" or "coding" per se and hence does not belong to a programmer's lawn.
Instead, we can refine these abstract models into concrete executable code (e.g., C, C++, Java, Python) automatically using a code generator. This model-to-code generation is a popular topic in the model-driven development (MDD; not-so-previously) community.
Right now designers -- of both the visual and user experience persuasion -- are dealing with recruiters and job ads that are now asking for front-end (and, in the crazier ones, back end) dev chops. Not just HTML and CSS, but Ruby and PHP and my god, take your pick.
Programming is the most frustrating, difficult, low-status white-collar job available. You're on the bottom of the food chain in every company in the world. Money will be spent on floral urinal cakes before they buy the programmers new keyboards.
, "No, Advertising Exec Guy, putting a giant Flash ad on this checkout page is a terrible idea. We're not doing that."
Programmers don't command the sort of respect and investment in resources allocated to, say, partners in a law firm.
advertising is actually closer to design.
This is so, so very wrong.
« Older How Yahoo killed Flickr and Lost the Internet by M... | Many visitors to Boston assume... Newer »
This thread has been archived and is closed to new comments
Buy a Shirt