You could learn Angular or React. The flux (or store) design pattern is very popular due to one way data flow and both frameworks have support for it. React has Redux and Angular has NGRX which is basically redux for Angular but uses rxjs. Personally I would go the Angular / NGRX route and they have really good documentation on best practices and how to best layout a web app. Use the Angular CLI if you do Angular though, don't try and make a project from nothing, let the CLI build the boilerplate and handle webpack. React is less of a framework than Angular and is more modular. Things that are built into Angular, such as http helpers or animations, you need to get an npm package for. Angular has a steeper learning curve though because it is more than just doing JavaScript.Anybody have any good resources for learning about design patterns and/or modern application development/web development practices?
I'm going to try test myself this week by building a website while writing the least amount of code as possible.
Yeah, I agree with this.Sounds like you just need more experience. Since you obviously recognize the problem, the next step is to actively try to change.
Self-contained code is good.
Design/architecture is a different skill, planning is a different skill. Few people are born with these.
I'd rather work with someone who's detail oriented vs not. The real question is whether that person can be productive (i.e produce good work in a timely fashion)
I'm having trouble with this thread because of the terms. Being detail-oriented is a good thing for a coder. I think we're talking about narrow-thinking or blinders here. And code should be as self-contained as possible. Isn't that a key point of OOP? I'd like to hear more concrete examples of how this code isn't interoperable.
Depends on what "self-contained" means. Writing decoupled code is important for a variety of reasons. However writing a block of code in a completely different style that doesn't fit with the rest of the code base is also a problem. The goal should be to have a consistent code base that has decoupled or independent components that can interact with each other in a variety of ways to form features.
Right. That is the goal.
I would never interpret code written in a style that doesn't fit or is hard to understand as "self-contained" though. I'd just call it shitty.
Good thing I never referenced style or said I wrote code that's hard to understand.
Have you been more than one place? Honestly it sounds a little like you need a mentor, or even just a senior developer.
Architecture should be for architects or senior developers. They should get the big picture and they should be able to explain the big picture to you while still giving you a small enough piece to work on that your detail will help.
You may also be better in situations where more logic is required than UI. I have coworkers like that. They are capable as UI folks but it's not what they are good at (really... almost any of them, and they will be the first to say that).
With your focus you might be better at new cognitive and data analysis work or data warehouse Cognos \ Informatica type work where you have stricter inputs and outputs. SAP. These all REALLY sought after areas that may better suit you.
Or again... just a mentor to help you stay on track.
I agree. I know people who are like that, and it is very difficult to work with them.I'm having trouble with this thread because of the terms. Being detail-oriented is a good thing for a coder. I think we're talking about narrow-thinking or blinders here. And code should be as self-contained as possible. Isn't that a key point of OOP? I'd like to hear more concrete examples of how this code isn't interoperable.
I'm confused OP, are you given no requirements or documentation for the code/features that the company wants you to write?
I mean for example you say you have some issues with your code interfacing properly with other parts of the system because you feel you don't have a grasp of the "big picture" of what is going on with the overall codebase/project.
But surely for the task you are given you are either interacting with an API for a different part of the system, which should have good documentation/requirements. In that case your code will either be compliant with the API or it won't be, in which case it probably won't work at all.
If you are not using API's but interacting with code/classes/objects/modules etc... directly then what task is it exactly you are trying to accomplish, and once you have reached the point where the code works and is tested to reasonable degree why isn't that just..."done" so to speak?
I can understand getting annoyed if you are lacking some low level details of exactly WHAT is going on or exactly HOW something should work but I'm not really following you exactly. Can you give a mock code example of something you made and some other part of the system and why they integrate "badly"?
Do NOT go into QA. I repeat. DO. NOT. GO. INTO. QA.
It's a dead-end path that's not respected by your bosses and peers (1) it's been outsourced to India, my entire QA department was gutted down to a handful of people and (2) companies are more and more expecting the dev people to do the QA job (essentially a 2-for-1 deal).
Most software shops don't give a shit about quality, and it shows in how the QA is treated.
Just don't do it. You're irrevocably fucking over your career. Maybe consider QA when your 50 and nearing retirement or something.
I understand this attitude but it is definitely not all true for all software. Especially government contractors.
Kinda is with web dev, though.
Banking institutions have web dev, you know.
True. I guess there are some case where people still care about QA in web dev. Not so many, though.