Lessons Learned After Two Years of Being an Engineer

After almost two years as an engineer at my current company Moda Operandi (and four total with my stint in digital marketing), I’m moving onto my next engineering role at an ed tech company called 2U and I could not be more thrilled! Through years of private tutoring since high school, teaching several classes of Bootcamp Prep at Fullstack, and working at National Writing Project, the importance of education has been top of mind and it’s been a dream of mine to be able to improve the direction of education on a larger scale — which I now have the great fortune of doing, with an awesome team to boot!

I’ve had a great experience at Moda these past few years and it’s definitely bittersweet to leave such great coworkers and some amazing products behind. On that note, I want to recap some of the lessons I’ve learned during my first two years working as an engineer.

Disclaimer: Some tips may seem obvious to you or are things you already learned before your first role. Some may be more general and apply to fields outside of engineering. This is my specific experience and therefore may not necessarily apply to you!

Make friends with coworkers

During my first few months at Moda in marketing I had to actively learn how to smile at coworkers and make a lot more small talk than I knew how (in case it wasn’t obvious I am 100% an introvert). After a while it became more natural to talk to my coworkers about my weekend plans or have heart to hearts with them over coffee breaks. When I moved to the tech team two years later, I was so focused on trying to pick up new technologies and figure out how to navigate the codebase that I assumed making friends with my new teammates wasn’t as important. This was amplified by the fact that programming can be pretty heads down and independent minus a few meetings here and there.

I didn’t reflect on this much until being encouraged by my manager to share my wins and communicate more, and hearing a Developer Tea podcast on the importance of getting to know your coworkers even if you’re an introvert. Once I made more of an effort it made such a visible difference both to my happiness/morale and communication with teammates. Of course, no one has to be best friends with their coworkers, hang out with them on weekends or even happy hours and so on, but make the time to ask them about their weekends or hobbies. Be curious and treat them like fellow people. Lower your guard down (within reason) and trust me you will reap the benefits and be a lot happier working with people you know beyond their job functions.

Think about what you can do for your company, not what your company can do for you

Many complaints or resentments you hold towards your company can result in direct action items on your part as soon as you reframe your state of mind.

My personal experience with this was feeling envious of other companies that had heavy outward presence in the tech community, especially knowing that Moda had the talent and awesome products to be well-known. After some time of wishing leadership would do more, I brought up the idea of us having an engineering blog which eventually led to me spearheading an entire team initiative of building our presence in the industry through things like hosting meetups, starting our team blog, organizing discussion circles and more.

The point is, ask for what you want instead of wishing everything will fall into place. When you ask, frame it in a way that makes it obvious that what you want is for the company’s benefit. Want to get promoted? Ask what you can improve to move to the next level, and execute. Want to be in fewer meetings? Talk to your manager about how you’d be more productive with more solo time.

Another point is to not be too discouraged by any projects or features falling through because of change in business plans. Part of working at a company is not being a cowboy coder obsessed with your code and your progress - you’re part of a team, and the team follows overall business priorities, not a sole individual’s. Also there are always lessons to be had and things you learn even with projects that don’t come to fruition. You can gain lots of insight with time spent without necessarily deploying the code to production.

Do not take feedback lightly!

When you’re starting off your career in engineering, feedback (most commonly through code reviews) is singlehandedly the biggest way to grow. Therefore do not take this lightly — take to heart all the lessons people want to teach you and actively work on pain points that managers or coworkers point out.

Also ask for informal feedback and advice from your coworkers on how to grow! They are your best resource for navigating both how to be a better engineer and how to be a better employee at your specific company.

Work on building your skills outside of work

This is not something that every engineer will necessarily have the time to do but if possible, I highly encourage sharpening your technical skills outside of work. It helps a lot to work in different contexts so that you touch different technologies, interact with lots of different people, and get opportunities that you might not have at work.

For example, as I mentioned earlier I taught at Fullstack for a few months part time. This was beyond helpful in improving my ability to explain coding concepts and help others debug code. Beyond teaching/mentoring, some common ways to build skills would be open source projects, side projects (solo or with friends), code kata, giving engineering talks, and more!

