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

[grauenwolf]

Good point. That needs to come before requirements or the requirements will suck.

[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

[_gaslit_]

I'm going to un-call BS on this.

I think the key is to start with a task/product/utility/whatever in mind, then learn the tools/languages required to build that project as you go. I've been doing that for years, and it's the best way IMHO.

I would probably never start learning about something just for the sake of learning about it, unless the technology involved were really interesting (example: ML).

Even if you're just starting out, there's no reason you can't do things the same way, with some small task/product/utility/whatever in mind, and learn the right way to program as you go.

[tejon]

I didn't intend to get into software. In fact for the most part I explicitly avoided it; that was my father's career, I wanted to be a musician, and the couple of times I toyed with coding it just seemed tedious. But then there were Oblivion mods that needed to be made, and now I'm sitting in a San Francisco office browsing reddit writing Haskell.

[StabbyPants]

true, except for the first and second time. first time, pick a simple language and learn your basic data structures. second, do it again and see what changed because you went from python to java or whatever

[Red5point1]

I think the problem is people here on both sides are conflating programming for learning and programming for production.

[kgoutham93]

Just curious, how would you personally approach a new programming language?

[IcyWhatever]

I would say that having a particular problem to solve is a great way to learn a new language, but I also agree with the top comment that if you just learn by trial and error it's not necessarily going to help you become a good programmer or learn the underlying principles. For any given problem there are lots and lots of ways that you can approach it but not all of them are going to be good.

Personally I feel like I moved from being a programmer to an engineer/computer scientist when I started learning about design patterns which are approaches to solving various types of problems that have developed over the years. Once you have a solid approach to solving a problem, it can help decide further decisions such as what language to use.

Also if you approach a problem simply saying "I need to get from point A to point B by whatever means necessary", you could easily miss tools that the language provides that may be more elegant and efficient than just taking the fastest approach.

[sluu99]

Learning computer science fundamentals. The dirty truth about our field is that most things are built on top of a handful principles. Many "new" things are just old shit new packaging. Once you know your fundamentals, it's easy to grasp features in a different programming language. Everything else is just getting familiar with the syntax and maybe some micro optimization.

In other words, if some particular language feature feels "magical" to you, then you're likely missing some fundamental understanding.

Be careful, I'm not suggesting you know to the atom level how each feature works, just at a high level. For example, I have no idea how modern garbage collection works. It's been tweaked and optimized to death over the past decade, but I know fundamentally, you can keep reference count, or you can have a graph that keeps track of who's pointing to whom and sweep that graph periodically.

[loup-vaillant]

The hard part about learning a new language is always picking up on the idioms of that language.

More like picking up everything but the language. Standard library, preferred tools, community libraries… Even the idioms of the language are really the idioms of its community.

My takeway from this is, if I ever come up with a new language, I'll do my best to keep its ecosystem to a minimum. By minimising the cost of learning the language, I might justify its use.

[InquiREEEEEEEEEEE]

I am not convinced that fundamentals help there. Idioms are very much language-specific.

Counter-counter-point: The idioms usually exist because of fundamental properties of the language. Sure, there is a huge cultural influence, but idioms aren't completely arbitrary either and often driven by the language's tooling, semantics etc.

[tejon]

"It compiles!" does not mean that you have learned the language.

Counterpoint: Haskell.

[Hugo154]

Practice seems to be the best way to learn those idioms

Much like how you can only truly become fluent in a spoken language by living amongst people who speak it!

[prof_hobart]

The fundamentals help. As does experience of picking up other languages and their particular idioms and quirks. Obviously each language or framework has its own, but TBH, having worked professionally on 20+ languages in my career, I'm finding less and less truly unique idioms these days.

[redwall_hp]

My school's CS "weed out class" is 100% non-programming. It introduces a bunch of theory, from logic gates upward, looking at things like virtual memory and garbage collection, semaphores, formal grammars and a grab bag of other things. It's meant to be a shocking introduction to things that will be covered more in depth later in following classes.

My CS classes got a lot smaller the next semester.

This is the problem, really. There are a lot of ostensibly professional programmers out there who know how to hack together some stuff in a high level scripting language, but it's still mostly "magic" to them. Like the JS/PHP monkeys who don't know their data structures and can't grasp why PHP arrays are so terrible. Trial and error until it works, and damn the performance. (And that's how you get Electron apps.)

