5 ms·

The upvote question is easy to answer -- this is Hacker News. Of course we upvote programming. And I agree with the point about writing. And I think we shouldn'

The upvote question is easy to answer -- this is Hacker News. Of course we upvote programming. And I agree with the point about writing. And I think we shouldn't read "everyone needs programming literacy" from hacking a ROM any more than we should read "everyone needs to know woodworking" from "here's a cool piece of furniture I built for my daughter." But I will try to answer the question about foisting software literacy, since you seem to be questioning the larger trend. The question to ask here is, what do you think the skills economy will look like in 15 years? Looking casually at the trends, it's difficult to avoid the conclusion that software is eating the world. My friends in scientific research have either learned to code or are hobbled by their inability to do so. Financial institutions are increasingly just software companies with some domain expertise; I know finance people who can't get jobs because--to simplify a bit--they don't know SQL. Many non-technical office workers I know interact with a computer on some sort of programmatic level (e.g. Excel macros) and almost all of them would benefit enormously from programming literacy to help them in that. And all of that is trending upwards quickly; that's why programmers are in such high demand. Cooking is great and an important personal skill, but it's only an essential skill for chefs, whereas if you can't code, you might become the equivalent of the guy who can't use email in today's office environment. So to me, it's a question of what the world's going to look like in the future, not a question of what's most practical around the house. Forecasting the future is hard and it's an interesting debate--there are all sorts of reasons software might be less important than we might guess, and of course software people are predisposed to think software will be super valuable. But I think it's the right way to frame the discussion: if software runs the world, you really need to know it. If it doesn't, you don't. I'm not accusing you of this because I don't know you at all and your comment doesn't suggest it, but I hear a little bit of insider entitlement in a lot of programmers' arguments against increased software literacy. "I don't want all those other people jumping in and pretending they're software engineers too. The future belongs to the select few, which happens to include me. Leave software to the pros!" It's seems absurd to me that programmers don't want more people to understand the ins-and-outs of their profession...unless they feel threatened by such a thing. There's something very fishy about telling people who don't code, "Oh, yeah, don't do what I do. Learn to cook instead." Are you sure we're not just trying to keep all the marbles?

alanctgardner2 14y ago
Personally I have no horse in the coding-skills race; I really enjoy problem solving and architecting systems more than writing the code itself. If there were lots of commodity coders, I could direct and manage them and enjoy myself plenty ;) From the 'software is eating the world' perspective, I see increased use of software, but not increased production in unconventional areas. If you look at the progression of home computers, we've gone from booting directly into BASIC, to an iPad, where you really can't do any development. The slow march to 'appification', and the trend of taking away customization and development tools from consumer-grade products makes me think that while software is becoming more important, average people need (and want) to code less and less. It's definitely a programmer's perspective to say that any knowledge industry (like finance) is just software + domain knowledge. Someone in that industry would approach it from the other end, and say that they can write a req and get some commodity software to solve their problem from some developer half-way around the world. This is where I think the industry is going: not universal programming literacy, but a more stratified culture where 'commodity' development is it's own discipline. Consider the ease with which any consultant can knock together a CRUD Rails app with some business logic the client specifies. We've removed a ton of overhead and boilerplate, and lowered the barrier to entry tremendously. As time goes on, and development technology advances, I see software development/engineering and computer science diverging more and more. At some point, development might be an apprenticeship or more 'hands-on' education, to learn the existing patterns and practices. In short, development will become a commodity, but via an emerging class of commodity developers who can handle 95% of client requests. There will still be people who do hard things, and hack in their spare time, and they'll make things better for everyone. But they'll stay in the minority, and development will stay out of reach for people who aren't explicitly 'developers'.
- icambron 14y ago
  > Someone in that industry would approach it from the other end, and say that they can write a req and get some commodity software to solve their problem from some developer half-way around the world. I agree that's how they'd like it to work. But in reality, their in-house teams have become more and more technology-oriented, and programming literacy has become a higher priority in hiring. An "analyst" used to be a clever kid with a finance degree; now they have a finance degree and are comfortable in VBA, SQL, and an analytics package. Badass programmer? No. Software literate? Yes. > We've removed a ton of overhead and boilerplate, and lowered the barrier to entry tremendously. Agreed (I'd caveat that by noting that we've also hugely increased our expectations for software functionality, but the point still stands). But note that all of these consultants who can knock out a CRUD Rails app still have to read and write code. What the lower barrier to entry means is that a bunch of people who previously couldn't do it now can, including potentially the business analyst who defined the requirements, assuming they have some basic software literacy. That's going to quickly translate--is already translating--into the expectation that the analyst can actually write the code. Being able to actually code your solution to a problem makes you more productive, because your employer doesn't have to pay a consultant to accomplish that work, and because there isn't an extra layer of communication overhead. So businesses will begin demanding software literacy as they become more reliant on basic software development (or, depending on prevailing labor conditions, simply paying more for it), because it makes them more efficient. This is similar to how productivity technology (voicemail, email, software calendars) hasn't made secretaries' jobs easier, or turned them into a turnkey commodity; it has largely eliminated secretaries and replaced them with the expectation that you do that work yourself. Same with travel agents. Same with tax accountants. As the tools allow for more productivity, people are forced up the productivity ladder. Progress. Being literate in software is different than being an expert software engineer, and fortunately for expert engineers, we can simply solve higher-level, or at least harder, problems, so this development is actually good for us. My view is consistent with your idea that there will be a bifurcation between hardcore developers building frameworks and a bunch people who know the basics and can use the tools. The only difference in our views, as far as I can tell, is that in mine, this army of "commodity" programmers fielding client requests will be the clients themselves, and not an outsourced stable of kinda-engineers. Those kinda-engineers will be employed at firms as business analysts, product managers, etc, because their computer literacy will be really valuable there.

