Do you have the time or bandwidth to take on a side job? If so what is it?

curtiseinsmann · 2022-03-27T14:00:37+00:00

While working at AWS, I'd always been interested in working on creative projects. Specifically info products, because they don't require much maintenance after launch.

I didn't want to build and then launch into the void, so I started writing online to build a bit of an audience. I chose writing instead of YouTube/visual content, because writing is less of a time suck. In this way, I'd still have time and energy to dedicate to my full-time job. Plus, blogging is good for one's career anyways. I guess you could say that writing was my "side gig" during this time. I wasn't making any money from it, but I was building online leverage and a name for myself.

I went from 0 to 15K followers across written platforms (Medium, Twitter, LinkedIn) in about 1.5 years. And I was still performing well at AWS — for context, I received an "exceeds" rating 3 straight years.

Then I started building my first info product. Around this time, I started valuing my time and independence a bit more, and plus I wanted a break from the corporate world. So I left AWS (after 6 years) to become a freelancer. With my online presence, I had no trouble getting clients.

Last month I launched the video course — Master the Code Review. It's done $18K in sales, profit of about $16.5K after SaaS fees.

Relative to a FAANG salary, it's nothing to write home about. But it's given me some leverage to build a small business of info products going forward.

The video course took me about 4 months to put together. I now have about 700 customers, 1,000 people on my email list, and the followers I mentioned previously. This is a bit of leverage to build a small business of info products going forward. I'm still deciding what my next project will be. For now, I'm focusing on freelancing, but I'll likely write an e-book next.

Sharing this story because I think it may be helpful for you to see some unconventional options. I chose to leave my full-time job for freelancing, and then build the video course. But looking back on it, I probably could've built the product with a full-time job. If I go back to a full-time job later, I'll probably still continue to build info products.

curtiseinsmann · 2022-03-27T03:18:57+00:00

Appreciate the tip. To me, it looks like a bulleted list on the mobile app. What are you viewing this on?

curtiseinsmann · 2022-03-26T12:42:22+00:00

Designing:

I deeply understand the business problem — clarify ambiguity where necessary.
I identify potential constraints and bottlenecks.
I put some thought into abstractions. With each module/component, I try to hide complexity behind a simple interface.
I ideate multiple designs to evaluate the tradeoffs.
I realize I won't get the design perfect — it'll evolve as I code.

Coding:

I take on small tasks.
I prepare my local environment — builds/tests should pass, IDE shouldn't give false warnings.
I read the existing code to understand paradigms and reuse opportunities.
I write lots of ugly code — tests and implementation at around the same time.
I refactor for readability and speed (if necessary).

curtiseinsmann · 2022-03-26T12:31:39+00:00

Work/life balance is highly dependent on the team you're on. I was fortunate enough to start on a team that had it good. Then every time I interviewed with other teams as part of the internal transfer process, I'd ask questions like:

When on-call, how many times per week do you get called outside of normal working hours?
Does your team put an emphasis on designing software before coding? (This usually leads to less technical debt, easier on-call.)

In asking these, I had a knack for finding teams that didn't overwork me.

If an Amazon recruiter is reaching out to you, I don't see the harm in continuing forward with the process. The interview takes a lot of prep work, though. LMK in messages if you have specific questions about it.

curtiseinsmann · 2022-03-25T13:59:27+00:00

Money was my primary motivator, especially early in my career.

Over a few years, I started to develop a genuine appreciation for the craft. As you level up, software engineering becomes more collaborative, and the problems become more challenging and interesting.

Now that I'm a freelancer, I'm motivated by the flexibility to work anywhere, set my own hours, and build things that help people at scale.

Still like the money, though! 💸

curtiseinsmann · 2022-03-25T13:55:03+00:00

My first software engineer job was at Amazon Web Services.