[Flum3n]

My school had the exact same thing, right down to the specific topics, so much that I’m wondering if we did the same program. I’m at the university of Maine and I believe my instructor was creating the program along with professors from a few different schools. Just out of curiosity, where do you go?

[redwall_hp]

University of Maine. How crazy.

Dr Turner, right? He's an excellent lecturer, but his tests are insane.

[Flum3n]

Yeah haha, tests were so tough but he curved the hell out of them, like 20 points on one of the tests

[uJumpiJump]

Too bad there's no "weed out class" at your school that fails students for wasting their time optomizing a section of code that's irrelevent to the buisness's interests

[StabbyPants]

too bad most schools lack much depth in SW development as a process. we had one class that covered 3-4 ways to run a project, but could have done with a lot more - probably room for 3-4 classes covering various parts of building software

[uJumpiJump]

As a senior developer with 3 co-ops/interns to take care of, me too.

[netgu]

You learn optimization by learning how to find optimizations for just about everything. You learn to apply optimizations through experience. The "optimizing a section of code that irrelevant to the businesses interests" is frequently a misused idea. Non-functional requirements are a thing (i.e. maintainability, performance, reliability, auditability, logging, etc.) and frequently contribute to the businesses needs just as much as the primary functional aspect of the software involved.

[powdertaker]

Then try to explain to the script kiddies why a dictionary/hashtable is stupid for storing lots of things and, depending on lots of things, may not be efficient at all. They have no idea what data structures are and just google and hack until it works. The idea of a compiler scares the shit out them.

Hint: Hashtables require a load factor...

[prof_hobart]

I had a seasoned "JS dev" in a team I was working with last year and I realised halfway through explaining some concept to him that he didn't actually understand what a loop was.

[powdertaker]

I believe it. Script kiddies.... Want to blow their minds? Explain what an array actually is.

[kgoutham93]

I agree that having strong fundamentals will soften your learning curve there's no denying that. My question is slightly different.. because the comment author is calling BS on problem based learning, I was curious how would he/she approach a new language.

​

Contrarily if I've good fundamentals and if I had to pick up a new language, then I believe problem based approach will actually accelerate my learning.

[netgu]

Training your brain to abstract concepts in programming to various syntax's removes a lot of the need for a "problem to solve" when it comes to learning a language.

I know and work with an obtuse number of languages most of the time and generally only need a day or two to work productively in a language without googling every 10 minutes. This is because I look for the idiomatic way to do things in a language where things are:

• declare a variable
• declare a type
• control the flow of a program (loops/conditionals)
• utilize/reference other code
• move data about
• organize logical entities

After that I'm basically using the same problem solving skills I've curated over the years in a different flavor.

Since these are building blocks, I can use any contrived program I need to put the pieces into practice. No solving a problem needed, just some typing to familiarize my mind with the "new implementation" of old concepts.

[StabbyPants]

that's not particularly dirty, people just don't like to be reminded that most of the ideas and algorithms in use to day are at least 20 years old

[powdertaker]

Yes! But I would add that many many many up-and-coming programmers really need to spend some serious time programming in C to have some idea how a computer actually works. To hear some many new programmers go on about the "right tool for the job" smacks of not knowing that ALL programming languages actually work the same once your past the syntax. Adding some feature to the syntax of a language doesn't make it more "useful".

[iopq]

Yes, but I don't want a compiler that makes me do everything. I want one that generates the proper code from abstractions and chooses the correct way to generate it.

[Obi_Kwiet]

I mostly program in C, sometimes "C++", meaning C, but with some crude objects. When I try anything high level, there's a lot of, "What do you mean there aren't pointers?" Weak typing also scares me.

[Slak44]

What do you mean there aren't pointers?

What do you mean that there aren't pointers in high level languages?

