These are some lessons I learned while working on large (actually not that large) software projects in my first three programming jobs. I think they’re good ones so maybe you can try to steer your experience in their direction.
Your organization will suck. There is no way around it. You should try to keep things sane by introducing more folders and naming things carefully. As you abstract concepts and break things down into smaller pieces, you will begin using vague, generic terms like
group or end up making things too specific and introduce redundancy. I think this is a limitation of the english language that we have to live with.
Of course some redundancy can actually be good. Don’t let DRY keep you from your own sanity and common sense.
Don’t be afraid to explore the source code of whatever libraries you happen to be using when you inevitably come across a shortcoming in their documentation. One of the reasons we use Open Source software is because The Code is the Documentation™.
The people writing those libraries ran into the same issues you’re using their software to solve and they figured out a solution. Try to make sense of what they’ve done. Maybe you like it and want to adopt their organization techniques or style to your own code.
Or maybe you hate it and wonder how they managed to produce anything that even remotely does what it’s supposed to. Shake your fist at their horrible API and hope you never have to debug their code. (yeah right!)
Don’t lock yourself in to preconceived notions. Everyone has invented many wheels. Some wear big tires, some have large radii, some have spinners, and some are even square. If you’re used to one kind and someone else thinks they have something better, hear them out, evaluate their nonsense, and slap them upside the head!
Just kidding. Don’t assume you know more about something than another person. If you’re stuck with noobs, try many approaches until you find one that works. If you’re surrounded by experts, challenge their opinions and find out why their way is a good way.
Having a good ops person/team is amazing! I’m lucky enough to work with a few and it makes the whole development process exponentially easier. Screw something up? Just build a whole new box from
Unfortunately, if you aren’t so fortunate, you will have to do it yourself. This is actually an area where I am still unexperienced and I don’t look forward to doing this work.
These things are light on concrete examples and that’s because I’m a bad story teller. Basically, I’m publishing this because I came across an article that talked about lessons learned from building an Angular-JS project, but the lessons don’t specifically apply to Angular-JS; they could be applied to any project. This is just my attempt at reiterating that list.