11 Great Tips From A Guy Who Leveled Up From Intern To Dev

Hi everyone! This is a revised version of my article from my personal blog.

This is an article that expresses a few major learnings I would like to take away and mistakes I wouldn’t want to commit again from my journey, and maybe stand out like a guide book for those who are starting their career in Software Industry. I have tried to put up my learning and takeaways from my voyage in the simplest way I can.

Learning is a Continuum Concept, where at every level and stage of your life, you learn and take away something from your previous experiences

I am closing in on completing two years of my career at a startup, starting as a Graduate Intern Developer to Junior Developer and what a journey it has been. I have learnt a lot during the course of this ride. I explored newer nooks of the developmental and DevOps technology. I have made mistakes and learnt from them.

During the Internship experience, I encountered a bunch of challenges that are very much typical to all, who is going through a transition from the College Graduate phase to the Working Professional phase. Likewise, I am going to address the challenges that I had faced along with the changes in my perception while growing as a working professional.

Some takeaways so far from my experience:

1. Tutorial Hell

Initially, when we start out as newbies, it is quite common that we prefer to learn videos from Youtube Tutorials, Udemy or any other LMS application. Some might prefer following and reading from some open blogs like Freecodecamp or Medium blogs.

Now, let us first understand what is Tutorials Hell?

Tutorial Hell is a typical situation, where you find a lot of tutorials and you are not sure about which one to follow and learn from. Assuming, let us say somehow you figured out which tutorial to learn from. Now you struggle with what to do/build with what you have learnt.

Initially, I had a very hard time getting through this situation. I was learning Node.js and I was very new to the Event-Driven Programming Paradigm and had a lot of confusions about fundamentals, despite I had followed one of the many tutorials available.

Generally speaking, I do not have any issue with tutorials, but I find that most of the tutorials, always tend to miss 4–5 core concepts, as they expect you to have a technical grasp of the same. Those missed out concepts create a lot of voids as you go ahead.

Let me give you an instance from my own experience. If you have worked on any JS-based framework/libraries, you must be knowing different ways of handling asynchronous operations (Callbacks, Promises, async-await). Those of you who do not know, do not worry, it is just 3 different ways of handling async operations. The point being, Callbacks are a real pain, whereas Promises and async-await is a better and cleaner way of writing code.

Initially, when I started out writing RESTful APIs, I followed the Callback way of handling asynchronous operation, because the tutorial I had followed did not bother to speak about Promises and async-await. For around a month or so, imagine my life, handling every DB calls and asynchronous functions as callbacks. It was too difficult to write simple logic, despite the problem statement was quite straightforward.

With time, as I kept exploring different technologies, one thing that I realised is that nothing beats the OFFICIAL DOCUMENTATION. Every technology that you want to learn, has its own Learning Management System or its own Official Documentation published, which surely covers every aspect of the technology that you are learning. Since then, any technology that I want to explore, I always prefer to follow the official documentation.

Avoid Cobwebbed by tutorials

Finally, after we learn from the resource, follows another overwhelming situation where you are more confused about what to do with the updated knowledge portfolio?

Initially, since I was already working on a project, I could easily fill in whatever I learnt to fulfil the project requirements. It allowed me to constantly learn and explore.

There could be scenarios where you learn technologies out of the scope of your project you are working on. How to deal with situations in that scenario?

Difference between Knowing vs Understanding

The best thing one should do after learning technology is BUILDING SOMETHING. Build, Create something you want. Be it simply for fun. Does not really have to be a real-time useful product. It is simply a product that you can apply conceptual learning to practicality.

If it’s a new programming language, you can explore more by trying to solve problems from HackerRank or other competitive platforms. Maintain a GitHub Repository to keep track of whatever you are learning with simple documentation for your understanding. This allows you to have your own documentation that you can look back into whenever you want. Creating and documenting the Proof of Concepts is a deal.

Meanwhile, KEEP CODE-READING from different GitHub repositories. I used to randomly code-read just to get a glimpse of different approaches to solving problems and writing code. This actually helped me improvise the way I wrote the code.

Open Source Contribution allows you to spread your wings and collaborate with people having different ideologies.

Open Source Contribution allows you to spread your wings and collaborate with people having different ideologies.

One more way to get through this situation is to CONTRIBUTE TOWARDS OPEN SOURCE. Try to search for some Open Source Projects built on top of the technology and try actively contributing towards it or recreating your own project as a Proof of Concept.

2. Build Products, not Junk

This seriously was a huge misconception I had initially, where I thought trying to solve the problem statement and coming up with a solution, is the most important thing. Probably, because of an attitude sometimes your graduate syllabus forces you to inculcate, where finding a solution is considered important than any other factors.

