What did I learn as a Software Engineer at a Startup -Wiser Solutions?

This is my first role where not only I thoroughly enjoyed the work I was doing on every day basis but also had good times with my coworkers except when they get annoyed by my vague questions.
I finally was able to take the theory I had learned in my undergrad CS courses and apply them in real life applications. This work experience is what I was looking for after I switched from Data Science to backend development.

This is my first workplace where I felt I was not enough, I mean my skills were not enough 😉 which is a really really good thing because working with people talented and experienced than you is always the best thing that can happen to you. I tried so hard to persuade my coworkers that being competitive is not a bad thing but my company culture discouraged for various reasons or at least I felt it that way. Being competitive and being jealous are two different things and how being competitive can be good needs a separate thread of discussion. My coworkers are some of the nicest and unbiased teammates that I have ever met, they not only helped me become better software developer and answered my questions at any time of the day but also aided in thinking and communicating clearly! I certainly have things that I disagree with, but there were so many common grounds for us to be able to work together and learn from as they were seniors, experienced and knowledgable.

With time and dealing with complex projects, I realized that I had many more concepts yet to learn if I wanted to be a better backend developer but at the same time I ended up developing more passion for backend development. Starting with the role, I was little concerned and had expressed my concerns to my manager about my experience and minimal to no exposure to majority of tech stack but everything I learned was totally worth pursuing the role.

I had at about 6 month experience in full stack development in my previous role and I had not been part of product based architecture and design discussions. When I first saw the C4 diagram, I got so excited that I felt I have won the world, that is how much I loved C4 diagrams, maybe little exaggeration until I find something that is more beautiful and efficient, this totally makes me dishonest to C4 diagrams 😛. I even started a philosophical conversation with my manager saying how software architecture diagram is just like an architectural diagram or prototype to follow along when building bridges or houses. I would imagine any developer would get excited and feel accomplished if they get to see complicated micro-services architecture that allows them to visualize how services are interacting to each other and what tools are being used in order to get the entire application up and running. Visualizing how things work and being small part of making that application work was and is such a joy and mean so many things to me at an engineering as well as philosophical level! Being confused if you should ask or recommend something to an experienced architect and finding out you were correct when you finally decided to ask was a whole lot of confidence boost.

I completed 30+ tickets with various complexity that taught me new skills, prompted me into thinking critically and honed some of my preexisting skills.
Some important notes during completion of tasks:

· Engineering guardrails allows us to stay within company’s engineering best practices.

· Do not take logging, monitoring and debugging tools for granted.

· While streamlined requirements and clear expectations allowed me to see the value of clarity and planning the projects but at the same time, I was also able to learn to see the bigger picture and understand how to handle the requirements that had very little details.

· Configurations is the culprit of most of the errors.

· Bad debugging tools can delay development process at a much higher rate than you think.

· Taking the complex problem and dividing them into smaller chunks and solving each of them separately and combining those individual solutions has been, is and will always be valuable in solving a challenging problem.

· I was able to get more insights into what bad arguments look like from seniors, but still disagree to some because I am not convinced enough!

· I undervalued and postponed learning security and networking neither had taken courses to understand the underlying principles of security and networking.

· My majority of learnings came from code reviews and peer reviews.

· I realized that I am not a huge fan of daily stand ups not only at Wiser Solutions but at my previous roles too.

· Architectural diagrams, design diagrams are cool at high level but taking the theory and implementing it requires lot of sweat and perseverance especially when you are working on new and evolving technologies and there is no community for answering your questions if you get stuck.

· Always double check your assumptions and pay attention to minute details when you seem not to find solution after multiple attempts. If needed, know when to take a break and start fresh and from scratch. It allows to see the same problem from different perspective and with much ease especially when it is a complicated one.

· Make a list of common errors for ex. SyntaxError or ConnectionError that you come across with and examine what is it about your thought process and problem solving strategies that almost a pattern has been established and carefully trace down ineffective strategies!

· This one is pretty obvious, but when asking a question, let your coworker know all the options that you have tried , so they don’t waste their time in providing all the possible solutions that you have already implemented and did not succeed! This will prevent you from being judged on your problem solving skills but also shortens the conversation and time required to solve a problem.

· You will need a good understanding of containerization if you want to successfully debug singlehandedly.

· When I had to deal with something totally new, I would ask myself: Do I understand how distributed system works ? my answer most likely will lie on how distributed system is working as a whole. At the end of the day, it is all about data moving from one place to another for calculation to be performed on it and producing a result that adds value to the business. Especially in startups, working on some of the challenging problem that no one is solving and has not been solved before gives you the sense of achievement but comes with additional need of perseverance and energy to calm down your thoughts of hopelessness.

· Good sense of structure and predictability will take you a long way

· If you are working on completely unfamiliar problem, and it is taking time for you to understand the problem, look at the project structure surfacely. Check if you understand the definitions well and allow yourself to put the problems in domains for eg. if there are terminologies that may look intimidating then it is a “mindset or attitude” issue, if so deal with them more, read more about them and look examples and if needed, find all the occurrences of them in the codebase/design doc to get the better idea.

· Your goal should be to receive as less feedback as possible in code reviews, jot down the most frequent domain of reviews you get and hone skills and learn more in that domain.

· Fundamentals and engineering principles always stay the same no matter what tools and technologies you use.

· In my opinion, It is crucial for any organization to let every developers know not just seniors and managers to understand why they did what they did or why they picked tool x over tool y or have documentation on their design or software decisions and actively promote everyone to have such mindset to help entire organization build quality product.

· Never assume someone is always right even if they are a lot senior, if it does not make sense or you are not convinced enough, ask questions and clarify. Looking stupid is not the reason to not raise questions or concerns.

For technical details, regarding the project completion, I have to verify if we are allowed to share details! Thank you for reading.

what did you learn from your work experience at a startup ?