Things I Wish I Knew When I Started Programming
27 Dec 2015
If by some magical event I could go back in time to the day before I started my first job as a software engineer, this is what I would say.
Drive Slow
I mentioned a similar message in a previous post and I believe it is worth repeating. When starting a new job or a new career, it is easy to place external pressures on ourselves regarding time. This is a common issue that can arise when comparing one’s own work with those around them. As the new employee, noticing and measuring your own speed and efficiency against existing personnel can feel like the correct thing to do; however, chasing the “competition” or “proving that you are just as fast as them” will only result in high stress levels and bug riddled software.
The people who seem “fast” or come off as a “10x engineer” were not born that way. They took their time and learned their craft. And with that, they have slowly accelerated their process and patterns to make them appear extremely quick and efficient.
Deadlines should be thought of as real and valid; however, working at lightning speed to try and meet those deadlines will end up causing more work in the long run. What would be better, missing a deadline by a day or making a deadline and incurring so many bugs and tech debt that it takes two weeks to clean everything up?
ABL
Glengarry Glen Ross’s iconic scene has very clear message: Always Be Closing, meaning that one should constantly strive to be in the process completing a sale. When starting out writing software and even after years of doing it, a similar attitude can be extremely helpful: Always Be Learning.
From day one to day one thousand, learning and absorbing new information is very important. A key to learning new things is in asking questions. When starting a new job or a new career, there seems to be a stigma attached to asking questions. We are all under the impression that “they hired me to do this job, they must assume I know exactly what I’m doing.” This mentality can inhibit our natural inquisitive nature which is a great catalyst to learning.
Ridicule and impostor syndrome are the most likely the reasons stopping people from asking questions. The idea that questions might expose a person as not “good enough” or “smart enough” for their job is ridiculous and often unfounded. Getting over these fears early in one’s career is extremely important. Questions should be encouraged and celebrated. Ask questions every single day, ask a lot of them but make sure not to ask the same one too many times. No one enjoys repeating themselves.
It is Ok to be Wrong
Similar to not asking questions, most new engineers are terrified of being wrong. A golden rule is to be correct frequently, but no one is capable of being correct all the time. The trick to being wrong is how a person reacts when it happens. There is a huge difference between promoting a technique or solution and being closed-minded to alternatives.
If someone was never wrong, how could they learn? And if they did not learn, how could they Always Be Learning? Tackling instances of being wrong with an open mind helps refine a person’s skills, shaping them with feedback from others. While this mentality, like others already mentioned, is relevant throughout a person’s career, it is especially important in the beginning. In the beginning a person is likely wrong a lot of the time. This means that in the beginning a person has the most opportunity to grow; to be wrong and learn from those mistakes. Internalizing these mistakes can help bolster a person’s technical skills and confidence.
R.T.F.S.
At the onset of one’s career, it is easy to treat third party software or services as magical boxes of mystery. However, this is not necessary. It is actually very easy to open and read the source of many third party applications (especially in web development). Therefore, it becomes imperative to Read The Freaking Source.
Reading and having at least a basic understanding of how a piece of third party software works is paramount for a new developer. If foreign code is treated as magic, that is all it will ever be. This magic can become a crutch that an innocent new developer may find themselves leaning against more and more until it eventually breaks, leaving the developer confused and helpless.
Note: Not all third party software’s source can be read as not all of it is open source. If this is the case, do not try to read the source, it will not make much sense.
Who wants to be confused and helpless? No one wants that and no one needs to experience that. Reading the source code of a library or crucial bit of third party open source software can help bring light to an otherwise shrouded system, bringing a new level of depth to a developer’s understanding.