Write everything down

I don’t know if it’s because I’m getting older or relying on my phone too much instead of memory, but I find myself easily forgetting things I learned not too long ago. For this reason I find it absolutely crucial to log everything.

Write down when you struggled for hours on something and what the fix was (trust me, it will definitely happen to you again - and it feels terrible to waste time struggling on something you already know you solved). Write down common commands you use and passwords along with notes during planning meetings and one-on-ones. Keep it all handy and organized!

Optimize your pull requests/code reviews

Before submitting pull requests do a final line by line check to catch any minor errors. Also, directly mention team members on lines of code that you’re unsure about or want specific review. It’s common knowledge that the more lines the PR has the less heavily dissected it will be, so calling specific attention guarantees review of what you’re unsure about.

If you have time, look at other team members’ pull requests even if they’re not directly asking you for a review (the more related it is to your project, the more important). Try to understand what the code’s doing and pinpoint any areas you see that could be refactored. Reading others’ comments on pull requests that aren’t your own is a huge opportunity for learning how to refactor.

As for your own code reviews, if you feel that you’ve gotten feedback to change some line that you feel is better written as is, talk with your reviewer! Code is not always black and white and you may have picked up on some aspect that your reviewer hasn’t. Or if the reviewer’s way is better, you want to make sure you clearly understand why it’s optimal.

Knowing when to ask questions or continue struggling on your own

Probably the hardest aspect of being a junior is deciding when to continue struggling trying to figure something out that you’re totally clueless about, or ask a more senior engineer for help.

First, give yourself a time limit and/or specific action items you’ll do before asking. You can search on Google and vow to read the first 10 tabs, or try xyz debugging tools, and if all those fail you might decide to ask then.

If it’s locating a file within the codebase or anything more contextual that you’re unfamiliar with and that Google can’t answer, just ask after a few minutes of poking around the code.

Some rapidfire tips specific to software engineering:

  • Familiarize yourself with team’s style guide/code style (even if they don’t have an official one documented) and adopt. These might be anything from preferring utility libraries like Lodash over custom functions, preferring ternary operators or not, writing short blocks of functions or if statements on one line vs multiple, always explicitly including return in Ruby, etc.
  • If you’re not particular about IDEs it’s helpful to conform to what the majority of your teammates use that you’ll be working with most frequently. It saves a lot of time when pairing or debugging something together.
  • Help look into urgent issues and step up for support, including in more unfamiliar domains that are unrelated to any code you’ve written. Even if your efforts lead nowhere and the problem is fixed before (which as a junior will most likely happen), it’ll help you get more practice debugging and fighting fires.

Overall I know I have much left to grow as an engineer, but seeing this list makes me proud of how far I’ve come during my time at Moda. Growth in programming can feel incremental and slow at times, especially when you “waste” half a day on a bug that another engineer spots the error for within a few minutes, but if you’re tackling new challenges with smart, hard-working people every day, everything else will fall into place!

Full-time Development

It’s already been a year since I’ve last written and 9 months since I’ve been a full-time developer/engineer. Crazy to think about what it feels like to be on the other side of a goal you’ve worked hard to reach. Going to try to recap some thoughts I’ve felt and experienced over the past year.

Graduation from Fullstack

Fullstack Flex was 100% worth it for me. There was simply no other way I was going to learn development as much and as efficiently while still working full-time as with Flex. The project phase was way more difficult to balance with work since it also included a lot more working on off days, but everything came through in the end. Our capstone was a native app that saved the progress of your coding projects for you and played back its diffs over time, so you could easily track the progress of your code as well as scrub back to a previous version. Was a ton of fun to work on and I’ve been meaning to get back on improving it.

I chose not do to Hiring Day since I was able to successfully transition to engineering at my current company, but the classmates of mine who did were all able to successfully find new positions which is exciting. Just last week I caught up with some alumni at an event hosted at their sister school. Talking about everything from impostor syndrome to our first time deploying a feature was really amazing. Knowing that network is always there to rely on is super invaluable.

