Thanks for the info, this is something I've always wanted to learn a bit more about, would appreciate any resources you could point me to.
391 karma · joined October 10, 2011
My advice to you is this:
1. Focus on learning Javascript firs and foremost. Kyle Simpson's "You Don't Know JS" series is amazing: https://github.com/getify/You-Dont-Know-JS
2. Best practices are hard to come by, they essentially are: Crockford's Javascript The Good Parts, The Mozilla JS docs, and some styleguides on Github. Also lint your code through JSLint or JSHint.
3. Don't worry about build tools like Brunch, Gulp, Grunt etc. unless your job forces you to use one. If you're building small sites and apps, you won't need one.
4. When it's time to use a Framework, pick one and stick to it until you know it quite well. Frameworks are very different from one another. Backbone, Angular and Meteor.js are all quite different, but in the end they all do one thing, serve a web app.
Product-market fit has more nuance than the words suggest. Maybe the product wasn't right for the market they tried (Caviar for rural Kentucky I'd imagine), or the market as a whole never wanted the product (drive thru dog grooming), and then there's the matter of timing, maybe it was right, just not at that moment. It would be interesting to explore those deeper assessments of lack of product-market fit (as assessed by the founders and outsiders) and see which one is most common. I'm sure we'd find some fun surprises.
I've perused the site, but didn't see anything on expanding to a pre-processor. Does anyone know if that's possible?
I would view this as a blessing though. For me, interviews are a chance to evaluate how well we can communicate. If I can't be relaxed, make jokes and just feel free to talk, then I won't feel that way working for you during the next year, and that to me, is a no go.
I'd say indirectly you dodged a bullet, sounds like you two might be a high risk for constant miscommunication.
Try reading this guys book, seems legit, maybe he offers strategies for handling scope creep and such: http://texmexconsulting.com/
Then drink a beer, do some Yoga, and relax before the evenings work!
I've encountered this phenomenon and there are a few situations where it can feel natural or correct to copy and paste code. While I can't say these are great reasons, they do merit being considered.
0. QA concerns. You can't just modify/change logic without triggering a need for QA to re-check. This is in fact, one of the biggest stumbling blocks for code quality in a company. You just can't refactor as needed, it has to be planned for and paid for. There are times when you're basically stuck using bad/logic and just extending it.
1. You're a guest in the code. You're just working on this feature for one iteration, and the other guy who will likely be on the project for the rest of the year wrote the bunny code. I wouldn't change how he does things, I'd instead talk him and let him know there's a better way. I wouldn't implement a second type of fix.
2. It's unclear what direction the primary authors want the codebase to grow in. For instance do you use library level functions to accomplish tasks the language syntax can? (for loops vs an iterator function). Some prefer one over the other. I would just follow the style I see
3. Styleguide logic. E.g. the code should look as much as possible like it's written by one person. While I know this rule applies to indentation and visual appearance. I think it's fair-ish to apply to it to logic as well.
These are a few things to think of, but I agree with the author of the post, be careful, this code will multiply.
Comments like yours not only degrade the HN community, but the coding community in general. I'm not going to engage or dissect your comments any further, rather I'm just going to ask that for the sake of this community and our profession, you hold yourself to a higher standard next time you comment.
Most new devs get it wrong when choosing what to learn. They forgo learning plain JS in favor of jQuery, then they forgo jQuery to learn a front-end framework. It should be the other way around. Do absolutely all you can with plain JS first, then use jQuery as needed (and make sure your copy of jQuery only has what you need), and then only for complex interactions, use a front-end framework, but most interactions on a website aren't complex enough to merit one.
For any site that is mostly content with some interaction, well written pure JS should be the solution you try first.
New to coding - Chris Pine's Learn to Program is THE book. I like it more than Why's guide, or any website.
New to OO - Try Sandi Metz's Practical Object Oriented Design in Ruby, this book should be your second ruby book, as it teaches you how to write good Ruby.
New to Rails - Try the Hartl tutorial or Agile Web Development with Rails
New to Command Line Apps - Build Awesome Command Line Applications in Ruby, it's an O'Reilly book I liked.
Advanced Ruby - Confident Ruby by Avdi Grimm, along with his Ruby Tapas screncasts.
On the other hand, I agree with most of the sentiment here, these are starting to feel like ads and pitches, and I have a feeling the single founder that will benefit the most here is the author.
For instance most API design is based off the standard Rails scaffold command, and an explanation about what's wrong about that would have been nice, and elevated this article from kind of a screed, into something informative and worthy of study.
On the contrary, I started in web development by learning Rails, and it's simple, streamlined way of responding to an HTTP request has allowed me to pick up other architectures quite quickly. By being so simple, it gives me an easy point of comparison, and then I can appreciate other architectures differences.
The work you wish you'd done sooner (1 to 6 years ago), would have been done with that year's tech. Starting an app 6 years ago, whatever idea, would have been harder to do. Early versions of mature frameworks we enjoy now weren't as easy to deal with. In the last few years things have gotten much faster.
It's easy to see how easy work is to do today and look back and say, "If only I had those lost years!" but that's not the case, that work would have been different by it's nature, due to the tech.
If only you'd started your app 15 years ago! You could have gone through the fresh hell of flash, php, hand writing deployment and basically being a sysadmin!
Would appreciate a comment from OP on what the use case is with this library? Maybe an example app or ideal use case?
I think anyone's first thought when Amazon gets into a business is that it's dominance is inevitable. Not so sure in this case, I've made tons of marketing pages just like this, hardly a guarantee of success. They'll have to do the hard work of convincing people they can provide quality service. You can't just return a home renovation if it goes wrong.
That I suppose is the core of the "I hate JS" arguments, to get it to do what you want, it has a slightly unintuitive non-syntactical way of solving it's problems. That of course, is only the case if you intend to replicate the programming styles the syntax of other languages gives you. I don't think you should. And now with ES6, we have those other styles in our syntax, so it's even less of a problem. Hate on JS all you want, but it's probably not so amenable to you because you're using a metal file when you really need a belt sander, close but not quite right.