It goes without saying that - we all learn how we learn. Learning computer programming, depending on how you define that is not a major feat, but solving problems of all sizes with programming is. An aspiring programmer watching an experienced engineer sail through code, could describe what they’ve witnessed as an impossible or mythical road. But, what if I could go back and be that young/green engineer? What I would raise my hand and ask “what exactly will I need to learn to sail like that?” Actually, let's break that down even further. Very doubtful that a young engineer would be as precise and direct since most things at that point are dreamy. So, “how can i do that?”. Instead of giving a dissertation on what i’ve observed from either bootcamps or computer science degree programs, and alternate learning tracks in general, I’ll just go ahead and answer my own question.
When we dream of being a programmer, it’s a nice warm place all year round with crystal clear water and sungold beaches. It’s in features, and finished viable applications. What the sailor knows that you aren’t aware of now, is that those who are able to predominantly work on only features are in extremely rare and privileged situations; and likely wasn’t always the case for the individual. And it makes sense - why on earth would I let a green engineer ignite my systems. Yes ignite, there will be a ton of fires. I’ll give a fun example that occured in recent times. One of my favorite engineers who has come a long way since this story was given the keys to the kingdom, or sudo access to a production server. One early morning, woken up by alerts on the server. We did identify the problem and all that was left was a simple application restart. Priding ourselves on a HA (high availability) architecture, there would be no outage to users. The engineer was happy to take over that part of our surgery, and as I watched over the server, the engineer shut down the server itself and not the application. Without identifying who is to blame, this is the type of issue that exposed our willingness to facilitate fires because we didn’t have the credentials to turn the vm back on. To make matters worse, all of our pats on the back with HA was misplaced as all the content didn’t load correctly.
Be Cautious
I have elected to totally switch from feature thinking to problem thinking, which requires skills that are less based on creativity. So how dangerous are you? My initial energy when asked to troubleshoot anything is very cautious, and totally lacks my usual enthusiasm for life. At that moment I don’t even trust the person that has spent the last three months on it, and the reason why is, I wouldn’t be in this situation if they knew exactly what is going on and what to do to fix it. I also expect the same treatment in return. Are you the engineer that copies directly from stackoverflow without understanding the impact? So tread like you’ve never tread before. Learn from others mistakes as well as your own. Some of the learning involved is not to be sped up.
Be a Deep Learner
If you can imagine how physically deep lingual skills must reside (just a hunch), to the point where you can feel pain when you are in search of a word. I am totally comfortable not keeping every method or a configuration in my head, that's where the speedy modern day research skills come in; oh yeah and stackoverflow. Y’all can have all the regex you want on deck, not me. Deep Learning of the smallest parts/components of a software can inform your understanding of what they are capable of. If you understand what something is capable of, then you are able to troubleshoot it better. Knowing what you understand well, is the same as understanding what you don’t know well. Either you do or you don’t. And your competence in these parts allows you to be less cautious. Imagine driving all day with your hazards on. With the technologies you use often, make an assessment of what you know deeply, and keep adding skills.
Don’t Reinvent the Wheel, Comes with much Risk
One of my favorite lessons from being a Mass Communications major which I apply to life, is “you have to know the rule, before you break the rule.” If I’m not mistaken, it was referencing video composition rules, like “rule of thirds”, “lead room”, “head room”, etc. Now I clearly didn’t make it pro in video production yet (hehe), but the importance of the rules impacts my viewership of any content I watch. These boundaries if I may, has not only survived but flourishes in whatever aspect ratio we are trapped into today. So looking back at the hard work to get projects up as a young coder, there was way too much bending of technology. If you want to be (stay) around then you gotta be aware of it’s trends, buzzwords, do’s and don’ts. Awareness doesn’t mean endorsement (Thanks Twitter). There are some strong don’ts, look at it this way, it’s hard to name a programming language you aren’t able to build a website with in one form or another, but that doesn’t mean there aren’t bad choices. We tend to lean towards our limited toolkit at this stage without understanding risk. If you’d like for what you do to assume less risk and probably increase its ability to reach project success, then understand what your current toolkit can do, and do for others now. My advice is always to be supported by a community that you enjoy, and understand, even if it’s from a distance. If you decide to bend something good luck.. So I’ll make the claim that keeping it simple will help your process and lessen the forks in the road.
Endorse the architecture, and architects
Understand the roles of things from it’s high level. Therefore you’d learn alot about how things interact with each other from end to end. A web server is just that, a web server, and a lot more goes on there on the wild wild west. This endorsement of architecture would help to verify that other technologies can meet a requirement. I am not saying that the grass is greener by no means, but this purely becomes your job, to describe the difference in water retention of Kentucky BlueGrass and Tall fescue. The more you're willing to take that on, and hopefully make it your duty to acquire real-world benefits and fit to your team and organization, you're assuming some ownership of it’s adoption. So all this results in being depended on to produce something bigger than writing lines of code, and where failure is personal and therefore not an option. It’s common to come across these people many call smart/brilliant, these big and broad thinkers. I’d listen to them before passing judgement.