There are two factors that we tend to fail to focus upon, firstly END-USER of the application and secondly CLARITY over USER REQUIREMENTS.

What user wanted vs What you delivered

Sometimes we fail to understand the user requirements. At times, we misinterpret given User Requirement, due to our individual perception and experience, which, of course, is not a mistake. But, it is very important to clarify what you have understood with the client/user/product-owner.

It is always better to ask, in the very initial stage of the project, with the product-owner/client, whether your understanding of the requirements are accurate or not. When you question the client in the very first stage, you won’t end up building a product that was not required.

Similarly whenever, requirement pitches in between the development cycle, ensure you clarify that as well, just to make sure that your project doesn’t end up going south.

Bad UI/UX: Label [PUSH/PULL] and Why? Do I need the handlebar to push?

Always focus on building the product on the basis of how the product owner (End-User) wants it.

Bad Design Aesthetics: A button showing the corresponding number and another actual button to click the floor number

When you are building the product, ask yourself, “As an owner of the product, does this make my work easier? Does this solve my problem? Is this solution feasible? Is this the only approach available? Are there better approaches?”.

By the time, your research is done, and have it evaluated based on the above factors, you will have a conclusive and evident answer, portraying clarity over how to go about building the product with a better User Experience.

Keep constantly in touch with end-user and build the product always iteratively.

3. Knowing the Best Practices

To those who do not know what do I mean by Best Practices? Best Practices are evidently proved guidelines with a strong theory behind them.

Daily Healthy Routine is the closest analogy to the Best Practices

Just like how we follow certain practices on daily basis like bathing, washing hands after eating, and so on, to maintain our hygiene and keep ourselves neat and tidy. Similarly, in software development, we follow a certain set of proved norms, just to ensure that the product we are building doesn’t rot with time or newer requirements.

Every technology you learn, there are always best practices tagged along with it. It is quite difficult to remember all the best practices. Over time, one thing that I realised and noticed about the BEST PRACTICES is that most of them try to learn and recollect the best practices. And fail to understand the theory behind the practice that we should follow.

If you understand the theory behind the practice, it wouldn’t be difficult to remember them while implementing it.

Practice tells you that things are good or bad; theory tells why.

Let us take a simple instance, whenever we want to scale your project structure, how do you figure that out?

We have a proposed model called the Scaling Cube Theory, which describes the basic principle behind the model and why should you consider it when scaling the project.

Scale Cube: Service Scalability Best Practices

Each axis of the indicates, as shown below:

• X-axis: Scaling by cloning, otherwise known as Horizontal Duplication. Usually monolithic projects when deployed, have multiple cloned copies of an application behind a load balancer. When you have only one service to deal with, we are mostly advised to go with Monolithic Architecture.
• Y-axis: Scaling by splitting different services, known as decomposition. Usually, projects with complex problems statements and several services, are often advised to split the application into multiple distinct services. When you take this kind of decomposition approach, we call it Microservice Architecture.
• Z-axis: Scaling by splitting similar things, known as Data Partitioning. In projects where robustness is a very high priority, improving Infrastructure from the Data Storage point of view helps a lot. In this kind of approach, there are several replicated copy of the code, but each of them is accessible only to a subset of the data.

If you see in the above instance, by knowing the theory behind the Scaling Cube, it is easier for us to understand which approach to be considered when we are building the project architecture, based on the business requirements of the project. When we apply Scaling Cube, it is easier to evaluate whether or not to scale the project.

4. Debugging

At the early stage of my learning, I devoted a lot of my time to debugging, since I was very new to the technology I was working on. And I did not have the grasp of the errors and crashes that followed. I always used to seek help from StackOverflow and Grepper extension for finding the cause and origin of the bug and do some quick fixes. As I kept exploring, I became quite familiar with some set of errors.

But as I kept exploring new services and stacks, sometimes it was due to bugs in packages that I am using, it so used to happen, where I encounter some new types of error. I couldn’t afford to spend more time to debug and resolve errors, so I started following a simple backtracking method to debug called Five whys.

Debugging is a sort of aggravating task when you can not figure out the origin and cause of the error. The five whys method was a very basic technique, which helped me determine the root cause of the error in the easiest way, by iteratively asking the question “Why?”.

5 Whys: Technique used by Toyota Motors for finding manufacturing defects

I used loggers to ensure from where exactly the issue has originated. This saves a lot of time. It is important to find the origin and root cause of the error.

Also ensure that you document the tracked bug, which is at the application level. It is important to document the bug, maintain the history of bug tracks and record the solution for the bug reported.

