Are projects using frameworks not as good as projects using pure programming? [duplicate]

Question

This question already has answers here:

Are there concrete reasons not to use libraries and code snippets heavily? [closed] (16 answers)

Closed 6 years ago.

I've been a Rails developer for a year now (originally self taught), and am at the point where I want to improve. I've been reading books on how to improve the quality of my Ruby code (I read Design Patterns and Practical Object Oriented Design in Ruby).

I'm trying to improve the quality of my code and to add to my portfolio, but I'm having trouble thinking of anything motivating to do with just Ruby since in my head it feels cooler or more usable to have a Sinatra app (I'm thinking about learning Sinatra) and a browser to interact with the app than having to run a pure ruby app through the console with $ ruby my_app.rb and have it spit out some info. I know the results are really similar, but still.

My question is, do employers think lesser of projects that use frameworks than projects (Rails, Sinatra, etc) that are built from complete scratch (just the programming language itself)?

Answer 1

TL;DR: No

There's really two things going on here when employers look at a resume, or at least some employers.

1. Do you have a basic understanding of the underlying technologies? Buzzword match up - Ruby, HTML, CSS, JavaScript, PostgreSQL, MongoDB, or whatever the platforms they are using. Knowing the platforms often makes you acceptable candidate.
2. Do you know and understand the frameworks that we specifically use here? Rails, SASS, Mongoid, ActiveRecord, or whatever else that makes sense for that organization. Knowing these makes you a better candidate.

If you have the list of #1 covered, and you're missing one or two from #2. Normally not a big deal. You can be taught one or two frameworks. It's more important that someone is a good cultural fit and aligns correctly to our organizational values than you have every framework on the list.

---

Given the above, the importance of most frameworks sorta depends on what you are trying to do. If you are targeting a specific type of job or a role in a specific organization - finding out what frameworks are used and make yourself familiar with them is a huge plus. But at the end of the day, you'll want to use some frameworks. There's no value in reinventing everything you need every time.

Now, I have in the past hired someone who didn't really come close to covering nearly all of #1 but they came across as really bright and we all knew it was going to be a junior position. That turned out to be a pretty good hire. Normally, if someone can't at least speak to most of #1, then the conversation is over pretty quickly. Even if you can't speak to my list in #2, having a list you can speak about how you've used it, the benefits and failings you have discovered and why you might choose to use it again would be a huge benefit in most interviews.

Answer 2

Yes and no.

If all you've done is wire up crud apps using some framework specifically to do that, employers will question if that's all you can do - especially if it's an older technology.

Likewise, if you spent the past 2 years doing something that would've taken a week if you'd just used Framework X, that doesn't reflect well on you either.

Employers value people who get stuff done, ideology and technology be damned.

Answer 3

There are two questions here. The first question, the subject line, has to do with quality of the code. The second and last question is about employers and what they look for in a candidate.

I think @Travis answers the second question adequately. Employers are certainly looking for a lot of things, including proficiency with the technologies and tools in the business space, but they're also looking for a "fit" within the company. And perhaps even more than that, what they're really looking for is problem solvers. If you lack in a certain language, technology, or framework, but you can show an employer that you have an ability to learn quickly and solve problems, then that's valuable to an employer.

I think employers understand that they're not usually going to get candidates that have every single bullet point on their wish list; but what you're hoping you get is fast learners who are capable and adaptable and can be brought up to speed quickly.

Now, as to the idea of an app being good or bad based on framework usage: here's the bottom line on that one: It depends. Some frameworks are good, and some are bad, and it's only through using them that you will realize how good or bad they are and what barriers they bring or eliminate to a software development project. By the same token, some apps built without frameworks are a mess of spaghetti, but some projects will be just fine. It depends on the people who worked on them.

The larger question, the more concerning question to me, is: Is the app something I can manage and grow and change over time, easily, and with little friction? If the answer to that question is yes, then I don't really care if it used a framework or not.

In my experience, it depends greatly on the language, but some frameworks do a really good job of making apps extensible, easily manageable, and easily changeable as the app grows and evolves. Little friction is experienced when changes need to be made, and in those apps they are a true joy to work on as the age and evolve.

Other apps... you feel as if every line of code that needs to be changed is a major hassle, and with each and every moment you spend in the code you wish for a chance to rewrite it from the ground up.

The trick is to write lots of code, learn, work with other programmers, talk, experience, and gather up a library of thoughts and lessons learned. Aim to make code that is friction-free and is easy for anyone who comes after you to adapt and change. To me, these are the noble goals of our profession.