EVERYTHING I Learned from a Summer of Software Development

As a Computer Science and Economics double-major at UC Berkeley, I had always struggled to find a job or internship that “fit me”.

I started my professional career as a marketing intern for an early-stage virtual reality startup in the summer after my first year at Cal. I liked it for the most part. I liked thinking about potential users, putting myself in their shoes, and determining how best to market them our software and hardware products. But I despised marketing on social media. I didn’t like posting on Facebook, Twitter, Instagram, and guerilla marketing on Reddit.

In the summer after my second year, I interned in a part-time business development role for a human resources and staffing startup. My job was to cold-email hundreds of startup teams in San Francisco and New York, asking if they needed help hiring non-technical employees. I absolutely loved the people at the job but once again, I despised the job itself.

Upon further reflection of my experiences at these internships and disillusioned involvements in Berkeley’s Red Cross Club and Associated Student Union, I realized I was missing out in the key area. I wasn’t living up to my potential.

I wasn’t using any of my economics or computer science knowledge in anything outside of my academics. That fact, in turn, would discourage me from getting excited to learn or put in extensive amounts of effort in my classes. If I was working jobs that don’t utilize what I’m learning, why the hell am I learning computer science or economics (let alone both), and why am I trying?

I experienced this thinking especially in my computer science classes. I liked what I learned, but I didn’t try to apply that knowledge in my class projects. I figured my future jobs wouldn’t require it, so there was no point in putting anything beyond minimal effort.

At the end of my third year at Cal, I knew I didn’t want anything to do with social media, emails, or finance. I was too late (and discouraged) to recruit for my then-ideal internships in product management or consulting, and so I decided to take an uncomfortable step forward. I applied and received an offer for a low-risk, high-reward Software Development internship in a boutique engineering firm.

And it was amazing. Over ten weeks during the summer, I worked in a 5-person team to develop an initial, fully-functional prototype web application for a client. Here’s what I learned:

Software Development is more interesting than I ever expected

My prior experience in software development had come from two sources. The first was my computer science class projects, which as I mentioned earlier, did not garner much of my attention or effort. The second was in building static websites for myself and my business fraternity using HTML, CSS, and some JavaScript — side projects I genuinely enjoyed but didn’t find enough time (yes, this was an excuse I used) to work on due to my academics and extracurriculars.

This summer internship taught me how to build a full-fledged web application. This was exciting.

I now had a goal in mind. Someone wants to use this application to do something, and I had to build said application so that they could do that something. I had to make them happy. Furthermore, the something was no longer providing static information with a website. This something was dynamic. It had to respond to a certain user’s input in a certain way. It had to be able to take in a process information to produce a specific result.

Applications include a front-end (client) and a back-end (server). The former is what users see and interact with. The latter is how the correct information is stored in and accessed from databases. That information is used at some point in a user’s interaction, and my job was to take it from the back-end and convey it to the user at the right time on the front-end.

Frameworks >>> Languages

As I mentioned above, I came into this internship knowing HTML, CSS, and some JavaScript. I didn’t have to learn a new language for my job. One of the big detractors for me going into this internship, however, was using these languages to build a full-scale web application.

From my experience building my fraternity’s website over the three weeks of Winter Break last December, I had an idea how difficult this project would be. Those three weeks were rewarding, but I hated how much I had to copy HTML from one file to another just to render the same exact elements (a navigation bar at the top, two footers at the bottom) on every page of the website. It made my code messy and redundant.

Then came this internship, and my introduction to the JavaScript framework React. All of a sudden, each component (i.e. navigation bar, footer, etc.) need only be written once and simply referenced when needed with a <NavigationBar /> tag. I could use logic to determine which elements should be rendered (shown onscreen) and which should not. I had control over every element at any given moment in time.

Languages >>> Frameworks

One of my coworkers came into this internship as a back-end developer. He was well-versed in Python, but knew very little HTML, CSS, or JavaScript. So when he finished building the back-end of the application, he struggled to transition to the front-end. He struggled to get accustomed to React because he didn’t have a fundamental understanding of the web structure and how the three basic languages played together to render elements. It took him a few weeks of questions, trial-and-errors, and Googling to adapt.

And so beyond that, I know my HTML and CSS skills are solid, but my JavaScript skills have a lot of room for improvement. This article also convinced me to dedicate more time towards it.