5. When you have to explore something new, create Proof of Concept

Whenever a new problem statement pitches in, something that you have not worked on. Always create a Proof of Concept for the same. Try out different possible solutions for the same. And do some research work on the different possible solution and make a simple Proof of Concept with enough documentation(for your teammates to follow up). Have a healthy discussion and take opinions from your team.

Proof of Concept is not final implementation, rather they are intended to provide proof that a given system would work effectively for the problem statement posed. Take feedback on the PoC, and also do not forget to keep them in your GitHub Repository for future reference for yourself and others.

6. Unit Tests makes your code better

I learnt this the hard way, but honestly speaking, Unit tests are the best way to catch bugs. In the initial stage, I hardly knew and cared about writing Unit Tests for the APIs, I used to often find myself concentrating on completing the tasks in the expected slot with good quality.

Unit Testing: Verify if the piece of code is doing what it is intended to do

Writing Unit Tests helps you to verify that the code is doing what it is intended to do. Unit tests always help and provide strong backbone support to maintain your code and safely refactor them from time to time. Sometimes, Unit Tests helped me to discover edge cases that I have missed upon. Since the time, I have learnt to write Unit Tests, I have always made it a habit to write Unit Tests for the code I write, which gives me more confidence in the quality of the code I deliver.

7. Maintain Documentation

Documentation is always the best way to define a feature from the User’s perspective. Before developing the feature, document the feature first. As a developer, always maintain documentation for the feature you are building.

“Documentation is a love letter that you write to your future self” -Twitter

Whenever you can, ensure that you have the document written has been reviewed by the end users and stakeholders before any development begins. As and when the feature is modified during development, make sure that the corresponding changes are documented. Just as documentations are modified, so should be the Unit Tests.

8. Writing Blogs

Writing blogs is useful for many reasons. Writing blogs will help you realise if you have understood the concepts well and if you are able to explain them in a way others can understand. As developers, we mostly work on creating and adding values to the product, we are building maybe by resolving a bug or implementing new features, which most of them do, but writing blogs would help you get a better understanding of the concepts and gives you a very good feeling about helping people. Some day, someone might read your content and may be able to produce a feature required for their project through your guidance. Your experience can help someone get proper guidance.

9. Contribute towards Open Source

Open Source has a great community built around. Contributing and being part of the Open Source Community allows me to explore and embrace newer perspectives. Contributing to Open Source helps me a lot in improvising my problem-solving skills.

I get to meet like-minded people and they help me inspire to become a better developer. It is always nice to be part of a peer, passionate about developing and building products. Trust me, it feels great to have your name as a contributor to someone’s project, which boosts your positivity and confidence.

10. Always be Open to Continuous Learn

Firstly make sure that you build upon your fundamentals. Keep your fundamentals strong. If your fundamentals are strong, switching between similar technologies and exploring them would not be a difficult task.

Keep exploring new technologies. The Software and Technology Industry is an everlasting industry that keeps expanding with time. As time evolves, the industry also keeps evolving with new technology arising every new day. Always ensure you are open to switch and learn, explore and practically work on those technologies.

Read Technical and Non Technical books to keep yourself aware of the revolutionary changes happening in the industry. Keep reading blogs published by Major MNCs and have an understanding of their system design and architecture and the theory behind it.

I always keep exploring different technologies, because it helps me have a wider perspective. Wider perspective helps you come out with better and creative solutions. I prefer to be a Generalizing Specialist.

A Generalizing Specialist is jack-of-all-trades, and master of a few

11. Be polite

Life becomes much easier as a developer when you start listening to others. Always have a certain level of humility when listening to others. It is very important to be open to different perspectives and opinions.

Every expert was once a beginner.

You were a beginner before you reached this stage today.

Always be there for those who need your guidance and keep helping others learn and grow. In the process of guiding others and helping them expand their wings, there is a lot that you will explore and experience as well.

These were some of the major takeaways from my journey as an Intern to a Developer. I hope all the beginners who are reading the article, will find these useful for your journey. Those who have already passed this phase might find it very much relatable.

The post has been longer than expected, if you got this far, I appreciate your patience and thank you for your time.

If you like the article, hit the like button, share the article and subscribe to the blog. If you want me to write an article on specific domain/technology I am provisioned in, feel free to drop a mail at [email protected]

Stay tuned for my next article.

That’s all for now. Thank you for reading.

Signing off until next time.

Happy Learning.

Previously published at https://ohmyscript.com/2021/04/13/reflecting-on-my-voyage-as-an-intern-to-a-developer/