Background Info

During my time in high school and my first year at college, I worked at an ed-tech company focused on providing students the tools to succeed. I started as an intern bouncing around a couple departments, and then finally settled down as a Software Engineering Intern. After taking a break during my senior year of high school, I returned to the company as an Associate Software Engineer. Overall, my time there was around 2 years. Here are the 5 lessons I learned that changed how I worked, thought, and acted in a professional environment.

1. Give very, very liberal estimates.

   • Something I couldn’t get through to my head was that giving short time estimates on tickets, while it may sound impressive to others at first, results in a stressful environment for you with not a lot of wiggle room. Things come up, you can get stuck on a problem that consumes days of progress, you could start feeling burnt out and might not be able to grind things out as much, anything could happen.

   • Often, the estimate you give doesn’t just go through one ear and out the other of your boss, but rather they will use this estimate to make commitments to other teams or in the overall timeline on what’s being worked on in the current quarter. So by setting unrealistic expectations on how fast you can get something done, you’re not only doing a disservice to yourself but to your coworkers who rely on you. My new general guideline for giving realistic estimates is: x weeks * 1.5. This gives you enough room to complete your task early if everything goes well (easy brownie points with little effort) and backup time in case things don’t. This also means you have to restructure how you give estimates. Don’t just commit to a time right then and there if you aren’t 100% confident about how long a task would take. Instead, say "I don't know, let me get back to you on that later today" and do some research. What does this task entail? How many moving parts are there? How many do you need to touch? Do you need some time to figure out how the existing code works? All of these are factors that increase and increase the amount of time it will take for you to deliver.

   • Do not think of yourself as a coding god, as you likely will not be able to become familiar with existing code and churn out a feature in two days. Don’t set yourself up for failure.

2. If you cannot meet a deadline, tell your boss.

   • Sometimes, despite our best efforts, things take longer than expected. That is okay, that doesn’t mean you’re not a good engineer, and that doesn’t mean you can’t grasp things properly. It just means that the circumstances were not as they were expected. We’re human, we’re not always right. That’s why these things are called estimates and not exactimates. But as I said in the previous point, sometimes the estimate you gave in the past has been established across teams and other estimates have built on top of it. That’s why, if you’re certain (or even half certain) you won’t be able to meet a deadline, tell your boss immediately. If your boss is worth the dollar they’re making, they will be understanding. Their priority at that moment isn’t that you weren’t able to reach a deadline, but rather now helping you figure out an updated deadline and making sure the people that have built off your previous deadline are now aware it’s been updated.

   • Now, that’s not to say you should be using this as a fallback method. If you have to rely on pushing back a deadline twice in, say, a quarter, you should start thinking about whether you’re effectively estimating time properly.

3. Ask many, many questions.

   • My ego when I first started working made me think that I was someone who didn’t need the help of others. It made me think that I was someone who could look at existing code and be able to explain every aspect of it. Part of it was the pride and over-confidence I had as a result of starting my career so early, the other was me being young and not knowing how the industry works. I thought I was different from everyone else, that I could think faster and do things faster. Turns out, I just had a lot of energy and drive. That will not always be the case over time, as you may start to slow down in progress and that’s okay. If you don’t immediately understand the code that you see, ask someone who does. Chances are, someone else has already had to look at that code before and did the heavy thinking on how it works or why it does what it does. You can save yourself so much time by simply having humility and asking your coworkers questions. Don’t make a new blueprint for the wheel your friend already has one.

   • This point is also really important when you’re treading territory that you’re not entirely familiar with. I was more of a backend guy before I started working, and I hardly touched web dev. However, my position thrust me head first into the world of frontend, and at first, I was overwhelmed. I thought I knew JavaScript inside and out, but React was a whole new beast. It came with a new set of challenges: component composition, state management, frontend-backend communication, and much more. We were using packages that I had no clue existed or how they worked. I spent too long trying to toy around when I had an untapped resource of engineers who had 4+ years of experience working with this technology on hand. As a result, tasks took much longer for me because I was both trying to learn and reach a deadline.

4. Don’t jump on every new tool.

   • I’ll be the first to admit, new technology is really exciting. Seeing things like Turborepo and Next.js App Directory, I was living in an era where every other week came with innovation in the frontend world. But, you need to understand that while these technologies can have potential benefits, migrating to them will be a dedicated investment. You have to ensure that nothing was broken in the process like your workflow, your coworker’s workflow, your CI/CD, or your existing code. Your coworkers may also be working on tasks that involved the old tooling you were using, and they don’t have the time to deal with your troubleshooting and experimenting when they have deadlines to reach. You do not need to make a proposal for every new thing that comes out.

   • A standard question to ask yourself when you see a new tool and want to migrate your codebase to use it: Will we survive and do fine without it? If the answer is yes, then re-evaluate whether you need to migrate to it right now, or could you just wait till a quarter where you can tackle existing tech debt. If the change is absolutely necessary or has the potential to bring about a tremendous positive impact on how long it takes to complete tickets or the quality of your code, then advocate for it. When you advocate for it, do your research. How can it positively impact us? What is it doing differently than your existing tooling? Is it battle-tested and production ready? Be prepared to hear these same questions from your boss.

5. Don’t be afraid of making mistakes.

   • The number one thing that you need to come to terms with when you’re in a junior position is that you will make mistakes. It’s not about never making them, it’s how you deal with them when they happen that matters. Your boss may not hold it against you if something happened as a result of a decision you made, but what they will remember is how you acted during it. Maybe your commit brought down production and you had to rollback. Maybe one of your functions got caught in a recursive call and brought down the database. How were you acting during the alarm bells and panic? Were you calm, collected, and focused? Or were you panicking, uncommunicative, and deflective. Accept responsibility and work to fix it, and you’ll win the hearts of any of your future bosses.