You need to know the fundamentals languages before you jump into the more complicated frameworks.

Just Start

You can’t spend all your time learning languages and frameworks (consuming) theoretically without actually doing something (producing) with them. You have to start writing code to see what works and what doesn’t. When you have a goal or vision in mind for what you want to achieve, when you know what the end-product looks like, you can push yourself forward with the skills and knowledge you have to achieve it. Along the way, you’ll build upon your foundation and gain confidence in yourself.

But before you start, make sure everyone involved is on the same page

Before writing even a line of code, the entire team should know the structure and design of the application from beginning to end. The team should know the capabilities of the application, the flow from one state to another, and the consistent visual and structural design of the application. The team should know which features the application absolutely must support — which features compose the minimum viable product.

Simply put, everyone must be on the same page throughout the process. The client, project leader, designers, engineers, and other business-focused teams, must all communicate to create an initial prototype on paper.

This was one of the problems we faced throughout the summer — the designers were behind, leading the engineers (us) to create a visual design and features the client didn’t especially like or want. We all eventually got on the same page, but we wasted a lot of resources building things that didn’t make it into the final prototype.

I’m happy we faced this problem because it taught me the importance of communication and a clear vision. This doesn’t mean that there can’t and won’t be changes and iterations for improvement as the product is built, but knowing the features and design agreed upon at the beginning is of utmost importance to ensure everyone’s time and energy is spent productively.

There are pros and cons to working in a team

On the positive end, you can share knowledge and critique one another in a team. With team members, someone is likely to have a solution to a problem you’re facing and there’s always someone to bounce ideas off of to ensure you come up with the best solution. You can ask one another how they would implement a feature or design an element, or how they built a component of the application. Team members can split the work it takes to build the application and specialize on what they are good at or what they want to learn. A team is a collaborative environment in which everyone can learn from one another and produce the best application possible in the shortest amount of time.

On the opposite end, design and implementation become more difficult. The entire team must be on the same page in terms of which and how data is stored, accessed, and utilized in various points throughout the app. You must be careful to take advantage of code written by your team without changing anything that might break their code. Solution: Git and version control.

Everyone must comment their code extremely well to ensure the team understands what is going on and why. Solution: do this even if you’re working alone so that anyone looking at your code (even yourself in the future) can understand it.

You don’t understand as much of the application the knowledge you gain is limited to the parts you worked on directly. For example, my work was focused heavily on the front-end of the application. I explain to you anything and everything I developed on the front-end extremely well, the rest of the front-end (that I did not work on directly) well enough. I can tell you how the front-end is accessing and utilizing data returned to it from the back-end. However, I can’t really explain to you how the data is being stored, accessed, or returned from the back-end. It’s hazy to me because I didn’t work on it as much and so I don’t understand the entire flow of the application. Working in a team essentially pushes you to work on what you’re good at or what you really want to learn. Solution: there really is none. Be more vocal about working on the things you don’t know, which doesn’t make much sense if you were hired for certain job because of certain skills? Work alone?

There’s so much more to learn!

That final con makes everything so much more exciting, but also a bit nerve-wracking. If I want to go the route of a full-stack developer, I’ll need to learn so much more about the back-end and even the front-end than I do currently.

If the company I work for post-graduation uses different frameworks than the ones I know, I’ll have to teach myself those as well. And so we come to a fork in the road.

Do I focus on getting better at what I already know? Do I apply to jobs that I’m more qualified for and in which I can understand and utilize more deeply my current skills?

Or do I focus on gaining a broader understanding of everything that’s out there — learn about Angular and Vue on the front-end, even though I’m experienced with React? Do I apply to jobs in which I can develop a wider breadth of skills on both the front- and back-ends?

The answer is probably somewhere in the middle, but how do I decide the extent to which I pursue one over the other? And which companies are looking for which focus?

These questions make me anxious for my software development future, but excited at the same time. I have so much room for growth, and if I can learn React in under 3 months, I’m sure I can do the same with anything else that comes my way. Skills are very transferable in software development.

The tradeoff to work in a team is worth it (in most cases)

If you’re working on a small-scale project in which you’re trying to maximize your personal development and control the complete implementation from start to finish, do it alone.

