I have been working for around 8 years in different roles in the IT industry. As I was not particularly brilliant at my job initially and it took me some time to get better at some aspects of my job, for the rest I am a work in progress. I have actively observed and learned from different people around me seniors, peers and juniors. These are the lessons I have learned from the limited time in the service based companies till now, I feel these are some good lessons which might help someone who is starting out in IT or Tech but you never know the opinions or lessons might evolve with time.
1. Problem Solving is more important than language
When I started my career I was fortunate enough to work under a manager who asked me to develop various tools from scratch. As I was particularly new to coding, after making some progress I showed him the code I have written.
His advice was “Show me the algorithm, show it to me in English what you are trying to achieve and when it is clear in your head then start writing the code”
That is one piece of advice which has helped me tremendously. Rather than jumping directly & going berserk with the code, I think about it for a while and then start coding.
After coding for a few years I have now developed an intuition, I think for a bit about the main approach and then start coding improvising little bit here and there and figuring out the pattern after messing around for a bit. This feeling is akin to finding notes of a new song on a keyboard or finding a brilliant move in chess from muscle memory.
Another point is tools and languages can be learnt later if the approach is clear in your mind. So Problem Solving approach is more important than the programming language because a language can be learned by repetitions.
2. Build for scalability
While building software it is a good idea to build for scalability by keeping production deployment in mind. Potential future bottleneck can be avoided by thinking about some general points like
Avoid hardcoding if possible so that the code is flexible. One example would be defining macro/variable and replacing it’s value so that it replaces it in all the places. Another example could be not hardcoding username and password in the code but taking input from user or fetching it from database after validation.
Dynamically initializing paths and other variables to avoid human error
Reutilizing functions by handling different possible parameters that can be passed
Modularizing the code so changes are easier if required in the future without impacting the existing structure minimally.
Have an idea about initial & potential no. of users and scale vertically or horizontally as per need
3. Version Control Systems
It is good to understand the concept of Version Control Systems (VCS), it could be any product like CVS, SVN or Git based but the underlying application is to allow multiple developers to collaborate at the same time by letting them work on different modules independently.
Sometimes conflict resolution needs to be done at the time of merging code in the main branch when there are different versions of code repositories are there.
I drew this below diagram which explains the version control system at a high level
4. Communication
Communication is basically the key, no matter how good your work is if you are not able to convey it, you will not be able to take full advantage of it.
It is a good idea to drop a status mail with your progress on things you are working on. So that your lead is aware of what you are working on.
When building a product for business if the business has no use for the product, it will live on your PC. Make sure you include the business in requirements and expectations, communicate early and often.
If you are in service based company try to build a “Sales” deck as you program. A lot of people don’t know what we do, we should present what we are building so that if there is a potential opportunity we can maximize it. Another important aspect is when you are working it is fresh in your memory, so if you build a deck or notes at that time it will be helpful for your future self when you try to recall after some time.
5 . Know your audience
Specially when you are working with clients or end users it is important to have an idea about their level of technical capabilities. Sometimes you have to tone down the technical details and present an abstract idea when you are working with the business folks because they might not be interested in the nitty gritty details.
6. Don’t be afraid to break things
I remember when I started my first job assignment and when I used to compile code I used to get hundreds of compilation errors and my heart used to sink. But the good thing is, the higher the no. of errors you face the more easily you can solve those issues next time.
Another advice that was given to me by my Lead once was don’t be afraid to break things. Even if you break it, you will get a better understanding of internals when you fix it yourself.
7. Backup your file
It’s a good idea to save your file and create backup if you are working locally. I have lost some work more than once so thought of mentioning it. It’s better that you learn from my mistakes.
8. Comments & Documentation
Human memory is fickle. So when you are coding, a good approach would be to have descriptive comments so that if you work on it two years from now, you will be able to recollect what you did and how you did it.
Or if a new person comes in to maintain the code, he/she is able to understand the reasoning behind the code.
If your company follows some standards in comments that will be great for consistency in the code base.
E.g. of a simple function header comment
#------------------------------------------------
# Function Name: full_Name
# Parameters: firstName (str), lastName (str)
# Return: (str)
# Description: Concatenates firstName and lastName
# parameters with a single space between
# them and displays the result.
# Example of Usage:
# >> full_Name('Zeeshan','Ali')
# Zeeshan Ali
# ---------------------------------------------
For business continuity it is a good idea to create documents when you are working on a project and it is fresh in your mind. It will help you and will also help in giving Knowledge Transfer (KT) when someone new joins the project.
9. Learn debugging & root cause analysis
Debugging code is an essential technique that will come in handy when we encounter bugs while working on projects or working on ticket fixing.
“In my opinion debugging is the technique of eliminating scope of code to consider for analysis, step by step till we reach the actual root cause of the bug”
Often people utilize different debuggers which help in simulating the flow of execution by placing break points
10. SQL Delete/Updates with where condition
If you are working with databases and have to update or delete records make sure you double check you are writing the where condition to target correct records.
I remember making a blunder of updating the whole table when I forgot the where condition and since there were auto commits enabled. By the time I realized my mistake I couldn’t rollover to the previous state. Luckily, that table was not that important for business.
11. For Frontend/Game/App Developers
When you are starting out the best way to learn is recreating replica of existing webpages/games/Apps. That way you will have fixed spec and it is similar to getting a design document with wireframe that you need to recreate. Many developers want to start out with their original idea at first, but I would say recreate a few apps because
Replicating webpage/apps/games is similar to learning sentences of a new language. When you have learned enough sentences you can convey your own message in that language.
12. vim is underrated
At the start of my career, I worked on Unix/Linux environment where by default I had to work on vim editor. Once I got the hang of it my speed of writing code increased a lot because you can do everything from the keyboard without touching the mouse.
New code editors like Visual Studio Code also have a plug-in for vim if that is your preference.
13. Regex
If you are into automating stuff it is good to have some knowledge of regular expressions. The primary use is pattern matching like find or find and replace. It could be used for validation of fields, web scraping, data parsing, data correction & standardizing etc.
I use the below website to make sure my regex is capturing the correct pattern when I am writing a complex regex.
I do have a lot of thoughts on this topic, I will cover this more extensively in another post.
14. Breadthwise or depth-wise knowledge
Since we have limited time we can master limited no. of things now it is up to you to decide where you want to invest your time.
You can be a generalist who knows little bit of everything. Such cross functional roles are good in early career they expose you to different aspects and help in identifying your likes and dislikes or in best case find your calling.
Expertise is gained by putting in the effort/hours and mastering the ins and outs of that particular field. It is particularly useful in niche fields like in game dev, if you have a specialty in say Level Design or Model Rigging you will be taken more seriously if you apply for those specific roles.
15. Don’t be too hard on yourself
Last but not the least be kind to yourself.
If you are not understanding programming. Maybe you are not learning from the right medium or you need more practice. I would say don’t lose hope you will get it eventually, trust me.
When I started my career I felt I will never be able to learn coding, I used to have serious imposter syndrome but I didn’t give up and eventually I did get better and started to enjoy it.
Not giving up is the key, you will eventually get better at it. But how much effort to put & is it worth it, that is the question only you can answer. After all, programmer is not the only job profile in IT industry.
* FIN.*