+1. You can easily turn 10 hours of connecting the dots into 2 hours with the right materials.
Though in my experience, the courses on Udemy/Udacity and the like have been disappointing. I always get the feeling that they're trying to fill up time, and they tend to move really slowly.
I often go through these "amazing courses", everything makes sense, everything works, and then I'm unable to do anything other than what the course showed. So, I'm still forced to spend some hours outside of the course to really learn.
This 2-hour-course vs 10-hour-learning is a false dichotomy to me.
YMMV. I chose 'materials' instead of courses specifically since I've found books to be more useful.
A course, or any kind of structured learning, is just a foundation. I would still expect to spend hours outside of the course, but with a good background I can now search for more specific things than if I had started w/ a blank slate.
I have mixed feelings about Udemy. On one hand, it's a large platform with lots of interested customers. On the other, courses are often heavily discounted and priced very low. 50+ hours of content for $20? You have to treat your audience like they're both smart and busy. I don't have time for that. I'd rather pay $100 for 5 hours of good content.
> "for some writing code itself is an act that clarifies the still-murky concepts and helps to produce a good writeup."
This is my philosophy after ~2 years of working on distributed systems. I got sick of vague design discussions where everyone has a 5 minute memory.
I am much happier to sit at my desk and figure it out by writing code, then produce a design doc once I have a solid prototype working. It feels more honest and real.
At the same time, I wonder if I'm missing out on a different way of doing things.
If I'm working within a system I like to code the minimum golden path, add a tests that passes, then add more checks or a new test and go back to the code, etc. Usually the constraints of the system point the way to an obvious skeletal implementation and you can learn as you go along.
On a greenfield project it is especially valuable to have discussions beforehand if people have done something similar before but talking about code at a high level tends to become nebulous rather quickly.
I think the philosophy behind TDD is really valuable in the sense of "start with a goal in mind", but I find that I get better results with running and iterating than going to the effort of writing tests all the way out.
Probably just a mismatch of our testing tools vs the types of things I need to develop usually
If the problem is in a space that we know what the solution 'should' look like, getting as much of that down in the most abstract sense is something I like to do. However that design is only a -proposed- solution, and of course subject to all sorts of changes.
But where things are murky in a design, yeah, sometimes the easiest thing to do is code it out.
In either case, (up to date) diagrams of data flows are one's friend in any distributed system.
I think it depends on the size/scope of what you're doing, how complex it is, and how much novelty (technical and domain) there is in it.
For things that are not terribly new, are small enough to knock out with 1-2 devs, and aren't massively complex, just writing some damn code works really well. But the larger it gets the more useful it is to do some thinking beforehand, especially about the overall architecture, technology choices, potentially tricky error cases, etc. Also it can be particularly useful to flesh out public/widely-used APIs and data storage details, as those tend to be difficult to change once put in place.
That said, I don't think a fully fleshed-out "specification" is useful in most cases. A wiki page, or maybe a few, is usually enough. You just want to spot major problems far enough ahead that you can avoid them instead of running into them.
But hey, YMMV, this is just what I've found. TBH I wish it was different, because I actually _like_ hacking out code more. It's just that thinking ahead _works_ better IME.
I do this a lot too, it works great. For any non-trivial work, we don’t really consider a design doc “good” unless the author wrote a proof-of-concept demonstrating the feasibility of whatever approach is being advocated, specifically focused on whatever is novel or risky with the project. Iterative development starts before the doc is ever reviewed.
> I am much happier to sit at my desk and figure it out by writing code, then produce a design doc once I have a solid prototype working. It feels more honest and real
Can relate, every single time I did the opposite, I ended up rewriting anyway because I wasn't following the design doc.
If you own anything, you're not a peon. However, owning 100% of something is simply a very different mindset than owning just 99% of something. In the former, you solely control you own destiny.
In the latter example, you're beholden or subject to others. Not necessarily bad, but a very different experience.
Kind of like long term dating versus getting married.
You’re probably right, but worth a shot even if it fails is a terrible reason. Not only will they screw over their customers, but they’ll get even more of a reputation for doing so than they have already.
If you keep on moving fast and breaking things, people who don’t like it when you break their stuff are going to think twice about trusting you.
Though in my experience, the courses on Udemy/Udacity and the like have been disappointing. I always get the feeling that they're trying to fill up time, and they tend to move really slowly.
I've had more luck with books being very useful.