But if you’re working on a large-scale web application as we were doing over the summer, you need a team. My mentor Patrick knew what he was doing when he signed on for this project. He had knowledge and experience in the languages and frameworks we used on this project — he set up the entire structure himself! If Patrick had done this project alone, there wouldn’t have been much more he would have had to research to achieve a similar implementation and design as the other four of us achieved this summer. So why didn’t he do this project alone?

It wouldn’t have been feasible. The five of us combined put in at least 40 hours of work every weekday throughout the summer. Patrick working alone could have put in 8–14 hours every day, perhaps more if he were really pushing himself, but not much more if he wanted to remain healthy and sane. What we did as a team in 3 months would have taken Patrick at least 5 months to do alone. Furthermore, it wouldn’t have been as fun or meaningful to him (or us) had he worked alone. There’s more to learn in a team than just technical knowledge, and Patrick really wanted to teach us what he knew and learn more along the way. The communication and motivation skills learned are invaluable, and the camaraderie developed among the five of us throughout the summer was priceless.

Software Development is a lot of brainpower, little-to-no physical power

I expected a lot going into the internship. I expected to learn what I did not know. I expected to be challenged to come up with the best (or at least, a very good) implementation for various elements of the application. I expected to work 8 hours a day, 5 days a week. I expected to be held accountable for my work and progress. Those expectations were met.

But I didn’t expect that sitting down and looking at a screen for at least 7 of those 8 hours would be so physically and mentally taxing. My eyes were red and tired by the end of the day for the first few weeks. It was easy to forget to get up to stretch and ease my eyes every hour if I got into a great flow or I noticed my coworkers hard at work. Each day left my body stiff and in desperate need of exercise.

Luckily, I came up with potential solutions, albeit after the internship ended.

Psuedocode on paper, transcribe it to actual code on the computer.

If I know what I need to do, the data I have, and the objective at hand, I can work out all the logic on paper. I can write out the different cases in which I need to do one thing rather than another, I can write down exactly what should be rendered in which case, and I can note the data I need to pass from one element to another. I’ll need to make changes and perfect the design on the computer, but an hour on paper and an hour on the computer is better than two on the computer.

This would also give me the opportunity to think through the possible edge cases and find out what to do in each case, rather than discover the cases as I code. In the end, I would have cleaner code if I worked first on paper.

Use a timer to relax away from work and the computer every hour

I’m 99% sure there’s already an app or Chrome extension for this. The Pomodoro technique would also work well. Taking a small break every hour would give me a chance to clear my mind and re-approach my work with fresh eyes, so it’s a win-win.

Get a standing desk

Sitting sucks, standing rules. There’s not much more to say about it. But I will.

My back was pretty screwed up during the internship due to an unrelated issue while weightlifting. Sitting down for an extended amount of time (8+ hours) did nothing to help my back. Standing would have given it more blood circulation. And let’s face it, standing is more fun.

In an ideal future, I would work in a company with a nearby gym where I could work out in the middle of my day, perhaps during my lunch break, and then return to eat and work simultaneously.

It’s opened up more opportunities

Well, it’s opened up opportunities for more opportunities.

This software development internship was the first step in a professional career I’m now excited to undertake. Learning React and what I can build in just a few months if I put in the work has given me self-confidence and hope for the future.

In the final weeks of my internship and summer break, I re-built my fraternity’s website using React so that I could simplify the structure and make future edits and improvements more feasible for myself and others. I’m in the vital planning stage of a side-project using Spotify’s API, and have several ideas for future projects.

Patrick repeatedly proclaimed “There’s always a solution” whenever my coworkers or I found ourselves stuck in the design or implementation of a feature.

I agree with him and it goes beyond feature-building. If you have the data you require to build an entire application or software, actually building it is not impossible. It could take months to do so, a lot of capital, hard work, and perseverance, but it is possible. There is always a solution.

And that makes me insanely happy.

Thank you to my mentor Patrick Lu (LinkedIn) and coworkers Calvin Lee, Leo Sun, and Anish Saha for an amazing summer doing what I once thought I would never do or enjoy. I loved every moment of it.

Rahul Rangnekar is a senior studying Computer Science and Economics at the University of California, Berkeley. He is an avid writer and programmer, and hopes to find a career combining his skills into a software development or product management role. He enjoys weightlifting, reading, and cooking.Find him on LinkedIn.