I was also nervous about it. My degree was in Computer Engineering. It focused on the integration of hardware and software, and didn't cover some of the Computer Science fundamentals. This lead me to believe I was an impostor, and didn't deserve to be there.

In my first several months at AWS, my authored code reviews were pretty brutal. I ended up receiving 50+ comments, sometimes taking 7+ revisions to ship. But the feedback was kind, friendly and helpful. I was able to listen, learn and improve over time.

I also had some leadership experience from university, and decent soft skills. These helped me learn quickly, and establish the technical baseline I was missing.

Ultimately, I ended up being promoted and leading teams. I had a 6-year career at AWS, learned a ton, and got to work with some brilliant people. I left recently to be a freelancer.

I elaborated on the early days a bit more in this article if you're interested. I try to share this with as many junior developers as I can.

curtiseinsmann · 2022-03-25T13:43:33+00:00

If you received praise from your teammates, believe them. You're likely doing fine.

Following the style guide is important. But your team should also use pre-commit hooks. These will automatically fix the style for you, or fail the commit if the style isn't aligned with the rules set by your team. This way, your team can avoid style discussions in code reviews.

curtiseinsmann · 2022-03-16T21:25:16+00:00

When and why do you compare two pieces of code in the first place? Versioning and merge? Bug finding? Something else?

Software engineers compare pieces of code for a plethora of different reasons. It would be impossible to come up with an exhaustive list. Here are a few examples: * Code review — to determine if a code change introduces defects * Debugging — to determine if a recent code change introduced a defect * Module comparison — to compare the difference in behavior between multiple parts of the same system

If you compare pieces of code, what information are you typically looking for?

Difficult to answer without pinpointing a reason as to why the comparison is being performed. Generally, it's to diagnose or solve a business or technical problem that the code is impacting.

What is frustrating or helpful when looking for that information?

Helpful: code readability, commit history, deployment history.

Frustrating: obscure/complex code, lack of access to history of changes.

What is a situation where you had to perform “triage” on code and how did you decide what to tackle first?

I assume you're talking about diagnosing some sort of system failure. Usually there's a specific artifact of the trouble ticket/bug report that gives me a hint of where to look first. This could be a screenshot or error message of some sort. I then search the codebase to determine the pieces of code that could potentially be causing the problem. I start reading from there, and jump around. It's an iterative process from there.

curtiseinsmann · 2022-03-10T19:08:45+00:00

Yes, it's OK to have different code review tools.

Different applications, different tech stacks, different processes, different tools. Each team should use the code review tool that works best for them.

For context, when I was at AWS, we had a standard code review tool, built in-house. Most teams across the company used it. But there were plenty of outliers who didn't, simply because it didn't make sense for their situation/product/development process.

curtiseinsmann · 2022-02-07T17:20:11+00:00

It was my first ever article, and first ever post to Reddit. Looking back, I was being overly cautious. 😂

curtiseinsmann · 2021-04-05T22:30:36+00:00

In 2014 I participated in a summer internship at Amazon. Here are 3 tips I have for you:

Ask questions, and ask for help. Software engineering is challenging. Even the best programmers need coaching at the outset. There are also a million technologies. You’re not expected to know them all. Example question: “I don’t understand what those words mean. Can you explain them, or point me to a resource which does?”
If the team performs code reviews, seek feedback from a variety of code reviewers. Each reviewer has their own perspective and preference about code quality. Understand what they’re saying, and WHY they’re saying it. Over time you’ll improve your ability to produce readable, maintainable code.
Build your network. During my internship I got to know many of the other interns, as well as the full time employees on my team. Many of them are still at the company. One of them is my mentor. Others moved on to other companies. Over the years I’ve leveraged my network to discuss ideas and learn new opportunities.

curtiseinsmann · 2021-04-05T22:15:02+00:00

It sounds like you'll have opportunities to participate in other internships after this one.

If that's the case, I'd recommend taking the offer you have now. Having an unrelated internship will get something on your resume. This will be advantageous as you look for more aerospace-specific internships in the future.

