Wow, great question. And such a coincidence that I just posted an article about my single best piece of advice. I would say very simply, that you're not an impostor in the world of software development. You're a problem solver, and that combined with the fact that you enjoy doing it is what defines your value as a software engineer. The rest is just gaining knowledge, and passing through the fear of stretching that knowledge in search of solutions to problems. Read more here .

What is this sorcery!?!? I like it though, very interesting idea.

Disclaimer: This mostly relates to React and Redux As Brandon said the two aren't mutually exclusive, and in fact they aren't really comparable directly. MV* describes an entire application, from the data to the presentation and business logic. Components simply describe a methodology for organizing your view layer, and doesn't necessarily address the state and logic of your application. You could do the other two aspects within your components, as they do in the React documentation, but I wouldn't advise mixing concerns this way. If you're using a component based architecture for your view layer, you could conceivably use a straightforward MVC implementation using Backbone or something replacing the Backbone views with a React component tree. It's my opinion though that the traditional model pattern doesn't lend itself well to a component system with virtual dom rendering. Models are designed to contain and observe specific aspects of state, where as with a component system (with a virtual dom), you're not focused on what specifically changed within the state and only care about what the new state is so you can re-render your components. With that in mind, managing your data using a Flux implementation is a better fit, because you gain simplicity by using singletons (or a singleton in the case of Redux) to store state, and forget about creating models to compartmentalize specific aspects of state. Then your business logic could go anywhere, but I would recommend using Redux (or my library ReduRx ) and encapsulating your business logic in action creator functions. I wrote an article recently that talks about how to view React / Redux applications specifically outside of the traditional MVC pattern, so if you're interested in more of my thoughts check that out.

Disclaimer: I haven't delved much into Angular 2, but I know a great deal about React. I think the question is not so much how is it better in general, but how it's better for your use case. All frameworks have their advantages and disadvantages; but I think as a whole one isn't universally better than another. Some general points for why you would choose a framework though might be: Community and support Availability of additional libraries and components Availability of developers who know the framework There are other aspects which people will surely bring up, but from a general sense you can frame your choice with these in mind. Not so much as "This is better than that", but more from a standpoint of why the framework is a good choice at all. Really though you'll want to explain how it's a good fit for your use case. What are the aspects of your application that lend themselves to a particular framework or methodology? Does the framework fit your particular skill set in some way that makes it easier for you to develop with it? That sort of thing. I think you're better off justifying it that way as opposed to trying to say that Angular 2 is a universally better framework than X or Y.

Have you seen Swagger , the api scaffolding tool? It'll build an api with validation, and has generators in a lot of languages.

Also a write-up on Medium (linked from Hashnode).

This comes from my experience as a Node / FE dev, but I would say it could be faster if you know what values are causing the issue and where to check them. If you have to rewrite your logging a few times though it probably would have been faster to put in a break point and browse through all the values in the call stack. In other languages the time to set up that environment and it's general usefulness might be more pronounced, so the threshold would be higher, but I think that if you don't have a good idea where the issue is you're better off stopping execution and taking a look around.

GitHub: The single point of failure for the open source world.

I think if you're going to use a generator, then what it does should be very minimal; i.e. it probably shouldn't create a complete project. This isn't true of the generators I've seen, which make a lot of assumptions about how your application works so that they can create a minimal working project. This makes sense, because a generator that only half generates a project probably wouldn't be too popular, and would require you to know what's missing. The issue though is that at least some of the assumptions they make are not ideal, and you end up having to refactor the generated code right away; which in my mind defeats the purpose of generating it in the first place. This doesn't mean that some form of scaffolding isn't useful, since there are some basic commonalities between most of the projects you create that utilize the same frameworks and tools. My suggestion would be to do as @lichtjaeger suggested, and make your own generator. Yeoman generators are fairly straightforward to produce, and you can get some basic scaffolding for what is repetitive in your projects.

I'm a bit surprised that "print something" is more popular at the moment than using breakpoints to debug. I always compare doing logging to shining a flashlight in a dark room; you have to point it in the right direction to find what you're looking for. Using breakpoints is like turning on the light; you can look around and see everything and find what you're looking for more easily. As far as "something else" it might be language specific...but another approach might be writing and observing unit tests, which will indicate specific issues as you code.