Photo by Protos Art on Unsplash

Level Up and Launch: Week 28 Review

“ There’s always more demands than there’s time to meet them, so it’s constantly a matter of trying to balance them. ” — Marc Andreessen

Note: Starting this week I’m using a shorter review format. My aim is to reduce the amount of time I spend writing. To that end, I removed the sections “What went well” and “What can improve.” Going forward, I will abbreviate the content from those sections and include it the opening summary.

I’m into the job-seeking phase of Level Up and Launch. Although finding a job is my top priority, I’m still leveling up via my side project, React Interactive Dashboard (RID). In short, I’m content with my Week 28 progress.

On the job front, I started making contact with my network. One person got back to me with a couple of leads. Also, I applied for five jobs at companies where I have no connections. One of the companies rejected my application. Another invited me for an interview. I haven’t heard back from the other three. So, after one week, my application-to-first interview conversion rate is 20%.

Over the weekend, I put in a few hours of job-related desk research, which led me to 13 job openings. I will start applying for those opportunities this week. If my application-to-first interview conversion rate holds, I will have 2 to 3 more interviews on deck soon.

Despite a slow start, I made progress on RID. I didn’t complete my task (i.e. an indicator widget), but I’m happy with my effort, what I learned, and my workflow. In particular, I wrote failing tests before writing the implementation code.

My workflow was derived from content by Newline, JavaScript Scene, and React’s documentation. I combined the information into a generic nine-step React development plan. In Week 28, I used the plan to guide my thinking and my actions. The steps I followed are:

1. Break the app (or component) into components
2. Create types and interfaces for props
3. Build a static version of the app
4. Determine what should be stateful
5. Determine where each piece of state should live
6. Create types and interfaces for state
7. Hard-code initial states
8. Add inverse data flow
9. Add server communication

Following my development plan and writing tests first slowed me down. Skipping steps and cutting corners to move faster was tempting. But, I kept reminding myself that the extra time I was investing would pay off in the future in the form of less time spent refactoring and bug fixing. Moreover, over time, as TDD becomes second nature, I should write code faster than I ever could before.

In the evenings, I read Eric Elliott’s functional programming primer, Composing Software. It’s the first functional programming book I can read without falling asleep.

Without sacrificing rigor, Elliott discusses the key concepts in functional programming from pure functions to monads. In between, he covers higher-order functions, currying, partial applications, and functors. Elliott explains each topic using simple words and a conversational style that makes me feel like he’s sitting right next to me.

Of course, each discussion includes code samples, which make the ideas more concrete. But most important, Elliot never lets readers lose sight of the book’s main topic, composition. Elliott reiterates that, at its core, software development is composition. There are better and worse ways to compose. And, with few exceptions, functional composition trumps the inheritance-based composition of object-oriented languages.

After his treatise on functional programming Elliott switches gears to Object-Oriented Programming (OOP). So far, his discussion of OOP is as good as his discussion of functional programming. I’m keen to read more this week.

If I could improve anything, it would be my time management. Before starting Week 28, I didn’t give much thought to balancing my job search with leveling up. As a result, my schedule was erratic, which resulted in excessive context switching. It’s not a huge problem, but it’s worth solving. In my view, the key questions are:

1. Should I split time between job searching and coding or focus on one thing per day?
2. If I split time, should I code before or after job searching?

After some thought, I concluded it makes the most sense to split time each day. First, for me, coding every day is more efficient than coding every other day because it takes less time to get into a flow. Second, I get alerts about new jobs every day. In general, it’s better to be an early applicant than a later one, so postponing applications to good opportunities doesn’t make sense.

On splitting time, my policy is to do the deepest work first. Since coding is deeper than job searching, it has priority. And speaking of deep work, in Week 28, I didn’t do 10XP (i.e. 10 pomodoros of deep work per day), which was a catalyst of my pre-vacation progress.

If I combine 10XP with two hours of job searching, I will work a total of six hours per day (seven including breaks). Furthermore, each day will have the same basic structure which means less time planning, easier scheduling, and more time doing.

In summary, my continuous improvement goal is to better manage my time. To make it happen, I will take the following actions:

1. Split time between job searching and coding each day
2. Do 10XP first thing in the morning
3. Do 2 hours of job searching in the afternoon

Week 28 Goals Recap

1. Job Search: Reach out to contacts at target companies — ACHIEVED
2. Job Search: Apply for five cold opportunities — ACHIEVED
3. RID: Build indicator widget including tests — INCOMPLETE
4. Interview Prep: Review interview question lists — INCOMPLETE
5. Interview Prep: Continue Reading Composing Software — ACHIEVED
6. (Optional) HNS: Start refactoring JavaScript to TypeScript — NOT ATTEMPTED

The indicator widget is 50% to 60% complete. In short, I finished a static version. All tests are passing. My next step is making the component stateful. Then I need to add “server” communication (via JSON Server) to finish the job.

I completed both job search tasks. Still, I have several people to contact. As mentioned earlier, I applied for five job and converted one of them to an interview.

Both interview prep tasks went well. Unfortunately, I didn’t have time to review both interview questions lists. I went over my general JavaScript question list. I will go over my React questions this week.

I had no time for refactoring Hacker News Search. I doubt I will have time for it this week, so I moved the ticket back to the Level Up and Launch backlog.

Week 28 Deliverables

No deliverable this week.

Project Board

Level Up and Launch Public Project Board

Looking Ahead: Week 29 Plan

My plan for Week 29 is more or less the same as Week 28. First, I need to continue contacting people in my network. Again, my goal is to connect with people at interesting companies, determine if they have roles that are a good fit, and position myself to get interviews if they do. On the side, I will ramp sending cold applications.

On React Interactive Dashboard, I plan to finish the indicator widget. Once I’m done with the indicator widget, the next component in my backlog is a list widget, which is similar. So, I imagine there is an opportunity to reuse the indicator widget code to develop the list widget.

Finally, I will continue reading Composing Software and review my React interview questions.

Week 29 Goals:

1. Continue contacting network
2. Apply for 10 jobs (warm or cold)
3. Finish the indicator widget
4. Start the list widget
5. Review React interview questions
6. Read Composing Software

See you next week for an update on my progress.