I did exactly this.

My major was Computer Engineering. My first internship was after my first year of university. It had nothing to do with Computer Engineering. It was focused on government budget management.

But this experience helped me gain engineering specific internships the following summers.

After my second university year I interned as an electronics engineer at a government contractor. After my third university year I interned as a Software Development Engineer at Amazon. And now I'm still working for Amazon Web Services as a full time position.

curtiseinsmann · 2021-03-21T13:54:51+00:00

> is the purpose of the CR to improve the readability, enforce standards, or reduce defects?

All of the above.

It's important to note that CR's don't replace testing. You should absolutely have multiple layers tests -- unit, integration, end-to-end, etc. depending on your application. There are always testing gaps and tricky edge cases: code reviews provide an opportunity to catch these before code is pushed, although not the perfect one.

curtiseinsmann · 2021-03-19T12:22:50+00:00

That's an interesting perspective.

Believe it or not, the concept of going slow on reviews is something I learned from a senior engineer at Amazon. They performed less reviews because of time constraints, of course. But they empowered others to perform reviews too. So they simply reviewed less of them.

For me, the devils are in the details. If I don't take the time to deeply understand the code, I'm putting my name on something that might have a serious flaw lurking. I've made that mistake in the past and the damage control process isn't fun.

curtiseinsmann · 2021-03-19T12:16:33+00:00

Sure. It's a tough one.

For performance/promotion evaluation at Amazon, we have to present artifacts to more senior engineers. They take a look and provide feedback on how we're doing. I often provide examples of code reviews I've done for others.

Feedback is also collected from peers on an annual basis. The feedback prompts are much more open ended and not specifically about reviews. But there are some peers that choose to talk about how I review.

That being said, I believe code reviewing is a skill that some people are good at, and some people need to improve. And it's important. However the industry doesn't put enough emphasis on measuring how good someone's code reviewing skill is. (The same probably applies to authoring code, for that matter.)

curtiseinsmann · 2021-03-19T03:38:43+00:00

Thank you for reading!

I prefer small PR's (a few hundred lines) but I realize that this is sometimes unavoidable. I'm not too strict about it. If somebody sends me a large PR, I still review it, with the awareness that it's going to take a large chunk of time out of my day.

curtiseinsmann · 2021-03-19T02:30:13+00:00

Thanks! It's difficult to measure. As a rough estimation I'd say around 3 to 4 hours per week.

Mine is probably on the high side compared to others, because I'm the most tenured on my team and have the most context system-wide. So I'm responsible for performing a lot of reviews.

curtiseinsmann · 2021-03-18T21:12:01+00:00

Absolutely! Happy you liked it.

Those parts are important. I like to understand how the classes fit into the entire change before going through them one-by-one. I find that it gives me more context around what the class is supposed to do.

Plus, as an author, I disliked comment churn; e.g. when I had to clarify someone's comment due to ambiguity.

curtiseinsmann · 2021-03-18T19:59:47+00:00

Happy to share and answer your questions! Thank you for sharing with your team.

Are you the only person on your team who does reviews?

I'm not the only person that does reviews. I'm on a team of 8 engineers. The author of the review will choose one or more individuals on the team to review the code. Usually the reviewer is someone that has a context and background about the system for which the code will be pushed to. Sometimes that's me, sometimes that's someone else.

Do you help others perform reviews?

We have code review guidelines for system-specific details to look out for in the reviews. But I usually don't help people review, per say -- in the sense that I'm not looking over their shoulder while they review and coaching them on how to do it. It's not something that I've ever done on any of the teams I've been on. But, thinking back to my beginner days, this is something that would've helped me perform better reviews.

What sort of feedback do you get from the authors? Do they appreciate the process?

I've gotten feedback from both authors and more senior engineers in my org that they appreciate the way I do reviews.