Coding on the 9-5

I made the official transition to junior software engineer in July, and it’s been a full nine months now. I work on our company’s internal CRM app for stylists so our team is much smaller, which I appreciate. I’ve been blessed to work with incredibly talented and experienced coworkers who I have so much to learn from and a well-maintained, clean codebase (something most devs don’t have the privilege of).

My first task was a full-fledged feature in the app, which I’ve since iterated on and added more features as well. It took some time getting onboarded and learning my way around Rails (something I’m still working on) but I was really proud to see something I built go live and be used and depended upon by our stylists. That addiction to seeing code change someone’s productivity or lifestyle, even in the smallest way, is singlehandedly my biggest reason for coding (yeah, sounds like a Silicon Valley spiel but it’s true). Besides that I’ve worked on more backend related tasks, which is more of a challenge so far but also a good opportunity to learn.

I find that getting into code flow is pretty difficult in an office environment, especially with tasks that require more planning/thinking than bug squashing or CSS tweaks. I’m aiming to get better at concentrating and iterating faster, starting and failing and trying again harder. It’s also been said many times but working on the tech team I do realize now how key communication is with each other, and it can easily be the downfall rather than just ‘bad code.’ I’ve heard this learning amongst many other junior devs too and it’s funny how it takes seeing it personally to fully realize.

Next Steps

The feeling of reaching a goal (in this case, becoming a full-time dev) is always strange because after a month or two of bliss, our human minds are wired to think, what’s next? It seems weird to be content and put your full effort into where you are presently, but that’s what I’m trying to focus on. I am also making time on the side to create simple side projects that I had wanted to make before Fullstack (and now can approach with much more confidence!) and practice algorithm problems. A part of me does feel insecure that I didn’t go through the multiple tech interview process that most other bootcamp devs do, so I’m trying to up those skills. I do know that the insecurity is unfounded and I am where I am because I work hard and am capable — something that slips my mind a lot of the time but I try to consciously remember.

In the mean time, I’ve been thinking about where to take this blog. It’s not so niche that it can have a consistent following really, nor is it just a personal journal since I keep that separately, but I think I’d just like to have some sort of public forum so any passersby can have a feel for my voice and my interests. On that note, with the time I have now not going to class every other day I’ve been back to working out at least 4-5x a week and am really enjoying it, thanks to Classpass! Thinking my next post will be about that :)

Letting Go

As far as I can tell, [success] is just about letting the universe know what you want and working toward it, while letting go of how it might come to pass. Your job is not to figure out how it’s going to happen for you, but to open the door in your head and when the doors open in real life, just walk through it. Don’t worry if you miss your cue. There will always be another door opening. – Jim Carrey

Over the past month at work, thanks to organizational team restructuring and supportive leadership, I have been given great opportunities to work more closely with the tech team, begin programming projects, and transition into a site optimization and developer fusion role. Words can’t even begin to describe how awed and grateful I am that just by voicing what I want and where I want to be, I’m getting the opportunities to do and be those exact things.

The trouble though with reaching goals or getting anything you want is that the happiness is quite short-lived. The doubts, insecurities and selfishness kick in almost immedately. Thoughts like the below:

  • Where is my associated reward? Recognition?
  • Why are people giving me these chances? Why do I deserve it? (aka prime impostor syndrome)
  • Why don’t I get to do these things all the time right now? Why do I still have to do old grunt work?

I’ve gotten such a rare, great opportunity to work at a company with people I love, getting to practice the skills I’m still learning and developing, with little pressure and lots of freedom — and all I was doing was whining, venting, and basically only thinking about the treasure, the instant gratification, the wild goose chase that all my dreams could possibly be solved in this moment: right here right now, with little effort.

Why am I in such a rush? Why can’t I enjoy the path to the treasure and just be thankful that doors have been opened, things are moving along well, and I am on track to great things? Why am I dying to have those great things now? And how do I even know if those great things I’m thinking I want are even things that I want?

