I'm looking for courses that seem to be the opposite of this... no language or programming at all, but instead looking at the process of breaking down problems.
We've hired several devs out of bootcamp, and they're all taught how to code, but not how to solve problems using code...
Anyone have material that might be good for this? Books, videos, courses?
Thank you so much for posting these links. I started reading How to Solve It and am a few pages in, and am so happy to have found this book. This is the value that I find here at HN that keeps me coming back every day. The new tools and new technologies, and the interesting tech news are all very interesting, but none as valuable as the gems that people leave in comments for others to discover, thereby enriching their lives.
Put the newbie gumshoes to work by tracking down simple bugs and designing simple patches to fix them. They need to be able to read other people's code to decipher and debug the coding style they are seeing before they are allowed to build any new module themselves. They need to understand other styles so they can form their own. They should be able to detect any code "smells" and reason with pros/cons why their implementation could work better and provide proof (like execution timing or better readability).
Playing a lot of puzzle games help as well, especially games where the thing to do is very abstract like in a point-n-click adventure game.
>> They need to be able to read other people's code to decipher and debug the coding style they are seeing
>> They need to understand other styles so they can form their own
After 15 years of working professionally, I kindly have to disagree to a fair extent. It turns out that most - if not all - developers are not very good at writing clean code. Including (especially?) seniors who think they write the best code on their team. The code you're having the juniors dig through to tweak/maintain is probably terrible code that should not be used as a shining example of anything good. They're more likely to pick up someone else's bad habits than learn something useful.
It took me a very, very long time to realize that it's simply a matter of fact that no two developers think alike, and that any set of developers could argue all day as to why each other's code is ugly, unmaintainable, etc. There are extremely few instances where one implementation of any problem is "better" or "worse" than another - we simply think differently. My code will always be "smelly" to you, and your code will always be "smelly" to me.
Junior developers must be permitted to write new code from scratch. Whether it hits production as-is, or goes through weeks of refactoring, it's a must. No developer ever improved by only reading and maintaining other people's code. I have never met a developer who feels at home maintaining someone else's rushed garbage. And 80%+ of the code we write is rushed garbage to attain the 3 week mandatory deadline handed down by management even though we told them it would take 3 months.
There is a finite amount you can learn by reading other people's code. You might find specific idioms you admire and adopt, but you will not - and probably should not - try to conform to other developers' methods.
Not to mention, forcing new recruits to deal with everyone's legacy garbage is a surefire way to turn them off the industry before they've even begun. Let them code a small new feature; then sit down and find out what they did well and what needs improvement; truly tangible issues, not the typical "that's not how it's done" - which really only means "that's not how I would have done it".
>> It took me a very, very long time to realize that it's simply a matter of fact that no two developers think alike, . .
I was part of ThoughtWorks interview process sometime back. In one of the rounds called Pair Programming, a senior developer worked with me on the given problem statement. I arrived at right solution, but he wasn't happy with the solution just because he didn't like the way I solved it. I came back and discussed the same solution with another senior developer and he liked the approach. However ThoughtWorks rejected me in the interview process.
I often wonder how pair programming is good (or even bad) in this context. How they can assume or think that two programmers going to solve the problem in "same" (or even ThoughtWorks "expected") way!
>> How they can assume or think that two programmers going to solve the problem in "same" ... way!
It takes a lot of restraint and stepping back from being in "first-person developer mode" to understand that someone else's unique approach is quite likely valid. I purport to be able to do so but I still find it incredibly difficult to ignore my brain's initial instinct to start pointing out the supposed flaws in someone else's structure, when the simple fact is my own code for the same problem would probably be filled with the same holes - just in a different form.
Honestly, there are only a few metrics that really matter when it comes to quality code:
1. Does the code accomplish the task it's supposed to? I mean really, this is practically the only thing that really matters in most cases. Simply: if deployed, will it work?
2. Are there no glaring security problems with the implementation?
3. Does the code not excessively overuse resources (cpu, memory, network/system calls, etc.)? Real excess beyond what is reasonable, not micro-optimizing.
4. Is the code not a complete mess? No serial use of copy/paste, crazy spaghetti mess, or inability or blatant refusal to follow basic coding standards?
That's it. Deploy that shit, and move on to the next problem. ;)
This is exactly what I was thinking! The points that were written is just as what I had in mind. But I guess still your missing one important point on testing. The code should work if deployed, but at the same time, we need to have through testing for the same.
I always start with reading test cases rather than source code directly. Thats the way it should be (IMHO).
After experience with several junior developers I plan to do the following to train the next one. First, let them solve an isolated problem in our code base. At pull request step comment excessively (this is what inevitably happens with all junior developers, the PR is so huge that GitHub chokes on it). Finally, pair them with a senior developer to solve the issues raised in the PR, rather than letting them fix them alone and engage in an endless loop of commits and comments.
Your advice here probably applies more to beginner programmers where the goal is to prevent them from just copying/pasting code and following bad practices. It's a good thing for them to learn to write things from scratch. I've been programming for a while and I've felt for a long time like my skills kind of plateaued. Writing things from scratch and reading a lot about design principles haven't really helped me improve at all. But lately I've started to read code, really read it to understand what it does and this has vastly improved my skills.
> There is a finite amount you can learn by reading other people's code. You might find specific idioms you admire and adopt, but you will not - and probably should not - try to conform to other developers' methods
From my own experience I disagree with this since reading other people's code has helped me improve a lot. I've noticed that I am so much more creative and intuitive about good software design when I go to write code now and I believe it is credit to reading code everyday
As much as this is mostly true, its not always true... I've met at least 3 developers in my career i consider to write very good code, often better than my own... and a small handful i consider 'not-shit' and 'employable'...
The vast majority are just shit though. That was a hard lesson to learn. You want to give people the benefit of the doubt, but the industry is full of people who have learned nearly nothing in their careers compared to a really good grad who has never worked anywhere but has raw talent and good problem solving skills.
I'm hoping there's a way to teach them problem solving BEFORE they learn to code... I feel like it should be a prerequisite to enrolling in the bootcamp. I don't remember how I learned it, but it certainly wasn't reading other people's code at my first job.
Some people can be taught to write code, however far fewer can be taught to or have the natural ability to problem solve. This is the 'art' aspect behind software development that I feel the 'teach everyone to code' approach overlooks. With any creative field there is a huge amount of 'prior art' that exists and that is also constantly evolving, and the more of this you are at least aware of or - better still - capable of reproducing, the better you will be able to express yourself / problem solve with software.
I hope I am not alone in feeling that looking at the code of a well-engineered and well-structured project can be quite the artistic-appreciation experience, and that this experience always leaves you with some piece of knowledge and understanding you didn't have beforehand.
I know that I learned the basics of chaining things together to get an effect by experimenting on my own in QBasic; basic graphics and audio were super easy, so I could also experiment with the difference between internal data state and how to represent that state.
When I started a directed education, learning new programming concepts always expanded the set of problems that I could solve. Learning how to reason through them didn't come separately, it came through writing programs of increasing complexity over time.
Before learning any meaningful amount of programming, I was introduced to the idea of examining the capabilities of your available tools and using them to find creative solutions...with adventure games.
I would consider a curiosity for exploration and experimentation to be central requirements to become a problem solver (at least through the path that I did). Start with that general mindset, present a world for them to explore, introduce them to the tools they can do it with, and there's no way to stop them from that point on.
I don't really know of anyone who learned problem solving with a computer before they learned to code. Supposedly Dijkstra, but that man thought computers cheapened computer science.
I feel like there's so much intrinsic to the code to solve the problem though, like how the debugger works, git bisect / git blame to determine where an issue might have arisen, commenting out lines of code and checking if they cause a particular issue, etc.
I don't think I learnt about problem solving in the abstract, it was more about specific applications of problem solving in the programming world.
Someone gives you a one paragraph description of a feature... I assume you don't immediately open up the debugger and start git bisecting... I'm talking about the things that happen immediately after being presented with a problem, and before you start typing code.
Just to leave some suggestions of puzzle games that are little hidden gems and that provide great logic thinking training.
IMO they should be played in the order below:
> We've hired several devs out of bootcamp, and they're all taught how to code, but not how to solve problems using code...
Frankly any Algorithms & Data structures book should do the trick. Choosing the right data structure is often half the solution when solving a problem. That plus SICP and a book about Discrete Math should be enough for 90% of the daily problems.
I'm not sure Algorithms & Data Structures will help you all that much in the real world. In most modern languages, all the algorithms and data structures are already implemented in the standard library, and while having heard of them is beneficial, you won't get a lot of value out of knowing how to do a binary search.
The problems that I see most junior devs struggling with are at a much higher level. How do you organize large scale programs? How do you make sure that different parts interact flawlessly? A book about design patterns could help here, but without experience you won't appreciate what the patterns are good for.
But by far the most difficult part to wrap your head around is concurrency. How do you make sure your assumptions all hold up when multiple threads / processes / users are all doing stuff in parallel? That's really hard to understand, and you need a combination of theory and experience to master this.
I'm not sure what my point is. Software development is hard, a bootcamp and an Algorithms book is probably a good start, but after that you need to still put in a lot of effort to reach your full potential.
Algorithms and data structures can actually be great not because you implement your own but because you can find out why your N^3 algorithm is slow (give you three guses) and why iterating through your data is slow (since you used the wrong data structure)
I like Bootcamps for what they are, a tool to fill Junior level positions for people to begin working their way into a career and I love teaching the people who graduate and are interested in continuing their career, but there is more to programming than paying for a Bootcamp and spinning up a Rails/React app.
PS: Forget anyone who says "I already know how to code, I don't need to learn this". Those people are fucking boat anchors, they just sink.
I'm inclined to disagree as well. Organization of large scale programs/problems is straightforward if the composing parts are sensible. The datastructure is root of all. A proper explicit structuring of the data is crucial to constructing a good abstraction. I usually accent reading others' programs or solutions, with objective of finding new ways to see the problems. Of course it's important that said programs are good quality. Inspirational properties of elegant programs should not be underestimated. To me, most influential such readings were classic textbooks (Norvig's PAIP), classic algorithms (like qsort) and others' kata solutions. Also, another thing that I find is very important is if you work on very complicated stacks like web or native apps, to step back from time to time and do some cleaner programming in simpler environments. This helps maintain curiosity. What I do is write small programs, and I don't implement actual stack calls (like filesystem calls or dependency calls), just stub them. This let's the mind feel free. When I'm done, if I want to have it functional, I'll implement the calls. Point here is not to burden self.
As an algorithmist, I strongly agree. Algorithms are of value, but they are not a high priority for junior devs. For a tiny fraction of problems, algorithms knowledge is absolutely essential, and often cannot be picked up at the time of need. But for almost all problems, especially the problems facing junior-to-intermediate devs, there is rarely any algorithms work. As you said, code organization. Long lists of things to remember to take into account (e.g. what areas require one to stop and get a security expert). Etc.
I think the best thing you can say for algorithms training is that, without it, you often don't notice that you need to get an algorithmist.
When people say, as my sibling commenters do, "find out why your n^3 approach is slow", or "do a substring match", I wonder what problems they're solving. Has this shit actually come up in your career, or is it just something that you imagine will come up? How many times has a cubic algorithm actually been the problem? As compared to doing five hundred DB queries, instead of one query that JOINs properly and returns a 500-row result set, which I see juniors and students do all the time, and is not an algorithms problem at all (it's the same asymptotic complexity, btw!). How many times have you tried to figure out a fast approach to substrings, and how rude was your code reviewer when they pointed you at the standard library?
> The problems that I see most junior devs struggling with are at a much higher level. How do you organize large scale programs? How do you make sure that different parts interact flawlessly? A book about design patterns could help here, but without experience you won't appreciate what the patterns are good for.
I couldn't disagree more. Algorithms are the base level that you build on. Anything non-trivial you will have to understand what is available to you and create something new. Take something common, doing a substring match on a list of items. If you don't have algorithms knowledge I'd bet your solution is going to adversely affect the final program.
Good choices of data structures, and solid understanding of algorithms are the units of composition in creating software. IMO
> But by far the most difficult part to wrap your head around is concurrency. How do you make sure your assumptions all hold up when multiple threads / processes / users are all doing stuff in parallel? That's really hard to understand, and you need a combination of theory and experience to master this.
Or use Rust and have the compiler check it for you, so you don't have to be a wizard.
Pretty much this. I show/tell people all the time that most of solving the problem is how you structure the input data. `Rock, Scissors, Paper` is perhaps the best simple demonstration of this.
That said, I don't think it's something that correlates to being a bootcamp grad. I'm usually the one `solving problems with code` and the closest thing that I have to an education in this industry is the boot camp I attended (lifelong programmer regardless). I know other boot camp grads who are the same way.
I encounter developers from all backgrounds who know how to code but can't solve problems. There's just _a lot_ of bootcamp grads right now.
FYI, it's spelled 'discrete math.' I know this only as someone who spent years incorrectly spelling 'discreet' as 'discrete' because of my math background.
I agree that it would do the trick... but given that Problem Solving is such a basic skill, I would hope that someone could have figured out how to do it without requiring years of college math and csci.
(for reference, my real concern is my cousin is in a csci-150 course, having trouble because her prof isn't used to teaching to students who haven't been programming for years... nobody has bothered to figure out how to teach problem solving, and they're left to teach themselves or drop out)
How to Design Programs is written to address this issue.
From the preface:
The typical course on programming teaches a “tinker until it works” approach. When it works, students exclaim “It works!” and move on. Sadly, this phrase is also the shortest lie in computing, and it has cost many people many hours of their lives. In contrast, this book focuses on habits of good programming, addressing both professional and vocational programmers.
With “good programming,” we mean an approach to the creation of software that relies on systematic thought, planning, and understanding from the very beginning, at every stage and for every step. To emphasize the point, we speak of systematic program design and systematically designed programs.
My dad has been trying to learn to code and all the courses labeled "learn to code" seem to be coding on the web. Not learning "How to solve problems using code".
Ive had to take him manually through basics of control structures, variables,etc.
From a higher vantage point, the ultimate reference still is from Descartes in Discourse on the Method of Rightly Conducting One's Reason and of Seeking Truth in the Sciences, esp. Part II
Parse this file and tell me the total of all $ amounts, and the line where we've reached 50% of the total $.
How do you approach this problem and break it down.
I've seen problems like this solved by looping through the file twice, because they answer one question at a time...
But I'm hoping there is something out there that can teach the general process of breaking down the problem, identifying loops, identifying generalizable code, and anything else that needs to happen before your code can work.
I have no idea if this works (it did for 3 test cases), and I still end up reading through the array (but not the file) twice.
# assuming file with $100\n$200\n$23\n$50 etc.
linenum_vals = []
with open('numbers.txt') as input_file:
for i, line in enumerate(input_file):
try:
linenum_vals.append([i, float(line[:-1][1:])])
except ValueError:
print("Not a number value on line", i)
total = 0
for i in linenum_vals:
total += i[1]
half = total/2.0
for p in range(len(linenum_vals)):
if linenum_vals[p][1] == half:
print("Half of total found on line", linenum_vals[p][0])
break
else:
if linenum_vals[p-1][1] < half and linenum_vals[p][1] > half:
print("Half of total in between lines", p-1, p)
break
else:
if p+1 != len(linenum_vals):
if linenum_vals[p][1] < half and linenum_vals[p+1][1] > half:
print("Half of total in between lines", p, p+1)
break
print("Half of total wasn't found in the file.") # probably because the list of values isn't in order
What way would you do it? I feel like I'm missing something.
I would probably keep a running total as I read through each line, then store `line_number: running_total` in a dictionary.
At the end, return the highest key in the dictionary for your total, and then run a reduce that returns the first key/value pair that is >= half the total
Thinking a little outside of the box - but if you could sort the lines by amount in ascending order, then total from both ends, take half after each addition, then shift a pointer to where "about half" would be based on where you were in the totaling (and which end) as you go.
I don't have any specific implementation - or if this idea would even work - but I do think sorting the lines first might be of help toward a better solution (I could be completely wrong on this). As well as tackling the totaling and checking from both ends of the list.
You'd have to keep track of everything, of course, in order to know at the end where in the -real list- (unsorted) the half-way total point is at. If this idea has any merit at least.
coding: "write a socket listener that reads from a buffer and converts it into a null-terminated string".
solving a problem: write a program that does (some open-ended business problem). Or generalize the socket listener so that it works on any platform, OS, hardware, network configuration, etc.
A coder might do great on confined problem space, but when you ask them to write a larger program they dont normally know how to design it. This isn't just true of bootcamp coders though. Tons of CS grads wouldn't do any better. Otherwise FizzBuzz would have never been a thing.
This is focused on teaching "computer science without a computer" to children, but some of my professors used it for bachelors students too. I'd highly recommended it to people of any age looking to get started with learning computer science: http://csunplugged.org
It's not solely a programmer thing. You might like to consider people who have been trained to solve problems eg Engineers or Mathematicians int al - they will probably give you more bang for your buck. They will probably have some rudimentary or rather better programming skills as well.
Well, my current concern is for my cousin, who is in a CSCI program by an ex-Math prof...
The problem is that they're teaching her syntax, but not really about how to solve the problems...
I don't remember being taught either... but it's certainly something I learned... She's incredibly frustrated because she sees her classmates breezing through class, because they've been programming for years and have learned the general problem-solving skills to get through class... she is having to learn both at the same time.
But, since there's so much focus on bootcamps lately, and it's a problem they ALSO have, I was hoping there was a solution there.
(my point being... colleges aren't doing a better job at this inherently... it's likely just that students have 4 years to figure it out or drop out, before joining the workplace)
I've decided to make my course on complete full-stack web development free, forever! It's a massive amount of content. Please let me know what you think of the course!
I'm going through it as a tech professional who is a non-developer. I know how to code, I just don't do it professionally (and I don't know Ruby, let alone Rails).
I'm loving it. Obviously the "here are some commands" and "go find Google Chrome" made me laugh a little but I understand the audience they're for. I love how quickly we get into actually creating something, it keeps my interest when I see progress. It's been 15 minutes and I already have a Rails blog set up, yay!
Seriously, I haven't gotten that far in, but right now I'm fully believing there is a success story with your teaching method. Congrats, that's not an easy feat.
Thank you! Your words mean a lot. I agree that learning by doing is especially useful for coding and it's always great when non-developers pick up developer skills (it makes you better at what you do, and developers love you more too)!
Message me if you have any questions along the way. I'm here to help.
for you it sounds great but for someone like me I like to understand how things work under the hood. Yeah I made a blog in 15 minutes using Ruby and Rails but how did that happened under the hood? I like to fully understand things not just be told how to do it.
I guess that's why PHP being embedded in HTML allows me to see the bigger picture.
First, from what I understand, Rails has a lot of "magic". So on that note, you're probably just not going to like Rails or Rails-like frameworks in general (like Django, lots of magic). PHP or even something like Flask might be better for you. Different people like different levels of abstraction, and believe it or not you can write web pages in C. PHP was originally designed as an abstraction over C, to add a little "magic" so you didn't need to know how things worked under the hood in order to get a web page running. These days, Rails is the new magic, and PHP is the new "under the hood".
Secondly, the course does go into more detail later on (I'm on #20 of the "build a saas app" right now), where after every video that you write code, there's a video that explains why you did that and what it does to the program. It actually goes into more detail than I was expecting for a tutorial that starts off with "here's how to install Google Chrome".
I just skimmed the content, but I really appreciate that you have beginning content on how computers and the Internet work. I've seen too many people learning to code who start with 30K LOC of bootstrapped code, before they ever learn what the basic roles of a web server, browser, and an HTTP request actually are. Starting simple is a very good thing.
Based on the skimming through the titles it looks like a quite complete material.
As it looks like after completing this course people should be quite capable to build their own solutions, I would recommend you to cover the security aspect more broadly.
Perhaps cover multiple commonly known attack vectors (and how they are mitigated) and basics of the cryptology.
I would also suggest you (based on the other comment here) to not push Chrome only. It is very important for our liberty to have various actively used browsers.
I'm not sure he's suggesting everyone should only ever use Chrome, but rather heading off "it doesn't work on my system!" complaints that are common with these tutorials. He goes into painstaking detail on exactly which version of Rails, exactly which version of Ruby, and exactly what gems you need to use to make sure the learner is using the same environment as the teacher. Suggesting that everyone use the same browser goes hand in hand with this. If you're a beginner and you run into compatibility issues with your browser, you might be turned off and quit. Making sure everything is the same while you're learning is really just good practice.
Interesting point. I think job markets don't move as fast as technology itself. Just because a new framework comes out (and yes, in the web world, it feels like a new one pops up daily), doesn't mean an employer will say, "Ok team, let's rewrite everything in React, or Angular, or (insert your favorite new trend of the year)." A search for web development jobs will show openings for frameworks that came out 15 years ago. It's more important that a student learns to code and understands the fundamentals of problem solving and program design than worry about the latest frameworks or tooling.
HTML,CSS, and Javascript are never out of fashion. The only thing he teaches that is applicable to what you said is Ruby on Rails and even then Rails has a strong foothold on the market.
Systems that already exist need to be maintained. Why do people still write COBOL? Because it's cheaper to maintain an already in place system than to rip it out and replace it with the newest fad.
My professional experience says otherwise. There's always more work maintaining/enhancing sites than creating new ones.
By the way, Rails is the craze from maybe 10-6 years ago. consider e.g. [0] But it is still far, far from dead. Time flies, but not as fast as you suggest.
Roben,
I'm actually disappointed to find out that you've made this course free.
It seems the folk on reddit gave you a nasty bit of pressure?
Well, i don't see how you're going to be able to maintain this project(100's of hours of videos) without earning anything for it. Quality is bound to decrease in the long run.
I believe you should stick with your previous model(Free for a month or two, subscribe when its useful or pay a fixed sum for lifetime access).
Maybe incorporate an Ubuntu-style 'suggested payment' part to the signup? You could have one or two reminders during the course if they choose 'Free'. Or supplement with paid-for content that goes beyond the course?
I agree that it's a lot of work and wouldn't be unfair to seek some compensation.
Obviously I don't have insight into what the creator will be doing with it in the future, but what I fully expect is these videos will be free, but the additional videos on React and other frameworks/languages will be offered at additional cost.
OT: The reviews on the frontpage are fake right? I'm not bashing the course by any means, I'm just curious. I see lots of services display similar user quotes and was wondering if it's a standard marketing practice.
There are marketers who do this with real quotes, sometimes by asking customers for a statement and permission to publish it.
Those here look kind of unrealistic since all reviews are worded thoughtfully, gave 5 stars, have similar length and no grammatical errors. Also, each user has a perfect portrait image as profile picture - this isn't even the case on LinkedIn...
They are real. Some of the students are international where English is not their first language. I'm happy to put you in touch with these students, or any past students if you'd like to hear more from them.
I see you make heavy use of Cloud9, glad to see that I'm not the only one using it as a learning sandbox environment. It is truly a great platform, I use it to introduce people to Linux (terminal, editing files, etc.) without the hassle of setting a virtualbox, installing any software in their computers, or risking my machines.
I agree - I especially love that it allows students to bypass many of the headaches of installing the right dependencies (something beginners struggle with for hours or days). Cloud9 let's you get straight to coding.
Not sure if you're into Javascript development, but check out HyperDev.com - it's awesome! It takes things to a whole new level of fast.
I think we have Docker to thank for progress on this front.
I tried it few weeks back and sadly they force you to add credit card to proceed. Few seconds of googling showed people using fake ones to circumvent it. Not really interested in that nor exposing card details.
I'm on the same boat.
I don't feel comfortable sharing CC details for a free service I might be interested to try (even though I won't have much time until next year to do something), and doesn't seem fair "cheating" the system using a fake one.
Oh sorry, I don't have a proper one, just when receiving new interns/researchers. Most of our research tools run on Linux but it is quite easy to destroy valuable data, so a c9 sandbox works wonders :)
lynda.com has some great courses on php by the authors kevin skoglund & David Powers. These courses are not free though and they are mostly about php.You will find courses covering html,css,javascript and a lot more there too.
PS I don't work for them I only like their work
This is great work. And (this is not a jab at the creator) a signal for me to move on from web development.
We are now at a similar point to knowing HTML in 1998 would land you a plum job; except it's now frontend frameworks. There's going to be tremendous downward pressure on wages in the next few years; especially in web development.
I recommend everyone who wants to stay competitive to move on to harder things or leverage whatever soft skills they have.
Looks like this is from the same guy that did Codermanual. Wonder if he is actually going to be around to help for this course as he more or less abandoned the other one after a couple of months of it getting popular. I have a pretty bad taste in my mouth for this instructor still from that experience.
Why Choose Ruby for a beginner. Why not JS and NODE EXPRESS or PHP that would have made this more simple for people who are new to programming and looking to get a job.
What makes you think JS or PHP are "more simple" for that audience?
There are plenty of Ruby jobs out there, and it's an elegant and well-designed language that's got a mature framework. Especially crucial for relative beginners: it doesn't have the flavor-of-the-week problem that JS does, nor is its most prominent example a legacy mess, as Wordpress is for PHP.
all most all of the web is written in PHP, a beginner can't understand how everything fits together by learning Ruby. With php you can literally insert it into HTML. For me is all about the big picture, Plus I think there are more jobs in PHP than Ruby
Well, and then you get people who insert php into html in production environments. Believe me, I've seen it more than once. I don't see how PHP is easier than Ruby. It's not Haskel, after all.
I'm guessing this course isn't aimed at people who's new to Web development? how are we suppose to know some of those rail commands? like generate scaffold blog posts?
This course is comprehensive and goes from beginner to some fairly advanced content. No previous coding experience is required. You will be guided from the beginning.
i'm pretty sure that if you can't learn for yourself for free by using the internet (or even libraries and help files etc. like i did) your already starting on the wrong foot.
having the ability to solve that problem for yourself is important... if you struggle with that you will struggle in most real world dev roles imo, because you will need to continue to do this for yourself throughout your career.
Are the later parts paid only or unlocked when progressed to certain point? 'User Memberships and Accepting Subscription Payments' and 'User Profiles and Relational Databases requires' shows message 'Lecture contents locked'.
We've hired several devs out of bootcamp, and they're all taught how to code, but not how to solve problems using code...
Anyone have material that might be good for this? Books, videos, courses?