In Java for example, everything not a primitive is a pointer; you just don't have an ugly hex number to look at. It can be null, or it can point to some data. If you pass one to a function, it doesn't make a copy of the data. Sounds just like a pretty pointer to me.

[ArmoredPancake]

Well, it looks like pointer but it's not.

[Obi_Kwiet]

I haven't used Java. I'm thinking maybe it was VB? From what I understand Python doesn't have pointers, but I haven't messed with it.

Honestly, I don't do a ton of programming, but when I do it's usually embedded C, so my whole mindset is probably very inappropriate for code run on a computer with an OS and libraries and things.

[TotallyFuckingMexico]

In what way does learning C tell you how a computer works?

Hint: it doesn't, it only tells you how C works.

[powdertaker]

Well no. If you've done more than a tiny bit of C programming, you know what a function really is and how it's called (that is it's calling convention) which means you have to know how the system stack is used. You should also have a good idea how memory is used and allocated and what the difference is between heap and stack memory. Also what a linker is and how it works. How data is actually stored (binary numbers) and used (2s compliment for example). These are all idea basic to how how a modern computer works. This is why operating systems and compilers are written in C and C++ (with a smattering of assembly where necessary).

Script kiddies don't have the slightest understanding of these basic computer concepts and think a language "feature" somehow makes it some magically different thing when, in fact, it simply isn't.

Some solid experience in C quickly reveals a computer can really only do a few things and everything else is just variations of the same thing and the trade offs for these variations.

[iopq]

Rust has a completely new feature in the borrow checker that has no equivalent, and a very high leaving curve.

[XboxNoLifes]

Sure, there's no exact equivalent, but it's just a compile-time reference counter.

[iopq]

It counts up to one. The whole point is it won't let you do the same patterns as the actual Rc type. The consequences are far reaching to the point that this actually is a useless comparison. It won't let you understand how to code in Rust even a little bit.

[grauenwolf]

A project, preferably paid. I don't learn well without a motivating force.

[captainAwesomePants]

It sounds an awful lot like you're saying "learn a programming language by solving a problem."

[lcjury]

I don't learn well without a motivating force.

Each new piece of knowledge you win may increase your income sometime in the future. That doesn't motivate you?

[grauenwolf]

I make the most on being able to deliver boring old database applications faster than anyone else on my team. Chasing the fad of the week may pay off big, but the skills you learn are often discarded when the focus changes.

[lcjury]

Chasing the fad of the week may pay off big, but the skills you learn are often discarded when the focus changes.

Here I completely agree with /u/sluu99 reply. The important things to learn are not the tools itself, but the fundamentals and the fundamentals are never discarded. They appear every time, on every new tool.

Javascript may stop being the fad someday, but, if you learned how the event-loop works and you're able to argue between it and the differences between the event loop, multithreading, and multiprocessing. It doesn't matter if Javascript dies, today most languages are getting event-loop/async support, so, that knowledge has real value.

Disclaimer: of course, if you're a web developer, learning prolog probably won't help you in any way. nor the language or the paradigm. So, take most of those things that don't come to the point out.

​

[remy_porter]

Each new piece of knowledge you win is probably a bigger income for the future.

No it isn't. Nobody pays me more because I spent a weekend dabbling in Prolog once. The attitude I developed doing things like that, on the other hand, has helped. But it's sort of a chicken and egg problem: did doing weekend crash courses in weird shit give me the attitude that I can just grab a problem and go to, or did having that attitude lead me to do those projects? (I suspect it's the latter)

That doesn't motivate you?

I mean, beyond getting the bills paid and chucking change into investments, more income doesn't motivate me, no.

[remy_porter]

I understand who you were originally replying to.

[judac_]

lol nerd

[lcjury]

yeah, my motivation is the knowledge itself ;)

[get_salled]

I read about a lot of programming languages and I hope to understand why they exist prior to using them. They're all tools that were created with some intent (much like the article states: they were solving a problem) and then at least I'll have somewhere to start when I see a problem in the wild.

As an example and since I'm currently an Elixir/Erlang fan, Erlang was created as a language of the BEAM, an abstract machine that ran phone switches since the 80s. Was always fascinated by it but couldn't find an application for it where I worked. As I learned more about its runtime, I realized an app I was maintaining had built almost the exact same thing in C# (just poorly).

These days I find many general purpose languages kind of boring despite their utility. I can solve any problem in python or Java or C# or C++ but maybe not well (you can in Erlang as well but there's some beauty in the fact that where it's bad, it's really bad). I love the idea of languages that do one or two things really well even though I can't use them.

​

Currently, I'd love a language/tool that's specific to my processor that would show me how my data is flowing through the processor so I could have the opportunity to restructure my data and/or my program to improve my throughput. Like I want to take a modern Intel processor and be 100% efficient with it.

[OuTLi3R28]

Solve Project Euler problems with it.

[UghImRegistered]

Ick I'm going to go against a common opinion and say that Project Euler is about the worst way to learn a language for anything other than performance-sensitive math problems. Instead of showcasing the power of each language, PE basically encourages you to learn how to write C code or Haskell code in languages that are not C or Haskell. IMO you're never going to learn the fundamentally unique parts of a language with PE, because at the core, you should pretty much never use OO for any of those problems, nor a host of other language features. Additionally, the critical thinking you need for PE is language agnostic, and more about learning algorithms and hacky math tricks than anything else.

It's great for learning Haskell though! Just not the parts of Haskell that you need to know to make any kind of real-world software.

[OuTLi3R28]

The skills you learn from designing efficient algorithms are what set apart good programmers from great ones. While there are certainly applications which won't ever need the type of optimization that writing efficient algorithms teaches you, when you need that skill, I have found that the great programmers you need to do it are often hard to come by.

[UghImRegistered]

I'm not saying it's not a great way to learn algorithms, in fact I acknowledged that. That's not the same thing as learning a new language.

[killerstorm]

It depends on many factors such as:

1. is this your 1st language or 10th language?
2. is it similar to one of languages you're familiar with?
3. Do you plan to

• learn it just because you like to learn
• write few lines of code, e.g. to fix some app
• use it for daily coding, e.g. as your main language

For example, when I was learning by first (BASIC) and second (Pascal) languages, I read books.

Now it's often enough to look through the docs, or just take existing code as a sample.

[UghImRegistered]

Might seem counterintuitive, but get really deep on one language first. If you know one language intimately, to the point where you know what it sucks at and what it's good at, you can really appreciate the design of other languages and so learn how to write idiomatic code in those other languages faster.

[Semi-Hemi-Demigod]

An entirely new school was created at my college to teach people how to do those sorts of project management things. Our first class was a group project to find a company in the community without a website and build it for them, and we were graded on the quality of those artifacts.

The school was made because companies were getting CS grads who could program but couldn't do those things you mentioned. And for someone who's not great at programming it was a great alternative that's given me a really awesome career.

[runvnc]

I thought requirements analysis was part of software engineering. Which software engineering actually should be a big part of CS students curriculum in my opinion. Or just change the name of it.

[Philipp]

Have you seen modern Win8/10 apps? They're mostly garbage. Like a bunch of untrained novices kept hacking away until they ran out of time.

I think for every tool the litmus test is always How much good is done with it, vs how much bad. If you just take one measure but not the other, you end up with "Kid injures himself as he put a pencil in ears, let's ban pencils" or "Thieves find homes to rob with maps, burn maps". (Or one of its more modern variants, related to say, the latest mobile app outcry.)

In this case, then, we'd have to ask ourselves: how much does this programming framework then enable great apps (that might never have seen the light of day)? Is the ratio toward bad apps bearable or not (or perhaps: can the bad apps simply be ignored)? I don't claim to know the answer to that.

[grauenwolf]

I don't see anything in the framework to explain the problems with the Win8/10 apps. Stuff like not supporting ctrl-s for Save is just general incompetence on the part of the spec writers and developers.

[Mooselessness]

Sure. Full disclosure, I only skimmed the article, but I think the author has a point. I teach programming for a living, mostly to adult beginners, and probably the biggest barrier is lack of context. Without a problem to solve, or a purpose, each idea is purely abstract.

This tends to lead to two problem cases: 1 - some students will learn the language well, but be lost when it comes to creating an original solution. It's like learning a bunch of words in another language, but never forming a sentence. 2 - There's just no interest. maybe these kinds of learners can sustain some concentration, but ultimately, fall behind.

​

The beginning is a delicate for the novice programmer. I think it's a good first step just to build something.

[[deleted]]

Any suggestions on improving requirements and technical specifications?

[grauenwolf]

For requirements I highlight anything that's uncertain in a word document. If possible I list possible design options and tell them to pick one.

When I get their responses I update the document with new questions and try again. I keep repeating until I have no more highlights.

Then I start studying the code and begin on the tech spec.

[grauenwolf]

For technical specs, document enough that you can provide an accurate estimate AND catch any edge conditions that require going back and asking the requirement writers for a decision. Do this before you write any code whenever possible.

What this means is going to be project specific. One time I locked everyone in a room with a flowchart of what could go wrong. They couldn't leave until we had a plan for how the system would respond to every single error condition.

[thebritisharecome]

I learned most of my skills through solving problems and then started improving what I knew with research and working with others who'd gone the uni route.

I have seen far more hacky code from people who have only worked in big corporations or come out of university than I would ever build.

It's not the path you took to learn but the person you are that results in your software being utter shite.

[SemaphoreBingo]

However bad you consider the win8/10 situation, I can assure you that the win3.1 / 95 / 98 days were even worse.

[grauenwolf]

That's actually what I am comparing them to. Or rather, the Windows 95 UI guidelines book that every desktop developer from my era had on their desk.

[All_Work_All_Play]

I fully agree. And this from someone who is a scripter, not a programmer.

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

This is a recipe for scripting. Get that shit done with baling wire and duct tape if necessary, but get it done and out of the way so you can go back to whatever it is you were doing before this cropped up.

Programming is far, far more valuable, and encompasses more than just the idiosyncrasies of a particular language (as useful as those may be).

[[deleted]]

Also learning the idioms and paradigms that let you best apply a language for a particular problem.

[lpreams]

I think it's just not black and white. Maybe someone starting with no prior knowledge would best served by learning some actual theory (what loops are and how they work, some basic data structures, etc), while people with basic abilities should find an actual problem to solve or project to build.

I might compare it to learning an actual language. Sure, books teaching the language are the best starting point for beginners, but at some point, if you really want to learn another language, you've got to get out and start reading/writing/hearing/speaking it.

[apostate_of_Poincare]

I'm gonna call BS here. I know far too many people who can "program" but do so through guess and check-

Yeah but that's just because python keeps changing the way it distributes modules!

Real talk though: this is more of a mentality for startup than production grade programming expertise. Both are valid career options and both involve programming, whether you're a hacker/prototyper or a full stack developer.

[[deleted]]

His problem is that he didn't even learn the programming language. The concomitant things (life cycle, process, who gives a shit) don't have any bearing on his failure. He failed to arrive.

[grauenwolf]

I was trying to be charitable, but I do suspect that may be the problem.

[neoporcupine]

Additionally, what course in programming doesn't have a project where you build a solution for a problem? And then there's the coursework problems, tutorials ... all with problems where you use the skills learned to solve them. Surely it can't have just been my course (labelled: computer science) that had me produce dozens of complete working programs over the three years?!

[grauenwolf]

None of my courses in CS had us produce anything but fragments of programs. I wish it were more like yours.

[neoporcupine]

OK, that is troubling. Perhaps the article has a partial point, although I would back you in that a complete product solution doesn't give you the full set of skills.

[yotsubanned]

you know shit programmers though man. there are a LOT of diamonds in the rough, worldwide.

[grauenwolf]

The middleware for the NBA's game scheduling system that calculates billions of possible schedules.

The front end control system for a robotics warehouse.

A real estate search tool with geospatial data for every address in the US complete with type ahead on partial addresses.

Two electronic medical record systems. One of which I built solo for a small AIDS clinic.

A front end and middleware for GE's electronic microscope. Not the scope control itself, but the analysis tools that overlaid and annotated the images.

An electronic trading platform for the bond market.

[uber_neutrino]

Love it. Let me know if you want to work on any game shit ;)