alanctgardner2 14y ago

Personally I have no horse in the coding-skills race; I really enjoy problem solving and architecting systems more than writing the code itself. If there were lots of commodity coders, I could direct and manage them and enjoy myself plenty ;) From the 'software is eating the world' perspective, I see increased use of software, but not increased production in unconventional areas. If you look at the progression of home computers, we've gone from booting directly into BASIC, to an iPad, where you really can't do any development. The slow march to 'appification', and the trend of taking away customization and development tools from consumer-grade products makes me think that while software is becoming more important, average people need (and want) to code less and less. It's definitely a programmer's perspective to say that any knowledge industry (like finance) is just software + domain knowledge. Someone in that industry would approach it from the other end, and say that they can write a req and get some commodity software to solve their problem from some developer half-way around the world. This is where I think the industry is going: not universal programming literacy, but a more stratified culture where 'commodity' development is it's own discipline. Consider the ease with which any consultant can knock together a CRUD Rails app with some business logic the client specifies. We've removed a ton of overhead and boilerplate, and lowered the barrier to entry tremendously. As time goes on, and development technology advances, I see software development/engineering and computer science diverging more and more. At some point, development might be an apprenticeship or more 'hands-on' education, to learn the existing patterns and practices. In short, development will become a commodity, but via an emerging class of commodity developers who can handle 95% of client requests. There will still be people who do hard things, and hack in their spare time, and they'll make things better for everyone. But they'll stay in the minority, and development will stay out of reach for people who aren't explicitly 'developers'.

icambron 14y ago
> Someone in that industry would approach it from the other end, and say that they can write a req and get some commodity software to solve their problem from some developer half-way around the world. I agree that's how they'd like it to work. But in reality, their in-house teams have become more and more technology-oriented, and programming literacy has become a higher priority in hiring. An "analyst" used to be a clever kid with a finance degree; now they have a finance degree and are comfortable in VBA, SQL, and an analytics package. Badass programmer? No. Software literate? Yes. > We've removed a ton of overhead and boilerplate, and lowered the barrier to entry tremendously. Agreed (I'd caveat that by noting that we've also hugely increased our expectations for software functionality, but the point still stands). But note that all of these consultants who can knock out a CRUD Rails app still have to read and write code. What the lower barrier to entry means is that a bunch of people who previously couldn't do it now can, including potentially the business analyst who defined the requirements, assuming they have some basic software literacy. That's going to quickly translate--is already translating--into the expectation that the analyst can actually write the code. Being able to actually code your solution to a problem makes you more productive, because your employer doesn't have to pay a consultant to accomplish that work, and because there isn't an extra layer of communication overhead. So businesses will begin demanding software literacy as they become more reliant on basic software development (or, depending on prevailing labor conditions, simply paying more for it), because it makes them more efficient. This is similar to how productivity technology (voicemail, email, software calendars) hasn't made secretaries' jobs easier, or turned them into a turnkey commodity; it has largely eliminated secretaries and replaced them with the expectation that you do that work yourself. Same with travel agents. Same with tax accountants. As the tools allow for more productivity, people are forced up the productivity ladder. Progress. Being literate in software is different than being an expert software engineer, and fortunately for expert engineers, we can simply solve higher-level, or at least harder, problems, so this development is actually good for us. My view is consistent with your idea that there will be a bifurcation between hardcore developers building frameworks and a bunch people who know the basics and can use the tools. The only difference in our views, as far as I can tell, is that in mine, this army of "commodity" programmers fielding client requests will be the clients themselves, and not an outsourced stable of kinda-engineers. Those kinda-engineers will be employed at firms as business analysts, product managers, etc, because their computer literacy will be really valuable there.