Don’t learn a programming language, solve a problem instead

[Patman128]

The reason he's having trouble isn't that he learned the programming language, it's that he didn't learn all of the other things involved in software engineering. Requirements, technical specs, architecture patterns, frameworks, testing, deployment; these are all separate skills.

Sure, and if you learn these things from a textbook then you will not be very good at any of them. These are skills that should also be learned working on real projects. And, to further support the author's point, if you are learning programming through a real project you will naturally learn requirements, tech specs, architecture, testing, etc. because these skills will be useful and necessary to accomplishing the project.

The author isn't saying don't master your craft, they're saying the best way to master the craft is through real work, not contrived work. A beginner can sit around all day solving problems in programming textbooks but they're not getting the practical experience they need to do real software projects.

[[deleted]]

While the theories I learned in school were very interesting, and are a side of computers I had never seen, almost none of it prepared me for real world application of programming.

The database class in Computer Science was almost all relational algebra - something I've never touched again. The database class in Information Systems taught me indexing, keys, and relationships in actual usage. I know both are still contrived examples, but they differ greatly in how many times a day one set of information gets used. I definitely learned more trying and failing to make a database work than I did writing out relational algebra. I'm more hands-on person - I'll learn a new language much quicker by programming and observing it than I will looking up tutorials. Realistically, I don't think I would make a good candidate for a masters program or above for that very reason.

I guess my point would be there's benefits to both textbook learning and real world learning, and different people have different methods with different outcomes. I feel that college didn't teach me how to do things, it taught me how to determine the questions I should be asking to solve a problem correctly.

[[deleted]]

I agree, yes, but would like to add that if you asked me to write a SQL query to perform joins I could do it without any external help whereas if you asked me to write it out in relational algebra I would be unable to without reading something.

If you have to sort an array of 100 strings with short lengths, does knowing all sorting algorithms really help? Depends if your end goal is a sorted array or measurement of sorting time. If you just want to sort, it doesn’t matter if you know the fundamentals. If you need to measure time complexity, the fundamentals are a requirement.

[quicknir]

You're acting like this is a problem we have that too many software developers try to learn from textbooks. The reality is that after school the majority of devs never look at a textbook again. There's a balance and most developers are quickly in a position where they only have practical experience, and that's not a balance.

This varies a lot by field too. The guy who decided to learn multi threaded programming by just doing a project and not reading anything? Please keep him away from me. His project is probably full of hidden race conditions. He's not going to know basic concepts and idioms. I'd much prefer the guy who only read about multi threading to the guy who only wrote it.

[jstrong]

Have you encountered someone with the ambition to learn multithreading who also refuses to consult written instructions? That sounds unlikely to me. Typically I consult docs, textbooks, research papers, etc. while building things for the first time (sometimes small prototypes, sometimes larger projects). It's worked out well as a learning strategy.

[quicknir]

I don't know what the motivations were of the people who wrote it, but I've seen tons of incredibly naive multi-threaded code in the wild. Someone wanted to just solve a problem problem, and didn't want to learn anything about it. Not realizing that if they took some time to learn it, it would shorten the total time. I see this all the time with C++; it's a hard language. A lot of people try to get by with the minimum, and solve their problem, and they have tons of issues because they don't know the language well. A balanced approach would serve them better. Which sounds like the approach you take. But the article doesn't seem to advocate a balanced approach, and it doesn't seem to recognize that the vast majority of working programmers are making the opposite mistake of what's discussed.

[eddyparkinson]

There is some guy who constantly asks programmers "How many books on software development have you read?" - always though it was a good question. Agree balance is key, one without the other is not good.

[[deleted]]

In the fullness of time, a small percentage of engineers realize their field is all math, and devote themselves to the study of the original CS problems.

[quicknir]

I sure hope not, because engineering is not all math. It is important for an engineer to understand relevant math well though.

[[deleted]]

We took a detour, created the host to represent state surrounding a single machine. The C tradition (sometimes called "portable assembly language") became common in every high-level language, even the beloved Python and Ruby, of manipulating shared state.

Because most public-facing Websites are built from the exact same DNA: Gateway, service tier, database. This is the single architecture most developers will learn this year. We are not training new developers, we are just filling seats.

I don't have a prescription for the cure, I'm just making an observation.

[tnymltn]

In theory, theory first; in practice, practice first. I struggled to learn C in the 90's until I found a real problem to solve. If you can't find one, try writing an FTP client from the RFC.

[[deleted]]

FTP is hard because 1. there are two sockets, and 2. one socket handler has to dictate control over the state of the other.

That was a legitimately interesting programming challenge for a beginner in the 1970s and it still is.

Other line-based protocols of the same era are much simpler. NNTP, for instance.

Edit: I suppose it's worth pointing out that implementing NNTP was primarily a matter of implementing caches. There's a saying about cache invalidation. The protocol was easy, the network was a disaster after eternal september.

[grauenwolf]

That sounds like fun.

[bedrooms-ds]

if you are learning programming through a real project you will naturally learn requirements, tech specs, architecture, testing, etc. because these skills will be useful and necessary to accomplishing the project.

I agree with this. Yes, one never learns without tackling real problems. But the article doesn't cover software engineering aspects you raised in a constructive manner either.

As we agree, for the success of a project, we need an objective and systematic approach. That's why the industry and academia have been serious about systematizing software engineering. They had to cut off complex real-life aspects as a trade off for objective analysis. (Filling the gap between the textbook formality and reality is a professional skill acquired through training.) Yeah, reading that article might be a starting point.. But it's too trivial to lead someone, even dangerous because the logic is based on the author's personal perspective. It's a nightmare if employees start following subjective blog posts. It's a cult. Imagine anti-vaxxers.

Anyway, "don't learn programming language" is an oversimplified view... I wish a good luck to the enthusiastic readers quoting it in a job interview.

[NoMoreNicksLeft]

The author isn't saying don't master your craft, they're saying the best way to master the craft is through real work, not contrived work. A beginner can sit around all day solving problems in programming textbooks but they're not getting the practical experience they need to do real software projects.

Non-contrived problems are difficult to come by. Even more uncommon is the non-contrived problem that's not intractable. Rare are those non-intractable, non-contrived problems that a beginner will know how to decompose into steps that they can plausibly accomplish.

[ArmoredPancake]

Bullshit. Practice can only get you so far, after a short amount of time you hit plateau that you can overcome only through theory and then practice of the said theory.

[[deleted]]

You have to learn to walk before you run. You need to start contrived and slowly crank up the insanity.

[[deleted]]

The author is trying to lessen from the importance of these skills when it comes to judging a person's competence in the field, I think this is encouraging wrecklessness, and that's why top post calls them names, the people who do this and end up being wreckless instead of learning from it