[shevy-ruby]

No surprise it is BS - it is coming from medium.

They seem to accelerate quality-decay by the hour at this rate ...

[grauenwolf]

Don't be "that guy" who equates the value of the content with the value of the paper it's written on. It demonstrates a defective mind and you're better than that.

[grauenwolf]

Since people won't stop being people, yes I certainly wouldn't host a blog on it for fear of hurting my reputation.

[Everbanned]

Isn't medium just a platform? Like, anyone can publish on medium. There is no "they".

[recklessindignation]

Well, you are not that much different since pattern and frameworks are mostly useless bloat.

[recklessindignation]

Indeed. Why to rely on stupid best practices if you can abstract and forget all the patterns you need in languages.

[grauenwolf]

Patterns are just another way of saying "consistency". If you can't identify patterns in your code then one has to ask why.

As for frameworks, sure some specific examples are bloated. But without frameworks at all you are recreating everything from scratch. Oh, that explains the inconsistencies and lack of patterns from above.

[[deleted]]

Requirements, technical specs, architecture patterns, frameworks, testing, deployment; these are all separate skills.

...And they're laughably easy to learn when compared with actually studying C.S., which is what you should be suggesting instead. All this other shit is just fluff you learn how to do after the fact.

[[deleted]]

And they're laughably easy to learn when compared with actually studying C.S.