Of course, appreciating the path and its associated triumphs and struggles just as it is is pretty difficult — so much of our life, and even more so with technology now, has been built up to glorify instant gratification. We think we deserve the world now, and we think we’ll love it when we get it. But rarely is either case true.

So this week/month/year I will remember to keep my head down, thank every person who’s touched upon my journey and has helped open doors (and God, of course, the driving force behind every open door), and remember Jim Carrey’s words — it’s not up to me how things will happen, just take the chances when they present themselves and keep chugging along otherwise.

How to be Productive

There’s no other clickbait I fall for harder than any productivity-related headline. Safe to say I read way too many productivity articles, even though they all expound on the same basic suggestions. That being said, I do think humans need certain tips pounded into their heads several times in different shapes & forms before they finally act on them. So hear it again! Here are some of the only productivity tips that work for me.

Embrace natural light.

It’s just a known fact. Natural light means better sleep, thus alertness through the day and higher productivity. Plus too much artificial light gives me headaches.

Leave the house.

No matter how great of a workspace I try to set up in every apartment, I end up getting almost nothing done at home. The temptation of having my bed less than 20 feet away is too great. Not only that, but apartments with great natural light are hard to come by (I’ve certainly never lived in one). Working in cafes or high ceiling libraries are much better environments. Plus, every time I look up distracted all I see are fellow people working!

Timebox.

Call it time block, timebox, obsessive scheduling or whatever, but it really does work. Plan every minute of your day, break it down into 30 minute chunks, and switch tasks regularly. When I started doing this I was really surprised at how much faster I accomplished tasks than I had estimated, as well as how many tasks I could accomplish in an 8 hour day (to the point where you start to think ‘hmm, I should think of more to do’).

I usually stay flexible after planning, e.g. if I go over time limit on a certain task I’ll shift things around and let it be. The important thing is to start the task and get the menial, easy to accomplish things out of the way. It’s really quite amazing how much you can get done if you just plan (and conversely, how much you won’t get done if your to do list is floating around in your head or living in checkboxes instead of on a calendar. Or if your goals are grand but too lofty to accomplish at once without breaking down into chunks).

Turn off notifications.

Though I’m definitely not at a level where I can stop checking social media or quit gchat altogether, I’ve learned to turn off notifications and block all interruptions (at least, non-work related ones) while trying to get things done. Giving into temptations of checking your phone or email is already enough. Don’t let it bother you first.

Say no.

I’m still learning this one, but you really can’t do everything. If you’re not at least 90% convinced of an idea, whether that’s a party you were invited to or a new side project collaboration, don’t do it. Same with hobbies or things you’re trying to learn, scheduled activities, and literally anything. Since getting serious about studying web dev I’ve said no a lot more to plans with friends, church meetings, fun Meetups and regular gym time – all not ideal, but necessary.

Make it as easy as possible to begin.

Pack your bags and choose your outfit the night before. Set up your workspace, Sublime editor and dev tools in advance. Write your name in the Word doc. You’ve heard it before and you will keep hearing it until the end of time, just start.

Say no to meetings! (but talk to people)

This one’s just work-related, but try to avoid any meeting where you’re not absolutely needed. Emails, one-on-one touchbases, and walking to people’s desks to have conversations is the way to go.

Write it all down (by hand).