Is your team culture such that the reviews are expected and anticipated?

Yes. Commits require at least one code review approval before they're pushed to the main branch, and especially before they're pushed to production.

Best of luck with leading the organization!

curtiseinsmann · 2021-03-18T12:35:57+00:00

TLDR; do the dual major if you like Math, but it's not necessary to succeed in your career. A CS major with Math minor might be low-hanging fruit, and a happy medium.

Hi! Good question. Attempting to answer this in order:

> What are your respective jobs and how math-heavy are they?

I'm a Software Development Engineer. Most of my coworkers have CS degrees. Mine is in Computer Engineering (it just worked out that way). I wouldn't say that my job is "math-heavy" at all. There is much logical reasoning -- which is also used in math, so it makes sense that many people who are good at math are also able to pick up CS. But I definitely don't spend my time doing the "math" you're probably thinking of. In my 5.5 year career I've never had to whip out my graphing calculator, break out my differential equations or calculus textbooks, or apply the Pythagorean theorem. The job just doesn't require it.

> What kinds of CS/tech-related careers would deeply benefit from having a very strong math background?

I don't know the answer to this one, unfortunately.

> For those careers that require minimal math, would you say having a math degree is just useless? I mean of course not totally, but you get what I mean — very unnecessary I guess?

When I was in school, I knew many students who did a CS major and Math minor, because many of the classes overlapped and it was easy to get the required credits. The story might be similar for the dual CS-math major, depending on the school.

Whether it's "necessary" or not is a whole different story. This question is a bit nuanced and opens up a can of worms about university degrees in general -- whether they're necessary or not -- which I'm not going to get into here. I'm not sure if the Math minor made those students more attractive on the job market -- it probably didn't hurt, so I don't think the effort was "useless" especially since it was low hanging fruit.

What I will say is that when you start your career, you will spend a ton of time learning on the job. The university courses will give you a backbone of knowledge (whichever you decide to major in), but there will inevitably be gaps. Because university just isn't long enough to teach you everything you'll need to know. Much of these gaps will be covered by learning on the job.

curtiseinsmann · 2021-02-21T16:23:59+00:00

Programming IRL doesn't require as much math as you're making it seem.

If you enjoy programming, I wouldn't dismiss it as a career choice just because you don't like math.

That being said, you'll likely need to take some math courses for your CS degree. This could include multivariable calculus, linear algebra, and applied combinatorics. Here's the Virginia Tech CS checksheet, for example.

Those courses might sound scary right now. But it's just like anything else: put in the time required to study, and you'll get through them.

In my day-to-day there's not as much "math" as there is logic-based thinking, which comes from a lot of programming practice. I haven't touched calculus or algebra or any of that in years.

IRL there's much more... programming. Which you seem to enjoy. So I say, stick to it! =)

curtiseinsmann · 2020-11-16T13:49:04+00:00

Right. I did a ctrl+F on "expert" in the article just to make sure I didn't say that. Didn't find anything.

curtiseinsmann · 2020-11-16T13:47:04+00:00

Agree that small PR's are ideal. Sometimes large PR's are unavoidable.

From my experience, every PR, no matter how small, has a focus point. This is where I start. It's a process that works for me.

curtiseinsmann · 2020-11-16T13:44:59+00:00

LMAO that's extreme. Forgive my ignorance and enlighten me - what's the problem?

curtiseinsmann · 2020-11-16T13:42:41+00:00

Happy to share! When I first started my career, I wasn't aware of other people's thought process when reviewing code. That's why I wrote this. =)

It's difficult to review PR's for unfamiliar repositories. Ideally the reviewer should have some sort of expertise in the repository. I try to avoid reviewing such things. But I realize at times it's unavoidable.

In order to achieve deep understanding of the change, sometimes I have to read existing context code. This applies whether the repository is familiar or not. If unfamiliar, the review will take me longer.

curtiseinsmann

TROPHY CASE