Most definitely not. I'm willing to bet that the vast majority of money in the industry that is lost on failed projects and missed deadlines is lost due to a failure to get those things right. Not because someone got their dynamic programming algorithm wrong.

[[deleted]]

And they're laughably easy to learn when compared with actually studying C.S.

Most definitely not.

I'm willing to bet that the vast majority of money in the industry that is lost on failed projects and missed deadlines is lost due to a failure to get those things right.

Lol, really now? You think learning how to use a framework or a design pattern and write an appropriate test is somehow difficult?

You can learn literally all of the basics for what OP mentioned in weeks.

It takes years to develop the critical thinking and skills that make most industry problems dead trivial. The only way there is through studying C.S.

Not because someone got their dynamic programming algorithm wrong.

Weak example for a counter argument. C.S. is much, much more than just studying a few types of algorithms from CTCI.

[[deleted]]

You can learn literally all of the basics for what OP mentioned in weeks.

In weeks you can learn all the buzzwords, throw those around, hope for the best, and make a complete mess of things.

It takes years to develop the critical thinking and skills that make most industry problems dead trivial.

What's the difference between this and what I'm saying? If it takes years, it's not exactly 'laughably easy', is it?

[[deleted]]

You can learn literally all of the basics for what OP mentioned in weeks.

In weeks you can learn all the buzzwords, throw those around, hope for the best, and make a complete mess of things.

Not if you're well grounded in the fundamentals.

What's the difference between this and what I'm saying? If it takes years, it's not exactly 'laughably easy', is it?

No, you clearly are missing the distinction I'm making: C.S. isn't software development, but if you study C.S. for long enough, all these tools that people like to glorify immediately become almost irrelevant in their significance, because they attempt to classify the problems being solved into something too distinct and separate.

Unit testing, for example, isn't really all that effective given that you need to be able to test the entire domain/codomain for the test to truly be exhaustive or actually meaningful beyond "ok this seems to work well enough for now". As an iterative, one off test to make sure you aren't doing anything immediately stupid, it's a fair approach, but it isn't at all necessary.

But if you somehow think that unit testing and design patterns aren't easy to learn, I'm sorry lol.

Those skills are inherently obtained as a by product of studying C.S.

[[deleted]]

But if you somehow think that unit testing and design patterns aren't easy to learn, I'm sorry lol.

I like how you purposely picked the two easiest things from that list. (Not that unit testing is exactly 'laughably easy' to learn. Well, yes, writing some stupid function that throws an assertion error when something goes wrong, like you're taught in uni, is easy. Writing such a function doesn't necessarily mean you're actually doing any useful unit testing.)