I'm actually already anal about it due to colour blindness. When most cables look to you either black, grey, blue or brown and people tell you that 'the orange one connects X to Y rack'… you buy a hand-labeler, zip-tie bands, and keep meticulous notes like an OCD freak.
Monoprice if you do not know about them. Get cables in any size, shape, ends, length, color. It is cheaper to get the stuff from them than it is to make it yourself. And with your issue, you need to develop a colour code system (e.g. switch to switch black, gateway routers white something like that. We do switch to switch RED and our VMWare stuff YELLOW so you know not to mess with those connections) You might even want to think about using the different connectors as a way to segregate cable due to your limited colour palette.
If you would happen to have anything to add, I'm always happy to get more insights like the one you gave already. Thank you once more! :D
Things they do not tell you in class, round 1.
Learn to write a proper IT email. It is part cover your ass, part WTF happened, part I fixed that shit. After you fix something, send an email documenting the event, no matter how small. Depending on NDA etc concerns, this email will have a TO and a CC field. The TO field is to the people who were impacted by the event; The customer, the department head, the people who fixed the problem, within reason. The CC field is for your boss, the email for your IT group where you keep your "CYA documents" aka cover your ass, and possibly the boss of people who are not on your team who helped out, especially if things went really well. Part two of this message is the subject. Short, to the point, almost bland "Report on trouble with customer X 10-26-2016" Something like that. Part three is a paragraph with no more than FOUR sentences. "There was a problem. We found the problem. We fixed the problem. Below is how we fixed it and how we are working to prevent issue in the future." 99% of the people you send this message to will stop reading at this point. The final part is a detailed description of the issue, how it was discovered, how it was fixed. This part is for you and the team so you have a record of things being fixed, and more importantly, how you fixed it for when it happens again. Writing this out will help you cement in your brain good troubleshooting and communication skills. One great bit of advice I saw is to read airline accident reports from crashes. You do not need to be that anal, but you want to be able to have a written record of how you solved problems and are now taking action to prevent the problem from occurring in the future. Even if the only person who gets this letter/email is you, writing it out and learning how to make an after action report like this is a part of the skill set that will cement and if by nothing more than rote repetition retain knowledge.
Also, people in general cannot write worth a shit. Write good, clean, concise messages and you will stick out. And remember, nobody reads past about four sentences.
Part of your job in IT is to be proactive. As a networking guy, get Nagios Core for free, and also MRTG and know how they work, why they work, and how to monitor your network tree. Learn how to do the alerts, SNMP, etc. This will also force you to dig into Linux a bit to learn postfix, scripting, etc that you will need in the future. Don't be like me and have a mental hump about coding and scripting, every networking job in the future is going to be at least a little bit coding. Know what is failing before the phone rings; I've had people call after I get the alerts and can then talk to someone impacted as if I am already working on the problem. Even if it feels like a minor thing, when you come off as a guy who knows what is going on, you instill confidence in your user base. Cisco also has monitoring tools, but you may end up in a non-Cisco environment and it is always nice to have free options. Nagios can also be set up to display on a Raspberry Pi as a web site on a bigger screen TV to act as a NOC screen, which looks cool as hell to the non tech people who walk through the office.
Another part of your job, one that is rarely talked about? Make you boss look good. If you can keep other people off your boss's back, and make their job easier, do it. Keep them in the loop, let them know if shit is happening. And if your boss does not respect your talents, time, effort or energy? With a CCNA you will get recruiting calls weekly with job offers, depending on where you live. This industry, for people who are good at their jobs, is too competitive to deal with shit tier direct reports. I could make double what I am making, and have had that offer, but my boss is awesome and I'm staying as long as she is.
You will have days that fuck all of nothing happens, and you will want to spend it on reddit and hubski. Read manuals instead. Document shit that has not been updated in a while. Start a WIKI for your work stuff. Because you will have days like I am having where I am on the go and working overtime to get a project done on time. I worked 13 hours today deploying computers, and have 100 more to go before we start wiping them and boxing them up for return. I'll not have a down day for at least a few weeks. You will also have times like these, but IMO, the crunches and the soft times even out over the year.
As a network guy, if you ever come into work and say "I'm bored" you better fix that shit. Either look at BIOS file updates, read manuals, check monitoring, document equipment and procedures, DO SOMETHING. Being bored when all the stuff is working will breed complacency and that becomes habit forming. Learn the good habits now and carry them forward; the people who need to notice these things? They do and will.
If I think of more stuff I'll post here.