It took me 3 years into college to finally learn how to effectively study with no one hovering or forcing me (and then the ‘A+’s rolled in! #notsohumblebrag). All it really took was me writing study notes/outlines on paper (definitely not on the computer! Don’t do that) and reading/highlighting. As more productivity apps beckon for attention, I still think the best ‘hack’ is to get down & dirty with pencil & paper - this goes for studying, planning, or any high level thought processes.

Discipline, not motivation.

Motivation is a little like runner’s high (maybe, I’ve never experienced it): it comes during & after working, not before. There will be very few times motivation to do hard tasks will strike, most likely after long stretches of time that you haven’t done work that guilt starts to motivate you. Whether I’m motivated or not, I know that Sundays and Mon/Wed nights are times for studying. Embrace habits & routine, displace waiting around for motivation.

Some tips I’m still working on:

  • Wake up early: I’d like to say this is impossible due to the very warm nature of my bed, and the very cold nature of everything not my bed (solution: wear more clothes?) But morning time is most alert & productive time, so I’d like to get in this habit.
  • Do your most challenging task first: My work responsibilities make trying this tip difficult, but on the weekends I’ve definitely found it works. Tapering off in work flow is natural, so get the hardest thing out of the way and you’ll feel great!

More reads on productivity:

  • Why procrastinators procrastinate, and how to beat procrastination (Wait but Why)
  • One of my favorite sites, catered toward creatives but really for anyone who wants to be a maker. (99u)
  • Straightforward, high impact reads on the importance of building habits (James Clear)
  • Go beyond just getting things done - access deep processing on a regular basis (Cal Newport)

Fullstack Flex Week 1

It’s already been one full week since my first day of Fullstack Flex! My cohort is comprised of 12 people, all from unique backgrounds working in different industries (tech, health, consulting, etc.) Some are looking to make a career change, but many are also just looking to expand their knowledge and learn to code to have the power to create. Everything bootcamps advertise about their students is true—students are hungry and eager to learn and all excited to be there. It’s a super refreshing environment and makes you more energized as well.

During the week we reviewed Javascript problems from Foundations, the pre-work course, and through David and Nimit’s in depth explanations I grasped so many concepts I struggled to self-teach myself. Concepts such as closure, prototypes, and inheritance became familiar, then even more confusing, then started to kind of make sense again. It was great to also begin considering runtime and avoiding expensive calls when writing code, instead of just aiming toward what works or what’s most concise.

I’m starting to feel the struggle of balancing work, class, health, sleep, and social life and know the dilemma will only get graver as the weeks go on—I’m not keeping up with at least 2 or 3 of the 5 at any given time. It’s difficult to adopt the “drop everything and go” mentality that full-time bootcampers have, mainly because the purpose of the part-time program is to give leeway and allow you to also work full time. I know I’m being selfish in wanting to be in control of everything, but understand that will lead me to lose control of most things. Better to focus on a couple at a time! At present, I would obviously like to prioritize focusing on the class while still being fully present at work during work hours, and know I should not compromise on health and sleep too much. It’s those off-day off-hours I need to optimize! Will update progress as I go along.

Speaking of off days, a huge benefit of the part-time program is the downtime you have between the days of classes. This has already proved helpful in further studying concepts you didn’t fully understand in class. For example, I was pretty confused over the difference between classical & prototypal inheritance in Javascript. I’d like to write a full post about this someday, but for the time being I’ll explain what I’ve gathered here.

  • Classical inheritance doesn’t truly exist in Javascript since there are no classes, but the new keyword and constructor functions aim to resemble classical inheritance found in many other languages. So as an example, you would have SuperUser inherit from User by setting SuperUser.prototype to User.prototype, either by Object.create or new. Both SuperUser and User are constructor functions and thus capitalized for convention.
  • Prototypal inheritance in its true Javascript form doesn’t involve constructor functions nor the new keyword. Instead, you would have a function user_prototype that has relevant functions for other functions to “share”. Then, user’s prototype is set to user_prototype using Object.create. One can also chain objects: super_user’s prototype can be set to user also using Object.create.

A powerful trait of Javascript is polymorphism, where “methods” (just functions in JS) can be overriden (ex. SuperUser’s prototype can have a method of the same name as User’s prototype, which thus overrides the User prototype method). This applies to both the classical and prototypal inheritance approach to writing Javascript. Normally in other languages with classes, this is not the case.

Hopefully the above was helpful to those stumped over inheritance! I haven’t fully grasped it but I think I’m getting there. Both the article Why Prototypal Inheritance Matters and the Mozilla documentation for JS were helpful as well.